Teaching a bedside pulse oximeter to talk to a Raspberry Pi

The idea

The 7500 outputs a plain ASCII line every second on pin 3 of its DB9 connector: SpO2=096 HR=065. No proprietary software required to read it — just a serial adapter and something listening. The goal was overnight trend tracking: capture the whole night, then each morning compute means, low points, and desaturation counts, and drop a chart into a phone-friendly channel.

It reads the device; it never sends anything back. That one fact keeps the wiring down to two conductors and removes any chance of the logger disturbing the instrument.

Parts

Wiring

Four of the six FTDI wires stay unconnected. That surprises people, so it's worth saying plainly: to read a device you need only its transmit line and a shared ground. The adapter's own transmit, its 5 V power, and the handshake lines all go nowhere. Plug the FTDI's USB end into the Pi and the device enumerates as /dev/ttyUSB0.

The gotcha

Nearly every serial device today runs 8N1 — eight data bits, no parity, one stop bit. The 7500's manual specifies 8N2: eight data bits, no parity, two stop bits. The stop bit carries no data — it's just guaranteed idle time between bytes — so an 8N2 device read by an 8N1 receiver mostly works. The eight data bits are identical either way.

"Mostly" is the trap. When the line is marginal — a long cable, a little noise — a receiver expecting only one stop bit has less timing slack to find the next byte boundary, and once in a while it latches onto the wrong bit and reports a garbled value. A pulse of 72 becomes 250. It's rare, maybe a fraction of a percent, but it wrecks any min/max you compute and manufactures desaturations that never happened.

The software

Split into two programs on purpose. The logger has exactly one job — read the serial line and append timestamped rows to a CSV, forever, with no network and no analysis that could fail and cost you data. Everything that can go wrong (Wi-Fi, parsing choices, chart rendering) lives in a separate summary program that runs once a morning and can crash harmlessly.

The logger, at its core:

# open read-only, matching the device's 8N2 framing
ser = serial.Serial("/dev/ttyUSB0", 9600,
                    bytesize=8,
                    parity=serial.PARITY_NONE,
                    stopbits=serial.STOPBITS_TWO,
                    timeout=5)

# one ASCII line per second: "SpO2=096 HR=065"
LINE = re.compile(rb"SpO2=\s*(\d+)\s+HR=\s*(\d+)")

while True:
    raw = ser.readline()
    m = LINE.search(raw)
    if not m:
        continue
    spo2, hr = int(m.group(1)), int(m.group(2))
    # zeros mean "no reading" -> write blanks, not fake data
    write_row(now(), spo2 or "", hr or "")

The summary reads the night's CSV and does the judgment the logger deliberately avoids:

• Plausibility gate. The 7500 has no status flag on its serial line, so the summary decides trust itself: keep SpO₂ only in 50–100, pulse only in 25–220. Anything outside is a corrupted frame, dropped before it can skew a mean.
• Honest coverage. A sensor that slips off at 3 a.m. shouldn't report a full night. Coverage is real samples over the whole elapsed span, and a low-coverage night is graded and labeled as such, not dressed up.
• Suppress what can't be trusted. On a sparse night, per-hour event rates are meaningless, so they're withheld with a reason rather than posted as authoritative numbers.
• A chart. SpO₂ and pulse traces that break at gaps instead of drawing straight lines across missing time, plus a per-minute coverage ribbon so you can see the night's shape at a glance.

Where it lands. The summary and its chart post to a Discord channel — text plus the graph as an image — so the night's result shows up on a phone without logging into anything. A scheduled run fires every morning. A second small service listens in the same channel for on-demand requests: post any message and it re-runs the summary against the latest recording and replies. That covers naps and odd-hour sessions, and lets a non-technical family member pull a fresh report by simply typing in the channel — no terminal, no commands to remember.

Alongside the PAP data

The nightly CSV isn't only for the Discord summary. Converted to a format OSCAR understands — the open-source CPAP/BiPAP analysis tool — the same data can be laid directly over a night of PAP therapy, so an oxygen dip lines up against the exact respiratory event that caused it. That overlay is the real payoff: SpO₂ and pulse in the same timeline as pressure, flow, and events.

A small converter turns the logger's epoch,spo2,hr CSV into a per-second data file (ChoiceMMed MedView .dat) and OSCAR's Oximetry Wizard imports it after the PAP session is loaded. The alignment works because the logger timestamps every sample from the Pi's NTP-synced clock — real wall-clock time, often more accurate than a consumer oximeter's own drifting internal clock. If the PAP machine's clock is correct, the two line up automatically; if it's off by a fixed amount, that offset is applied once at import. In practice the oximetry dropped straight onto the therapy timeline: SpO₂ and pulse traces sitting directly under the pressure, flow, and event flags, with the machine's own desaturation counts now computed against the two datasets together.

Two things had to be solved before the import was usable, and both are worth knowing if you're building the same thing:

• One session, not sixteen. OSCAR ends a recording session at every gap in the data. A night with the sensor slipping on and off became a dozen-plus fragments, and the wizard only imports one session at a time — so you could never load the whole night. The fix is to bridge the gaps: fill every missing second with a "no reading" record. The trace still shows the dropouts honestly, but the recording stays one continuous session covering the night.
• One reading per second. The 7500 occasionally emits slightly faster than once a second, so two readings can share a clock second. OSCAR wants a clean 1 Hz grid, so the converter collapses duplicate seconds to a single reading before filling gaps. Skip this and the "continuous" timeline still has hidden hiccups that can re-fragment the import.

The converter is a single Python script that needs nothing installed — standard library only, no third-party packages — so it runs on even a stripped-down Pi. It applies the same plausibility filter as the nightly summary, so the junk frames are gone from the OSCAR view too. Run it against a night's CSV, copy the resulting .dat to whatever machine runs OSCAR, import the PAP night first, then import the datafile through the Oximetry Wizard.

Why live, not playback

The 7500 stores up to 70 hours internally, and it can replay that memory over the same serial port. It sounds like the easier path: skip the overnight capture, just dump the stored night in the morning. But playback has to be started by hand on the device — you hold a button combination until the screen reads PLA bAC, and only then does the stored data stream out. Someone has to be there, awake, pressing buttons, every single morning.

Reading the live stream instead makes the whole thing hands-off. The logger runs as a service; the sensor goes on at bedtime and the data flows on its own. Nothing to remember, nothing to press, no morning ritual — the summary is simply waiting when everyone wakes up. For a routine that has to survive being tired, forgetful, and busy, hands-off beats the manual dump every time.

What the build taught

Prior art

One published project comes close: rogerkl/poxparse, which pulls data from a Nonin 8500m. It's worth reading, and it's a different route to a related end. Rather than reading the live serial stream, that project captures the device's memory dump with a logic analyzer and decodes it in PulseView, then parses the export to CSV — a clever workaround for a modern PC that no longer has a serial port.

Two details there are useful to anyone extending this method across Nonin's line. First, the 8500m's framing is 8O1 — eight bits with odd parity — not the 7500's 8N2. Different model, different framing: exactly why reading the spec beats assuming. Second, its stored-memory playback is coarser and quirkier than a live stream — a datapoint every four seconds, arriving in two bursts — which is a good argument for reading the live 1 Hz output when the device offers it, as the 7500 does.

So the approaches are complementary rather than duplicate: that one recovers a stored session off an 8500m via logic analyzer; this one logs the live stream off a 7500 straight to a Pi. Same family of device, two different problems solved.

Feedback

If something here helped, tripped you up, or you're rebuilding it on a different Nonin and want to compare notes, send a message. Email is optional — leave it if you'd like a reply.