Choice of processor chip

The first Gratheon beehive sensor kit should optimize for DIY availability, simple firmware support, and enough power for HTTPS telemetry. That makes ESP32-WROOM DevKit the default MVP choice.

Production decision: the Phase 3 pod uses an ESP32-S3-MINI-1 module on a carrier PCB. It has enough GPIO for the LoRa option and the Robotic Beehive UART, native USB for factory flashing and BLE for phone setup. See the product description.

Recommendation

Chip / board Networking Strength Weakness Gratheon use
ESP32-WROOM DevKit WiFi, BLE Very common, cheap, Arduino-supported, enough RAM/CPU for TLS + HX711 + sensors + deep sleep. Dev boards are not the lowest-power option; quality varies by clone. Default DIY MVP.
ESP32-C3 WiFi, BLE Lower cost/power, RISC-V, modern Espressif support. Fewer pins/peripherals; less headroom for future audio/ML. Second supported board after MVP firmware stabilizes.
ESP32-S3 WiFi, BLE More RAM/CPU and USB; better for future audio/TinyML experiments. More expensive than needed for a scale. Acoustic/edge-ML prototypes, not base scale.
ESP8266 WiFi Cheap and proven for simple telemetry. Older, less RAM, weaker TLS/support path. Only for community ports, not official first kit.
STM32 / GD32 + radio Depends on module Stable embedded platform, good for custom low-power PCB. Adds radio/module complexity and toolchain support burden. Defer until custom PCB.
RP2040 + radio Depends on module Great tooling and IO. No native WiFi on plain RP2040; higher integration burden. Not recommended for MVP.
nRF52 BLE Excellent low-power BLE. Needs gateway; not ideal for direct internet telemetry. Useful for future sensor nodes, not first WiFi kit.
Arduino Mega / ATmega None Familiar educational board. Needs extra networking, too bulky/power-hungry. Avoid for product.

Connectivity decision rule

  1. WiFi first for the public DIY kit: simplest onboarding and cheapest support.
  2. ESP-NOW or LoRa gateway second for apiaries where multiple hives are near each other but there is no WiFi at every hive.
  3. LTE-M/NB-IoT cellular last for paid remote-field kits because modems, antennas, SIM provisioning, and power management raise complexity and cost.

Firmware implications

  • Keep a single firmware codebase with board-specific pin maps.
  • Default outdoor reporting interval should be 10–15 minutes; 1 minute is useful for demos but wastes battery.
  • Use deep sleep between readings and power-gate the HX711/sensors where possible.
  • Store WiFi, endpoint, hiveId, API token, send interval, and calibration factor in non-volatile memory.
  • Send JSON to POST /iot/v1/metrics with timestamp and dedupeKey so retries are safe.

Potential sources