1) What this board is best at

The Beetle ESP32 is ideal when you want ESP32 capability (WiFi + Bluetooth, strong CPU, good RAM) in a small footprint, with quick wiring options that suit prototypes and wearables.

Great use cases

• Wearable sensors: motion, heart rate, temperature, step detection, basic telemetry
• Small IoT nodes: WiFi telemetry, MQTT sensors, simple web dashboards
• Bluetooth projects: BLE beacons, phone-controlled gadgets, proximity triggers
• Compact controllers: small enclosures, robotics modules, instrument panels

Less ideal use cases

• High-power motor control directly (you still need drivers and separate power rails)
• Precision analog measurements without good analog design (WiFi/BLE radios add noise unless designed carefully)
• Projects requiring many I/O pins (this board is compact; I/O is intentionally limited)

2) Specs that matter for real projects

These are the practical constraints you should design around:

• CPU: Dual-core Tensilica LX6, up to 240MHz
• SRAM: 520KB
• Flash: 16Mbit
• WiFi: 2.4GHz 802.11 b/g/n (up to 150Mbps class link rate)
• Bluetooth: v4.2 BR/EDR + BLE
• USB supply: 5.0V via Micro USB
• VIN supply: DC 3.5V–6.5V
• Form factor: 35mm × 34mm
• I/O provided on board labeling: 4 digital, 4 analog, plus I2C and 1 serial port exposed

3) Powering correctly (USB vs VIN) and avoiding brownouts

3.1 Recommended approach: power by Micro USB (5V)

For development and most stable operation, power by Micro USB from a decent USB charger or a powered USB port.

3.2 VIN power (3.5–6.5V)

If you need battery or embedded power, VIN allows DC input in the specified range. For example:

• Single-cell Li-ion/LiPo (3.0–4.2V) can be workable depending on your design margin (often with a regulator and protection).
• 5V rail from a buck converter is commonly used for stable power under WiFi bursts.

3.3 Avoiding resets (brownouts) when WiFi/BLE transmits

• Use a stable supply with headroom (WiFi current spikes are real).
• Add a bulk capacitor close to the board if wiring is long (e.g., 100µF–470µF).
• Do not power motors/relays/solenoids from the Beetle’s power rail. Use separate supplies; share ground.
• For wearable builds: battery + regulator + proper decoupling beats “random USB power banks” for stability.

4) I/O overview (digital, analog, I2C, UART)

4.1 Digital I/O

The board exposes a small set of digital pins (labeled D2, D3, D4, D7). These can be used for: buttons, LEDs, MOSFET drivers (logic-level), chip-selects, interrupts, etc.

4.2 Analog inputs

The board exposes analog inputs (A0–A3). These are useful for: battery voltage (via divider), potentiometers, analog sensors, and simple instrumentation.

4.3 I2C (recommended expansion bus)

Because I/O is limited, I2C is the best way to attach multiple sensors and displays with minimal pin usage: OLED displays, IMUs, RTCs, temperature sensors, environmental sensors, port expanders, etc.

4.4 UART (serial port)

UART is used for GPS modules, RS485 adapters, external microcontrollers, and device-to-device debugging. It is also excellent for separating debug logs from application serial devices (depending on how you wire your system).

5) Programming with Arduino IDE (recommended for most makers)

5.1 Install ESP32 board support

1. Install the Arduino IDE.
2. Open Boards Manager and install ESP32 by Espressif Systems.
3. Select an ESP32 board profile. If you don’t see a Beetle-specific profile, choose a compatible generic ESP32 profile (often ESP32 Dev Module).

5.2 First bring-up: Blink

Pick one available digital pin (per your board labels) and blink an LED (external LED recommended so you know exactly what you’re toggling).

/*
  ESP32 Blink (external LED)
  Wire: LED + resistor to a chosen digital pin and GND.
  Adjust LED_PIN to match a pin you wired (e.g., D2 label on the Beetle board).
*/
const int LED_PIN = 2; // change to your actual GPIO mapping / chosen pin

void setup() {
  pinMode(LED_PIN, OUTPUT);
}

void loop() {
  digitalWrite(LED_PIN, HIGH);
  delay(250);
  digitalWrite(LED_PIN, LOW);
  delay(250);
}
    

6) Programming with ESP-IDF (for production-grade firmware)

If you are building a commercial-grade IoT device or want maximum control (partitioning, secure boot, OTA strategy, logging), Espressif’s ESP-IDF is the canonical toolchain.

ESP-IDF is worth it when

• You need robust OTA with strong versioning and rollback
• You need FreeRTOS-level task control and careful performance
• You need advanced WiFi/BLE features and better diagnostics
• You are building a product, not just a prototype

7) WiFi patterns (connect, HTTP, NTP time, simple web server)

7.1 Connect to WiFi (station mode)

#include <WiFi.h>

const char* WIFI_SSID = "YourSSID";
const char* WIFI_PASS = "YourPassword";

void setup() {
  Serial.begin(115200);
  delay(200);

  WiFi.mode(WIFI_STA);
  WiFi.begin(WIFI_SSID, WIFI_PASS);

  Serial.print("Connecting");
  while (WiFi.status() != WL_CONNECTED) {
    delay(300);
    Serial.print(".");
  }
  Serial.println();
  Serial.print("Connected. IP: ");
  Serial.println(WiFi.localIP());
}

void loop() {
}
    

7.2 HTTP GET to a server endpoint

#include <WiFi.h>
#include <HTTPClient.h>

const char* WIFI_SSID = "YourSSID";
const char* WIFI_PASS = "YourPassword";

void setup() {
  Serial.begin(115200);

  WiFi.mode(WIFI_STA);
  WiFi.begin(WIFI_SSID, WIFI_PASS);
  while (WiFi.status() != WL_CONNECTED) delay(300);

  HTTPClient http;
  http.begin("http://example.com/iot/ping?device=beetle-esp32");
  int code = http.GET();

  Serial.print("HTTP code: ");
  Serial.println(code);

  if (code > 0) {
    Serial.println(http.getString());
  }
  http.end();
}

void loop() { }
    

7.3 Simple web server (status page)

#include <WiFi.h>
#include <WebServer.h>

const char* WIFI_SSID = "YourSSID";
const char* WIFI_PASS = "YourPassword";

WebServer server(80);

String page() {
  String h = "<!doctype html><html><head><meta name='viewport' content='width=device-width,initial-scale=1'>";
  h += "<title>Beetle ESP32</title></head><body style='font-family:Arial;padding:16px'>";
  h += "<h2>Beetle ESP32 Status</h2>";
  h += "<p>IP: " + WiFi.localIP().toString() + "</p>";
  h += "<p>RSSI: " + String(WiFi.RSSI()) + " dBm</p>";
  h += "</body></html>";
  return h;
}

void setup() {
  Serial.begin(115200);

  WiFi.mode(WIFI_STA);
  WiFi.begin(WIFI_SSID, WIFI_PASS);
  while (WiFi.status() != WL_CONNECTED) delay(300);

  server.on("/", [](){ server.send(200, "text/html", page()); });
  server.begin();
  Serial.println("HTTP server started.");
}

void loop() {
  server.handleClient();
}
    

8) Bluetooth patterns (BLE beacon + phone connectivity)

8.1 BLE “advertising” concept (beacon-like)

A simple BLE advertising approach lets you broadcast a device identity and a small payload (like a sensor state). For phone integration, you typically build a simple mobile app or use a BLE scanner tool.

/*
  BLE advertising example (concept)
  Requires the ESP32 BLE Arduino library (commonly included via the ESP32 Arduino core).
*/
#include <BLEDevice.h>
#include <BLEServer.h>
#include <BLEUtils.h>

void setup() {
  Serial.begin(115200);

  BLEDevice::init("Beetle-ESP32");
  BLEAdvertising* adv = BLEDevice::getAdvertising();
  adv->setScanResponse(true);
  adv->start();

  Serial.println("BLE advertising started.");
}

void loop() {
  delay(1000);
}
    

9) I2C sensor example (recommended expansion approach)

Because the Beetle ESP32 is compact with limited pins, I2C is typically the cleanest way to add sensors. Below is a generic I2C scan sketch to confirm wiring and discover device addresses.

#include <Wire.h>

void setup() {
  Serial.begin(115200);
  Wire.begin(); // uses default SDA/SCL for your board mapping

  Serial.println("I2C scan...");
  for (byte addr = 1; addr < 127; addr++) {
    Wire.beginTransmission(addr);
    if (Wire.endTransmission() == 0) {
      Serial.print("Found device at 0x");
      Serial.println(addr, HEX);
      delay(5);
    }
  }
  Serial.println("Done.");
}

void loop() { }
    

10) UART example (GPS/RS485/Serial device integration)

ESP32 supports multiple UARTs. A typical pattern is: keep Serial for debug, and put your module on Serial1/Serial2. The exact pins depend on how you wire and configure it.

/*
  UART passthrough concept:
  - Serial  : USB debug console
  - Serial2 : external device (GPS/RS485 TTL module)
*/
HardwareSerial ExtSerial(2);

void setup() {
  Serial.begin(115200);

  // Example pins (adjust to your wiring). ESP32 allows pin remapping.
  ExtSerial.begin(9600, SERIAL_8N1, 16, 17); // RX=16, TX=17 (example)

  Serial.println("UART bridge started.");
}

void loop() {
  while (ExtSerial.available()) Serial.write(ExtSerial.read());
  while (Serial.available())    ExtSerial.write(Serial.read());
}
    

11) Wearable build tips (threads, strain relief, power strategy)

This board’s gold-plated pads are designed to make “non-solder” connections easier, including sewing into fabric with conductive thread. If you’re building wearables, treat it as a mechanical engineering problem as much as electronics.

11.1 Mechanical robustness

• Strain relief: do not rely on the pad joint to carry mechanical load. Stitch/glue cables down near the board.
• Flex points: avoid placing the board on a bend line (elbow/knee areas). Put it on a flatter area (upper arm, chest strap).
• Encapsulation: use conformal coating or a thin enclosure to protect against sweat and abrasion.

11.2 Power strategy for wearables

• Use a protected LiPo + proper regulator/charger module if needed.
• Design for duty-cycling: short WiFi bursts, then sleep.
• Prefer BLE for continuous low-energy phone interaction; use WiFi only when uploading batches of data.

12) Reliability best practices (watchdog, reconnection, state machines)

IoT reliability does not happen by accident. Use these patterns:

• State machines: IDLE ? CONNECT_WIFI ? RUN ? ERROR_RECOVERY
• Timeouts everywhere: WiFi connect timeout, HTTP timeout, MQTT reconnect backoff
• Non-blocking loops: keep the main loop responsive; avoid long delays that starve networking tasks
• Watchdog strategy: if the device gets stuck, it must self-recover
• Telemetry + logs: emit a heartbeat and reset reason to help diagnose field issues

13) Security minimums for IoT

• Never ship default credentials (WiFi, admin endpoints, OTA passwords).
• Use HTTPS/TLS when practical; if you must use HTTP internally, lock it to your LAN and segment networks.
• Do not expose raw control endpoints to the public internet (put devices behind a broker or VPN/Zero-Trust gateway).
• Firmware update discipline: versioning, rollback plan, and a controlled release process if you deploy multiple devices.

14) Troubleshooting (symptoms ? causes ? fixes)

Symptom: Board doesn’t appear on USB / cannot upload

• Try a different Micro USB cable (data-capable; many are charge-only).
• Try another USB port and avoid unpowered hubs.
• Verify you selected the correct ESP32 board profile and correct COM port.

Symptom: Random resets, WiFi connects then drops, boot loops

• Power supply instability (WiFi bursts): improve supply, add bulk capacitance, shorten power wiring.
• Motors/relays sharing the same rail: separate power domains; share ground.
• Firmware blocking: remove long delays; use a state machine; add timeouts.

Symptom: GPIO reads wrong or behaves inconsistently

• Wrong pin mapping (Dx/Ax label not equal to GPIO number): confirm mapping for this exact board revision.
• Using 5V signals on 3.3V GPIO: level shift or use compatible modules.
• Floating inputs: enable pull-ups/pull-downs or add external resistors.

Symptom: I2C scan finds nothing

• SDA/SCL pins wrong for this board mapping.
• Sensor not powered or wrong voltage.
• Missing pull-ups (some boards/modules include pull-ups; some do not).

15) Quick checklist (copy/paste)

DFRobot Beetle ESP32 (#4370) Checklist
-------------------------------------
? Respect 3.3V logic on ESP32 GPIO; level shift 5V signals
? Power via Micro USB (5V) for first bring-up
? If using VIN, keep within 3.5–6.5V and ensure supply is stable
? Add bulk capacitance near the board if you see WiFi-related resets
? Prototype in Arduino IDE; migrate to ESP-IDF for production-grade needs
? Prefer I2C to expand sensors/displays while conserving pins
? Use state machines + timeouts + reconnect logic for IoT reliability
? Add watchdog strategy and basic persistent logging (ring buffer)
? Keep security sane: no default creds, avoid public endpoints, controlled OTA