Saikumar Mandaji

When moving from bare-metal STM32 to Zephyr RTOS on nRF52832, one of the first challenges is adapting to Zephyr's device model. Instead of directly configuring SPI registers, everything goes through the Device Tree and Zephyr's HAL.

Key concepts:

• Device Tree overlay — define the SPI bus, chip select GPIO, and flash node in .overlay file rather than in C code.
• spi_transceive() — Zephyr's SPI API bundles TX and RX into one call with spi_buf_set structs, unlike HAL's separate send/receive.
• Chip Select control — Zephyr manages CS automatically if defined in DT, or you can control it manually via GPIO API for timing-sensitive flash operations.
• W25Q16 commands — WRITE ENABLE (0x06) must precede every page program or sector erase. Status register polling after erase is essential — the chip holds the SPI bus busy otherwise.

Lesson learned: Sector erase on W25Q16 takes up to 400ms. Without polling the BUSY bit in the status register, subsequent read/write operations silently fail. Always implement a timeout-based busy-wait loop.

Most embedded developers treat GATT as an afterthought — pick a characteristic UUID, throw data in, done. On production medical sensor devices, poor GATT design causes app crashes, data loss on reconnect, and months of debugging.

Service and characteristic structure:

• One service per functional domain — separate Vitals Service (HR, SpO₂, temperature) from Device Info Service (battery, firmware version, serial). Mixing concerns into one service makes the mobile side brittle.
• Notify vs Indicate — use Notify for high-frequency sensor data (no acknowledgement, lower overhead). Use Indicate for critical alarms and configuration confirmations (acknowledged delivery). Never use Indicate for streaming data — it will saturate the connection.
• Characteristic descriptors — always include a CCCD (Client Characteristic Configuration Descriptor) on notifiable characteristics. The central must write it to enable notifications — if your firmware doesn't handle CCCD writes, notifications silently never start.
• Data packing — pack multi-field sensor readings into a single characteristic rather than one characteristic per sensor value. Fewer notifications = lower power + lower connection event load.

Reconnection and state handling:

• Reset all CCCD states on disconnect. The next central to connect must re-subscribe. Retaining CCCD state across connections causes silent data floods to unexpected clients.
• Buffer the last N sensor readings in a ring buffer on the device. On reconnection, flush the buffer before resuming live streaming — this prevents data gaps in clinical recordings.
• Implement a connection timeout watchdog: if the central stops responding (GATT timeout), trigger a disconnect and restart advertising rather than hanging in a half-connected state.

MTU negotiation:

• Request MTU of 247 bytes (maximum for nRF52840 with data length extension). This allows packing multiple sensor samples per notification — critical for ECG streaming at 500 SPS.
• Always handle the case where the central rejects the MTU upgrade and falls back to 23 bytes. Your characteristic write handler must cope with both sizes.

Key lesson: Document your GATT profile as a table (UUID, properties, format, units, range) before writing a single line of firmware. Every ambiguity in the profile becomes a bug in the mobile app integration.

The AD8232 is a single-chip ECG front-end that handles instrumentation amplifier, right-leg drive, and high-pass filter in one package. But clean ECG output requires careful system design around it.

Design considerations:

• Sampling rate — ECG requires minimum 250 SPS for accurate QRS detection. At 500 SPS you get comfortable headroom. Using Raspberry Pi's ADC (via ADS1015/MCP3008) limits you — use ADS1115 at 860 SPS for better resolution.
• Lead-off detection — AD8232 provides LOD+ and LOD- outputs. Poll these before processing samples. Attempting to detect heartbeats with disconnected leads produces noise that looks like arrhythmia.
• Baseline wander — movement artifacts and breathing cause slow baseline drift. A high-pass filter at 0.05Hz in firmware removes this without distorting the QRS complex.
• Power supply noise — the AD8232 is sensitive to power rail noise. Decouple with 100nF ceramic + 10µF electrolytic close to the VCC pin. Use a dedicated 3.3V LDO if possible.
• MAX30100 integration — combining SpO₂ (MAX30100) with ECG (AD8232) on the same device requires careful I2C timing. Run MAX30100 interrupt-driven and ADC sampling on a separate timer to avoid interference.

Key insight: ECG is 99% analog design and 1% digital processing. Spending time on PCB layout (ground planes, lead routing, shielding) gives better results than any digital filter.

ESP32's dual-mode radio (BLE + WiFi) is powerful but the two share the same 2.4GHz antenna. Understanding coexistence is critical for reliable simultaneous operation.

Architecture decisions:

• Task separation — run BLE scan/connect on Core 0 and WiFi/MQTT on Core 1. ESP-IDF's xTaskCreatePinnedToCore() makes this straightforward. Never block the BLE event loop with MQTT operations.
• MQTT QoS selection — QoS 0 for high-frequency sensor data (acceptable loss), QoS 1 for alarms and critical events (guaranteed delivery). QoS 2 is too overhead-heavy for constrained devices.
• Reconnect strategy — implement exponential backoff for MQTT reconnection: 1s, 2s, 4s, 8s, max 60s. Aggressive reconnection floods the broker and drains battery.
• Offline buffering — store missed MQTT publishes in a ring buffer (NVS flash) during WiFi outages. Flush on reconnect. This prevents data loss in poor coverage areas.
• BLE data flow — collect data via BLE GATT notifications from peripheral sensors into a queue. MQTT task drains the queue and publishes in batches. This decouples the two radios cleanly.

Topic design tip: Structure topics hierarchically — device/{device_id}/sensor/{type}/data. This allows wildcard subscriptions on the backend for fleet monitoring.

Industrial sensors speak in currents and voltages that MCU ADCs cannot read directly. The signal conditioning chain between sensor and ADC determines measurement accuracy more than any software calibration can fix.

4–20mA current loop:

• Convert to voltage using a precision shunt resistor (typically 250Ω → 1V to 5V range). Use a 0.1% tolerance resistor — 1% error here propagates directly to measurement error.
• Add a 100nF filter capacitor across the shunt to suppress noise. Cut-off frequency: Fc = 1/(2π·R·C).
• Use ADS1115 (16-bit) over internal MCU ADC (12-bit) for industrial measurements where ±0.1% accuracy is required.

Transimpedance amplifier (TIA) for gas sensors:

• Electrochemical gas sensors like SGX-7NO produce femtoamp-to-nanoamp currents proportional to concentration. A TIA converts this current to a readable voltage: Vout = Igas × Rfeedback.
• Choose Rfeedback based on full-scale current. For NO sensors at 100ppm, typical output current is 40–200nA, so Rfeedback of 10MΩ gives 0.4V–2V output.
• Use a precision voltage reference (MCP1525 = 2.5V, 0.4% accuracy) as the TIA reference voltage — power supply noise on the reference rail directly appears on the output.
• PCB layout: guard rings around the TIA input node. Any leakage current (even 1pA on PCB surface) competes with the sensor signal at these impedance levels.

Key rule: Solve the analog problem in hardware. Software calibration can compensate for offset and gain errors, but it cannot fix noise, non-linearity, or impedance mismatch.

Medical alarm design is guided by IEC 60601-1-8 (alarm systems) and IEC 62304 (software lifecycle). The principles apply even in R&D devices not yet in clinical trials.

Alarm priority levels:

• HIGH — immediate patient danger (SpO₂ < 85%, flow failure). Continuous audio + visual. Cannot be silenced for more than 2 minutes.
• MEDIUM — deteriorating condition (SpO₂ 85–90%). Intermittent audio. Can be acknowledged.
• LOW / ADVISORY — informational (sensor disconnected, battery low). Visual only acceptable.

Firmware patterns:

• Independent alarm task — never couple alarm evaluation to the measurement task. A separate high-priority RTOS task evaluates alarm conditions every 100ms regardless of measurement state.
• Watchdog timer — hardware watchdog must be kicked by the alarm task specifically. If the alarm task hangs, the device resets — this is intentional and required.
• Alarm persistence — once a HIGH alarm triggers, it stays active until the condition clears AND an operator acknowledges. Auto-clearing alarms are dangerous in clinical settings.
• Fault injection testing — intentionally break sensors in test builds to verify every alarm path fires correctly. Unit tests are insufficient for safety-critical paths.
• Power-fail alarm state — store last alarm state to non-volatile memory before power loss. On restart, if the device was alarming, restore that state rather than booting clean.

Philosophy: Design alarms to fail safe. If the alarm subsystem itself has an error, the device should alert — not stay silent.

When working on ultra-low-power products with Si Labs BGM220, hitting the theoretical sleep current numbers from the datasheet requires solving several hardware problems that most reference designs ignore.

Power path design:

• Leakage is the enemy — at nA targets, even a 10MΩ pull-up resistor leaks 330nA at 3.3V. Audit every resistor on power-sensitive nets. Replace pull-ups on unused pins with software-configured internal pull-ups that disengage in sleep.
• Voltage regulator quiescent current — standard LDOs have 50–200µA Iq. For nA targets, use a nano-power LDO (Iq = 25nA range) or run directly off battery with protection-only circuitry.
• Load switch isolation — sensors, LEDs, and peripherals must be power-gated via a P-channel MOSFET or dedicated load switch. If a peripheral draws 100µA idle and is continuously powered, no firmware trick recovers that.
• Capacitor leakage — use ceramics exclusively. Tantalum and electrolytic caps have significant leakage at nA budget levels.

PCB layout for leakage control:

• Guard rings around high-impedance nodes to intercept surface leakage before it reaches sensitive pins.
• Conformal coating on production boards — humidity causes surface leakage orders of magnitude above dry-lab measurements.
• Separate analog and digital ground planes joined at a single star point near power entry.

Firmware side (BGM220):

• Use EM4 (Energy Mode 4) for deepest sleep — RAM not retained but sub-100nA achievable with GPIO/RTC wake.
• Disable all unused peripherals explicitly before sleep — even a peripheral left in reset draws microamps on some SoCs.
• Measure actual current with a dedicated power analyser — never trust simulation. Real boards always have surprises.

Result achieved: Through hardware + firmware co-optimisation, sleep current below 500nA was consistently achieved on production hardware, enabling multi-year coin cell operation.

For projects where data needs to broadcast to multiple listeners simultaneously without connection latency, custom BLE beacons are the right architecture.

Custom advertising payload design:

• Manufacturer Specific Data (AD type 0xFF) — pack up to 27 bytes per advertising packet. Define a custom company ID prefix followed by your payload struct.
• Tight packing — a typical sensor beacon: 2B device ID + 2B temperature (0.01°C resolution) + 1B battery % + 1B status flags = 6 bytes total. Compact and extensible.
• Sequence counter — a 1-byte rolling counter lets listeners detect missed packets and assess link quality independently of RSSI.
• Lightweight obfuscation — XOR payload with a key derived from device ID to deter casual sniffing of proprietary formats on shared radio environments.

Advertising interval strategy:

• Fast advertising (100ms) for active/alarm states, slow (2–5s) for idle — a state-machine in firmware drives interval switching based on device condition.
• Randomise interval slightly (±10ms) to avoid systematic collision with other devices on the same channel hopping pattern.

Gateway/receiver side:

• Filter on company ID immediately — ignore all unrecognised advertising packets to minimise processing load on the gateway.
• Device registry keyed on BLE MAC: track last-seen timestamp and flag devices as lost after 3× their normal interval.
• Average RSSI over 5 consecutive packets before any proximity decision — single-packet RSSI is too noisy for reliable distance estimation.

Key advantage: 50+ beacons can be monitored simultaneously by a single gateway with no connection slots consumed — far more scalable than maintaining concurrent connections for fleet monitoring.

Rather than relying on generic terminal emulators, I write project-specific Python tools using pyserial that understand the device's exact data format and surface problems immediately.

Core architecture:

• Serial reader thread — read UART in a background thread; pass data to the main thread via queue.Queue so no bytes are dropped while the main thread processes output.
• Structured log format — define a lightweight log protocol on the device: [TIMESTAMP][LEVEL][MODULE] message. Python parses and colour-codes by level: DEBUG=white, INFO=green, WARN=yellow, ERROR=red.
• Binary packet parser — for sensor data sent as packed structs, use Python's struct.unpack() matching the exact layout defined in firmware. Any struct mismatch becomes immediately visible as garbage output.

Visualisation:

• Real-time plotting with matplotlib — sensor readings, ADC values, RSSI over time. Catches drift, noise spikes, and glitches that scrolling text hides entirely.
• CSV export with PC timestamps — logging a full day of device operation and analysing patterns in pandas has caught multiple intermittent bugs that never appeared in short test sessions.

Specific tools built:

• BLE beacon sniffer parser — device in observer mode outputs raw advertising data over UART; Python tool decodes custom beacon payloads and shows all nearby devices in a live table with RSSI, device ID, and sensor values.
• Power event logger — firmware logs sleep/wake events with timestamps over UART; Python calculates actual sleep durations, wake frequency, and estimated average current — no power analyser required for initial debugging.
• Sensor calibration tool — interactive script sending calibration commands over UART, reading raw ADC values back, computing correction coefficients, and writing them to device NVS flash — the entire calibration workflow automated in one tool.

Key insight: A logic analyser captures what the hardware does. A custom Python tool captures what the firmware thinks. The gap between those two is often exactly where the bug lives.