This year, Specialized discontinued the app that supported it and moved to a new one that is incompatible. The servers also stopped responding: it is no longer possible to sign in, reset a password, or create an account, so I can no longer use the old app. I was left with a useful device I could not use, and an uncomfortable question: did I really own it?

Document Structure

This case study documents the complete reverse engineering process of the ANGi sensor and the development of an open, independent alternative (OpenAngi) using AI tools. The work is organized into 5 main parts:

• Part 1: Claude and BLE Exploration — Initial hardware exploration, BLE service enumeration, and static decompilation of the original APK.
• Part 2: OpenCode and Android App Development — Building the AngiTester test bench, developing the final independent app OpenAngi (100% server-independent), and code comparison.
• Part 3: Hardware and Firmware – Comparative Analysis — Extracting nRF52832 firmware, Ghidra analysis, finding the production UART console, and electrical power characterization.
• Part 4: DFU Firmware Update — Locating the official firmware inside the APK, updating via Bluetooth (DFU), and integrating the process into the app.
• Part 5: Assessment of AI Tool Usage — Comparing strengths and limitations of each model, project scale/costs, and legal considerations.

A note up front: all the tools used are available for free, which is why several different ones appear throughout the article. In some cases, we were trying different tools; in others, we ran into model limitations (for example, many models in OpenCode do not support images) or reached the available token limits.

Part 1: Claude and BLE Exploration

We carried out the first phase entirely in Claude (Sonnet 5) through the claude.ai web interface. One continuous session, one model, no interruptions.

Our first question was whether the project we wanted to tackle was feasible. Claude searched the web and confirmed that ANGi runs on a Nordic Semiconductor nRF52832 (Cortex-M4F, 512 KB flash)—an extremely well-documented BLE chip with a public SDK, identified from the device’s FCC filing.

Since the official app was effectively dead (no login, no password recovery, no new account creation), we ruled out capturing authenticated traffic and reorganized the plan around two parallel tracks:

1. Direct hardware exploration with nRF Connect for Mobile (Nordic’s free tool), enumerating BLE services and characteristics without going through Specialized’s app.
2. Static APK decompilation of the app downloaded from a mirror (apkmirror.com, since Google Play would not let us download it either) using jadx—the decompiled code does not depend on the backend being online.

We connected to the sensor using nRF Connect and shared the first screenshots for analysis. That gave us an initial map of its services: the custom service afd0ffa0…afd0ffa8, Battery Service, Device Information, and Nordic’s “Buttonless” DFU service.

a. Incremental Development of Exploration Scripts

With Claude, we incrementally built a series of Python scripts using bleak (a cross-platform BLE client). Each script answered a specific question left open by the previous one:

• angi_sniffer.py: connects to the sensor, subscribes to NOTIFY characteristics, and logs all raw traffic with timestamps to the screen and a CSV file.
• angi_command_sweep.py: automatically sweeps all 256 possible values (0x00–0xFF) on WRITE characteristics, comparing the STATUS register before and after each write to detect reactions.
• angi_heartbeat_test.py: listens passively without writing anything, specifically to rule out the hypothesis that certain observed packets were command responses. The result: they were a periodic heartbeat (an uptime counter increasing ~1/second).

The workflow was always the same: run the script against the real sensor → paste the log or traceback into Claude → let it adjust the code → repeat. Simple, but effective.

We made progress this way, but the process was relatively slow. The big leap came with decompilation. Claude put together a specific, detailed prompt for OpenCode (another AI tool, with direct filesystem access), with step-by-step instructions: decompile with jadx, perform a targeted search (grep) for UUIDs and constants already identified over BLE, identify classes and methods for each UUID, and generate a protocol document.

The result was a complete protocol map extracted from the decompiled Java classes. Using that information, we built the final angi_client.py: a complete interactive BLE client implementing the sensor’s real extended-command pattern, parsers for the three response packet formats (ASCII, 15-byte IMU report, and 20-byte impact report), named commands, a raw <hex> mode for free-form experimentation, and an autotest that sweeps the 17 known opcodes × 5 parameter variants with automatic reconnection.

b. Identifying the Hardware and On-Board Sensors

Another line of investigation focused on the hardware itself: we opened the sensor and took pictures of the board.

Claude identified the chips from their markings and cross-checked them against public manufacturer documentation:

• ST LIS3DH accelerometer: identified by the marking “C3H,” confirmed against a post by an STMicroelectronics engineer on the company’s forum.
• ST L3GD20H gyroscope: identified by the marking “3GDH,” verified against the same source.
• nRF52832 BLE SoC: in a BGA package beneath a protective layer of silicone.

c. Claude Session Numbers

At this point, with the original APK decompiled, we moved to OpenCode to continue developing the test apps and the final solution.

Part 2: OpenCode and Android App Development

We built the functional Android apps in the second phase using OpenCode, an AI-assisted IDE that runs in a terminal with direct filesystem access, command execution (bash/PowerShell), and code-editing tools. Everything that follows comes from real data in OpenCode’s local SQLite database, not estimates.

OpenCode used 3 different models during the session, all on free tiers:

738 assistant messages, 4.3 million input tokens, 319K output tokens, and 351K reasoning tokens. We switched between models based on the results: sometimes a model started taking longer or failed to solve problems, possibly because the session context had grown too large, so we tried another model.

a. Development with AngiTester

Before building the final app (OpenAngi), we needed an Android “lab test bench.” That is how AngiTester came about: a lightweight app made of 6 Kotlin files, whose sole purpose was to interact directly with the real SHS-D33F sensor (all sensors present as SHS-“last 4 digits of MAC”) and validate every hypothesis byte by byte.

AngiTester’s main screen has three key areas for inspecting BLE traffic in real time:

• Live command terminal (log [HH:mm:ss.SSS]):
  • Console-style view with smart auto-scroll (it pauses when the user scrolls up to read the history and resumes when they return to the bottom).
  • Logs all bidirectional traffic (TX/RX), ASCII notifications, status responses, and battery readings in real time every five minutes.
• Custom real-time IMU graph (ImuGraphView.kt):
  • Plots the accelerometer’s three axes ($g$) and angular velocity ($ ext{°/s}$) at 5 Hz in TEST mode.
  • Indexed by sample number (sampleNumber), avoiding horizontal distortion or “jumps” when BLE notifications arrive in bursts.
  • Smoothed Y-axis auto-scaling prevents a sudden peak from flattening the continuous curve.
• Direct and extended command buttons:
  • Direct modes (afd0ffa1): Activate (syncs RTC + MODE 0x01), Normal (0x00), Test (0x40 IMU streaming).
  • Extended commands (BLOCK_DATA afd0ffa4 + trigger 0x20): firmware version (0xC3), accelerometer/gyroscope test (0xC0/0xC1), LED control (0xFE/0xC2), impact simulation (0xFB), read/report recorded events (0x80/0x81), among others.

AngiTester was not merely a test app: it was the empirical tool that allowed us to decipher the hardware’s real behavior and uncover aspects that were unclear in the decompiled code:

i. Decoding and validating STATUS (afd0ffa2): We empirically verified the structure of the 1-byte bit field returned by the sensor:

• Bit 7 (0x80): ERROR bit (if 1, the remaining 7 bits are the error code).
• Bits 6-5 (0x60): Mode (0=NORMAL, 1=EXT_CMD, 2=TEST).
• Bit 4 (0x10): Active session.
• Bit 3 (0x08): Connection heartbeat active.
• Bit 0 (0x01): Last command completed.

We catalogued the raw status values observed during operation: 0x00 (freshly connected), 0x01 (NORMAL + active session), 0x03 (active session with pending events), 0x21 (EXT_CMD mode completed), and 0x82 (ACK with error/transient status following impact commands).

ii. Discovering and calibrating the accelerometer scale: The original APK divided all values in the IMU report (IcedotTestReport) by 100. However, when capturing stationary data with AngiTester and processing the evidence (angi_static.csv), we discovered that axes X, Y, and Z produced a resultant vector of ~1.73 g, which is physically impossible at rest.

Through cross-testing, we derived the true divisor for the accelerometer axes: \(ext{Divisor } K = 173.2 pprox 100 \cdot \sqrt{3}\) With this correction, the axes reported exactly ~1.00 g at rest (a mean error of only 9 mg), while accelVector and rotation retained a divisor of 100.

iii. Confirming the gyroscope’s single channel: We confirmed that Specialized’s firmware does not transmit the gyroscope’s 3 independent axes over BLE streaming. Instead, it reduces angular velocity to a single scalar channel (rotation) in °/s (bytes 11-12) and its angular acceleration (rotationalAccel, bytes 13-14). We determined that this corresponds to a tilting rotation axis (close to the helmet’s X axis).

iv. Validating the session arming and impact flow: We verified that if the 7-byte UTC RTC (afd0ffa7) is not sent before enabling MODE 0x01, impact reports are recorded with a timestamp of 0. We captured and validated the real impact notification on afd0ffa6 (a 20-byte packet: type, battery, version, timestamp, peakG, peakR, peakRA, and deviceID).

b. OpenAngi: the final independent app

OpenAngi is the final application (30 Kotlin files, a 16.5 MB APK): a complete rewrite from scratch using a modern architecture with Kotlin + Jetpack Compose Material 3 + MVVM + Room + DataStore + Foreground Service.

The app works without a server, accounts, or a backend: the phone itself sends SMS messages directly through SmsManager.

OpenAngi screens:

The app has four main tabs in a bottom bar, plus two overlay screens (Device and Alert):

BLE connection flow

Every GATT operation goes through a Mutex (one at a time, with an 8-second timeout). If any step fails, automatic reconnection repeats the entire setup from scratch, because the sensor loses its state when disconnected. The backoff grows from 2 to 60 seconds with jitter.

Impact flow: from detection to SMS

This is the app’s central component—the ImpactFlowController state machine:

The flow runs at the process level, not the UI level: even if the app is closed, as long as the Foreground Service is running, detection works and the full-screen notification opens the alarm directly.

Declaring an emergency: there is a dedicated button on the Device and Settings screens that triggers exactly the same flow with a synthetic event (type DECLARED, peak 0 g). The SMS says “declared an emergency (manual alert)” instead of “suffered an impact”. Useful if you need help without having had a crash.

Reliability: the Foreground Service

The AngiMonitorService owns the BLE connection and runs with a persistent notification showing the actual status:

• 🟢 Green: connected and monitoring (shows sensor battery)
• 🟡 Amber: reconnecting (with a countdown)
• 🔴 Red: disconnected

If there is no connection for 5 minutes, the app displays a high-priority notification: “OpenAngi lost connection to the sensor”. The guiding philosophy is never to fail silently—if something goes wrong, the user should know.

The BootReceiver reconnects automatically when the phone starts, and if Android blocks background startup, it sends a notification prompting the user to open the app manually.

c. How It Differs from the Original App: Protocol Facts vs. Code

One of the most important aspects of this project is understanding what was taken from Specialized’s original app and what was not—how much the tools copied from the original APK and what was created from scratch. We ran automated scripts comparing the 262,495 lines of the decompiled APK against all the new code:

The 3 “identical” lines are idiomatic Android boilerplate (if (bluetoothManager != null), if (cursor.moveToFirst())). The only shared literals are BLE UUIDs—functional data essential for communicating with the sensor.

From the decompilation, we extracted technical protocol facts—the minimum information any app needs to communicate with the sensor:

• BLE characteristic UUIDs (afd0ffa0…ffa8).
• Packet offsets and lengths: the impact report is 20 bytes, the RTC is 7 bytes, and the IMU report is 15 bytes.
• Byte values: modes (0x00 NORMAL, 0x01 ACTIVE, 0x20 EXT_CMD, 0x40 TEST), report types (1=LINEAR, 2=ROTATIONAL, 3=LINEARROTATIONAL), and STATUS bits.
• Numeric error codes (33=SUCCESS, 64=INVALID_PARAM).
• Activation sequence: write RTC + MODE 0x01.

All of this is documented and cited in the code comments. These are functional facts—like documenting that “the HTTP port is 80”—not copied creative expression.

The most significant architectural change is how alerts work: the original app depended on a Specialized backend that received the event through an API and sent the SMS from its server. When Specialized discontinued the service, that stopped working. OpenAngi removes that dependency entirely: the phone sends the SMS directly, without going through any server. It is simpler, more reliable, and does not depend on anyone keeping a backend alive.

In summary: from the original APK we took the protocol data (UUIDs, packet formats, activation sequence)—technical facts required to interoperate with the hardware—and built an entirely new app with a different architecture, different UI, and a fundamentally different alert mechanism.

d. Overall Software Development Summary

The numbers for the entire project reflect the scale of the AI-assisted work:

The table below breaks down the tools used in OpenCode:

In addition: 720 reasoning traces, 256 text responses, and 8 context compactions (when the context window fills up, the model compresses the history and continues).

What did we learn from the process?

AI did not replace the work—we were still the ones connecting the sensor, running scripts, taking photos, opening the device, decompiling the APK, and making design decisions. But it dramatically accelerated every intermediate step: instead of searching datasheets, reading forums, and writing byte parsers by hand, conversations with the models took us from “what is this chip?” to “we have a signed, working APK” in 3 days.

It is even one of the lines of research we are incorporating into the PID: closing the loop—granting LLMs access to hardware and enabling interaction with physical tools—to further accelerate the experimentation process.

The combination of tools worked well:

• Claude (web chat with vision, search, and image analysis) was ideal for the exploratory phase: identifying chips from photos, putting together an attack plan, and building incremental scripts.
• OpenCode (filesystem access, bash/PowerShell command execution, and code editing) was ideal for the construction phase: compiling, fixing Gradle errors, and iterating over 30 Kotlin files until we had a functional APK.

All Android app development—738 messages, 4.3 million input tokens, and more than a thousand tool calls—cost exactly zero dollars using free models.

Part 3: Hardware and Firmware – Comparative Analysis (Antigravity vs. OpenCode)

With the app running, we turned to the hardware itself: the sensor PCB has six test pads arranged in the standard Tag-Connect TC2030 footprint.

We connected a J-Link via SWD, and since the manufacturer had not enabled read protection on the nRF52832 (APPROTECT), we were able to dump the entire 512 KB flash memory over SWD without restrictions.

This stage presented an interesting opportunity: having already completed the reverse engineering of the protocol from the APK, we used the extracted firmware to compare two AI coding environments working in parallel on the same problem: Antigravity (Google’s agentic IDE) and OpenCode.

a. Initial Extraction and Decompilation with Claude and Ghidra

We dumped the firmware using OpenOCD and a Segger J-Link probe over SWD:

The dump yielded a 512 KB .bin file that we analyzed with Ghidra (the open-source reverse engineering framework).

We turned to Claude (Sonnet 5.5) to assist in the initial Ghidra analysis. We provided the memory map and string references, and Claude guided the setup of memory segments, identify the interrupt vector table, and distinguish Nordic SoftDevice calls (SVCs) from application code:

Claude also generated a Ghidra Java script (AngiAutoAnalyzer.java) to automatically label known Nordic SDK 14 functions and annotate BLE event handlers.

With the disassembly baseline established, we provided the raw Ghidra output to both Antigravity and OpenCode to assess their decompilation, analysis, and hardware-reconstruction capabilities.

b. Comparative Summary: Antigravity vs. OpenCode

We set both tools the task of analyzing the decompiled firmware: identify sensor initialization, locate the impact-detection logic, extract BLE handlers, and identify any debug/test interfaces.

c. Main Achievements of Each Tool

Antigravity: Hardware Insight and UART Console

Antigravity’s biggest contribution was bridging the gap between firmware and physical hardware. It not only identified the presence of a factory test console in the code, but deduced the exact GPIO pin (P0.30) used to trigger it, the required baud rate (38,400), and guided the physical search for those signals among the PCB test points using an oscilloscope.

OpenCode: Firmware Decompilation and Architecture

OpenCode excelled at deep static analysis of the firmware binary. It produced a comprehensive 77,793-line annotated C file, mapped the event-driven architecture centered around evt_set, identified the 24-byte telemetry buffer structure, and performed the most detailed decompilation of the fall-detection algorithm’s configuration and processing routines.

d. Finding the UART Console and Validating It on the Board

Identifying the PCB test points was a much more hands-on process: we used a multimeter and oscilloscope to identify the physical signals. GND and VCC were easy to locate from the battery holder.

Once the UART and console pin were confirmed, the task was to find them on the PCB. We observed activity on all test points while powering the device and found six with pulse signals (sensor communication), another six held low, and a single test point held high (3 V).

At first, we expected to find at least two test points high, corresponding to the UART’s idle state. When we asked Antigravity, it explained that the UART is not configured in normal mode to save power, and is only enabled at startup when P0.30 is held low. This led us to think that the only high test point should be the test-mode pin (P0.30) with a pull-up.

We described the situation to the model:

👤 User (step 258):

“Another question about the test points: one is at VCC, six show some kind of signal/pulses, and six show a low signal to GND. Could it be that the UART isn’t configured unless it is in test mode? Why would I expect to see two more UART pins idle at 3 V?”

🤖 Antigravity (step 259):

*“Exactly! Your deduction is 100% correct.

1. Why don’t you see the UART at 3 V (idle) in normal mode?
On Nordic nRF52 microcontrollers, the UART is not permanently assigned to fixed hardware pins….

2. Explanation of the signals you are currently measuring (Normal Mode)

• 1 test point at VCC (3 V): Main battery / VDD supply.
• 6 test points with pulses/signals: Bit-banged communication bus for the MEMS sensors (LIS3DH + gyroscope): clock, MOSI, MISO, chip selects (CS). Impact/movement interrupts (INT1 / INT2).
• 6 test points at GND: Disabled pins, unused inputs, or PCB ground pads (GND).”*

👤 User (step 260):

“I can’t access the pins; the nRF52 is a BGA. Would it be plausible for the test point at VCC to be that pin with a pull-up?”

🤖 Antigravity (step 261):

“Yes, that is HIGHLY likely! It is the standard factory-test architecture for boards with a BGA package.”

This response caught us somewhat off guard, as we could not identify what technical reasoning connected the nRF52’s BGA package to the conclusion that this specific test point corresponded to a pull-up. While we had provided several hints to see if the model could follow our own reasoning, its conclusion appeared to reach beyond what the available context supported at that moment.

To test the theory, we forced P0.30 low during power-up: the LEDs flashed in a different sequence, confirming test mode. When we measured again with the oscilloscope, two test points that had previously been low transitioned to high (UART idle level).

👤 User (step 262):

“I grounded it, and on power-up the red and green LEDs flashed, and TP10 and TP12 transitioned to VCC. Those must be TX and RX, right?”

🤖 Antigravity (step 263):

“GREAT NEWS! 🎉 You successfully entered Factory Test Mode!”

Next, we connected a USB-to-serial converter to both pins. Through trial and error, we determined which test point was RX and which was TX, and verified the actual baud rate of 38,400 baud:

With Realterm configured for 38,400 baud and the device in test mode, we interacted with the production console and verified its command set:

Test mode allows the device’s operating mode to be changed from an RF perspective for certification testing. This aligns exactly with the photographic documentation on the FCC website: the device powered by an external supply, with three wires exiting through one side (UART TX/RX and GND):

e. BLE Operating Modes

The firmware analysis and UART validation allowed us to reconstruct the ANGi sensor’s complete state machine across all operating modes:

1. Low Power / Sleep: Default state on the shelf or between rides. The nRF52 enters System ON sleep; the LIS3DH accelerometer remains configured for threshold-based wake-on-motion. Current draw drops to ~21 µA.
2. Factory / Production Test: Entered by pulling P0.30 low during power-on. Enables the 38,400-baud UART console, provides direct register access, and supports RF test modes for regulatory certification.
3. Normal Connected (Ride Mode): The sensor pairs with the phone, writes RTC UTC, enables MODE 0x01, and enters continuous crash-monitoring mode. Periodic heartbeats maintain connection state. Average current draw is ~62 µA.
4. Test / IMU Streaming: Enabled via MODE 0x40. Streams raw accelerometer and gyroscope data at 5 Hz over BLE characteristic afd0ffa8. Used by AngiTester for sensor calibration.

f. Fall Detection Algorithm

To understand how ANGi decides that a fall has occurred, we consulted several models and compared their answers with the firmware. Gemini (Gemini 3.6 Flash), ChatGPT (GPT 5.6 Luna), and Copilot all pointed to two relevant parts: impact configuration for the LIS3DH accelerometer and triaxial analysis by the L3GD20H gyroscope. Their explanations, however, did not show the same degree of caution. ChatGPT acknowledged several unknowns; Gemini proposed a more complete sequence but presented some hypotheses as facts that the available code did not prove. For example, it described a buffer as circular and pre-impact, and interpreted the 8 and 2 counts as confirmation samples.

Reviewing the C code later showed that these interpretations went beyond the evidence: the code writes samples, but that does not prove they are later read to decide whether a fall occurred; the values 8 and 2 appear as parameters, but we could not find who consumes them or what their timing means. OpenCode provided a more detailed reading of both branches. In its analysis, impact_detector_config (0x2F60C) sets a default threshold of 16000 and 8 counts for the accelerometer. When an interrupt occurs, it calculates the magnitude of the vector:

It checks whether it exceeds that threshold and whether the difference with the previous reading is greater than 1000. The routine records maximums, counts impacts, and signals an event. The gyroscope branch (0x2FAF8) sets a threshold of 1000 and 20 counts. It evaluates the difference between consecutive values:

and accumulates:

It checks whether $ ext{dif}_i > 1000$ and whether $ ext{acc}_i$ exceeds 20. It also updates counters and minima, can store X, Y, Z, 0xAAAA, and signals an event. The sensor’s identity is confirmed; the units and physical meaning of these values are not. “Energy” and jerk are analogies, not verified conclusions.

A LIS3DH task publishes telemetry while the L3GD20H gyroscope routine analyzes samples. This confirms parallel activity, but not that the two branches converge on a single decision. We have not yet reconstructed the criterion that turns these signals into a confirmed fall or the path that generates an alarm.

We could continue with a more exhaustive analysis, but considered the work completed sufficient for the project’s goals and activities. What is certain—and confirmed by the analysis of the APK—is that the device reports three types of events or alarms: Linear, Rotational, and Linear+Rotational.

g. Critical Review of the C Files and Detected Hallucinations

A close audit of the delivered .c files revealed strengths, but also inconsistencies and typical LLM hallucinations:

app_annotated.c (Antigravity) Although its Markdown report was very accurate about the UART console, the delivered C file (630 lines) was incomplete:

• Missing decompiled code: It contained only function prototypes, register tables, and comments; it did not include any function bodies.
• Technical inconsistencies:
  • It claimed the sensors used hardware SPI0/TWI0 and SPI1/TWI1 peripheral buses, while the firmware actually implements software bit-banging.
  • It identified the gyroscope as an L3GD20 with WHO_AM_I register value 0xD4 or 0xD7 (in fact, 0xD7 corresponds to the L3GD20H).

app_decompiled_annotated.c (OpenCode) At 1.9 MB and 77,793 lines of Ghidra decompiled code, this was a massive deliverable, but suffered from structural flaws:

• Duplicated function bodies: Of the 134 renamed functions, approximately 79 contained the new annotated body followed immediately by the original Ghidra body with a stray { bracket, preventing direct compilation.
• UART trigger confusion: The main() code checks whether P0.30 is held low to flash 3 times and enter rf_test_console_poll(). OpenCode misinterpreted this check as “button detection / charging contact.”
• Register map errors: It assumed the nRF52832 had a “P1” pin port (it only has port P0 with 32 GPIOs), confused the GPIO register base 0x50000500, and discarded the sensor’s 0xD7 response because it did not recognize it as the L3GD20H.

Final Verdict and Optimal Workflow

Neither tool delivered a perfect result on its own, but together they complemented each other: Antigravity excelled at physical and hardware validation; OpenCode excelled at decompilation breadth and architecture. The optimal workflow consisted of taking OpenCode’s decompilation base, stripping duplicates via script, and incorporating the hardware parameters discovered by Antigravity.

h. Power Measurements and Electrical Characterization

To conclude the hardware investigation, we measured power consumption with the device in different states using Nordic Semiconductor’s Power Profiler Kit II (PPK2).

The tool measures currents from 200 nA to 1 A with a 100 ksps sampling rate. We connected the ANGi to the PPK2, powering it at 3.0 V (simulating a CR2032 coin cell), and tested three representative operating modes from the device’s life cycle:

i. Normal Connected Activity (Monitoring During a Ride)

Once the sensor wakes up (from movement) and successfully connects to the phone, it enters its normal operating regime: the processor monitors the accelerometer/gyroscope and periodically sends a heartbeat over BLE:

Analyzing the stable interval (from second 20 of the capture onward, duration 41.86 s):

• Average current: 0.062 mA (62.1 µA)
• Maximum current: 21.64 mA (BLE radio spikes)
• Minimum current: 0.004 mA (3.9 µA in inter-event sleep)
• Charge consumed: 0.000722 mAh
• Estimated lifetime (continuous CR2032): 3,706.6 hours (~154.4 days)

ii. Connection Search and Low Power (Sleep / Standby)

When the sensor powers on or detects motion, it attempts to connect during an initial window (15 to 38 seconds). If it finds no authorized phone, it terminates transmission and enters deep low-power sleep after second 40:

Analyzing the low-power period (seconds 40 to 90.8, duration 50.85 s):

• Average current: 0.021 mA (21.0 µA)
• Maximum current: 0.024 mA (24.1 µA)
• Minimum current: 0.019 mA (18.8 µA)
• Charge consumed: 0.000297 mAh
• Estimated lifetime (continuous CR2032): 10,949.6 hours (~456.2 days / 1.25 years)

iii. Intensive Search Sequence After Disconnection

If the sensor loses BLE connection with the phone during a ride (for example, by moving out of range or signal drop), it initiates an intensive sequence of repeated retries (~15 attempts across a 180 to 900-second window) to re-establish the session:

Analyzing the search burst period (seconds 180 to 900, duration 720 s):

• Average current: 1.878 mA (1877.8 µA)
• Maximum current: 23.73 mA (continuous advertising and RF scanning peaks)
• Minimum current: 0.004 mA (3.7 µA)
• Charge consumed: 0.375561 mAh
• Estimated lifetime (if searching 100% of the time): 122.5 hours (~5.1 days)

Summary of Power Consumption and Estimated Battery Life

Specialized’s manual specifies a typical battery life of 6 months with rides of 6 to 8 hours per week. Using the empirical PPK2 measurements, we can technically validate this estimate:

• For 7 hours per week connected (pedaling at 62.1 µA):
  7 h × 0.0621 mA = 0.435 mAh/week
• For the remaining time (161 hours per week) in standby (at 21.0 µA):
  161 h × 0.0210 mA = 3.381 mAh/week
• Estimated total consumption: ~3.816 mAh/week.

For a CR2032 coin cell with a nominal usable capacity of 225 mAh:
Theoretical lifetime = 225 mAh / 3.816 mAh/week ≈ 58.9 weeks (~13.5 months)

Considering natural CR2032 self-discharge, voltage drops caused by repeated 21–23 mA BLE radio spikes, outdoor temperature variation, and occasional searches after disconnection, the manufacturer’s 6-month estimate is highly realistic and conservative from a hardware-engineering perspective.

Part 4: DFU Firmware Update

The disassembly process of the original sensor was not particularly harmless; the PCB ended up with issues, and opening the enclosure was far from delicate, damaging the sealing gasket (IP67). So I bought a couple of new sensors. It turned out that these sensors came with an older firmware and were overly sensitive to impacts, and with the official app discontinued, there was no way to update them. The initial idea was to try using the firmware extracted with the J-Link and upload it over Bluetooth—this time without damaging the sensor.

a. Building the Package and First Attempt with Claude

We provided the dump to Claude (Sonnet 5.5 on claude.ai), and in a few iterations we organized the memory map: MBR, SoftDevice S132 v3.0.0, an application of approximately 79 KB, a Nordic Secure DFU bootloader, and a settings page whose CRC matched that of the app. We built a DFU package using nRF Util and a Python client with bleak that reboots the sensor into bootloader mode, uploads the package, and logs every step. Claude tested it against a simulated bootloader, but real hardware steered the corrections: it looked for the wrong DFU UUID (the sensor uses the experimental Nordic SDK 12.x service, 8E400001), and the log revealed the correct one.

With that correction, the bootloader received the init packet properly (the CRC matched), but rejected it during validation with a generic error (INVALID_OBJECT), which in this bootloader covers signature, version, or format without specifying which.

b. Inspecting the APK with Antigravity and Finding the Embedded Firmware

That is when we switched tools. With Antigravity (Claude Sonnet 4.6 in Thinking mode and, briefly, Gemini 3.1 Pro in Low), we re-examined the decompiled APK. We found the code the official app uses to assemble the DFU and, even better, the official firmware embedded within its resources: shs_v2_6_13.zip, the exact same version 2.6.13 that had appeared in the dump strings. Analyzing previous logs pointed to a firmware version validation check. With that insight, the script was rewritten and the procedure documented in a README_DFU.md. The update finally worked: the sensor accepted the package, completed the transfer, and booted with the new version.

A detail that stung to discover: dumping the firmware with the J-Link was completely unnecessary. The binary had been there all along, inside the APK, packaged as just another app resource. We had expected the opposite: that firmware would be downloaded on demand from manufacturer servers as new releases appeared, rather than bundled inside the APK. Under that assumption, it never crossed our minds to inspect the APK’s raw resources before cracking open the sensor and wiring up the debugger. Furthermore, the APK’s .zip contains something our dump lacked: the init packet already signed and prepared by the manufacturer, which is precisely what the bootloader validates. The dump was valuable for understanding how the firmware was laid out, but updating the sensor only required inspecting the APK first.

c. Integrating DFU into OpenAngi

With the update already working from the Python script, the next step was bringing it directly into the app. We asked OpenCode (using mimo-v2.6-flash-free, a free-tier model) to review the DFU folder (the README, the .zip, the script, and the successful update log) and add an alert and DFU update flow to OpenAngi whenever an outdated firmware is detected. The result was version detection against 2.6.13, a “Firmware (Outdated)” row on the device screen, and a series of dialogs: update required, low battery warning, progress bar, rebooting, and error with a retry button. Under the hood, it uses the Nordic DFU library, with the official embedded .zip and the parameters previously used by the original app.

The final test, verified on real hardware, was a sensor (SHS-E6F5) updated from version 2.5.22 to 2.6.13: the command was sent, the sensor confirmed, appeared as DfuTarg, the transfer took 47 seconds, and upon reconnection, the app read the new version and reactivated the session. That ~2 h 10 min window ran entirely on a single model without subagents: 213 assistant messages vs. 13 from us, 291 tool calls (125 bash, 61 edits, and 59 reads), ~1.05 million input tokens, 65K output tokens, and 243K reasoning tokens, at zero cost.

Part 5: Assessment of AI Tool Usage

Each phase of this project utilized AI tools in a different way. To conclude, it is worth looking at the broader picture and drawing insights into how tasks were distributed among models and what worked best in each context.

a. What Each Tool Did

No tool replaced real fieldwork: every hypothesis had to be measured or executed directly on the sensor. What models accelerated was triaging raw binaries, writing and correcting tools, and parsing thousands of lines of decompiled Java. But they cannot touch hardware, and some of their interpretations were plain wrong.

b. Project Scale and Cost

The volume of work processed by the models was considerable. The exact numbers for OpenCode come from its SQLite database; those for Claude and Antigravity are estimates based on session logs:

The bulk of development—Android apps, firmware decompilation, DFU updates—ran entirely on free tiers at zero cost.

c. Observed Specialization and Limitations

The choice of tool was not random; each demonstrated clear advantages depending on the task.

• Claude (web interface with vision) was optimal for the exploratory phase: identifying chips from photos, analyzing nRF Connect screenshots, and iteratively constructing scripts without filesystem access.
• OpenCode (terminal with bash, file editing, and build capabilities) was the natural choice for building and debugging real applications: compiling with Gradle, fixing errors, and maintaining coherence across more than 30 Kotlin files simultaneously.
• Antigravity (agent with filesystem access and Thinking mode) proved effective when tasks required reasoning over complex decompiled Java code and debugging undocumented protocol quirks.

Every tool exhibited hallucinations or errors at some stage—detailed in section g of Part 3 and in section f on the fall detection algorithm. The guiding rule was consistent across the board: verify every result against real hardware or the original binary before making decisions.

As previously mentioned, this is also one of the lines of research we are incorporating into the Laboratory’s R&D project: closing the loop—granting LLMs access to hardware and the ability to interact with physical tools—thereby eliminating the need for a user to be present during the majority of the development process.

Conclusions and Legal Considerations

The entire process was influenced by the level of protection present on the device and its software. The analyzed APK did not employ obfuscation or encryption that prevented examining its logic, and the communication protocol with the ANGi could be observed and characterized without breaking cryptographic mechanisms. Furthermore, during hardware analysis we found that the nRF52 firmware was accessible under the device’s conditions, whereas it technically could have been locked down using the microcontroller’s hardware protection mechanisms (APPROTECT). All of this significantly facilitated our work and allowed us to carry out reverse engineering using relatively standard software, communication, and firmware analysis tools. It is important to emphasize that these observations describe the conditions found on the analyzed device and do not imply that the manufacturer deliberately designed the product to facilitate reverse engineering.

How Legal Is Reverse Engineering?

At this point, another question arose: if the device belongs to us, what are the legal ramifications of reverse engineering it to put it back into service? For this inquiry, we consulted ChatGPT (OpenAI, GPT-5.6 Luna) regarding the legal aspects of the process, particularly within the Argentine legal framework. The general consensus was that there is an important distinction between analyzing software to extract the functional information necessary to interoperate with one’s own hardware versus copying, modifying, or redistributing the original proprietary software. In this project, the Ride APK was used strictly as an object of analysis to uncover the communication protocol, but the applications developed subsequently were written entirely from scratch and incorporate no code, resources, or layouts from the original app. Similarly, the device’s original firmware is not part of OpenAngi’s codebase; it was used solely as analysis material and, subsequently, to experimentally validate the DFU update mechanism. In fact, analyzing the firmware was not even necessary to implement OpenAngi: it served primarily as an opportunity to explore using AI tools in firmware reverse engineering.

This question becomes especially relevant when considering potential publication of the project. One possibility—the one presented on this page—is to publish solely the process and findings of the reverse engineering effort; another is to additionally document the discovered protocol specifications; and a third is to potentially publish the source code or an APK of an independent implementation like OpenAngi. In contrast, publishing the original APK, Ride’s decompiled code, or proprietary firmware raises distinct intellectual property concerns, and for that reason, those materials are not part of what is considered for publication. In all cases, this represents a preliminary assessment rather than formal legal advice: if the project were to move toward public or commercial distribution, specific reviews of licenses, intellectual property, and trademarks would be required.

There is an interesting exception within the development itself. During testing, we also implemented the ability to update the ANGi firmware via DFU. To conduct this test, we used the firmware binary file bundled inside the original APK. This allowed us to experimentally confirm the update process and verify that an independent DFU mechanism could be implemented. However, the binary used is not code we developed, but a proprietary component originating from the manufacturer’s app. For that reason, we do not consider it appropriate to redistribute it as part of an open application without prior analysis of its rights and licensing terms. The approach we are evaluating is maintaining an experimental build that includes that file solely for internal DFU testing, alongside a separate public version of OpenAngi devoid of proprietary firmware. The latter would be the candidate for any potential public distribution.

At the Laboratory, we have worked on a range of projects using wireless modules, including different ESP32 variants and Nordic’s nRF52840. We usually follow the manufacturers’ design guidelines, which typically recommend placing a module near the edge of the board and leaving a clear area around the antenna to optimize its performance. However, we have seen projects ignore these guidelines more than once, which made us wonder how much of this guidance is a recommendation and how much is a requirement.

Espressif explains how to position a module with a PCB antenna in its Hardware Design Guidelines.

Still, we wanted to find out how much the signal from an ESP32 with an on-board antenna changes depending on where it is placed. Would the difference be just a few decibels, or could it make communication impossible?

The Experiment

To run a series of experiments, we built a test base: a single-sided PCB placed on top of another board to simulate a double-sided PCB with a continuous ground plane. It had six possible mounting positions for the same physical module. We did not use six different modules; we repeatedly moved the same one, holding it in place with soldered pins that provided both mechanical support and an electrical connection to the ground plane. For the center position, we removed the copper from the area that would be the antenna keepout beneath the antenna, as the manufacturer recommends. This area is usually defined in the module footprint, so that particular recommendation is followed even when the placement recommendation is not.

The board connects to a laptop running an app that sends commands over a serial port to configure experiments and collect data.

The app also communicates with a second ESP32 board that remains fixed in one position. We measured RSSI and throughput using three different protocols (ESP-NOW, BLE, and Bluetooth Classic), initially sending batches of 200 100-byte packets every 100 ms per run, for a low input rate of 8 kbps that would not saturate the receiving link. In total, we collected 70 sessions and about 800 RSSI samples per position and protocol.

Result 1: Footprint Position Matters, A Lot

The results table makes it quite clear:

That is an 11 to 12 dB difference just from moving the chip a few centimeters on the same board. Same module, same distance, same antenna. Losing 6 dB means receiving half the power. Here, we lost almost twice that just by choosing a poor location.

Result 2: The Ranking Is Consistent Across All Three Protocols

The best and worst locations were exactly the same for ESP-NOW, BLE, and Bluetooth Classic. Three protocols with different radio stacks operating at 2.4 GHz, and they all agreed:

Position 3 was the clear winner: it was best every time, across all three protocols, leading the runner-up by 4.1 to 7.9 dB. Position 1 was consistently second. Positions 4, 6, and 2 clustered in the middle, very close to one another. Position 5, in the center, was by far the worst (or tied for last in ESP-NOW).

Why Position 3 Wins and Position 5 Loses: The RF Explanation

This fits perfectly with Espressif’s guidance. The antenna needs a copper-free clearance area around it (no ground planes or nearby metal components) to avoid detuning, and the feed should point toward a free edge of the board.

Position 3 is right at a corner, pointing outward with nothing nearby to block it. Position 5 is the opposite: it is enclosed by the other positions and surrounded by copper on all four sides, a textbook example of antenna detuning caused by insufficient keepout.

To visualize the results more intuitively than with a box plot, we wrote a script that generates “long exposure with synthetic LEDs” images: it overlays colored points of light on the board photo, one for each RSSI sample, with a soft Gaussian glow and a screen blend (light accumulates and brightens without obscuring what is underneath). The result looks more like an actual long-exposure photograph than a chart, and makes it easy to see the signal level at each position and how much it varies.

A Result That Does Not Quite Add Up: Positions 3 and 6

According to the manufacturer’s guidelines, positions 3 and 6 should both be the best: in both, the antenna extends beyond the base board and the feed point is near the edge, exactly as Espressif recommends. Position 3 always performed as expected, but position 6 did not do as well. In one run, position 4 beat position 6; in the next, the order was reversed. Positions 3 and 5 were always very stable, but position 6 showed considerable variation between repetitions.

We do not have a definitive answer yet, but we have a few hypotheses. Since we removed and repositioned the module by hand for each session, a tiny change in its resting angle may have affected the measurement. Also, at 2.4 GHz, walls and objects in the environment create reflections (multipath) that change with millimeter-scale differences in distance; the test environment may have disadvantaged that particular position.

What the Throughput Did NOT Show in the First Run

At an input rate of 8 kbps, the transfer speed was exactly the same for every position and protocol: a steady 8.00 kbps.

That does not mean module placement has no effect on speed. At this low rate, the link operates very comfortably even in the worst case: at -70 dBm, it is still nowhere near the sensitivity limit of these chips. We needed to push the test to its limit.

Second Run: Increasing the Transfer Rate

We ran a second set of tests. Same positions, same distance, same three protocols, but this time we pushed the network with larger packets and tighter timing. We brought ESP-NOW to about 160 kbps, BLE to 200 kbps, and Bluetooth Classic to 410 kbps (20 to 50 times faster than before).

RSSI again showed the same marked difference:

The ranking shifted a little. Position 6 moved up:

Position 3 was once again the clear winner, leading in both runs and every measurement. Position 6 came second in all three protocols, which was not as clear in the first run and now agrees with Espressif’s recommendation (feed facing outward). The other middle positions shifted somewhat; differences in that middle group are small and very sensitive to the environment.

And the most curious result of the second run: despite pushing the network hard, throughput barely noticed. We saw isolated performance drops during bursts of lost packets, but they were scattered equally across all positions. The signal has to degrade much further for throughput to drop systematically. RSSI exposes poor module placement long before you notice it in the transfer speed.

Transmitter/Receiver Swap: Bidirectional Link (A → B vs. B → A)

For this third round, we increased the distance between the boards to 350 cm (up from 230 cm) and swapped transmitter and receiver halfway through each test. We wanted to see whether the outbound link (A → B) and return link (B → A) produced symmetric RSSI and throughput, or whether link direction introduced a difference.

Position Ranking at 350 cm

At the greater distance, the gap between the best and worst positions remained wide (between 14.4 and 15.8 dB):

The ranking shifted a little compared with the previous runs:

Position 3 was again first in every case. This time position 2 moved up to second place and position 4 to third, with similar results across all three modes. Position 5 (center) remained last in BLE and Bluetooth Classic, dropping to -81 dBm in BLE. In ESP-NOW, position 6 fell to last place, probably because that orientation is more affected at 3.5 meters.

Throughput and Link Symmetry

Throughput was nearly identical in both directions (A → B vs. B → A):

• BLE: 7.80 kbps in A → B vs. 7.91 kbps in B → A (p = 0.2494, not significant).
• Bluetooth Classic: 7.87 kbps in A → B vs. 7.89 kbps in B → A (p = 0.7621, not significant).
• ESP-NOW: 7.84 kbps in A → B vs. 7.89 kbps in B → A (p = 0.5612, not significant).

Link direction can introduce small RSSI asymmetries, on the order of 0.3 to 1.7 dB, probably due to minor differences in sensitivity or transmission power between the two specific modules we used. But throughput is unaffected, and module placement on the PCB remains what really matters.

Near-Field Visualization

The synthetic visualizations were useful, but they made us want to try the real thing: mount a physical WS2812B LED on the board, move it through space in a dark room, and capture its path with a camera. We did—or at least tried.

At first, we tried moving the board with the LED by hand over the test board. We could see color changes, but the path was not very even, so no clean pattern emerged.

We then used a 3D printer (an Artillery Sidewinder X1). A Python script generated G-code for a systematic path in the XZ plane. We mounted the board on the extruder and let the machine sweep the module through different positions. The results:

There is significantly more “red” at position 5, indicating poor signal reception.

PCB Design Takeaways

Moving the module a few centimeters on the same board changes RSSI by 11 to 15 dB. Not all corners are equal.

Surrounding the antenna with a ground plane is the worst thing you can do. The module in the center, surrounded by copper, produced the worst results in almost every test. Pointing the feed toward a free edge is the safe approach: position 3 (corner with a clear path outward) won all six tests, and position 6 (same principle: antenna outside the board and feed point at the edge) also performed very well in the fast run. The manufacturer’s theory holds up.

That said, losing 11 dB is not the same as losing the connection. In every test, even position 5 (the worst) kept the link active, and throughput did not collapse until we forced very high rates. If a device operates over short distances, in an environment with good propagation, or with a generous link budget, a suboptimal location may be perfectly acceptable. The problem arises when the signal budget is tight: greater distance, walls, interference, or low-power modules. In those situations, the 11 dB “given away” by poor placement can be the difference between a stable link and one that drops out.

If you only measure transfer speed, you will not notice any difference at short range, even when the signal is 12 dB lower. RSSI is the only metric that immediately tells you whether the location is poor. And watch out for the middle positions: the first and last places were clear, but the ones in the middle shifted somewhat from test to test. If you are making a design decision based on a middle position, measure it a couple more times.

Note on Bluetooth Classic RSSI: in this mode, the firmware does not read an absolute RSSI value in dBm as it does with Wi-Fi/ESP-NOW or BLE. The ESP32 Bluetooth Classic controller only exposes esp_bt_gap_read_rssi_delta(), which returns a value relative to the “Golden Receive Power Range”—the power range the chip itself considers ideal for its internal power-control algorithm. A value of 0 means “the signal is within the ideal range,” a negative value means “weaker than ideal,” and a positive value means “stronger than ideal.” It is not an absolute power measurement and cannot be directly compared in dB with Wi-Fi or BLE RSSI. That is why the Bluetooth Classic graphs use a relative scale (for example, -16 to -28) instead of typical dBm values: they do not represent the same physical quantity, and their values should not be compared number for number with the other two protocols. Only the trend between positions within Bluetooth Classic itself should be compared.

In mid-2024, the idea of developing an ECG signal generator came up at the Laboratory. Eduardo Filomena, one of the Laboratory’s members, proposed it with a clear goal: to have a tool that could test electrocardiography equipment while also serving educational and demonstration purposes.

By that time, we had already been working for a while on a 12-lead wireless electrocardiograph. As part of that work, we needed to test the device and, until then, we usually used a function generator that included some biological signals. The problem was that this equipment was limited to a single ECG channel.

A generator capable of producing multiple leads and allowing us to customize the generated signals was especially appealing. It would let us run more complete tests on the electrocardiograph, generate different conditions and signals to evaluate its behavior, and potentially automate test sessions.

That need gave rise to the project documented in this series of posts. We intend to retrace the path we followed during development: from recreating the original design, started by Eduardo Filomena, through the tests and problems we encountered, to the changes and improvements we eventually incorporated.

The starting point was a Raspberry Pi Pico (RP2040) programmed in Arduino. The microcontroller stored the signal data and used it to generate the signals for the 10 conventional ECG leads through PWM. Since the microcontroller’s output was a PWM signal, it had to be conditioned to obtain an analog signal. The outputs passed through a series of passive low-pass filters, which attenuated the PWM’s high-frequency component and reconstructed the ECG waveform. A resistive divider then attenuated the amplitude to millivolt levels.

Our first step was to recreate the device. Before modifying it or thinking about a new version, we wanted to understand how it was built, how the signals were generated, and, above all, check how well it worked in practice.

That first prototype proved useful for the initial signal-acquisition tests with the electrocardiograph prototype we were developing.

Immediately after recreating the original device, we began improving its capabilities. One of the first changes was migrating the code to C. From then on, we carried out all subsequent development in Visual Studio Code using the official Raspberry Pi SDK for the Pico. As is increasingly common in our projects, various artificial intelligence tools assisted a significant part of the development and programming work.

But we did not want to stop at a software improvement. As we began using the generator, new needs emerged.

We thought it would be much more useful to have a device that could be carried easily and used independently, without relying on a computer during tests. So we decided to add an 18650 LiPo battery as a power source, along with a charging-management board. Besides making it portable, this offered another benefit for our use case: it allowed us to work with a floating ground reference relative to other equipment during testing.

We also added our own user interface, based on an OLED display and a rotary encoder. This let us select signals and configure the generator directly on the device, without connecting it to a PC.

We developed the enclosure in Fusion 360, going through several versions.

Electronic Design

The circuit design also went through several stages. As development progressed and we gained a better understanding of what we needed from the device, we changed both the electronics and the signal-conditioning approach. First, we switched to a Raspberry Pi Pico 2 (RP2350) to improve the device’s performance. Although the microcontroller was not the system’s bottleneck, it gave us more memory and a faster processor.

The final implementation uses active low-pass filters, specifically Sallen–Key filters, designed to reconstruct analog signals from the Raspberry Pi Pico’s PWM outputs. The design was heavily influenced by the components we already had available in the laboratory. The op-amps are Texas Instruments OPA2335, whose main feature of interest to us was their rail-to-rail operation, meaning they can handle input and output voltages very close to the supply rails. By looking at the passive components we had on hand, we found a combination that gave us a 256 Hz cutoff frequency, appropriate for the application.

Before building the circuit on a board, we ran several simulations to check its behavior and adjust the components. This allowed us to evaluate the frequency response, attenuation of the PWM’s high-frequency component, and the resulting output waveform.

Simulation

As shown in the image, we ran the simulation using LTspice, a free electronic-circuit simulator developed by Analog Devices.

The filter outputs pass through a resistive divider that reduces the signal. A second op-amp, configured as a voltage follower, isolates the divider from a 470-ohm output resistor, intended to simulate tissue impedance.

Around the same time, we were about to start a new project at the Laboratory: developing an external pacemaker. This led us to add a feature that was not necessary for the ECG generator itself but could be very useful in the future. We incorporated three input circuits connected to the Raspberry Pi Pico’s ADC to detect pacemaker pulses.

The idea behind this addition was to go beyond simply generating ECG signals. In the future, we wanted to use this hardware as part of a system that could simulate the interaction between a heart and a pacemaker, eventually moving toward an in-silico heart model. At the time, this was still a future idea, but it seemed worthwhile to prepare the platform so the same device could be part of that development.

Signal Generation and Processing

Another improvement we made was to expand the range of signals the device could generate. In addition to ECG signals, we added basic test signals—sine, square, and triangle waves—with controls to change their amplitude, offset, and frequency directly. These signals were especially useful during development because they let us test each stage of the system with known, easily parameterized waveforms. This allowed us to verify PWM generation, filter performance, and output behavior separately before moving on to more complex signals.

The most interesting part, however, came when we started working with real ECG signals. For this, we used the Lobachevsky University Electrocardiography Database (LUDB), which contains 12-lead ECG recordings. We developed a Python notebook to take these recordings and transform them into data that could be used directly by the Raspberry Pi Pico firmware. The first step is to read a recording and obtain its 12 leads. We detect the peaks corresponding to QRS complexes in one of them, then use those peaks as references to identify the cardiac cycles present in the recording.

Rather than simply selecting any heartbeat, we looked for one that could be repeated continuously. For each candidate cycle, we calculated the difference between its starting and ending values across all leads and selected the one with the smallest difference. This gives us a heartbeat that transitions as smoothly as possible when it starts again after completing a cycle.

Once a cycle is selected, we extract the samples for the nine leads used by the generator and scale them appropriately for representation as integer values. In our case, the data are rescaled using the operation 2000 + 30000, centering them around the value 30000.

This midpoint offset reflects how the Raspberry Pi Pico works: powered by a single supply (0 V to 3.3 V) and using a 16-bit PWM resolution (0 to 65535), the value 30000 establishes a DC level, or virtual ground, of approximately 1.51 V (45.7% duty cycle). This leaves enough headroom to represent both positive ECG deflections (P, R, and T waves) and negative ones (Q and S waves) without clipping at 0 V.

Finally, all samples are converted to integers and automatically packed into a .h header file. The file contains an array of heartbeat samples along with a structure holding additional recording information, such as rhythm and signal-related characteristics. The result is a real ECG heartbeat converted into a format the firmware can use directly. The Raspberry Pi Pico does not need to process the original signal or access the database: the samples for the cycle are simply stored in memory and repeatedly played through the PWM outputs. This processing also gave us something we had wanted from the beginning: the ability to add new signals to the generator without manually changing the firmware. Given a database recording, the notebook selects and prepares the heartbeat and generates the file that we later add to the project. The generator now has two broad groups of signals: synthetic, parameterizable signals for hardware testing, and real physiological signals, processed and prepared for playback on the device.

Communication and CLI

To make testing easier to automate, we also decided to add a CLI to the device, allowing us to change its behavior with commands—for example, the signal type (synthetic or real) and its parameters. We then created a small Python app with a graphical interface to control the device more conveniently. Another important feature of this app is that it lets us view the generated signals in real time. In the future, this could let us compare the generated signal with a hypothetical acquired signal and evaluate the acquisition system’s performance—a way to “close the loop.”

A Limitation and the Next Step

Despite all these improvements, the generator still had an important limitation: the signals it could play were predefined and stored in memory. We could choose among different recordings and play real signals, but we had no easy way to change their morphology or heart rate in real time. This became increasingly apparent as we used the device for testing. If we wanted to change the heart rate, modify a morphological feature, or generate a particular condition, we had to prepare a new signal in advance and add it to the firmware again.

The next question came naturally: could we generate the ECG in real time instead of limiting ourselves to replaying previously stored signals? Starting from this question, in upcoming posts we will explore mathematical models for ECG signal generation. The idea is to move from a system based mainly on replaying stored recordings to one where we can control signal characteristics much more precisely, changing them in real time to suit the test. This opens a new stage of the project: we are no longer only interested in replaying an ECG, but also in understanding how to model and generate one.

There was another limitation, and it was not purely technical. Repeating the same recording indefinitely also meant losing some of the dynamics of a real heart. Every cycle was exactly like the last: the RR interval repeated, the waveform morphology stayed constant, and there was no natural variation in heart rate. There was no baseline drift or small beat-to-beat variation in the amplitude and duration of the different components either. In other words, we could reproduce a particular signal very well, but we were not reproducing the dynamic behavior behind it.

This became especially clear when we thought about what we wanted the generator to do. It was not enough to have an ECG that “looked like” a real recording; we wanted to change its heart rate, introduce variability, alter its morphology, and simulate different conditions without finding and storing a new recording for every case. The first version was still very useful for testing the electronics and verifying real-signal acquisition, but it had a clear limit: we were not simulating a heart; we were replaying a recording of one. That difference is what led us to look for a way to generate ECG signals from a mathematical model.

For now, the files needed to implement this first version of the generator are available on GitHub in the Laboratory repository.

A few years ago, a physician came to the Prototyping Laboratory with the idea of measuring blood pressure using a pulse tonometer. A pulse tonometer measures blood pressure and pulse-wave characteristics directly over a superficial artery, usually at the wrist. The sensor flattens the radial artery against the bone and measures the pressure needed to keep it compressed. The idea was to add this capability to BioAmp, so we could measure blood pressure and the heart’s electrical activity at the same time. Simultaneous ECG and pressure measurements make it possible to estimate parameters such as pulse transit time (PTT), which correlates with arterial stiffness and is used as an early indicator of cardiovascular risk.

We initially tried to replicate a system that was already being used, based on an invasive pressure sensor. This is a medical device designed for continuous, accurate monitoring of blood pressure and other physiological parameters. It works by inserting a catheter directly into a blood vessel (usually an artery); the catheter transmits pressure to an external transducer, which converts the mechanical signal into an electrical one. The sensor’s tubing was filled with water, and the catheter tip was modified with a flexible membrane (a latex glove finger or a balloon) and placed on the patient’s wrist. Blood pressure moved the membrane and, with it, the water column, making it possible to measure arterial pressure. The sensor was connected to one of BioAmp’s differential channels; its Wheatstone-bridge output produced a voltage difference proportional to the applied pressure, which could be monitored alongside the ECG signal. This system was not very effective, at least in our implementation. Filling the tubing was difficult, and it was hard to prevent air bubbles from forming inside it. In addition, from a dynamic perspective, the hydraulic system introduced high compliance and strong damping, degrading the fidelity of the pressure waveform and reducing sensor sensitivity.

Redesign

We decided to redesign the system from scratch, changing the transducer to make it easier to use. During the literature review we conduct for our projects, patents are one of our sources. One that we found particularly interesting was patent US20050177047A1, “Device for, and a method of, transcutaneous pressure waveform sensing of an artery and a related target apparatus.”

The device illustration showed a pressure sensor and a kind of gel cone that transmitted arterial pressure from the skin surface to the sensor. We were already looking for invasive pressure sensors to assess whether they could be reused, and the illustration made us think we recognized the package of the sensor used. We are not completely certain, but it looks very much like NXP’s MPX2300DT1.

This sensor is a silicon pressure transducer rated from 0 to 2.3 MPa (0 to 23 bar), with a temperature-compensated voltage output, used in invasive pressure-monitoring devices.

CAD Modeling

We began modeling the device in CAD with the goal of reproducing the geometry described in the patent. We chose silicone for the gel cone and first designed and 3D-printed a PLA mold. The mold was held in a vise to keep it stable during casting.

Instead of conventional liquid silicone (RTV), we used a hot-glue gun. Although commonly called “silicone guns,” the glue sticks are actually made of thermoplastic polymers (usually EVA or other copolymers). Because the solidified material has a similar consistency and is easy to process, we decided to evaluate it as a practical, low-cost alternative.

We needed multiple iterations of both the mold and the gel cone to optimize the geometry and achieve a good casting. The rest of the device also went through several iterations as we looked for a shape that could hold the sensor securely while remaining comfortable to use.

Testing

The video shows the prototype connected to BioAmp, with the pressure signal displayed in BrainBay. This versatile software makes it possible to build a signal-processing flow diagram and obtain blood pressure directly in mmHg.

When ECG capture is added as well, we obtain recordings like this:

The redesign produced a pressure signal with a morphology consistent with a physiological radial pulse wave, avoiding the dynamic limitations of the initial hydraulic system. Integration with BioAmp demonstrated that simultaneous ECG and blood-pressure recording is feasible using a low-cost, non-invasive transducer.

Although the system still needs formal calibration against a clinical reference method, the preliminary results validate the concept of integrated radial tonometry and open the way to developing tools for estimating arterial stiffness and derived hemodynamic parameters.

Part of the Prototyping Laboratory’s work involves providing technological solutions to other laboratories at the UNER Faculty of Engineering. As part of these activities, we began working some time ago with the Center for Engineering in Rehabilitation and Neuromuscular and Sensory Research (CIRINS), supporting one of its research areas: the study of pain. In the first stage, they asked us to develop an algometer, a device used to measure a patient’s pain threshold. The complete system involved a robotic setup with a linear actuator that applied pressure to the patient’s skin, a force sensor to measure the applied pressure, and a control system for the actuator.

In a second stage, they asked us to develop a handheld algometer that could manually measure a patient’s pain threshold, significantly simplifying the system.

Redesign

The original control system had three power supplies: one for the linear actuator, one for a stepper motor, and one for the control system. For the manual version, we wanted to simplify this arrangement; by reducing the number of components, we were able to power the entire device from a single supply. The original version used an ESP32 DevKit, but it was out of stock when we placed the order, so we chose a FireBeetle 2 ESP32-E. This board includes a LiPo battery charger, which will make it easier to add a battery in the future and make the device fully portable.

The user interface consists of a 128×64-pixel OLED display and a rotary encoder with a push button. We also made the FireBeetle board’s buttons available for quick use. The FireBeetle 2 ESP32-E includes LEDs that we used to indicate the device’s status. The force sensor is the same one used in the original system: Honeywell’s FMAMSDXX005WC2C3. We also added a BNC connector, which can be used as an input with a push button (to indicate external events) or as an output to synchronize with other devices.

CAD Modeling

We based the physical design on the original system, but simplified the structure to make it significantly more compact and lightweight. The overall structure is a stack of 3D-printed parts held together by three M3×35 mm screws. We chose this approach because it allowed us to iterate quickly on individual sections of the design and made it easier to orient the parts for printing.

We placed the sensor in a kind of cradle built into the plastic part that holds it, and soldered the wires directly to its pads, avoiding the need to add a separate PCB.

Force is transmitted from the external contact point to the internal sensor by a 2.5 mm diameter steel rod. It slides smoothly inside a bronze sleeve and is supported by a plastic part. A spring applies force to the rod, keeping it in constant contact with the sensor with a preload of approximately 120 grams.

We also designed a small handle on the plastic part that supports the rod. It lets us pull the rod away from the sensor temporarily and lock it in place. This protects the delicate sensor from overload while we change the patient’s stimulation tip, which may be pointed, a blunt blade, or another type.

We also made a cap that attaches to the front to protect both the stimulator and the internal parts during transport. At the back, we added a cable clamp made from a wedge printed in a soft material (TPU) and a quick-threading nut. This allowed us to secure the cable firmly to the device body and prevent it from being pulled out.

Finally, we designed the control-module enclosure as two large interlocking parts joined by three M3 screws.

To make the FireBeetle board’s tactile buttons easy to use, we designed and printed small flexible plastic structures that press the on-board buttons when pushed from the outside. We had used similar solutions before, but in this case the FireBeetle buttons were soldered at 90 degrees. This orientation required more careful analysis to ensure the natural rotation of the printed part produced the optimal linear movement to trigger the button’s internal mechanical click without damaging it.

The stimulation tip used in this particular case is a hypodermic needle whose bevel was removed to prevent cuts and skin penetration. We considered printing a Luer-style lock to hold the needle, but the part was too small and complex, so we chose to reuse a plastic lock from a syringe.

Testing

To test the device, we printed additional mounting parts. These let us firmly clamp the stimulator in a vise and place a standard 100-gram weight on the actuator.

We captured data with no load and with the weight on the sensor, at both 10 Hz (the normal operating frequency with real-time display) and 500 Hz (the maximum frequency during measurements).

When analyzing the sensor measurements, the first thing we see is that the average values are accurate: when a 100 g load is applied, the system measures very close to that value. However, looking at the signal in detail over long periods reveals small variations and slow drifts. These are not random noise, but effects intrinsic to the sensor, such as temperature changes or internal mechanical settling. This is also visible in the histograms, where the distribution is not perfectly clean, and in the frequency analysis, which shows that nearly all the variation happens very slowly, close to zero Hz.

In actual use, however, things are quite different. If the sensor is zeroed immediately before a measurement and used for only a few seconds, these slow effects are no longer a significant problem. Over that short interval, the system is much more stable, and what dominates is simply a little electrical noise in the signal. In practice, this means the sensor works well for quick measurements as long as it is calibrated beforehand. The reading can be smoothed further by averaging a few values. In short, although it is not ideal for prolonged measurements without recalibration, it is perfectly usable and reliable in short, controlled scenarios, where it performs best.