OpenRuche – BeeBrave

Introduction

As global bee populations face unprecedented declines, beekeepers need reliable, non‑intrusive ways to monitor hive health. Traditional hive inspections—opening boxes and visually assessing frames—can stress bees and require frequent site visits. BEEBRAVE addresses these challenges by delivering a self‑sustained, solar‑recharged, long‑range monitoring station that reports environmental conditions wirelessly. In one compact package, it measures multiple parameters and transmits them over LoRaWAN to The Things Network, allowing beekeepers to intervene only when necessary.

Materials & Component Selection

At the heart of BEEBRAVE is an Arduino MKR WAN 1310, chosen for its integrated LoRa radio and ultra‑low‑power features. Around it we assembled:

HX711 + load cell: 24‑bit ADC for precise hive weight measurement.

DHT22 (external) & DHT11 (internal): Digital temp/humidity sensors to contrast external weather with in‑hive climate.

DS18B20 (OneWire probes): Waterproof temperature sensors placed near brood frames

VEML7700: High‑sensitivity I²C light sensor to log ambient lux.

Nano 33 BLE Sense: Onboard microphone plus edge‑AI model to detect queen‑specific buzz patterns.

Power subsystem: 1050 mAh LiPo battery topped by a small solar panel via a LiPo Rider Pro, with a REG09P regulator to switch sensors on only during measurement.

Wiring Diagram

BEEBRAVE’s wiring topology is straightforward:

I²C bus: VEML7700 → SDA/SCL

OneWire bus: DS18B20 probes share pin D4 (with 4.7 kΩ pull‑up)

UART: Nano 33 BLE Sense → MKR WAN 1310 RX/TX

Analog input: Battery voltage divider → A1

Digital I/O: DHT22 → D3, DHT11 → D2, HX711 → D6 (DT) & D7 (SCK)

Regulator shutdown: SHDN control → D5

Refer to the following schematic for pin‑to‑pin connections :

Software Implementation

1. Sensor Readings

In each cycle, loop() powers up the sensor bus by toggling the regulator, reads every sensor, packages the data, then shuts down and enters deep sleep.

2. LoRaWAN Communication

We use OTAA (Over‑The‑Air Activation) for secure, flexible network joins. AppEUI and AppKey are registered in TTN before deployment. On startup:

3. Payload Encoding & TTN Decoder

Each float is converted to four bytes using a union:

Final payload layout (bytes 0–39) :

"DHT11 temp - DHT11 humidity - DHT22 temp - DHT22 humidity - VEML7700 lux - DS18B20 left temp - DS18B20 right temp - HX711 weight - Battery voltage - Queen‑presence float"

On TTN, add this JavaScript decoder:

function Decode(f) {
  const data = f.bytes;
  function getFloat(start) {
    return new DataView(new Uint8Array(data.slice(start, start+4)).buffer).getFloat32(0, true);
  }
  return {
    dht11_temp: getFloat(0),
    dht11_hum:   getFloat(4),
    dht22_temp: getFloat(8),
    dht22_hum:   getFloat(12),
    lux:         getFloat(16),
    broodTempL:  getFloat(20),
    broodTempR:  getFloat(24),
    weight:      getFloat(28),
    battV:       getFloat(32),
    queenProb:   getFloat(36)
  };
}

Power Management

Between measurement windows, the system:

Disables all sensors via the regulator shutdown pin (SHDN_PIN).

Enters ArduinoLowPower.deepSleep(…) for 10 minutes.

This duty‑cycling slashes idle current by over 80 %, enabling multi‑day autonomy on the LiPo/Solar pack.

Enclosures & Physical Installation

DHT22 (external)A 3D‑printed PLA housing with vertical slits for airflow and an extended overhang to repel rain. Mounted under eaves or shaded hive walls.

DHT11 (internal)A simple case inside the hive’s upper brood chamber, avoiding direct contact with bees or condensation.

Nano 33 BLE SenseCustom box with microphone port to protect against humidity while letting sound through.

Cable managementExternal sensor wires bundled in heat‑shrink tubing and sealed with silicone at entry points to keep moisture and insects out.

PCB Design

The custom PCB consolidates connectors and protects against wiring errors:

Power plane: thick 3.3 V traces from regulator OUT to sensor headers.

Ground pour: minimizes analog noise for the HX711.

Header layout: labeled I²C, OneWire, UART, analog, and regulator SHDN.

Mounting holes: align with hive base screws for secure installation.

Experimental Results

Field Test Campaign• Duration: 3 weeks• Location: rural apiary, variable weather (5–25 °C)

Sample Data

Temp & Humidity (24 h): day/night cycles clearly visible, internal stability vs. external swings.

Weight evolution: gradual increase during nectar flow; drops align with forager return times.

Battery autonomy: average 4 days without sun; solar recharge restored full capacity in ~3 hours of bright daylight.

Luminosity: : the sensor recorded 0 lux at night, with a steady increase at dawn and peaks around 14:00–15:00 reaching up to 16, 000 lux, confirming its sensitivity to natural light.

Sound : the sensor outputs a binary value indicating the queen's presence (1) or absence (0); data shows that during nighttime, the queen is detected less frequently inside the hive, suggesting reduced activity or movement during those hours.

Limitations & Future Improvements

1. Technical Limitations of the Current Prototype

Despite the promising results from BEEBRAVE's deployment, several technical challenges emerged during field testing:

• DHT22 reliability: The external temperature and humidity sensor (DHT22) occasionally returned unstable or missing values, even after replacement. Similar issues reported by other teams suggest that this sensor may not be suitable for long-term outdoor use.
• Wiring and soldering issues: Manually assembled connectors led to communication errors due to weak or faulty solder joints. A transition to a fully custom PCB with secured headers would significantly enhance the system’s durability and ease of maintenance.
• LoRaWAN connectivity problems: While most MKR WAN 1310 boards connected to The Things Network without issue, a few units consistently failed to join the network. After extended debugging, the issue was traced to faulty hardware and resolved by replacing the board. This highlights the need for pre-deployment hardware testing procedures.

2. Limitations in the AI-Based Queen Detection

The Nano 33 BLE Sense runs an embedded model that predicts the presence of the queen based on hive sound patterns. While this model performs well under controlled conditions, several limitations were observed in the wild:

• Lack of "non-relevant" sound rejection: When environmental noise is captured (e.g., rain, wind, human voices), the model still outputs a probability between "queen present" and "queen absent", even though no bee-related sounds are present.Why not just add a third “noise” class?We tested this approach by adding a "noise" class to the model. However, the model quickly overfit to that class and began classifying nearly everything as "noise".This is likely due to the high variability of noise samples from the ESC-50 dataset (rain, traffic, talking, wind...), making it difficult for the model to extract consistent features. Some of these features also appear in bee-related sounds, causing misclassification.

3. Improvement Opportunities

➤ Power Optimization

• Smaller payloads: Encoding floating-point sensor values using fewer bytes or quantizing the data would reduce the payload size and lower energy consumption during LoRaWAN transmission.
• Adaptive duty cycle: Instead of measuring at fixed intervals (e.g., every 10 minutes), a smarter, event-driven strategy could trigger measurements only when significant changes are detected, such as sudden hive weight drops or unusual sound patterns.

➤ Enhanced AI Architecture

To improve robustness, we propose a two-stage inference pipeline for queen detection:

• Model 1: Determine whether the input sound is environmental noise or bee-related buzzing.
• Model 2: If a buzzing sound is detected, classify the queen status as "present" or "absent".

This layered approach filters out irrelevant inputs early on and ensures that queen predictions are only made when valid bee sounds are present.

➤ Audio Dataset Expansion

To close the gap between training conditions and real-world inference:

• We plan to collect more sound samples using the onboard microphone, under real hive conditions. This ensures the model is trained on data similar to its actual deployment context.
• Data labeling will be refined, with precise annotations such as “queen present, ” “queen absent, ” and “background noise, ” to help the model generalize better.

➤ Integration of Additional Smart Sensors

Adding complementary sensors could unlock new insights:

• Vibration sensors to detect wingbeat patterns
• CO₂ sensors to estimate hive metabolic activity

Low-power cameras for swarm detection or visual verification