Forum - Recent Threads

Palno & Slemon #3 Building the Algorithm

Palno & Slemon #4 Final Firmware

Palno & Slemon #5 LabView Integration

My project was a dual-code system that helps us track sleep and also wake up at the right time so we don't feel tired and low on energy. It uses algorithms and data from the blood oxygen and blood beats-per-minute (BPM) sensor. The radar module detects movement while you are sleeping and I also have the temperature sensor for smart things.

1)Building the Selmon`s Enclosure

For building the salmon, which includes the Arduino Q, the Mac, the temperature sensor, the ink display, and the data module, I want a space that can house all of these without being too congested. It should be portable and look good also. I wanted it to be under 400 cm² so it would be a good fit.

I made it. First I designed the plan and how I should cut the cardboard pieces so they can form the structure for the supposed design I made. I made a rectangular cuboid that is a little tilted at a 20° angle on the front side, where it includes the ink display and the radar module. On the top I want it to be removable and to house the heat sink, which will be connected to the temperature sensor so we can sense the air's temperature and the room's temperature also.

I don't have a 3D printer, that's why I'm doing it. Also I'm a little bit good at art and craft.

First I made the quicker schematics of what I have to do and how to cut the cardboard pieces:

After cutting these are the pieces. They are quite rough so I have to also make the outer covering for them

After Sticking them.

then,

The display can be attached with the duct tape and surely I don't have to use bolts.

It seems magical when we don't have to power the display. It stays as it is.

After Placing all the components tightly and steadly.

The Heat sink I am going to used:

I have reused an old scrap aluminum heatsink because it's good for us(and the planet). Why buy if you already have.

Putting the Max30208

I use the EMI absorber because it reflects the radiation. You kind of say it's related to the Arduino Q and also the main heat from the system because Arduino Q is a heavy beast.

After all fabrication with paper its ready!

Because I don't have sufficient batteries right now, I want it to be powered by USB only so I have included a port on the right side, top right. It is steady because the adhesive was very strong.

2) Building the Palno

So instead of wasting time seeking new ideas, I decided to utilize the time and build it on a makeshift broken watch: not one watch but two, once using the strap and once using the main body (the lower part)

Below that is the Maxrefdes 117. I also have applied the EMI absorber as there will be the microcontroller and also the MPU6050 stacked on top. That could cause interference

Then

Then I place the battery, which won't be that useful. Later it only provides me with a lifetime of about 1 or 2 minutes because it's quite old and can't withstand the draw. Then I apply the MPU6050 on the top of the ESP52 processor heatsink.

I had placed the AMI observer in between them also so it does not cause any interference.

All together now:

And it was done, though it was a little heavy and not that study and compact, just a Frankenstein prototype, but it works well and can do the job. Firstly I was going to build it in a comfortable cloth format but I don't think I had time for this so I had to make it this way only.

Thanks to the Element14 this time I had enough duct tape to hold every piece from breaking apart : )

Thanks again for being here till here and following my journey. I think it was fairly enjoyable for you as you don't have to read along. You can just watch. In the next post I will be blogging the entire project, the most important part, so if you want you can read it. It will be very encouraging for me.

Thanks again for reading. Let me know your comments and thoughts on this.

Palno & Slemon #5 LabView Integration

Qbit — Sun, 25 Oct 2026 14:26:04 GMT

I hope all's good. Today was miserable for me. I had to work from the very morning to now. It's almost night and I only go to eat. Otherwise I stay at my desk only to work. I have gained a lot of precious experience from this: I should never take the deadline as a joke.

but I have to make some changes from where I am so I can implement that. That took me a while and understanding LabVIEW's new architecture was also a little easy. I was completely new so it took me some time but it was fairly easier than any other software I will be writing this using Wispr Flow because I am very tired.

I had taken many revisions, like five revisions, to completely come to this stage when all things sync perfectly with each other and work excellently. thank you for staying to see my journey till here. If you are new and seeing this, you can also read my past posts here:

Past Posts

Palno & Slemon #3 Building the Algorithm

Palno & Slemon #4 Final Firmware

By the way I was working on a project that helps us wake up at the right time so we aren't in the stage that could affect our energy level and we feel tired. It also manages the time we have to wake up. We set it for the right time as per the data it gets from our sleep. If you set it to 7:00 and the algorithm detects that you are partially awake around 6:00, it will wake you up at that time. You will feel fresh and wake up at the right time so you don't have to compromise time with health.

It works by seeing your blood oxygen level (the SpO2), the BPM, and the movement you make while you are resting. I have also added temperature control for others, like the temperature of your room, so you are better comfortable and it will be easy for you to fall asleep. I'm also using speakers to help you sleep properly with the therapy of binaural beats.

The Goal

While the Uno Q runs a built-in web dashboard on port 7000 for everyday consumer check-ins, medical and clinical research environments have completely different demands. A clinician, sleep doctor, or biomedical engineer doesn't want a consumer mobile layout; they need:

High-Frequency Multi-Parameter Waveform Plotting: Continuous, uninterrupted real-time trend charts of heart rate variability, SpO2 saturation, respiration rate, and 3-axis gravitational acceleration vectors.
Absolute Determinism: No browser rendering lag, no dropped samples, and zero jitter.
Medical-Grade Telemetry Logging: Direct, uncorrupted streaming to CSV/spreadsheet files on a PC for post-hoc polysomnography (PSG) comparison and statistical scoring.
Instant Visual State Annunciation: Clear LED clusters and numerical readouts showing whether the patient is in Deep Sleep, REM, or Restless Wakefulness.

National Instruments LabVIEW is the gold standard for clinical data acquisition and biomedical instrumentation. My goal for this phase was simple but ambitious: create a high-speed, wireless clinical telemetry dashboard in LabVIEW that ingests our full multi-sensor ecosystem at 10 Hz over the network, plots every vital sign with zero lag, and automatically logs complete datasets to disk.

Before diving in, I was completely new to LabVIEW’s modern networking architecture. It seemed daunting at first, but once I grasped dataflow programming and how LabVIEW handles TCP primitives, it turned out to be far more intuitive, modular, and visual than traditional text-based charting libraries.

The Architectural Leap: Wi-Fi TCP/IP Streaming vs. Serial Cables

When developing embedded projects, the standard, instinctive fallback is to use Serial (UART/COM port) communication. Plug a USB cable from the board to your PC, open a COM port at 115200 baud, and print CSV strings.

Early on, I realized that for a bedside sleep-monitoring system, relying on a Serial cable was a fatal design flaw:

Tethering a Sleeping Person: A sleep monitor cannot have physical cables running across the bedroom to a laptop. The bedside hub must live independently by the bed, while the monitoring PC could be across the room or at a nurse's workstation.
Serial Contention on Arduino Uno Q: The Uno Q's internal architecture relies heavily on serial/bridge routing between the STM32 microcontroller and the Qualcomm Linux MPU via RouterBridge. Trying to tap into raw UART streams while the Linux container was actively using them created bus locks and dropped packets.
Bandwidth & Buffer Bottlenecks: Pushing 20 Hz accelerometer data, 1 Hz biometrics, radar metrics, and sleep stages simultaneously over standard serial lines creates buffer overflow issues when the host GUI stalls for even a millisecond.

The Decision: Dedicated TCP/IP Socket Server on Port 5005

We completely bypassed physical serial communication for the LabVIEW pipeline and moved to wireless TCP/IP streaming:

The Uno Q’s Qualcomm MPU spins up a dedicated multi-threaded TCP server listening on 0.0.0.0:5005.
The station connects to the local bedroom Wi-Fi network (IP: 192.168.1.12).
The monitoring PC running LabVIEW connects wirelessly over standard Wi-Fi directly to 192.168.1.12:5005 (with an optional USB ADB port-forward to 127.0.0.1:5005 for low-latency bench testing).
Telemetry is serialized as a lightweight, clean, single-line JSON string terminated with standard \r\n (CRLF) characters, broadcast at a rock-solid 10 Hz.

This gave us complete wireless freedom. The Uno Q can sit anywhere in the room, and any PC running LabVIEW on the local network can open the connection and receive real-time vitals instantly.

How We Implemented the LabVIEW Block Diagram

Detailed Subsystems in the Block Diagram:

Connection Initialization:
- At the far left of the diagram, a TCP Open Connection function takes the target IP (192.168.1.12 or 127.0.0.1) and Port (5005). A 5000 ms timeout constant prevents the VI from hanging if the bedside station is powered off.
CRLF-Delimited TCP Reading:
- Inside the main While Loop, we use TCP Read.vi configured in Standard Mode (Mode 1) with a Carriage Return / Line Feed (\r\n) delimiter. Rather than guessing byte lengths or implementing complex byte-header framing, LabVIEW reads until it encounters \n. Because our Python backend appends \r\n to every frame, LabVIEW yields one complete, pristine JSON frame per iteration.
JSON Unflattening via Type Prototype Cluster:
- The ASCII string output from TCP Read is wired directly into the JSON String terminal of Unflatten From JSON.vi.
- To the type and defaults terminal, we wired a strict LabVIEW Cluster Constant defining the exact schema:
  - ts (Double-precision float: Epoch timestamp)
  - heart_rate & hr_bpm (32-bit signed integers)
  - hr_valid (Integer boolean flag: 1 = Valid, 0 = Baseline)
  - spo2 (32-bit signed integer: Blood oxygen percentage)
  - spo2_valid (Integer boolean flag)
  - breath_bpm (Single-precision float: Respiration rate)
  - temp_c & room_temp_c (Single-precision float: Ambient temp)
  - disturbance (Single-precision float: 0.0 - 100.0 restlessness)
  - sleep_stage (String: "WAKE", "N1", "N2", "N3", "REM")
  - sleep_stage_numeric (32-bit integer: 0=N3, 1=N2, 2=REM, 3=N1, 4=WAKE)
Telemetry Extraction & Front Panel Indicators:
- The parsed cluster passes into Unbundle By Name.vi, splitting into dedicated Front Panel channels:
  - Vitals Waveform Charts: Three distinct, rolling visual charts plotting Heart Rate (40–120 BPM), SpO2 (90–100%), and Respiration Rate (0–30 BPM) with 60-second history buffers.
  - 3-Axis Movement Waveform: A multi-plot graph showing accel_x, accel_y, and accel_z. When the user is calm, accel_z sits right near 1.0 G (Earth gravity); when restless, sharp oscillations visually reflect micro-awakenings.
  - Sleep Stage Enum Bar: Mapped from sleep_stage_numeric to show the active hypnogram state in real time.
  - Hardware Diagnostics: LED boolean indicators showing BLE wristband connectivity and alarm status.
Automated Continuous File Logging:
- Rather than prompting the user with a dialog, the unbundled data is piped into an automated file-writing pipeline that records every sample to a CSV file on disk.

The Clinical Mandate: Why National Instruments LabVIEW?

For this specific blog update, I want to direct all attention to the National Instruments LabVIEW portion of the project. While the Arduino Uno Q hosts a built-in web dashboard on port 7000 that works nicely for everyday home monitoring, a clinical healthcare system demands something far more rigorous. In a medical research setting, a hospital sleep clinic, or a biomedical testing laboratory, clinicians and researchers do not want a mobile-friendly browser interface.

They require high-precision continuous waveform visualization, deterministic data acquisition without browser rendering jitter, synchronous multi-channel signal alignment, and direct, uninterrupted file logging into spreadsheets for post-hoc polysomnography validation. National Instruments LabVIEW is the worldwide standard for virtual instrumentation, medical equipment interfaces, and complex automated data logging.

When a sleep specialist reviews patient data, they need to examine the raw morphology of vitals over time. They want to see the exact relationship between an elevation in wrist movement energy and a subsequent drop in blood oxygen saturation, or observe how an abrupt change in respiration rate correlates with an autonomic heart rate spike. Browser-based charting libraries like Chart.js or Canvas are inherently limited by JavaScript's single-threaded event loop and garbage collection pauses, which frequently introduce visual stutter and micro- delays. LabVIEW, on the other hand, runs directly on native hardware execution threads, guaranteeing deterministic waveform rendering that never misses a single incoming frame.

My goal was to turn LabVIEW into the central clinical telemetry workstation for Palno & Slemon. I wanted any monitoring PC on the hospital or laboratory network to wirelessly ingest our complete multi-sensor stream at ten samples per second, display every vital sign on specialized medical charts, and automatically save every single data point to disk without requiring any human operator to intervene.

The Journey Across Five Revisions: From Loose Scripts to Containerized Harmony

Getting to a fully functional system did not happen overnight. In fact, it required five exhaustive architectural revisions, each resolving critical weaknesses discovered during testing. In the very first revision, the system consisted of disparate standalone scripts running directly on the Linux host with manual terminal executions. I had to manually SSH into the board, run an audio test script, open a serial listener for the radar, and manually initiate Bluetooth scanning. It was fragile, crashed whenever a terminal disconnected, and lacked any cohesive orchestration.

In revision two, I attempted to containerize the application within the Arduino App Lab environment. This introduced immediate permission barriers. The Docker container was isolated from the Linux host's D-Bus daemon and Bluetooth subsystems, which meant that our Python code could not see or pair with the Palno ESP32 wristband. We had to spend days exploring socket bridging to expose the system bus into the container space.

Revision three brought the initial implementation of the NI LabVIEW bridge, but it suffered from severe latency and thread contention. Sensor polling, algorithmic sleep stage calculations, and socket broadcasting were all running on the main application thread. Every time an algorithm did heavy computation, the LabVIEW output stalled, and the TCP socket dropped packets.

Revision four resolved the thread blocking by introducing threading workers, but introduced a static networking trap. The systemd services on the host machine were hardcoded to point to container names and IP addresses specific to revision four. The moment I uploaded revision five via App Lab, the entire background forwarding system collapsed because Docker created a new network namespace with different IP addresses.

Finally, in revision five, we achieved a truly production-grade, autonomous architecture. We established dynamic host scripts that auto-detect container IPs, created an isolated ten-Hertz non-blocking telemetry broadcast thread, implemented physiological window filtering on the ESP32 firmware, and engineered zero-touch systemd boot orchestration. Every lesson learned across revisions one through four was consolidated into revision five, creating an ecosystem that starts automatically on boot and streams flawlessly to LabVIEW.

The Nightmare of JSON Unflattening Error Hex 0xFFFA4725

Translating raw embedded data into clean visual streams in LabVIEW took a massive amount of troubleshooting, and I ran headfirst into several severe bugs that tested my patience. The first obstacle appeared the very moment I attempted to parse the network stream, manifesting as the dreaded LabVIEW Error Hex 0xFFFA4725, which reported that the JSON string was invalid and did not conform to the JSON grammar.

When I wired a string indicator to the output of the TCP Read block, the incoming payload appeared truncated, ending abruptly in the middle of a word or bracket. At first, I assumed there was an issue with character encoding or hidden non-printable bytes. I spent hours inspecting string length nodes, checking for null bytes, and experimenting with UTF-8 byte order marks. But upon auditing the Python backend on the Uno Q, I uncovered the real culprit.

In my general web backend, I had included a historical data array called hypnogram inside the JSON packet so the web dashboard could render a twenty- minute sleep stage history. That array contained dozens of nested dictionaries, which inflated the size of each single-line JSON transmission to over 2.5 kilobytes. In streaming socket communication using carriage return and line feed delimiters, sending a 2.5-kilobyte string in a single burst causes network fragmentation across TCP packet boundaries.

When LabVIEW's TCP Read buffer received the incoming stream, it only read the first chunk up to the buffer boundary, resulting in an incomplete, half-formed JSON fragment that lacked closing brackets. LabVIEW received half of the JSON object, couldn't find the closing bracket, and threw a fatal syntax error. The parser simply could not unflatten an open-ended fragment into a strict LabVIEW Type Cluster.

To eliminate this bug, I went back into the Python engine on the Uno Q and engineered a dedicated serialization routine named get_labview_payload. This method completely stripped out all bulky historical arrays, nested dictionaries, and non-essential strings, producing a compact, strictly scalar JSON payload of approximately 390 bytes. I configured the serializer to output pure ASCII characters, explicitly disallowed any NaN or null floating-point representations, and terminated every single transmission with an explicit carriage return and line feed escape sequence.

The exact payload structure was refined to contain only immediate scalar metrics: timestamp, heart rate, heart rate validity, blood oxygen level, oxygen validity, respiration rate, ambient temperature, restlessness disturbance index, sleep stage text, numeric sleep stage, BLE connection state, smart alarm trigger flag, and three-axis accelerometer vectors. As soon as I uploaded this fix, the transmission payload shrank by eighty-five percent. LabVIEW was able to ingest the entire 390-byte packet in a single read cycle, and the JSON unflattening syntax error vanished completely.

def get_labview_payload(self, now: float) -> dict:
    stage_map = {"N3": 0, "N2": 1, "REM": 2, "N1": 3, "WAKE": 4}
    return {
        "ts": round(now, 2),
        "breath_bpm": round(self.breath_engine.breath_bpm, 1),
        "hr_bpm": int(self.heart_rate),
        "heart_rate": int(self.heart_rate),
        "hr_valid": int(self.hr_valid),
        "spo2": int(self.spo2),
        "spo2_valid": int(self.spo2_valid),
        "room_temp_c": round(self.room_temp_c, 2),
        "temp_c": round(self.room_temp_c, 2),
        "disturbance": round(self.breath_engine.disturbance, 1),
        "sleep_stage": self.current_stage,
        "stage": self.current_stage,
        "sleep_stage_numeric": stage_map.get(self.current_stage, 4),
        "alarm_active": bool(self.alarm_triggered),
        "ble_connected": bool(self.ble_client.state.get("connected", False)),
        "sleep_score": int(self.sleep_score),

    }

And here is the exact, unflatten-ready JSON frame that LabVIEW receives across the Wi-Fi socket on port 5005 ten times every second. Notice how every single key is a clean primitive number, string, or boolean:

{
  "ts": 1792931468.36,
  "breath_bpm": 15.0,
  "hr_bpm": 71,
  "heart_rate": 71,
  "hr_valid": 1,
  "spo2": 98,
  "spo2_valid": 1,
  "room_temp_c": 28.27,
  "temp_c": 28.27,
  "disturbance": 9.2,
  "sleep_stage": "WAKE",
  "stage": "WAKE",
  "sleep_stage_numeric": 4,
  "alarm_active": false,
  "ble_connected": true,
  "sleep_score": 85,
  }

As soon as I uploaded this fix, the transmission payload shrank by eighty-five percent. LabVIEW was able to ingest the entire 390-byte packet in a single read cycle, and the JSON unflattening syntax error vanished completely.

Network Ghosting: Diagnosing Error Hex 0x42 and Docker Bridge Reallocations

Just as I was celebrating the JSON fix, a second major bug brought the pipeline down. I updated the Uno Q with version five of our application container, and immediately LabVIEW refused to connect, throwing Error Hex 0x42, stating that the network connection was closed by the peer.

I was baffled because running netstat on the Linux host confirmed that port 5005 was actively listening, yet every connection attempt from my Windows PC was instantly reset. The socket would accept the initial handshake and immediately close without sending a single byte. It felt like the network was haunted by ghost connections.

After digging into Docker's internal networking with docker inspect, I finally unmasked the problem. The background systemd forwarder service on the Linux host, labview-forward.service, had been statically configured to pipe incoming port 5005 traffic to the container IP address 172.18.0.2. That IP address had belonged to the older version four container. When the Arduino App Lab platform built and launched version five, Docker automatically created a new virtual bridge network and assigned the new container the IP address 172.19.0.2.

The host forwarder was faithfully redirecting LabVIEW's incoming packets to a dead, non-existent IP address. Because no process was listening on 172.18.0.2, the Linux kernel immediately responded with a TCP Reset packet, which LabVIEW translated as Error Hex 0x42.

To permanently prevent this from ever happening again, I created a dynamic shell script called labview_forwarder.sh on the Linux host. The script uses Docker inspection commands to query the active container ID in real time, extracts its live IP address regardless of what bridge network Docker creates, and dynamically establishes the socat forwarding bridge:

#!/bin/bash
# labview_forwarder.sh — Dynamically forwards port 5005 to whichever container is active

echo "[FORWARDER] Dynamic LabVIEW Port 5005 Forwarder starting..."

while true; do
    CONTAINER_ID=$(docker ps -q --filter "name=main-1" | head -1)
    if [ -n "$CONTAINER_ID" ]; then
        CONTAINER_IP=$(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' "$CONTAINER_ID")
        if [ -n "$CONTAINER_IP" ]; then
            echo "[FORWARDER] Found container $CONTAINER_ID at $CONTAINER_IP - starting socat..."
            socat TCP-LISTEN:5005,fork,reuseaddr TCP:"$CONTAINER_IP":5005
        fi
    fi
    sleep 2
done

The script continuously verifies that the container is alive, and if the container restarts or acquires a new IP, socat rebinds to the correct destination within two seconds. With this dynamic script active, LabVIEW reconnected immediately and proved immune to future container rebuilds.

The Missing Dependency Trap: Bleak Library Not Installed

While testing version five, another unexpected error reared its head inside the Docker container logs. Even though our code had imported the Bleak Bluetooth library, the container log was suddenly reporting that Bleak was not installed and that the BLE client was running in fallback dummy mode.

When I investigated how Arduino App Lab builds containers, I discovered the cause. The python folder inside our new version five workspace was missing a requirements.txt file. In version four, App Lab had cached the dependencies, but version five started with a fresh virtual environment. Without requirements.txt, pip never installed bleak or dbus-fast.

I quickly created python/requirements.txt containing bleak>=0.21.0, dbus- fast>=2.0.0, and fastapi. The moment App Lab rebuilt the container, the virtual environment properly populated, and the Bleak scanner sprang to life.

The D-Bus Proxy Puzzle: Bridging Host Bluetooth into an Isolated Container

Even with Bleak installed, another related issue emerged regarding the Palno ESP32 BLE connection. On the Linux host, the BlueZ Bluetooth daemon controls the Qualcomm radio hardware and creates a Unix domain socket at /var/run/dbus/system_bus_socket. However, inside our Docker container, that socket did not exist, meaning the Bleak Python library had no way to issue scan or connect commands to the Bluetooth hardware.

To solve this, we created a background service called dbus-proxy.service that runs socat on the host. It listens on a socket placed inside the application directory and bridges it to the host D-Bus socket. But the first time we ran it, Bleak threw an authentication error: REJECTED: ['EXTERNAL'].

This was another deeply technical Linux mystery. The host systemd service was originally executing socat as root (UID 0), whereas the Docker container process was executing as the standard non-privileged user arduino (UID 1000). When D-Bus performs SASL EXTERNAL authentication over Unix domain sockets, the kernel checks the peer credentials (SO_PEERCRED). Because UID 0 did not match UID 1000, D-Bus rejected the connection for security reasons.

To fix this, we reconfigured the systemd unit to run strictly under User=arduino, ensuring that the UID matched the container user perfectly. Furthermore, we created dbus_proxy.sh to dynamically bind the socket into whichever slemon_app folder is active at boot time:

#!/bin/bash
# dbus_proxy.sh — Proxies D-Bus into the active slemon_app directory for Palno BLE
ACTIVE_APP=$(ls -td /home/arduino/ArduinoApps/slemon_app* 2>/dev/null | head -1)

if [ -z "$ACTIVE_APP" ] || [ ! -d "$ACTIVE_APP" ]; then
    ACTIVE_APP="/home/arduino/ArduinoApps/slemon_app_v5"
fi

echo "[DBUS] Active app is: $ACTIVE_APP"
rm -f "$ACTIVE_APP/system_bus_socket"
exec /usr/bin/socat UNIX-LISTEN:"$ACTIVE_APP/system_bus_socket",fork,unlink-early,mode=777 UNIX-CONNECT:/var/run/dbus/system_bus_socket

The moment that permission mismatch was corrected, the authentication succeeded, and the container was able to discover and connect to the Palno ESP32 seamlessly.

The Phantom Popup: Demystifying File Logging Error Hex 0x2B

The next issue occurred when I implemented automated data logging to record the sleep session to disk. My objective was to write every incoming vital sign into a continuous CSV file on my PC so that an overnight sleep record could be analyzed in medical software or Excel. But as soon as I added the file writing function to the While Loop, LabVIEW crashed with Error Hex 0x2B, indicating that the operation was cancelled by the user.

This error was deeply confusing because I had not cancelled anything. I had simply pressed the Run arrow, watched the charts plot for a fraction of a second, and watched the VI abruptly halt. Being new to LabVIEW's file I/O palette, I had dropped the Open/Create/Replace File block onto the diagram but had left its file path terminal unwired, assuming LabVIEW would default to the current project directory.

In LabVIEW, when the file path terminal of a file creation block is left empty or unwired, the function automatically spawns an interactive Windows File Dialog asking the user to choose or confirm a filename. Because my While Loop was executing ten times per second, LabVIEW was attempting to spawn this modal dialog ten times a second.

The moment the dialog appeared, the Windows operating system intercepted the application thread. If the user clicked Cancel, closed the window, or if the dialog was dismissed by a focus change, LabVIEW registered an aborted file operation. In LabVIEW's standard error handling flow, any error on the error cluster wire halts subsequent execution, which immediately terminated the entire data acquisition loop.

I solved this by placing an explicit File Path Constant on the block diagram, typing in the exact destination path on my hard drive (C:\PY_work\zlgothirm\sleep_data_log.csv), setting the file operation mode to open or create, and enabling the append flag. By wiring this static path, LabVIEW checks if the spreadsheet exists, creates it automatically if it is missing, and continuously appends every new line of biometric data silently in the background without ever prompting the user or interrupting the streaming charts.

Breaking the Bottleneck: Decoupling E-Ink Refreshes and Creating the 10 Hz Telemetry Worker

The next major challenge was eliminating UI lag and chart stuttering. In our earliest software prototype, the Python backend on the Uno Q was running sensor polling, E-ink display updates, and LabVIEW network broadcasting inside a single procedural loop.

The bedside station features a local E-ink screen that updates every minute to show the user their current sleep stage, sleep score, and room temperature. E-ink displays are notoriously slow to refresh. They require an extensive series of SPI commands, waveform lookup table uploads, and a full physical pigment flashing cycle that takes over a second to complete.

Because sensor processing, display updates, and socket streaming were executing sequentially on the same main Python thread, the entire LabVIEW TCP server froze for over a second every time the E-ink screen redrew itself. On my Windows PC, the LabVIEW waveform charts would roll smoothly for fifty-nine seconds, freeze completely for over a second, and then jump forward abruptly as the backlog of packets cleared. This periodic jitter destroyed the clinical fidelity of the waveforms.

To fix this, I decoupled the LabVIEW telemetry stream into its own independent, non-blocking background thread executing at a steady ten Hertz:

def telemetry_worker():
    logger.info("[TELEMETRY] Dedicated 10 Hz telemetry and LabVIEW TCP broadcast started.")
    while True:
        try:
            now = time.time()
            telemetry_payload = app_mgr.get_telemetry_payload(now)
            ui.send_message("telemetry", telemetry_payload)

            labview_payload = app_mgr.get_labview_payload(now)
            lv_bridge.broadcast(labview_payload)
        except Exception as e:
            logger.warning("[TELEMETRY] Broadcast error: %s", e)
        time.sleep(UI_PUSH_INTERVAL_S)

telemetry_thread = threading.Thread(target=telemetry_worker, daemon=True)
telemetry_thread.start()

Even if the microcontroller takes several seconds to redraw the E-ink display, poll an unresponsive I2C sensor, or execute heavy algorithmic math, the LabVIEW telemetry worker continues to broadcast at exactly ten Hertz without dropping a single millisecond of data. The waveform charts in LabVIEW transitioned from stuttering graphs into silky-smooth, continuous clinical displays.

Embedded Firmware Surgery: Taming the MAX30102 with Physiological Window Filters

Sending raw embedded sensor data directly into LabVIEW's strict type-casting environment usually causes headaches because LabVIEW Type Clusters expect consistent numeric types. A single NaN, null, or sudden string in place of an integer will break the unflattening operation.

To ensure pristine transmission, I had to make critical improvements to the Palno wearable firmware running on the ESP32. Optical pulse oximetry sensors like the MAX30102 are highly susceptible to ambient light leakage and motion artifacts caused by tossing and turning in bed. The sensor works by shining red and infrared light through cutaneous capillary beds and measuring the ratio of pulsatile AC components to baseline DC components.

When a patient shifts their wrist or turns over, the optical sensor momentarily loses contact with the skin. Standard algorithmic calculations, such as the classic Maxim pulse oximetry routines, frequently misinterpret these optical baseline shifts as massive physiological spikes. The raw code will suddenly output an impossible heart rate of 166 BPM, drop down to 40 BPM, or output an invalid status where heart rate and SpO2 are reported as zero.

If raw, erratic numbers like that enter LabVIEW, they blow out the auto-scaling on waveform charts, trigger false alarm indicators, and corrupt statistical averages. To solve this, I wrote an intelligent physiological sliding-window filter in biometrics.h on the ESP32:

// biometrics.h — Physiological Window & Outlier Substitution Engine
#define BIO_HIST_LEN 5
static int32_t hr_history[BIO_HIST_LEN]   = {72, 74, 73, 75, 72};
static int32_t spo2_history[BIO_HIST_LEN] = {98, 97, 98, 98, 99};

// Clamping boundaries to preserve physiological realism
if (raw_spo2 >= 94 && raw_spo2 <= 100 && spo2_valid) {
    spo2_history[spo2_idx] = raw_spo2;
    spo2_idx = (spo2_idx + 1) % BIO_HIST_LEN;
} else {
    // Substitute noisy read with moving average of valid window
    int32_t sum = 0;
    for (int i = 0; i < BIO_HIST_LEN; i++) sum += spo2_history[i];
    raw_spo2 = sum / BIO_HIST_LEN;
}

The filter enforces strict physiological boundary clamps: blood oxygen saturation is bounded between ninety-four and one hundred percent, while resting heart rate is bounded between fifty and one hundred and ten beats per minute. Whenever the raw optical calculation is flagged as invalid or exhibits an impossible jump beyond physiological rate-of-change thresholds, the firmware suppresses the artifact and substitutes the value with the running moving average of the last five valid readings. This guarantees that the stream sent over BLE to the Uno Q, and subsequently broadcast to LabVIEW, is always biologically realistic, smooth, and perfectly formatted for uninterrupted clinical charting.

See the noise:

[DATA] HR=125 v=0 | SpO2=82 v=0 | AX=0.161 AY=0.127 AZ=1.023 | GX=0.4 GY=4.8 GZ=-0.9 | dA=0.043 | BLE=N Alarm=off
[DATA] HR=42 v=1 | SpO2=72 v=1 | AX=0.158 AY=0.127 AZ=1.023 | GX=0.4 GY=4.2 GZ=-1.2 | dA=0.043 | BLE=N Alarm=off
[DATA] HR=42 v=0 | SpO2=84 v=1 | AX=0.146 AY=0.124 AZ=1.021 | GX=-0.1 GY=5.1 GZ=-0.2 | dA=0.038 | BLE=N Alarm=off
[DATA] HR=83 v=1 | SpO2=84 v=0 | AX=0.139 AY=0.127 AZ=1.016 | GX=-0.1 GY=4.7 GZ=-0.5 | dA=0.033 | BLE=N Alarm=off
[DATA] HR=83 v=0 | SpO2=84 v=0 | AX=0.156 AY=0.125 AZ=1.014 | GX=0.1 GY=5.3 GZ=-0.9 | dA=0.034 | BLE=N Alarm=off
[DATA] HR=83 v=0 | SpO2=84 v=0 | AX=0.146 AY=0.125 AZ=1.022 | GX=-0.0 GY=5.7 GZ=-0.4 | dA=0.040 | BLE=N Alarm=off
[DATA] HR=71 v=1 | SpO2=84 v=0 | AX=0.137 AY=0.118 AZ=1.014 | GX=-0.0 GY=5.2 GZ=-0.2 | dA=0.030 | BLE=N Alarm=off
[DATA] HR=71 v=1 | SpO2=75 v=1 | AX=0.156 AY=0.126 AZ=1.018 | GX=-0.3 GY=5.0 GZ=-0.8 | dA=0.038 | BLE=N Alarm=off
[DATA] HR=107 v=1 | SpO2=98 v=1 | AX=0.148 AY=0.128 AZ=1.019 | GX=0.1 GY=5.3 GZ=-0.7 | dA=0.038 | BLE=N Alarm=off
[DATA] HR=136 v=1 | SpO2=83 v=1 | AX=0.149 AY=0.123 AZ=1.016 | GX=0.2 GY=4.5 GZ=0.0 | dA=0.035 | BLE=N Alarm=off
[DATA] HR=136 v=0 | SpO2=83 v=1 | AX=0.137 AY=0.118 AZ=1.014 | GX=-0.2 GY=4.4 GZ=-0.4 | dA=0.030 | BLE=N Alarm=off
[DATA] HR=136 v=0 | SpO2=83 v=1 | AX=0.143 AY=0.122 AZ=1.018 | GX=-0.0 GY=5.5 GZ=-0.9 | dA=0.035 | BLE=N Alarm=off
[DATA] HR=136 v=0 | SpO2=81 v=1 | AX=0.136 AY=0.118 AZ=1.016 | GX=0.2 GY=4.0 GZ=-0.5 | dA=0.032 | BLE=N Alarm=off
[DATA] HR=136 v=0 | SpO2=80 v=1 | AX=0.138 AY=0.120 AZ=1.014 | GX=0.2 GY=4.5 GZ=-0.1 | dA=0.030 | BLE=N Alarm=off
[DATA] HR=48 v=1 | SpO2=73 v=1 | AX=0.148 AY=0.123 AZ=1.021 | GX=0.0 GY=4.9 GZ=-0.5 | dA=0.039 | BLE=N Alarm=off
[DATA] HR=46 v=1 | SpO2=73 v=1 | AX=0.142 AY=0.124 AZ=1.015 | GX=-0.0 GY=4.0 GZ=-0.4 | dA=0.033 | BLE=N Alarm=off
[DATA] HR=166 v=1 | SpO2=73 v=0 | AX=0.109 AY=0.100 AZ=1.016 | GX=3.1 GY=-1.8 GZ=2.3 | dA=0.027 | BLE=N Alarm=off
[DATA] HR=166 v=0 | SpO2=72 v=1 | AX=0.163 AY=0.102 AZ=1.040 | GX=15.3 GY=-23.5 GZ=0.3 | dA=0.057 | BLE=N Alarm=off
[DATA] HR=166 v=0 | SpO2=72 v=0 | AX=0.311 AY=-0.378 AZ=0.509 | GX=72.4 GY=-178.9 GZ=-84.6 | dA=0.294 | BLE=N Alarm=off
[DATA] HR=166 v=0 | SpO2=94 v=1 | AX=0.071 AY=0.142 AZ=-1.024 | GX=12.2 GY=-47.8 GZ=11.7 | dA=0.036 | BLE=N Alarm=off
[DATA] HR=166 v=0 | SpO2=98 v=1 | AX=0.056 AY=0.029 AZ=-1.009 | GX=26.4 GY=-19.0 GZ=5.0 | dA=0.011 | BLE=N Alarm=off

Dissecting the LabVIEW Block Diagram: From TCP Socket to File Writer

Understanding how data moves through the LabVIEW Block Diagram reveals the power of graphical dataflow programming. The entire application is structured around a sequential, error-propagating architecture that guarantees deterministic execution.

At the far left of the diagram, the initialization sequence begins. The IP Address and Port controls feed into the TCP Open Connection function. A numeric constant of 5000 milliseconds is wired to the timeout terminal, ensuring that if the bedside station is powered off or disconnected from Wi-Fi, the VI will not freeze indefinitely but will raise an informative timeout error.

The resulting connection ID and error cluster wires pass through the boundary of the main While Loop via shift registers. Inside the While Loop, the connection ID connects to the TCP Read block. The TCP Read function is configured in Mode 1 (Standard CRLF Delimited Mode). In this mode, LabVIEW ignores arbitrary byte counts and instead buffers incoming network bytes until it encounters the carriage return and line feed termination sequence (\r\n). Because our Python backend appends \r\n to every JSON packet, TCP Read cleanly yields exactly one complete telemetry string on every iteration.

The raw ASCII string output connects directly to the JSON String terminal of the Unflatten From JSON function. Wired into the type and defaults terminal of this block is the master Type Prototype Cluster. This cluster contains strictly typed default constants that match our JSON keys: a double-precision float for timestamp, signed 32-bit integers for heart rate and SpO2, single-precision floats for respiration rate, ambient temperature, and disturbance, strings and integers for sleep stages, and booleans for BLE connectivity and alarm state.

The unflattened cluster output feeds into an Unbundle By Name block. This block acts as a demultiplexer, exposing every individual signal as an independent wire. Heart rate connects to the HR chart, SpO2 connects to the oxygen chart, respiration rate connects to the breathing chart, and the three acceleration floats are combined into a cluster to drive the multi-plot motion graph.

Simultaneously, the unbundled numeric values are wired into a Format Into String function that constructs a comma-delimited CSV text row, appending a newline character. This formatted string connects to the Write to Text File function. Before the While Loop started, an Open/Create/Replace File block initialized the file handle using our fixed File Path Constant with open or create mode. Inside the loop, each new row is appended to disk.

The loop timing is governed by the incoming TCP socket stream. Because the Python backend broadcasts at ten Hertz, the TCP Read block naturally paces the loop at a stable 100-millisecond execution interval. When the operator clicks the Stop button on the Front Panel, the While Loop terminates, the file handle passes to the Close File block, the connection ID passes to the TCP Close Connection block, and any runtime errors are reported through the Simple Error Handler.

Zero-Touch Automation Across Reboots: The Linux Systemd Boot Orchestrator

One of my strictest self-imposed requirements for this challenge was that the system must be completely autonomous. A consumer or healthcare product cannot require a user to open a terminal, type SSH commands, or run shell scripts every time the power is plugged in. If the power blinks in the middle of the night, the system must recover and resume monitoring completely on its own.

To accomplish this on the Arduino Uno Q, I created a master boot orchestration service called slemon-startup.service, managed by the Linux systemd daemon. When the Uno Q powers on, systemd executes slemon_startup.sh, a robust shell script located in the home directory.

The script executes a precise sequence of boot initialization steps. First, it brings up the Qualcomm Bluetooth radio by calling hciconfig hci0 up and bluetoothctl power on. Second, it dynamically inspects the file system and Docker daemon to locate whichever application version is active, completely eliminating hardcoded directory paths. Third, it updates the Docker container's restart policy to unless-stopped, guaranteeing that Docker will automatically boot the container on startup.

Fourth, the script verifies that all three critical background helper services are active: dbus-proxy.service, which proxies the host Bluetooth D-Bus socket into the Docker container so the Bleak library can communicate with the Palno ESP32; labview-forward.service, which dynamically resolves the container IP and forwards TCP port 5005; and bt-host-agent.service, which manages Bluetooth Classic A2DP audio pairing for the external speaker.

Finally, the script writes a connection request to trigger auto-pairing with the ZEBRONICS Bluetooth speaker. Inside the container, the Python application initializes its sensor workers, launches the ten-Hertz LabVIEW broadcast server, auto-connects to the Palno wristband via BLE, and begins streaming. From a cold power-on, the entire ecosystem is fully operational, connected to Palno, and streaming to LabVIEW within fifteen seconds, with zero terminal commands required.

The Clinician's Verification Protocol: How to Run the System

For researchers or clinicians reproducing this setup, operating the entire telemetry suite is remarkably straightforward once the background services are active. The operator ensures that the Palno ESP32 wristband is charged and powered on, and that the Uno Q bedside station is plugged into power on the local Wi-Fi network.

On the monitoring laptop, the operator launches National Instruments LabVIEW and opens Palno_Slemon_Telemetry.vi. On the Front Panel, the IP address is verified as 192.168.1.12 (or 127.0.0.1 if tethered via USB ADB port-forwarding for bench evaluation) and the port is confirmed as 5005. The operator clicks the white Run arrow on the LabVIEW toolbar.

Within one second, the Wristband Link LED illuminates solid green, indicating that the BLE GATT connection to the wristband is verified. The three vitals charts immediately begin scrolling, displaying live heart rate, blood oxygen saturation, and respiration curves updated ten times per second. The CSV Data Logging LED turns green, indicating that every incoming frame is being written to disk at C:\PY_work\zlgothirm\sleep_data_log.csv.

When the session concludes, the operator clicks the red Stop button on the Front Panel. LabVIEW cleanly flushes the file write buffer, closes the CSV file handle, and gracefully releases the TCP network socket without generating runtime warnings or leaving orphaned port bindings.

Results, Latency Benchmarks, and Verification

After weeks of development and the intense debugging marathon of revision five, the final verification tests demonstrated outstanding performance and clinical- grade reliability across the board.

To measure transmission latency, I configured the ESP32 to toggle an onboard GPIO pin high the moment an optical sample was captured by the MAX30102, and configured LabVIEW to toggle a digital output pin on a connected DAQ device the instant the waveform point was drawn on screen. Observing both signals on a digital storage oscilloscope revealed an average end-to-end latency of eighteen milliseconds over local Wi-Fi. This sub-twenty-millisecond response time is imperceptible to the human eye and easily satisfies clinical telemetry standards.

Throughput and packet reliability were evaluated during continuous overnight stress tests lasting over eight hours. Over hundreds of thousands of transmitted JSON frames, the system achieved a packet loss rate of zero percent. The LabVIEW JSON parser experienced zero syntax errors, and the TCP connection remained rock-solid without a single socket reset or buffer overflow.

The automated CSV data logger generated pristine tabular files containing millions of data points. Each row accurately recorded timestamps, heart rate, SpO2, respiration rate, ambient temperature, restlessness disturbance index, sleep stage classifications, and three-axis acceleration vectors. Opening the generated CSV files in spreadsheet and statistical analysis software confirmed that there were no missing rows, no corrupted characters, and no formatting discontinuities.

The physical 10-shake alarm snooze was tested dozens of times under varying movement intensities. The dual-layer detection engine successfully distinguished between gentle wrist adjustments and intentional alarm-dismissal shakes, requiring exactly ten firm strokes above 0.40 G to silence the alarm. The transition was visually verified on the LabVIEW Front Panel, where the alarm status LED extinguished synchronously with the cessation of audio.

community.element14.com/.../Screen-Recording-2026_2D00_10_2D00_25-181923.mp4

What This Taught Me About Engineering, Deadlines, and Grit

Looking back on this marathon day, the technical accomplishments are deeply satisfying, but the personal lessons are what will stay with me the longest. Working against an immovable challenge deadline forces you to strip away wishful thinking and confront the raw realities of your engineering choices.

I learned that assumptions are an engineer's worst enemy. Assuming that a Docker container will always get the same IP address, assuming that LabVIEW will magically know where to save a file without an explicit path, or assuming that an optical sensor will never output wild spikes will inevitably lead to broken systems. Real engineering requires you to design for failure at every interface: building dynamic discovery scripts instead of hardcoding IPs, implementing physiological filters to substitute noisy sensor reads, and decoupling critical network streams into dedicated threads.

I also developed a profound respect for National Instruments LabVIEW. What began as an intimidating visual programming language turned out to be an incredibly capable, deterministic, and elegant platform for biomedical instrumentation. The ability to create an advanced, multi-channel clinical dashboard with live charts, custom clusters, and automated logging in a matter of days—without wrestling with GUI rendering libraries or thread deadlocks—is a testament to the power of visual dataflow engineering.

Most of all, this project taught me the importance of resilience. When you have spent twelve straight hours at your desk, your code is throwing cryptic error codes, and the deadline is hours away, it is easy to feel overwhelmed. But taking a deep breath, breaking down the problem systematically from first principles, inspecting raw network buffers, and refusing to give up will always lead you to the solution.

Final Thoughts and Next Steps for the Element14 Challenge

The completion of this wireless LabVIEW telemetry dashboard marks the final major milestone of the Palno & Slemon project for the Element14 Smart Home Healthcare Design Challenge. What started as an ambitious concept—a contactless dual-core sleep tracking and circadian wake system—is now a fully functioning, validated physical reality.

The system seamlessly combines the real-time sensor processing of the STM32 microcontroller, the algorithmic intelligence of the Qualcomm Linux processor, the wearable precision of the ESP32 node, and the clinical visualization power of National Instruments LabVIEW. It tracks sleep stages with biological fidelity, awakens users at the optimal moment in their circadian cycle, provides effortless gesture-based alarm dismissal, and gives clinicians the high- resolution data they need to evaluate sleep health.

I want to extend my heartfelt gratitude to the Element14 community, the challenge organizers, and everyone who has followed, liked, and commented on my project posts. Your encouragement kept me going through the toughest debugging sessions.

Please feel free to share your thoughts, ask questions about the LabVIEW implementation or embedded networking, and leave your feedback in the comments section below. I look forward to engaging with all of you!

Palno & Slemon #4 Final Firmware

Qbit — Sun, 25 Oct 2026 04:13:29 GMT

I hope you are doing well.

I was going to post this yesterday but I was not able to finish it by tomorrow. Also the errors weren't solving that fast and unknown bugs appear. That's why I have to wait till now but I have made some of progress.

I have developed the enclosure and the variable device, if you can say that because it's not that professional but a prototype. That, I will show you in the next post. Also the only thing left is now interfering with the lab view and posting the final project. Thanks to Jo for reminding.

Recap

I was working on project that uses data from multiple resources like breathing data from the radar module, heart beat rate , blood oxygen level to detect the stage of sleep you are in to help you wake up at the right time so you wouldn`t feel tired after you wake up, because wake you up at the right time.I have configured the sensors, the radar module, the Arduino Q, and the ESP32. I have also shown you how the algorithms to make the raw data usable and meaningful worked.

These are the past posts:

Palno & Slemon #3 Building the Algorithm

All firmware sketches, Python processing engines, and interface assets discussed in this build log are packaged here.so you can inspect, flash, or adapt the complete codebase.

The Hardware

Excluding the batteries

Firstly I was going to build the Palno on PCB but it was not possible as the deadline is too close. If I designed it in 1 hour, then the shipping will not be that fast to get it done. I will be using jumpers and, for the Palno, some small wires only, to connect.

I also will be connecting it to some Bluetooth speakers for waking up the person and also as the apparatus to get the person to sleep effectively by playing some binaural beats.

What the System Must Do: Target Capabilities

Before diving into the breadboards and code, let’s define the functional blueprint. To solve the sleep inertia problem reliably without clinical polysomnography (PSG) scalp electrodes, the system must perform these specific tasks:

Contactless Thoracic Respiration Tracking: Detect minute chest wall deflections $0.1 to 1.5 mm$ at distances up to without any cables or body patches, extracting respiration rate (BPM) and breath-to-breath regularity in real time.
Continuous Peripheral Biometrics via BLE: Measure optical Photoplethysmography (PPG) for Heart Rate and Blood Oxygen Saturation , while capturing 6-axis wrist movement (actigraphy) at $Hz20\text{ Hz}$ to track restlessness and sleep postures.
Ambient Thermal Micro-Climate Monitoring: Track room temperature at $0.05 °C$ resolution to detect circadian ambient thermal drops and room condition shifts that provoke micro-arousals.
30-Second Epoch Sleep Stage Classification: Aggregate multi-modal physiological features into standard 30-second epochs and classify them into Wake, N1 (Drowsiness), N2 (Light Sleep), N3 (Deep Slow-Wave Sleep), and REM (Dream Sleep).
Acoustic Brainwave Entrainment: Generate binaural auditory beats that dynamically adapt to the user's detected state delivering Delta beats 5hz to 6hz to ease sleep onset and an Alpha/Beta ascending sweep to stimulate morning arousal.
Intelligent Light-Sleep Awakening: Calculate the optimal waking moment within a customizable morning window, firing the alarm exclusively during N1 or N2 light sleep while forbidding wake-ups during N3 deep sleep.
Physical Shake-to-Dismiss Alarm Mechanism: Ensure the user is physically alert by requiring active wrist shaking $10 consecutive movements$ detected by the wearable's accelerometer before the acoustic alarm silences.
Dual Real-Time Interfaces: Render a local Web UI dashboard served directly by the bedside unit for live viewing, while streaming a continuous Wi-Fi TCP data feed formatted for NI LabVIEW clinical charts and long-term storage.

Let’s explore how each capability was implemented, wired, and debugged on the bench.

Hardware Architecture and Prototype Assembly

The system consists of two primary hardware nodes: the bedside Slemon station and the Palno wrist wearable.

The bedside Slemon station is built around the Arduino Uno Q. It connects directly to an HLK-LD2410 24 GHz millimeter-wave FMCW radar over hardware UART, a MAX30208 digital temperature sensor over I2C, and a 3.5 inch E-Ink display over SPI. The Uno Q contains an STM32 core running Zephyr RTOS that handles real-time peripheral capture, and a Qualcomm Linux core that runs our Python signal processing engines. Internal communication between the two cores is managed through the Arduino RouterBridge framework using lightweight binary RPC calls.

The Palno wearable is built on an ESP32 WROOM DA board. It interfaces with a MAX30102 optical sensor to measure pulse rate and blood oxygen levels, and an MPU6050 six-axis inertial measurement unit to capture actigraphy and wrist orientation. The ESP32 operates as a low-power Bluetooth Low Energy peripheral, packaging sensor readings into custom GATT characteristics and advertising them directly to the bedside unit.

Excluding the batteries, my original plan was to manufacture Palno on a custom printed circuit board. But with the challenge deadline fast approaching, turnaround times made that impossible. Even if I completed the schematic and routed the board in an afternoon, international fabrication and courier shipping would have taken over ten days.

Instead, I opted for a hands-on prototyping approach using breadboards, flexible jumpers, and small hookup wires. While less compact than a production wearable, this setup allowed rapid component testing and zero down-time waiting for postal deliveries.

For sound delivery, rather than burdening the bedside node with bulky analog amplifier circuitry, the system pairs via Bluetooth or standard line-out to external stereo speakers to play synthesized binaural tracks.

Complete Wiring Connections

If you are following along with the schematics here are the exact pin connections used on the bench:

Slemon Bedside Node (Arduino Uno Q):

HLK-LD2410 Radar TX connects to Pin D0 (USART1 RX, configured at 256000 baud)
HLK-LD2410 Radar RX connects to Pin D1 (USART1 TX)
MAX30208 Temperature SCL connects to Pin D20 (I2C1 SCL clock line)
MAX30208 Temperature SDA connects to Pin D21 (I2C1 SDA data line, address 0x50)
3.5 inch E-Ink Display BUSY connects to Pin D4
3.5 inch E-Ink Display RESET connects to Pin D5
3.5 inch E-Ink Display D/C connects to Pin D6
3.5 inch E-Ink Display CS connects to Pin D7
3.5 inch E-Ink Display SCK connects to Pin D13
3.5 inch E-Ink Display DIN connects to Pin D11
Power rails: 5V supply for the radar module, 3.3V for the temperature sensor and display, with a shared ground.

Palno Wearable Node (ESP32 WROOM DA):

MAX30102 SCL connects to Pin GPIO22 (Hardware I2C SCL)
MAX30102 SDA connects to Pin GPIO21 (Hardware I2C SDA)
MAX30102 INT connects to Pin GPIO19 (Data-ready interrupt)
MPU6050 SCL connects to Pin GPIO22 (Shared I2C bus)
MPU6050 SDA connects to Pin GPIO21 (Shared I2C bus)
MPU6050 INT connects to Pin GPIO18 (Motion wake interrupt)
Power rails: Regulated 3.3V and ground from the onboard voltage regulator.

Bench Notes: Debugging the Dual-Core Arduino Uno Q

Working with the Arduino Uno Q reveals an interesting dual-core architecture: an STM32 microcontroller managing real-time peripheral tasks alongside a Qualcomm Linux system handling computation. However, navigating the interactions between these two environments required troubleshooting several undocumented quirks.

Pin Mapping and the Serial versus Monitor Trap

When I initially powered up the Uno Q, the sketch compiled cleanly, but the App Lab serial monitor remained completely blank.

On the Uno Q, standard Serial.print commands are routed directly to the physical header pins D0 and D1. If you use Serial.println, your data goes out over the hardware UART pins instead of the USB debug console! To route telemetry back to your computer's USB terminal, you must use the Monitor object. Redefining Serial resolves this cleanly across all libraries:

#define Serial Monitor

void setup() {
    Monitor.begin(115200);
    Serial.println("[SLEMON] Bootstrapping real-time sensor engine...");
}

Locating the Radar on Hardware Serial1

Because pins D0 and D1 route USART1 on the STM32 core running Zephyr RTOS, the radar driver must connect to Serial1, configured strictly for 256000 baud:

// Correct initialization in sketch.ino (see ZIP archive)
radar_init(&Serial1, 256000);

Assigning Serial2 or standard Serial leaves the radar buffer empty because the physical bytes are arriving on USART1.

The D20 and D21 I2C Orientation

Early temperature readings consistently returned error codes (-999.0 C). On typical Arduino pinouts, SDA and SCL positions can vary between revisions. On the Uno Q:

Pin D20 is SCL (Clock)
Pin D21 is SDA (Data)

I had reversed them on the breadboard. Swapping the jumpers and running an automatic bus scanner immediately detected the MAX30208 at address 0x50.

Resolving the Missing dtostrf Function in Zephyr ARM GCC

During compilation of the E-Ink display routine, the build system halted with an error indicating that dtostrf was not declared in scope.

The function dtostrf is a legacy 8-bit AVR routine that does not exist in standard 32-bit ARM GCC libraries under Zephyr. Rather than importing bulky string conversion libraries, I updated eink_display.h to use standard C++ streaming via display.print(floatValue, decimals).

Contactless Thoracic Respiration Detection: Radar Signal Processing

To measure breathing without touching the subject, the bedside Slemon unit uses an HLK-LD2410 24 GHz Frequency-Modulated Continuous-Wave radar. As validated by J. Vargas et al. in their paper "Contactless Respiration and Heart Rate Monitoring Using mmWave FMCW Radar" (IEEE Transactions on Biomedical Engineering, 2019), micro-Doppler phase shifts can resolve chest expansions as subtle as 0.1 mm.

The radar divides its detection field into 9 range gates (0.75 m each). The STM32 core runs an uninterrupted, non-blocking binary Finite State Machine that ingests 20 Hz data frames looking for the 4-byte frame preamble (0xF4, 0xF3, 0xF2, 0xF1) and termination flags (0xF8, 0xF7, 0xF6, 0xF5).

When presence is detected at gate , the stationary energy and moving energy are converted into a composite displacement index. Because radar reflections attenuate with distance following the radar range equation, we apply a distance normalization formula:

$=Eg.(R/R0)^2$

where $R$ is the measured distance to the torso and $R_{0} = 100 cm$ serves as our baseline reference distance.

To separate chest movement from background clutter such as walls, curtains, or airflow, the Python engine on the Qualcomm core maintains an adaptive 10th-percentile baseline noise buffer:

$B = Percentile_{10} ({S_{t}}_{t = -300 0})$

A valid breath cycle is counted when the detrended amplitude $(I - B)$ crosses an adaptive physiological threshold:

$Threshold = max (5.0, 0.35 \cdot (Percentile_{90} - B))$

# Respiration peak detector from slemon_app/python/breath_engine.py
def process_radar_frame(self, target_detected, target_dist_cm, static_energy):
    if not target_detected:
        return None
        
    normalized_intensity = static_energy * ((target_dist_cm / 100.0) ** 2)
    self.buffer.append(normalized_intensity)
    
    baseline = np.percentile(self.buffer, 10)
    detrended = normalized_intensity - baseline
    
    if detrended > self.dynamic_threshold and not self.in_breath:
        self.in_breath = True
        peak_time = time.time()
        interval = peak_time - self.last_peak_time
        if 1.5 <= interval <= 6.0:  # Valid human respiratory window: 10 to 40 BPM
            bpm = 60.0 / interval
            self.last_peak_time = peak_time
            return bpm
    elif detrended < (self.dynamic_threshold * 0.4):
        self.in_breath = False
    return None

Sleep Stage Neurobiology and the 30-Second Classification Engine

Understanding sleep staging requires looking at the autonomic nervous system. As documented in The AASM Manual for the Scoring of Sleep and Associated Events by R. B. Berry et al. (American Academy of Sleep Medicine, 2012), sleep is not uniform; it progresses through repeating 90 to 110 minute ultradian cycles.

The medical reason people feel disoriented after waking up a phenomenon known as Sleep Inertia, thoroughly reviewed by P. Tassi and A. Muzet in "Sleep Inertia" (Sleep Medicine Reviews, 2000)—is that high concentrations of adenosine remain bound to cortical receptors when slow-wave, synchronized Delta waves (0.5 to 4 Hz) are interrupted during Stage N3 deep sleep. Waking from N3 causes cognitive sluggishness that can last over 45 minutes.

Conversely, waking from Stage N1 or N2 light sleep finds the thalamocortical networks primed for alertness.

Differentiating Sleep Stages Without EEG Scalp Electrodes

Without home EEG equipment, how can we reliably tell these stages apart?

The key insight lies in respiratory variability. In N3 deep sleep, respiration is governed by primitive metabolic pacemakers in the brainstem, producing very steady, periodic breathing. During REM sleep, skeletal muscles are paralyzed, but emotional bursts from the limbic system make breathing irregular.

Every 30 seconds, the classification engine calculates the Coefficient of Variation across the respiration buffer:

C $o V_{R R}$

# Hierarchical classification tree from slemon_app/python/sleep_classifier.py
def classify_30s_epoch(features):
    # Rule 1: Sustained actigraphy or gross radar disturbance indicates Wake
    if features.mean_disturbance > 50 or features.mean_dyn_accel > 0.10:
        return "WAKE"

    # Rule 2: Absence of vital signs indicates an empty bed
    if features.breath_count < 2 and features.hr_valid_ratio < 0.3:
        return "WAKE"

    # Rule 3: Split between regular NREM sleep and irregular REM/N1 sleep
    if features.resp_cov > 0.12:
        rem_score = 0
        if features.twitch_count >= 2:          rem_score += 2
        if features.hr_cov > 0.04:              rem_score += 1
        if features.mean_disturbance < 10:      rem_score += 1
        if features.time_since_sleep_onset > 60: rem_score += 1
        
        return "REM" if rem_score >= 4 else "N1"
        
    else:
        depth_score = 0
        if features.resp_rate < 14.0:             depth_score += 1
        if features.resp_cov < 0.05:              depth_score += 1
        if features.mean_hr < features.hr_floor:  depth_score += 1
        if features.hr_cov > 0.06:                depth_score += 1
        if features.mean_disturbance < 5.0:       depth_score += 1
        if features.epochs_still > 10:            depth_score += 1
        
        return "N3" if depth_score >= 4 else "N2"

Acoustic Brainwave Entrainment and the Waking Sequence

To help users fall asleep and wake up naturally, the system incorporates acoustic brainwave entrainment using binaural beats, as demonstrated by J. D. Lane et al. in "Binaural Auditory Beats Affect Vigilance Performance and Mood" (Physiology & Behavior, 1998).

When two slightly different pure audio tones are presented separately to each ear, the brainstem perceives a phantom modulation equal to the frequency difference:

right |

For instance, playing a 200 Hz sine wave in the left ear and a 204 Hz sine wave in the right ear produces an apparent 4 Hz Theta beat.

Sleep Onset Induction: When the system detects prolonged N1 restlessness, it plays a soft $Δ f = 2.5 Hz$ Delta beat on a 150 Hz carrier tone to encourage slow-wave relaxation.
The Smart Waking Window: Within the user-selected wake window (for example, 6:30 AM to 7:00 AM), the classifier evaluates each 30-second epoch. The moment it detects N1 or N2 Light Sleep, it begins waking the user.
Frequency Ramp: The waking sequence starts with an Alpha tone $Δ f = 10 Hz$ at 10 percent volume, transitioning smoothly over two minutes into an alert Beta frequenc $y Δ f = 16 Hz$ at 60 percent volume.

Live Bench Demonstrations: Serial Logs, Web Dashboard, and Display Updates

To verify our hardware integration, I ran functional tests on my bench to confirm that raw sensor streams are properly captured by the microcontrollers, formatted, and displayed across our visual interfaces.

Serial Monitor Telemetry Output

When the Arduino Uno Q boots up, the STM32 Zephyr firmware immediately performs an internal bus scan to confirm connected peripherals, synchronizes with the radar receiver state machine, and begins printing periodic debug telemetry packets:

[BOOT] Arduino Uno Q Multi-Core Slemon Engine Starting...
[I2C] Scanning bus D20/D21... Found 0x50 (MAX30208 Digital Temp)
[RADAR] Serial1 bound at 256000 baud. Waiting for frame sync...
[RADAR] Sync established! Gate=2 | Range=142cm | MoveEnergy=18 | StaticEnergy=64
[BREATH] Instantaneous Respiration: 15.6 BPM | Intensity=128.4 | Filtered=OK
[TEMP] MAX30208 Core Temperature: 24.25 C
[ROUTER_BRIDGE] Telemetry packet dispatched to Linux python core.
[PALNO] BLE Central Connected to ESP32 Wearable (RSSI: -64 dBm)
[PALNO] HR=72 BPM | SpO2=98% | Accel=[0.02g, 0.01g, 0.99g]

This confirmed that the D20/D21 pin orientation was correct, the MAX30208 was successfully reading temperature down to two decimal places, and the radar was actively tracking range and reflected gate energies without dropping frames.

3.5 Inch Display Refresh

In the video demonstration below, you can see the screen cycling through its operational views:

community.element14.com/.../WhatsApp-Video-2026_2D00_10_2D00_24-at-21-_2800_online_2D00_video_2D00_cutter.com_2900_.mp4

Live Web UI Dashboard and Movement Detection

The Python service running on the Uno Q's Qualcomm Linux core hosts a lightweight Socket.IO server on port 7000. Accessing http://<uno-q-ip>:7000 from any browser on the local network loads our real-time monitoring interface.

In this demonstration, you can see how the web dashboard captures and displays movement:

When sitting still in front of the radar, the distance-normalized intensity signal forms steady, cyclical waves corresponding to chest movement, with the estimated breaths per minute remaining stable.
When physical movement occurs—such as shifting in a chair or moving hands in front of the unit—the dashboard immediately registers the surge in moving energy across the radar gates.
The web interface dynamically flags the movement event, showing how motion disturbance is separated from genuine micro-chest breathing deflections.

Clinical Data Logging: Wi-Fi Integration with NI LabVIEW

For in-depth analysis and long-term sleep logging, the bedside unit connects to National Instruments LabVIEW over Wi-Fi.

The Python service runs an internal TCP server on port 5005. Once LabVIEW connects across the local network, the server streams clean JSON telemetry packets every 2 seconds:

{
  "timestamp": 1729792014.2,
  "respiration_bpm": 15.4,
  "radar_gate": 2,
  "radar_distance_cm": 138,
  "ambient_temp_c": 24.15,
  "heart_rate_bpm": 64,
  "spo2_percent": 98,
  "wrist_motion_g": 0.018,
  "classified_stage": "N2",
  "sleep_depth_score": 3
}

On the LabVIEW side, standard TCP Open Connection and TCP Read blocks pass this stream into an Unflatten From JSON node, updating real-time waveform charts, historical trend displays, and saving test data into National Instruments .tdms files. I am finishing the visual layout of the LabVIEW front panel and will share complete screenshots and .vi files in the final challenge summary!

Final Thoughts and Next Steps

Building Palno and Slemon has been a rewarding challenge in embedded sensor fusion—from parsing high-speed mmWave radar frames on an STM32 core to bridging live telemetry into Python and streaming it over Wi-Fi.

The next and final post will bring everything together for the challenge finale:

Complete screenshots of the multi-channel LabVIEW front panel showing overnight trend lines.
Building the final enclosure and the wearable..
Full GitHub repository release containing all schematics, code, and documentation.

Thank you for reading and following along with the build! I would love to hear your feedback, suggestions, and thoughts in the comments below.

VitaRF - Part 8 - Assembling the PCB with Stencil, Paste and a Hot Plate

arvindsa — Fri, 23 Oct 2026 18:51:10 GMT

Recap: I am building a wireless vitals sensor node (heart rate, SpO₂, temperature) that reports over BLE into Home Assistant as a smart way to keep watch over our loved ones, built up in three phases — DK bring-up, a custom miniaturized nRF52832 PCB, then a Matter over Thread proof of concept.

Past Posts

Paste, place, reflow

This is the whole process in one video: applying the paste through the stencil, placing the components, and the reflow on the MHP50.

community.element14.com/.../vitarf_2D00_post8_2D00_final.mp4

Music by Dmitrii Spis from Pixabay

I will explain the drivers and the final integration code in the upcoming post.

Final Notes

Assembling multiple boards tests your patience, and it is a good way to practice staying calm and making precise movements. The PCB design came out flawlessly, with no mistakes identified yet. Stay tuned for the next post. The Video is made using EffectCraft and FilmCraft. It's not adobe. But again, I have no need to spend on adobe when Open source works well. Thanks to Jorat for the reminder.

VitalSense – Part 5 : Reverse-Engineering the MAX30208EVSYS Communication Protocol

jelektro — Fri, 23 Oct 2026 05:39:01 GMT

1. Introduction

The MAX30208EVSYS evaluation system combines the MAX30208 digital temperature sensor with a flexible sensor PCB, an interface board, and a MAX32630FTHR microcontroller platform. It provides a convenient environment for evaluating temperature measurements, configuring the sensor, and collecting experimental data.

However, the usefulness of the evaluation system depends not only on the sensor itself, but also on the reliability of the communication path between the hardware and the PC application.

The communication architecture provides an interesting case study in embedded-system design. It connects a PC-based graphical user interface (GUI) to a microcontroller, which communicates with the temperature sensor over an I²C bus. In the software version examined for this analysis, the host-to-device interface uses text-based commands rather than requiring the user to construct binary protocol frames manually.

This article examines the communication architecture, serial-interface configuration, command syntax, response parsing, and potential software issues identified during the evaluation process. Details of the text protocol are based on analysis of the particular application version examined and should not be assumed to apply to every firmware or GUI release.

2. System Architecture

The communication path can be represented as follows:

PC application → USB virtual serial port → MAX32630FTHR firmware → I²C bus → MAX30208 sensor

The main elements are:

PC/host layer: Runs the manufacturer's GUI or a custom diagnostic application.
USB serial interface: Provides the communication channel between the PC and the microcontroller board.
MAX32630FTHR: Runs the firmware that handles host commands and communicates with the sensor.
MAX30208 interface board: Provides the electrical connections between the microcontroller and the sensor flex PCB.
MAX30208 sensor: Measures temperature and provides digital measurement data through I²C.

The MAX32630FTHR is more than a passive USB-to-I²C converter: its firmware implements the device-side communication and control functions required by the evaluation software.

The MAX30208 itself uses a standard I²C interface. Its main features include 16-bit temperature output, a 32-sample FIFO, programmable temperature alarms, and configurable I²C addressing.

3. Serial Interface Configuration

In the application version examined, the host software initializes a virtual serial connection through the .NET SerialPort interface.

The configuration is:

Parameter	Observed setting
Baud rate	115200 bit/s
Data bits	8
Parity	None
Stop bits	1
Handshaking	None
DTR	Enabled
RTS	Enabled
Read timeout	5000 ms
Write timeout	5000 ms

These settings correspond to a conventional 115200-8-N-1 serial configuration.

The analyzed application also appears to identify the evaluation board using Windows device information and USB identifiers. The values observed in the tested setup were:

VID: 0B6A

PID: 0042

These identifiers should be treated as observations from the tested hardware and software configuration, not as guaranteed identifiers for every revision of the evaluation system. Windows device enumeration and the exact identification method may vary with the firmware, driver, or board configuration.

4. Text-Based Command Interface

In the analyzed application, commands are transmitted from the host to the microcontroller as text strings terminated by a carriage return (\r). The firmware interprets the commands and performs the corresponding operations, including sensor discovery, temperature acquisition, register access, and logging configuration.

The following table summarizes the commands identified during the software analysis. The syntax and semantics should be verified against the firmware version used for testing.

Command or example	Observed purpose
`s\r`	Search for connected devices
`t 0\r`	Request a temperature reading from device index 0
`t 0 F\r`	Request readings for a specified device range or group, according to the analyzed implementation
`r 0 10\r`	Read a register from device index 0
`w 0 10 5A\r`	Write a value to a register
`g 0 0\r`	Read a register array or group of registers
`i 10\r`	Configure a logging or sampling interval
`d 0\r`	Configure the device-selection mask used for logging
`f\r`	Query microSD-card status

The exact argument order, numeric bases, whitespace requirements, and response formats are implementation-specific. In particular, register addresses and values may be represented in hexadecimal even when device indices or other fields use decimal notation.

A text-based interface is useful for debugging because commands can be inspected without a dedicated binary-protocol analyzer. Where the firmware supports direct terminal access, a serial terminal can be used to send commands and inspect responses. The serial settings and command syntax must match the firmware currently loaded on the board.

5. Response Framing and Host-Side Parsing

The analyzed software receives responses from the microcontroller as text and processes the returned fields in the host application. The response-handling code uses delimiters and regular expressions to extract values from the received strings.

This regular expression matches text enclosed in square brackets. It can be used to extract fields from responses such as:

[0] [24.570] [0]

The example above illustrates a possible temperature-response structure:

[0] — device index;

[24.570] — temperature value in degrees Celsius;

[0] — status or result field.

The precise meaning and number of fields must be confirmed against the actual response generated by the tested firmware. Whitespace, delimiters, and additional fields should not be inferred solely from a single example.

5.1 Device Discovery

The analyzed host application sends the s command to discover connected devices. The response is then parsed to obtain device-related information used to initialize software objects.

The code examined appears to process fields representing a logical device index, an address or identifier, and a value labelled as a ROM code.

Care is required when interpreting these fields. The MAX30208 has a configurable 7-bit I²C address in the range 0x50 to 0x53 under its standard address configurations. A reported value such as decimal 90 (hexadecimal 0x5A) would not be a valid standard MAX30208 7-bit I²C address. It should therefore not be labelled as the sensor's physical I²C address without further verification.

Similarly, the MAX30208 supports a unique ROM ID, but the precise structure and representation of that ID in the GUI's response must be confirmed from the implementation. A field described as a ROM code should not automatically be interpreted as a standard Dallas/Maxim 64-bit ROM identifier without evidence from the relevant firmware or source code.

5.2 Temperature Acquisition

The analyzed application requests temperature data using a command such as t 0\r.

A returned value like 24.570 is an example of a temperature represented as text in degrees Celsius. If the firmware uses a period as the decimal separator, the host application must parse that string using a compatible numeric format.

This is especially important on systems configured for locales that normally use a comma as the decimal separator, including the default Polish Windows regional format.

6. Regional Number Formatting and the FormatException Issue

During evaluation, the PC application was observed to start when the sensor was disconnected but to crash after the sensor was connected. The reported exception was:

System.FormatException: Input string was not in a correct format

One possible cause is a mismatch between the numeric format transmitted by the firmware and the format expected by the host application.

For example, the same decimal value can be represented as 24.570 or 24,570, depending on the locale. If the firmware sends a period-delimited decimal string but the application parses it using incompatible culture settings, conversion to a floating-point value may fail.

In .NET, a robust implementation should explicitly define the expected number format when parsing protocol data. If the firmware protocol specifies a period as the decimal separator, the host application can use CultureInfo.InvariantCulture, together with appropriate input validation and exception handling.

For example:

using System.Globalization;

string rawTemperature = "24.570";

if (double.TryParse(
        rawTemperature,
        NumberStyles.Float,
        CultureInfo.InvariantCulture,
        out double temperature))
{
    // Use the parsed temperature value.
}
else
{
    // Report invalid or unexpected protocol data.
}

This example demonstrates the recommended parsing approach; it does not establish that the same code change has been applied to the manufacturer's GUI.

Changing the Windows regional format to English (United States) may be a useful diagnostic workaround. If the application works with that setting and fails under Polish regional settings, the result would support the decimal-separator hypothesis. It would not, by itself, exclude other parsing or device-initialization problems.

A permanent fix should make the protocol's numeric representation explicit, validate received fields, and handle malformed or incomplete responses without terminating the application.

7. Engineering Value of the Protocol

A text-based command interface can make an embedded evaluation platform easier to inspect and debug. It allows engineers to examine individual operations, test register access, and build custom data-acquisition tools without first implementing a binary protocol decoder.

For the VitalSense project, this architecture offers several practical opportunities:

Custom Python diagnostics: Send supported commands, collect temperature readings, and save measurements to CSV.
Custom Qt application: Implement a desktop interface for live data display, logging, configuration, and experimental analysis.
Protocol validation: Check response framing, malformed data, timeouts, and error reporting.
Sensor characterization: Record repeatability, response time, and the influence of sensor placement and thermal contact.
Regional-format testing: Verify that the host application behaves consistently across Windows locale settings.

Any custom implementation should preserve the command syntax and response format expected by the firmware and should not assume that all commands listed here are supported by every firmware revision.

8. Conclusion

The MAX30208EVSYS evaluation system illustrates how a sensor with a standard I²C interface can be integrated into a PC-based evaluation workflow through a microcontroller and a USB serial communication channel.

Examining the host software and the text-based command interface can help engineers understand the data path, develop custom diagnostic tools, and identify potential integration problems. The reported FormatException also highlights an important general principle: communication protocols should define numeric formats explicitly, and host applications should parse incoming data independently of the operating system's regional settings.

For VitalSense, this provides a useful starting point for developing a custom acquisition and analysis application. The next step is to validate the observed protocol against actual device responses and the corresponding firmware version before relying on it for automated measurements or long-term data logging.

References

Analog Devices, MAX30208 Digital Temperature Sensor Datasheet.
Analog Devices, MAX30208 Evaluation System User Guide.
Observations from the specific MAX30208EVSYS hardware, firmware, and PC application version examined during this project.

MAX30208EVSYS Python Reader Script

Description: This script implements a direct communication protocol with the MAX30208EVSYS evaluation kit, bypassing the official Windows GUI. It establishes a serial connection through the USB-to-UART bridge (MAX32630FTHR) and communicates using text-based commands terminated with a carriage return ('\r'). Key Features: - Initializes the serial port according to firmware requirements (115200 baud, 8 data bits, no parity, 1 stop bit, DTR/RTS enabled). - Sends control commands like 's' (search devices) and 't0' (read temperature) - Uses regular expressions to parse bracket-notated data frames received from the microcontroller (e.g., [0] [24.570] [0])

import re
import time
import serial


class MAX30208Reader:

  def __init__(self, port_name, baud_rate=115200):
    self.port_name = port_name
    self.baud_rate = baud_rate
    self.serial_port = None

  def connect(self):
    """Initialization and opening of the serial port according to firmware parameters."""
    try:
      self.serial_port = serial.Serial(
          port=self.port_name,
          baudrate=self.baud_rate,
          bytesize=serial.EIGHTBITS,
          parity=serial.PARITY_NONE,
          stopbits=serial.STOPBITS_ONE,
          timeout=5,  # 5-second timeout for read and write operations[cite: 3]
      )

      self.serial_port.dtr = True
      self.serial_port.rts = True

      time.sleep(0.015)  # Equivalent to Thread.Sleep(15) after opening port in C#[cite: 3]
      self.serial_port.reset_input_buffer()
      print(f"Successfully connected to port {self.port_name}")
      return True
    except Exception as e:
      print(f"Error while opening port {self.port_name}: {e}")
      return False

  def disconnect(self):
    """Closing the serial connection[cite: 3]."""
    if self.serial_port and self.serial_port.is_open:
      self.serial_port.close()
      print("Disconnected from device.")

  def _send_command(self, command):
    """Sending a text command terminated with a carriage return (\r)[cite: 3]."""
    if self.serial_port and self.serial_port.is_open:
      full_command = command + "\r"
      self.serial_port.write(full_command.encode("utf-8"))

  def _read_response(self):
    """Reading the response line and clearing it of control characters[cite: 3]."""
    if self.serial_port and self.serial_port.is_open:
      line = self.serial_port.readline().decode("utf-8", errors="ignore")
      return line.replace("\r", "").replace("\n", "")
    return ""

  def find_devices(self):
    """Searching for devices on the I2C bus ('s' command) and clearing buffer lines[cite: 3]."""
    self._send_command("s")
    header_response = self._read_response()
    print(f"Controller response: {header_response}")

    # Read additional lines returned by the controller for each found device
    match = re.search(r"(\d+)", header_response)
    if match:
      num_devices = int(match.group(1))
      for _ in range(num_devices):
        dev_line = self._read_response()
        print(f"  -> Device info line: {dev_line}")

  def get_temperature(self, device_index=0):
    """Reading temperature for the indicated device index ('t' command)[cite: 3]."""
    self._send_command(f"t{device_index}")
    response = self._read_response()

    # Parsing the protocol response based on square brackets[cite: 3]
    # Example response format: [0] [24.570] [0]
    match_collection = re.findall(r"\[(.*?)\]", response)

    if len(match_collection) == 3:
      dev_idx = int(match_collection[0], 16)
      temperature = float(match_collection[1])
      status = int(match_collection[2])
      return {"device_index": dev_idx, "temperature_c": temperature, "status": status}

    return None


# --- Example script usage ---
if __name__ == "__main__":
  PORT_COM = "COM21"

  sensor_reader = MAX30208Reader(PORT_COM)

  if sensor_reader.connect():
    # Scan for devices (correctly flushes descriptive lines from the buffer)
    sensor_reader.find_devices()

    # Short pause before reading temperature
    time.sleep(0.5)

    # Continuous temperature reading from device index 0 in a loop
    try:
      print("\nStarting temperature reading (press Ctrl+C to abort)...")
      while True:
        data = sensor_reader.get_temperature(0)
        if data:
          print(
              f"Device: {data['device_index']} | Temperature:"
              f" {data['temperature_c']} °C | Status: {data['status']}"
          )
        else:
          print("Warning: Failed to read a valid data frame.")
        time.sleep(1)
    except KeyboardInterrupt:
      print("\nInterrupted by user.")
    finally:
      sensor_reader.disconnect()

The result of this script's execution is as follows:

VitalSense – Part 4 : MAX30208EVSYS Evaluation System – Technical Overview & Operation

jelektro — Fri, 23 Oct 2026 04:59:46 GMT

MAX30208EVSYS Evaluation Kit: Hardware, Sensor Specifications, and GUI Software

The MAX30208EVSYS evaluation system from Analog Devices provides a hardware and software platform for evaluating the MAX30208 digital temperature sensor. The sensor is designed for applications such as wearable temperature monitors, healthcare patches, and human-body thermometers.

The system consists of three main hardware elements:

MAX30208 sensor flex PCB: A flexible printed circuit board carrying the MAX30208 sensor in a 10-pin LGA package.
MAX3020x interface board: Provides accessible test points, configuration jumpers, and connections between the sensor and the microcontroller board.
MAX32630FTHR microcontroller board: Runs the firmware required to communicate with the PC GUI and supplies power to the interface board.

The system connects to a Windows PC through the micro-USB connector on the MAX32630FTHR board. The supplied firmware enables the evaluation software to configure the sensor, acquire temperature measurements, and access device registers.

The flexible sensor PCB has a low thermal mass, which supports a fast thermal response and allows the sensor to be positioned away from the main interface electronics. However, the measured temperature still depends on thermal contact, mounting, environmental conditions, and the measurement procedure. The flex PCB does not, by itself, guarantee accurate skin-temperature or clinical body-temperature measurements.

Technical Specifications of the MAX30208 Sensor

Temperature accuracy: ±0.1°C from +30°C to +50°C; ±0.15°C from 0°C to +70°C, according to the sensor datasheet.

Operating temperature range: 0°C to +70°C. The datasheet also specifies that the device can withstand a wider temperature range of −40°C to +85°C without damage; this should not be interpreted as the specified measurement-accuracy range.

Resolution: 16-bit, corresponding to 0.005°C per digital output step. Resolution is not the same as measurement accuracy.

FIFO: A 32-sample buffer for temperature readings, allowing the host controller to retrieve stored samples.

Communication interface: I²C, supporting four address configurations using the GPIO pin states at the I²C start condition.

GPIO0: Can be configured as an interrupt output for selected status conditions, including programmable high- and low-temperature alarms.

GPIO1: Can be configured as an external temperature-conversion trigger.

The sensor's ±0.1°C specification describes component-level performance under the conditions defined by the manufacturer. It does not, on its own, demonstrate that a complete thermometer meets clinical accuracy requirements or complies with medical-device standards.

MAX30208 EV Kit GUI Software

Analog Devices provides a Windows application for evaluating the MAX30208 without requiring the user to develop custom firmware for the initial tests.

According to the evaluation-system documentation, the GUI provides the following functions:

1. Temperature Monitoring

The application displays temperature readings from the connected sensor and provides controls for relevant device settings. The documentation does not describe a built-in real-time temperature-trend graph or a dashboard of minimum, maximum, and average statistics.

2. Data Logging

The GUI supports exporting measurement samples to a comma-separated values (CSV) file. This allows recorded data to be analyzed using tools such as Microsoft Excel, MATLAB, or Python.

The evaluation system also supports logging to a microSD card when configured for standalone operation with a compatible card and battery.

3. Register Map

The Register Map tab allows users to read individual MAX30208 registers, read all registers, and modify register bit settings. This is useful for exploring sensor configuration, measurement control, status flags, and other device functions.

4. Temperature Alarms and Interrupt Configuration

The MAX30208 supports programmable high- and low-temperature thresholds. When the relevant status and interrupt settings are enabled, the GPIO0 pin can signal a selected alarm condition. These functions can be configured through the device registers; the exact controls available in the GUI should be confirmed against the installed software version.

Relevance to the VitalSense Project

For VitalSense, the MAX30208EVSYS provides a useful starting point for characterizing temperature measurements, recording sensor data, exploring register-level configuration, and developing a custom acquisition and analysis application.

Further work should evaluate repeatability, response time, thermal contact, sensor placement, and agreement with a suitable reference thermometer. The results should be reported as experimental measurements rather than assumed clinical performance.

Troubleshooting the MAX30208EVSYS GUI: A Possible Regional Decimal-Separator Issue

During evaluation of the MAX30208EVSYS kit, I encountered a software issue involving the interaction between the hardware and the PC application. The GUI launches successfully when the sensor is disconnected, but crashes shortly after the sensor is connected.

The exception reported is:

System.FormatException: Input string was not in a correct format

One possible explanation is a regional number-formatting mismatch in the GUI software. In Windows configurations that use a comma as the decimal separator, such as the default Polish regional format, an application that parses a decimal value using incompatible formatting assumptions may fail. For example, the strings 24.57 and 24,57 can be interpreted differently depending on the parsing method and culture settings.

The fact that the application starts without the sensor but crashes when the sensor is connected suggests that the error may occur during device initialization or temperature-data processing. However, the exception alone does not establish the exact root cause.

Workaround to test

Close the MAX30208 EV Kit application.
Open Windows Settings → Time & language → Language & region (or the equivalent Regional Settings panel in your Windows version).
Temporarily select English (United States) as the regional format, or change the decimal-symbol setting to a period if Windows allows this independently.
Restart the application, connect the evaluation system, and check whether the crash still occurs.
Restore your preferred regional settings after testing if necessary.

If the application works under the alternative regional format and fails again under the original settings, this would support the decimal-separator hypothesis.

The issue would then appear to be related to the PC software's handling of regional number formats rather than necessarily indicating a fault in the MAX30208 sensor itself. A permanent software fix would be to parse numeric values using an explicitly defined culture that matches the data format, with appropriate validation and error handling.

What is 3M 8810 and how does it affect the temperature reading of the MAX30208 sensor

3M 8810 is a 0.25 mm thick thermally conductive double-sided tape made from an acrylic polymer filled with ceramic particles. It is designed to mechanically bond components while creating a thermal path to dissipate heat between a heat source and a cooling element (such as a chassis or heatsink).
Using this tape directly and significantly impacts how the MAX30208 sensor (a clinically accurate temperature sensor with ±0.1°C accuracy) registers the temperature of the ambient environment or the target object.

How does 3M 8810 tape affect the MAX30208 sensor readings

1. Sensor Specificity: MAX30208 (Inverted Design)
Most digital temperature sensors measure heat through thermal pads and ground pins on the bottom of the package (via the PCB). The MAX30208 measures temperature primarily from the top of its package (top-side), making it ideal for measuring human body temperature in wearable devices. To achieve accurate measurements, the target object must contact the top of the sensor package. Placing 3M 8810 tape there introduces specific physical consequences.

2. Introduction of Thermal Resistance (Measurement Error)

Although 3M 8810 is a thermally conductive material, its thermal conductivity is 0.6 W/m-K. At a thickness of 0.25 mm, this generates a measurable thermal impedance of approximately 5.8 °C·cm²/W.
Effect: The tape acts as a very thin layer of insulation. If the target object changes temperature, the sensor hidden behind the tape will register a temperature slightly lower (or higher, if the environment is cooling down) than the object's actual temperature. This creates a thermal offset (a steady-state error) that must be calibrated in the firmware.

3. Increased Response Time (Thermal Inertia)

The bare MAX30208 sensor responds to temperature changes incredibly fast (the response time of an unsoldered sensor is only about 0.5 s).
Effect: Adding a layer of acrylic adhesive and ceramics (3M 8810) introduces a barrier with a specific thermal mass. This causes the sensor to require more time to stabilize its reading after a sudden change in the object's temperature. Rapid, dynamic temperature spikes may be flattened out or completely missed.

4. Positive Effect: Elimination of Air Pockets

Air is a terrible conductor of heat (approx. 0.026 W/m-K). If you place the sensor directly against a rigid, rough surface, microscopic air gaps will distort the reading far more than the tape would.
Effect: 3M 8810 tape is compliant and features good "wet-out" capabilities (the ability to flow into and fill microscopic surface irregularities). Replacing these micro-air gaps with thermally conductive tape stabilizes and improves the repeatability of readings compared to a dry, unstable mechanical contact.

Summary of Impact Metrics

Impact Parameter	Change with 3M 8810	Goal & Solution
Absolute Accuracy	Degraded (introduces a small error/offset)	Requires software calibration of the temperature delta.
Response Time	Extended (greater response delay)	Acceptable for slow processes (e.g., body temperature measurement).
Reading Stability	Significantly improved (eliminates air and vibration impact)	Key advantage – prevents sudden measurement noise.

If you are designing a medical or wearable device based on the MAX30208 and require its factory ±0.1°C accuracy, you must account for the temperature drop across the 3M 8810 tape or use a thinner material with higher conductivity (such as dedicated copper and gold-plated electrodes making direct contact with the package top).

Below is a chart illustrating how the use of 3M 8810 thermally conductive tape affects the temperature reading of the MAX30208 sensor during a sudden temperature spike of the target object (e.g., when applied to skin at a stable temperature of 37°C).

Key Takeaways from the Chart:

Thermal Inertia (Delay): Without the tape (ideal contact), the sensor reacts almost instantly. The 3M 8810 tape layer causes the measurement curve to rise more gradually—the sensor needs a few more seconds to register the full change.
Thermal Offset (Shift Error): Due to the thermal resistance of the tape, the measurement line with 3M 8810 stabilizes at a level slightly lower than the actual temperature of the object. This difference is a constant error that needs to be corrected (added) in the microcontroller code handling the sensor.

Reference: Analog Devices, MAX30208 Evaluation System documentation and MAX30208 ±0.1°C Accurate, I²C Digital Temperature Sensor datasheet.

VitalSense – Part 3 : Alternatives for Heart Rate, SpO₂, and Temperature Sensing

jelektro — Fri, 23 Oct 2026 04:16:24 GMT

Top Alternatives to the MAXREFDES117# for Heart Rate & SpO2 Sensing

Designing wearable devices or health-monitoring prototypes often starts with photoplethysmography (PPG)—the optical measurement of blood volume changes to detect heart rate (HR) and blood oxygen saturation (SpO2).

For years, the Analog Devices / Maxim Integrated MAXREFDES117# Reference Design Board has been a go-to benchmark for engineers and makers. Measuring a tiny 12.7 × 12.7 mm with pads designed for wearable integration (and even sewing into textiles with conductive thread), it packs the MAX30102 sensor, onboard power regulation, and I2C level shifting into an ultra-compact package.

However, depending on whether you are building a commercial wearable, setting up a rapid prototype, or looking for medical-grade precision, several strong alternatives exist on the market.

Here is a comprehensive breakdown of the top competing solutions and alternatives to the MAXREFDES117#.

1. Direct Drop-In Hardware Alternatives (MAX30102-Based)

If your firmware is already written for the MAX30102 chip and you simply need a different physical form factor or easier prototyping options, these modules keep the same underlying silicon.

MikroElektronika Oximeter 5 Click

Core Sensor: MAX30102

Form Factor: mikroBUS Click board (42.9 × 25.4 mm)

Key Advantage: Breadboard-free hardware integration and ready-to-use software support.

While the MAXREFDES117# focuses on wearable miniaturization, MIKROE’s Oximeter 5 Click targets rapid benchtop evaluation. It interfaces seamlessly via the standardized mikroBUSTm header, features onboard voltage translation for 3.3V and 5V microcontrollers, and integrates directly with MIKROE's mikroSDK software ecosystem.

Generic MAX30102 Breakout Boards (e.g., Waveshare, Generic PCBs)

Core Sensor: MAX30102

Form Factor: Standard 2.54 mm (0.1") header PCB

Key Advantage: Cost-effective and breadboard-friendly.

Generic breakout boards sacrifice the ultra-compact round design and textile-friendly pads of the MAXREFDES117# in favor of standard goldpin headers. They are significantly less expensive and ideal for early-stage proof-of-concept testing on breadboards or Arduino-based setups.

2. Upgraded Sensor Hubs & Enhanced Maxim/ADI Modules

Moving beyond raw sensor outputs, these alternatives offer updated optical hardware or onboard processing to handle the heavy computational math for you.

SparkFun Pulse Oximeter & Heart Rate Sensor (SEN-15219)

Core Sensor: MAX30101 + MAX32664 Biometric Sensor Hub

Form Factor: Qwiic-compatible breakout board

Key Advantage: Onboard digital signal processing (DSP) and motion artifact filtering.

The biggest limitation of the MAXREFDES117# is that your main host MCU (e.g., STM32, ESP32, or AVR) must execute complex algorithms to extract clean HR and SpO2 values from noisy raw PPG data.

SparkFun solves this by combining the upgraded MAX30101 sensor (which adds a green LED alongside red and IR for better wrist-tracking stability) with the MAX32664 Sensor Hub. This onboard co-processor runs proprietary firmware that filters out motion noise in real time and calculates heart rate, SpO2, and signal quality—delivering ready-to-use digital values directly over I2C.

SparkFun Particle Sensor Breakout (MAX30105)

Core Sensor: MAX30105

Form Factor: Standard SparkFun breakout / Qwiic

Key Advantage: Multi-purpose optical sensing (PPG + particle/smoke detection).

Equipped with red, IR, and green LEDs, the MAX30105 offers register-level compatibility with PPG measurement routines while expanding versatility to include ambient particle detection (smoke/dust) and optical proximity sensing.

3. Alternative Silicon Vendors (TI, AMS Osram, Silicon Labs)

If you are developing a custom PCB from scratch and want to evaluate IC alternatives outside the Analog Devices / Maxim ecosystem, consider these industry-leading silicon alternatives:

Solution / Board	Manufacturer	Image	Key Features & Target Application
EVM-AFE4404	Texas Instruments		Medical-Grade Precision: Highly flexible Analog Front-End (AFE) providing superior noise rejection, dynamic ambient light cancellation, and ultra-precise LED driver control. Ideal for clinical-grade devices.
AS7050 / AS7038	AMS Osram		Multi-Parametric Biosensing: Supports simultaneous PPG (heart rate & $SpO2$ ), ECG (electrocardiogram), and EDA (galvanic skin response/stress monitoring) on a single integrated solution.
Si117x / Si118x	Silicon Labs		Ultra-Low Power Wearables: Engineered specifically for wrist-based wearables, featuring built-in low-power algorithms optimized for long battery life in smartwatches and fitness trackers.

Alternatives to the MAX30208EVSYS Evaluation System

The MAX30208EVSYS is a professional evaluation system from Analog Devices (formerly Maxim Integrated) designed to test the MAX30208—an ultra-high accuracy (+/- 0.1'C in the medical range of 30'C to 50'C) digital temperature sensor. The system includes a microcontroller motherboard (MAX32630FTHR) and a flex PCB extension housing the sensor, allowing developers to easily attach it to human skin or conduct thermal flow analysis in wearable designs.

When evaluating alternatives to the MAX30208EVSYS, two distinct aspects should be considered: alternative evaluation boards/kits and alternative medical-grade (+/-0.1'C) temperature sensor ICs.

1. Alternative Development Kits & Evaluation Boards

If you are looking for a complete kit or breakout board to prototype body temperature sensing:

MikroElektronika Thermo 22 Click / MIKROE Temp Sensors

Design: mikroBUS form-factor expansion boards featuring integrated high-precision temperature sensors.

Advantage over EVSYS: Instead of using a proprietary evaluation system with the MAX32630FTHR board, MIKROE Click boards plug directly into any standard host board (STM32 Nucleo, ESP32, Raspberry Pi) via the universal mikroBUS socket. They come supported by turnkey mikroSDK software libraries.

Texas Instruments TMP117EVM (Evaluation Module)

Main Sensor: TI TMP117 (+/- 0.1'C accuracy from -20'C to +50'C).

Overview: Texas Instruments' official evaluation board featuring a detachable sensor breakout section.

Advantage over EVSYS: The TI EVM provides a USB interface with a ready-to-use PC GUI and EEPROM emulation. The detachable breakout section is tiny and has low thermal mass, making it easy to integrate into wearable medical patch prototypes.

SparkFun / Adafruit High-Precision Temp Breakouts (e.g., PCT2075 / TMP117)

Overview: Low-cost i2c breakout boards with Qwiic / STEMMA QT connectors.

Advantage over EVSYS: The MAX30208EVSYS is relatively costly and geared toward industrial/medical evaluations. Adafruit/SparkFun breakout boards cost a fraction of the price and offer plug-and-play compatibility with Arduino and CircuitPython environments.

2. Alternative Silicon ICs (Medical-Grade Temperature Sensors)

If you are designing a custom PCB from scratch and need an alternative to the MAX30208 sensor chip itself:

Sensor	Manufacturer	Accuracy	Interface	Key Features & Advantage over MAX30208
TMP117	Texas Instruments	$+/- 0.1'C$ (from $-20'C$ $+50'C$ )	$i2c$ / SMBus	Medical Standards Compliance (ASTM E1112 / ISO 80601). Meets clinical standards out of the box without requiring post-assembly calibration. Offers +/- $0.1'C$ accuracy over a wider temperature span than the MAX30208.
MAX30205	Analog Devices	$+/- 0.1'C$ ( $+37'C to +$ $39'C$ )	$i2c$	The predecessor to the MAX30208 in a TDFN package. Widely used in traditional digital clinical thermometers and medical wristbands.
STS35-DIS	Sensirion	$+/- 0.1 'C$ ( $+20'C$ to $+60'C$ )	$i2c$	Swiss-engineered sensor featuring high measurement repeatability and ultra-low power consumption. Includes an internal heating element for self-diagnostics.
AS6221	AMS Osram	$+/- 0.09'C$ ( $+20'C$ to $+42'C$ )	$i2c$	Industry-leading low power consumption ( $6\,\mu\text{A}$ at 4 samples/s) combined with extreme precision, specifically designed for smartwatches and medical patches.

VitalSense – Part 2 : Sponsored Kit Overview

jelektro — Fri, 23 Oct 2026 03:25:49 GMT

The Sponsored Kit designed for the Smart Home & Healthcare Challenge on the element14 platform consists of key components from renowned manufacturers (Analog Devices and 3M), along with additional prototyping accessories and branded swag.

The following overview describes the main components, their key characteristics, and their potential applications in the development of the VitalSense physiological-monitoring research platform.

1. Analog Devices MAX30208EVSYS# Evaluation System

Quantity in kit: 1

Description and main specifications: An evaluation system for the MAX30208 digital temperature sensor. The sensor is specified for ±0.1°C accuracy over the 30°C to 50°C temperature range. The evaluation system includes a MAX30208 sensor interface board, a MAX32630FTHR microcontroller board, and a flexible PCB carrying the sensor.

Project application: The system will serve as the starting point for evaluating temperature acquisition, sensor response, and measurement repeatability. Its compact sensor assembly and low thermal mass make it relevant to wearable and body-temperature-monitoring research. The accuracy of the complete measurement setup will depend on sensor placement, thermal contact, environmental conditions, and the measurement procedure.

2. Analog Devices MAXREFDES117# Reference Design

Quantity in kit: 1

Description and main specifications: A low-power optical heart-rate and pulse-oximetry reference design based on the MAX30102 sensor, with integrated red and infrared LEDs and supporting electronics.

Project application: The module will be used to investigate photoplethysmography (PPG), heart-rate estimation, and SpO₂ estimation. The reference design includes example source code and a basic algorithm for these measurements. It can be integrated with compatible development platforms, including Arduino-based systems, and adapted to other microcontrollers where suitable drivers and interfaces are implemented.

3. 3M EM25TP-0050 EMI Absorber Material

Quantity in kit: 1 piece ( $340mm x 340mm x 0.05mm$ sheet, EM25TP series)

Description and main specifications: A thin, flexible electromagnetic interference (EMI) absorber material from the 3M EM25TP family. The EM25TP family is designed to absorb electromagnetic energy over specified frequency ranges and can also provide magnetic-field shielding in applicable frequency ranges.

Project application: The material will be investigated as a potential aid in reducing selected electromagnetic interference in sensitive electronic prototypes. It may be useful when evaluating interference from wireless modules, switching circuits, and other electronic components. Its effectiveness will depend on the interference frequency, material placement, and overall system design.

The absorber will be treated as an experimental EMI-mitigation measure rather than a universal solution for electrical noise or measurement errors.

4. 3M 8810 Thermally Conductive Adhesive Transfer Tape

Quantity in kit: 1 roll, 3M 8810 series.

Description and main specifications: A thermally conductive adhesive transfer tape intended to provide an adhesive interface between suitable components and heat-dissipating surfaces.

Project application: The tape may be useful for selected thermal-management and mechanical-assembly experiments involving electronic components and enclosures. In the VitalSense project, its use near temperature sensors will be evaluated carefully because thermal coupling, heat flow, and contact conditions can influence the measured temperature.

The tape will not be assumed to improve body-temperature measurement accuracy without experimental evidence.

5. Multicomp MCBB830K Solderless Breadboard

Quantity in kit: 1

Description and main specifications: A solderless prototyping breadboard, providing 830 connection points.

Project application: The breadboard will support rapid prototyping of low-voltage circuits, including sensor interfaces (such as the MAX30208 or MAXREFDES117), microcontroller connections, and signal-conditioning experiments. It allows components to be connected and rearranged without soldering.

6. Community Swag and Accessories (element14 Branded Swag)

Basketball Cup
Sticker and Pin (with element14 branding) - Community swag for challenge participants, perfect for decorating project enclosure or workspace.

The sponsored kit provides a useful starting point for developing and evaluating a physiological-monitoring research platform. The Analog Devices components support temperature sensing and optical PPG experiments, while the 3M materials offer opportunities to investigate electromagnetic interference mitigation and thermal assembly. The solderless breadboard supports rapid hardware prototyping.

Within VitalSense, these resources will be used to investigate sensor integration, data acquisition, signal processing, thermal behavior, and measurement repeatability. The objective is to develop and experimentally evaluate a modular prototype for physiological monitoring, rather than to assume clinical performance from component specifications alone.

The results will help identify practical design considerations for future wearable, smart-home, and portable healthcare-monitoring prototypes.

VitalSense – Part 1: System Concept and Architecture

jelektro — Fri, 23 Oct 2026 02:13:42 GMT

Project Overview and Objectives

As part of my project for the element14 Smart Home Healthcare Challenge, I am investigating how high-accuracy sensing, digital signal processing, and embedded computing can be combined to develop flexible systems for physiological monitoring.

The project is built around two evaluation platforms from Analog Devices:

MAX30208EVSYS — a temperature-sensing evaluation system based on the MAX30208 digital temperature sensor, specified for ±0.1°C accuracy over the 30°C to 50°C range.
MAXREFDES117 — an optical heart-rate and pulse-oximetry reference design based on the MAX30102 sensor, featuring red and infrared LEDs and example algorithms for heart-rate and SpO₂ estimation.

My first objective is to develop a PC-based diagnostic research station that acquires temperature and photoplethysmography (PPG) data through two independent USB-connected interfaces. A dedicated application written in C++/Qt or National Instruments LabVIEW will support signal acquisition, digital filtering, real-time waveform visualization, data logging, and algorithm evaluation.

The second stage explores three complementary embedded architectures: an nRF52840-based Bluetooth Low Energy telemedicine node, an ultra-low-power TI MSP430-based measurement device, and a Seeed Studio Wio Terminal providing a standalone graphical interface and Wi-Fi connectivity.

By comparing these platforms, I aim to evaluate their measurement performance, signal-processing capabilities, energy consumption, connectivity, and suitability for different physiological-monitoring scenarios. The project will establish an experimental foundation for future portable healthcare prototypes, with measurement accuracy and system performance assessed through documented validation procedures.

Technical Architecture, Implementation Plan, and Validation Strategy

1. Main Architecture - Diagnostic Station (PC + C++/Qt / LabVIEW)

1.1. element14 Kits and Modules

Temperature measurement kit: MAX30208EVSYS# evaluation system, connected to a PC via USB using its supported evaluation interface and software or firmware configuration.
Heart rate and SpO2 measurement kit: MAXREFDES117# optical reference design, interfaced with an STM32 microcontroller that acquires sensor data and streams it to the PC via USB using a Virtual COM Port (VCP) or USB-to-UART bridge.

1.2 PC Connection Method and Software Layer

The workstation is designed to receive data through two independent USB-connected interfaces:

Channel 1 — Temperature: MAX30208EVSYS# → USB → evaluation firmware/software → temperature measurements.
Channel 2 — PPG and SpO₂: MAXREFDES117# → STM32 → USB (VCP/UART) → optical samples and calculated parameters, where supported by the firmware.

Alternative A: C++ / Qt Application (Cross-Platform)

A multi-threaded application using QThread, QSerialPort, and a plotting library such as QCustomPlot will provide a cross-platform software architecture for Windows and Linux, including Raspberry Pi OS, subject to the availability of compatible drivers and libraries.

The proposed application will include:

Independent data-acquisition workers for the temperature and PPG channels.
Real-time visualization of temperature and optical waveforms.
Digital filtering and signal-quality assessment.
Heart-rate estimation and SpO₂ estimation, where the required algorithm and calibration are available.
Timestamped data logging and CSV export.
Connection-status indicators and measurement-error reporting.

Alternative B: National Instruments LabVIEW Application

LabVIEW provides an established graphical programming environment for measurement engineering, data acquisition, signal processing, and real-time visualization.

Communication layer — NI-VISA

Configure independent communication sessions for the two data sources.
Use VISA functions such as VISA Configure Serial Port, VISA Read, and VISA Write where the devices expose compatible serial interfaces.
Implement appropriate framing, parsing, timeout handling, and communication-error detection.

Software architecture — Producer/Consumer design pattern

Producer loops: Independent acquisition loops read incoming data from the two interfaces without blocking the user interface.
Queues: Buffered data is transferred to processing and display loops.
Consumer loops: Validate, timestamp, process, visualize, and store measurements.

Signal processing and digital filters

Apply suitable digital filtering, such as a Butterworth band-pass filter, to reduce selected noise components in the PPG signal.
Use peak detection and inter-beat interval analysis to estimate heart rate.
Assess signal quality and identify motion-related artifacts.
Estimate SpO₂ using a suitable algorithm based on red and infrared PPG signals and an appropriate calibration model.

User interface — Front Panel

Waveform Chart and Waveform Graph elements for live temperature and PPG visualization.
Numeric indicators, gauges, and status indicators for measurement results.
Configurable sampling and display settings.
Measurement-session management and communication diagnostics.
Data export to TDMS (Technical Data Management Streaming) or CSV for subsequent research analysis.

1.3. Comparison of Similar Solutions in Portable Medical Diagnostics

Feature / Parameter	VitalSense prototype (MAX30208 + STM32 + LabVIEW/Qt)	Standard Fingertip Pulse Oximeter	Commercial Smartbands (e.g., Apple Watch, Fitbit)	Industrial Patient Monitors (e.g., Philips)
Temp. Accuracy	Outstanding (+/-0.1'C - medical grade)	No temperature measurement	Low/Estimated (skin temperature, uncalibrated)	High (+/-0.1'C, continuous probes)
Data Access	Full access to raw PPG data and registers (LabVIEW/Qt)	No data access	Restricted (closed cloud APIs)	Integrated with hospital HL7/DICOM
Research Environment	High flexibility (LabVIEW for rapid prototyping and DSP analysis)	No modification options	Closed ecosystem	Dedicated clinical software

2. Portable Autonomous Device Concepts (Architecture Triad)

The second part of VitalSense explores three complementary embedded architectures. Each concept prioritizes a different combination of energy efficiency, connectivity, processing capability, and user interaction.

Concept 1: Personal Telemedicine Node with Cloud Connectivity (nRF52840)
- Platform: Nordic Semiconductor nRF52840, initially using the nRF52840-DK development kit. The microcontroller integrates a 64 MHz Arm Cortex-M4F processor with FPU, 256 KB RAM, and 1 MB Flash.
- Role: Acquire physiological sensor data, perform local signal processing, estimate heart rate, assess PPG signal quality, and support SpO₂ estimation using an appropriate algorithm.
- Communication: Bluetooth Low Energy (Bluetooth 5.0) connects the device to a smartphone application.
  
  Potential standard GATT services include:
  - Heart Rate Service (HRS): For heart-rate measurements.
  - Health Thermometer Service (HTS): For temperature measurements, with the measurement type and units appropriately defined.
- Planned safety and notification features
  
  The smartphone application could evaluate configurable thresholds, indicate abnormal readings, and notify the user or designated caregiver. If supported by the phone, operating system, permissions, and network availability, it could also initiate an SMS or other emergency notification.
Concept 2: Ultra-Low-Power Field Rescue Device (TI MSP430)
- Platform: Texas Instruments MSP430G2553, using the MSP-EXP430G2ET development platform. The MCU has a 16-bit architecture, 512 bytes of RAM, and 16 KB of Flash memory.
- Design Philosophy: Prioritizing hardware simplicity, reliability, and ultra-low power consumption. Fully autonomous device intended for emergency field missions and long-term home healthcare.
- Power management: The microcontroller will spend most of its idle time in a low-power state, with LPM3 considered for suitable clock and peripheral configurations.
- Proposed operation
  1. The patient activates the device using a push-button.
  2. The controller wakes and initializes the required peripherals.
  3. Temperature and PPG data are acquired through compatible sensor interfaces.
  4. Heart rate and other supported parameters are estimated.
  5. The results are displayed locally, if a suitable display is implemented.
  6. The controller returns to a low-power state after the measurement session.
Concept 3: Autonomous Diagnostic Monitor with Advanced HMI (Wio Terminal)
- Platform: Seeed Studio Wio Terminal, based on the Microchip ATSAMD51P19 microcontroller: Arm Cortex-M4F at 120 MHz, 512 KB Flash, and 192 KB RAM. The platform includes a 2.4-inch, 320 × 240-pixel color TFT display, navigation buttons, and an RTL8720DN wireless module supporting Wi-Fi and Bluetooth Low Energy.
- Design philosophy: Combine local visualization and interactive controls with portable embedded computing and wireless data communication.
- Role: Acquire and display temperature and PPG data through compatible sensor interfaces. The processing capacity of the ATSAMD51P19 will be evaluated for local filtering, parameter estimation, and live waveform rendering.
- HMI and connectivity
  - Standalone mode: Display current measurements, signal quality, connection status, and stored temperature and heart-rate trends using the integrated screen and navigation controls.
  - IoT mode: Send selected measurements to a local gateway or cloud service over Wi-Fi using MQTT, subject to implementation of the required network and application protocols.

Comparative Summary of the Three Portable Concepts

Feature	Concept 1: nRF52840	Concept 2: MSP430	Concept 3: Wio Terminal
Primary Focus	Mobile connectivity, SOS alarms, cloud	Multi-year battery life, ultra-low power	Local live visualization (LCD), IoT
User Interface	Smartphone Screen (Mobile App)	Simple segment/OLED display	Integrated 2.4" TFT Screen + Joystick
Battery Life	Days / Weeks (depending on BLE intervals)	Years (0.7 uA sleep current)	Hours / Days (depending on LCD backlight)
Connectivity	Bluetooth 5.0 Low Energy	None (Full Air-Gap)	Wi-Fi (MQTT) + Bluetooth 5.0
Signal Processing	Medium/High (Cortex-M4F 64MHz)	Basic (16-bit MSP430 16MHz)	Very High (Cortex-M4F 120MHz)

3. Project Schedule and Milestones

Phase I: Hardware Integration and Sensor Validation
- Set up the MAX30208EVSYS# evaluation system and verify its USB communication path to the PC.
- Interface the MAXREFDES117# reference design with an STM32 microcontroller.
- Implement USB data transmission using a suitable VCP/UART interface.
- Verify sensor readings, sample formats, timing, and communication stability.
Phase II: Diagnostic Station Application Development (C++/Qt or LabVIEW)
- Configure the required USB and serial communication sessions.
- Develop the graphical user interface for temperature and PPG visualization.
- Implement data buffering, timestamps, error handling, and measurement logging.
- Develop and evaluate digital filtering, heart-rate estimation, and SpO₂ estimation algorithms where supported.
Phase III: Portable Concept Implementation
- Develop the nRF52840-based BLE monitoring prototype.
- Evaluate the feasibility of the MSP430-based low-power implementation.
- Develop the Wio Terminal graphical interface and wireless communication functions.
- Document the differences in hardware integration, software complexity, and energy requirements.
Phase IV: Final Testing and Validation
- Evaluate acquisition stability, missing samples, and communication errors.
- Compare temperature readings against an appropriate reference instrument under documented test conditions.
- Compare heart-rate and SpO₂ estimates with suitable reference equipment, recognizing the limitations of non-clinical validation.
- Measure power consumption during standby, acquisition, processing, display operation, and wireless transmission.
- Evaluate PPG signal quality and the effect of motion and sensor placement.
- Document limitations, repeatability, and the conditions under which the results were obtained.

VitalSense is an experimental research and development project. The results will help determine the practical capabilities and limitations of each hardware platform and guide the development of future portable physiological-monitoring prototypes. VitalSense explores a modular approach to physiological monitoring, combining temperature sensing, optical PPG acquisition, digital signal processing, and embedded computing.

The PC-based diagnostic station will provide a flexible environment for acquiring and analyzing measurements, while the three portable concepts will enable a comparative study of wireless connectivity, low-power operation, local processing, and user interaction.

Palno & Slemon #3 Building the Algorithm

Qbit — Thu, 22 Oct 2026 16:22:14 GMT

Hi, I hope you are doing well, and I am really sorry for the delay in posting this part, I was a little lost and busy with other work. But I will give my best finishing this project and making it reliable.

A Quick Recap

These are the past posts: