Open instruments, and where help is needed
A section for those who design electronics and write firmware. The hard problem is not the sensor: it is knowing how late each channel is.
What is actually needed
Not one more sensor. Sensors exist, many are good, some are open. What is missing — and what makes so much home-built instrumentation unusable — is always the same thing: nobody knows how late each channel is, or how much that lateness varies.
If the cardiac signal arrives with 40 ms of latency and the optical one with 380, and you have not measured it, you are computing recovery dynamics over times that do not exist. The computation appears to work. The result is an artefact.
Anyone who can design electronics and write code can fix this. It is a concrete, verifiable and publishable contribution.
The architecture, in four layers
Node. The sensor and its microcontroller. It samples, timestamps with its own clock, transmits.
Collection. A hub — a phone or a small Linux computer — that receives from several nodes and aligns their clocks.
Transport. The message to the server, in a declared and versioned format.
Storage. Immutable raw data, versioned derivatives, uncertainty and provenance on every value.
This project concerns the first two layers. The third and fourth are described on the data page.
Protocols: what to use for what
| Use | Protocol | Why |
|---|---|---|
| Worn on the person | Bluetooth Low Energy with standard profiles | Phones have the radio; profiles for heart, glucose and temperature already exist |
| Fixed environmental sensors | Zigbee, Thread | Very low power, mesh networking, batteries lasting years |
| Hub to server | MQTT | Lightweight, handles reconnection, persistent queues |
| Event marker across devices | Electrical pulse or light flash | No network protocol: time is aligned with a physical signal |
A note on Zigbee, because it comes up often and leads people astray: it is an excellent protocol, but not for what is worn. No smartphone has a Zigbee radio, so a dedicated gateway would have to be carried on the person, and the phone-as-hub model collapses. Zigbee makes perfect sense for the environment the person lives in: temperature, light, humidity, room occupancy. These are context data that matter — evening light affects sleep, and sleep is one of the measured conditions — and there a mesh network with multi-year batteries is exactly right.
Open foundations to start from
Microcontrollers. ESP32 and its derivatives cover BLE and WiFi on one radio and cost little; the internal converter, however, is unsuited to biosignals and a dedicated input stage is required.
Electrophysiology. Low-noise analogue front-ends for EEG and ECG have been available as single components for years, and underpin essentially every open project in circulation. The circuit is documented; the hard part is shielding and skin contact.
Reliable cardiac signal at minimal cost. A commercial chest strap transmitting inter-beat intervals over BLE is more reliable than any wrist optical sensor for heart rate variability, and it is validated in the literature. Not everything has to be built.
Accelerometry. Research loggers exist with open, documented raw formats. They are the standard in large cohorts, so the data stay comparable with what already exists.
Platforms with open SDKs. Some commercial wearable modules expose the raw signal and allow custom firmware: the quickest route to a prototype without designing the electronics from scratch.
Software
Linux and Python are more than enough. The library that genuinely matters is the one for synchronised streaming in the laboratory, born in neuroscience precisely to join streams with different clocks and estimate the offsets between them: it solves most of the problem, and it is already the community standard.
Alongside it: a library for task presentation with timing control, one for physiological signal processing, one for electrophysiology. All open, all maintained, all in Python.
The system clock must be synchronised over a network protocol; on a local network the precision protocol does far better. Either way the offset must be measured and recorded, not assumed.
The most useful contribution: the test bench
If an engineer were to give this project one thing, I would ask for this.
A generator producing a known signal — a pulse, a ramp, a sinusoid of known frequency — injected into the whole chain, from the sensor to the row written in the database. Then measure:
- latency, from the physical moment to the recorded timestamp;
- drift, how much that latency changes over eight hours;
- loss, how many samples are missing and how they are distributed;
- fidelity, how closely the reconstructed signal matches the injected one.
The result is a table with one row per channel and a declared uncertainty. It is worth more than a new sensor, because without it no dynamic measurement is defensible.
For optical channels the same is done with a flash of known duration and a photodiode; for chemical ones with a concentration pulse in a cell-free system.
Non-negotiable limits
Any device with electrodes in contact with a person, if connected to mains power, falls under electrical safety regulation for medical settings. For research on people this means: battery power and isolation, or already-certified equipment. A prototype running off a wall adapter does not go near a participant.
The same holds for validation: a home-built sensor enters the protocol only after a documented comparison against a recognised reference. This is not bureaucracy, it is the difference between a measurement and a number.
How to contribute
What is needed, in order of usefulness:
- A latency test bench, as described above.
- Connectors to commercial devices that currently offer no open route to raw data.
- Environmental mesh nodes for light, temperature and occupancy.
- Validation reports against a reference, including for devices you did not build.
For each: schematic and bill of materials, firmware, an open licence, and the measurement report with its uncertainty. Without that last item the contribution cannot be used in a study.