Shimmer Capture

Example: configure, stream, plot, record, rename and download the SD card of a single Shimmer3R from the browser
SDK …
Sensor link
disconnected
CRC 2 bytes
Has the sensor append a checksum to every packet, so a corrupted frame is reported as corrupted instead of being plotted. On at two bytes by default, which costs two bytes per frame and is the only way to tell a bad link from a bad decode; one byte lets roughly 1 in 256 bad frames through. Firmware that does not support it falls back to off on its own. Applied when you connect.
This page is an example application, not a product: one sensor, one connection, one recording. For configuring, streaming, recording and analysing data across your Shimmer devices, use Consensys, Shimmer's desktop application.
Clock
Real-world clock
–
Host clock
–
The sensor keeps its real-world clock in UTC, as desktop Consensys and the dock software set it, so both lines above are shown in this host's local time and should read the same. The Test tab measures how far the sensor's clock drifts from this host's over time.
LEDs
not read
The firmware's toggle-LED command holds the lower LED solid red on top of the sensor's own indications, and leaves it that way until it is toggled again or the sensor is power-cycled — a disconnect does not clear it. It is a "which sensor is this one" aid rather than a health check; the sequence that exercises every LED colour is on the Test tab, as part of the factory self-test.
Device commands
The channel inquiry is what tells this page the shape of a stream frame, so it runs on connect and after an Apply; it is here for the case where the sensor was reconfigured by something else meanwhile. The reboot is armed rather than immediate — the firmware cannot reboot while the link is up, and skips it altogether while the sensor is recording so that it can never truncate a trial. It is one-shot: it never carries into a later disconnect. Reach for it after writing advertising names, which the Bluetooth module only re-reads at boot.
Configuration
Configuration image (InfoMem, 384 bytes)
not read
Highlighted bytes differ from the image last read from the sensor. Every byte no field on this page models — the reserved bits, the MPL regions — is carried through a read, edit and write untouched.
Calibration turns the sensor's raw counts into physical units: C = R−1·K−1·(U − B), with B the offset, K the diagonal sensitivity and R the alignment. It is per sensor and per range, so a sensor calibrated at ± 2 g has nothing stored for ± 16 g and falls back to the factory defaults there — which is normal, not a fault. Nothing on this tab changes what the sensor measures; it changes how those measurements are read.
Stream
Record to CSV
not recording
File
–
Rows
0
Written
0 B
Recording starts once the first frame has arrived, so the columns are the ones the sensor is actually sending. Rows stream straight to the file you pick, so a long session is not held in memory.
Files are pulled off the card over the same Bluetooth link that carries the configuration, so a download and a live stream cannot run at once. Each file is verified by size on this host before it is deleted from the card, and an interrupted download resumes from what is already on disk — re-running it is always safe.
These names live in a record in the sensor's expansion-board EEPROM, not in its configuration image, so they survive a configuration write and are not part of a saved .bin. The firmware seeds the record with the factory names at first boot and treats it as the only source of truth afterwards, so what is shown above is what the sensor really announces. Every link reaches the record — BLE, Classic Bluetooth and the USB-C/dock connection alike.
Throughput test
not measured
Streams data for five seconds and counts what arrives, which is the only honest way to know a link's throughput: on BLE the connection interval is negotiated with the host's own Bluetooth stack, and on Classic Bluetooth the rate follows that host's own serial buffering, so two hosts and the same sensor can differ severalfold. It needs one of the Bluetooth links either way — the USB-C dock command set has no data-rate test at all. The figure lands in the SD card tab's stats and drives its download estimates, so measuring once after connecting makes those estimates worth reading.
Factory self-test
This is the same self-test the firmware runs on the production line. The sensor prints its report over this link as it goes, and stops everything else for the duration — up to about a minute for the LED-state walk-through. Nothing can interrupt it: Cancel stops this page listening, and the sensor keeps printing until its TEST END line. The LED tests are meant to be watched, because each line names the LED that should be lit as it is lit.
Real-time clock drift
The sensor's real-world clock is driven by its 32 kHz crystal, so the crystal's error shows up here directly — the absolute figure the self-test's own crystal check cannot give, because that one measures the 32 kHz crystal against the 16 MHz one and reports the difference. A wired link is the better one for this: its round trips jitter less than Bluetooth. Expect a usable figure within an hour or two, and leave it longer for a tighter one; keep this tab open and stop the host from sleeping. First measurements on hardware, docked: a stock Shimmer3R read about −9 ppm, and a unit reworked to 22 pF crystal load capacitors about −98 ppm. Docked sensors read a few ppm low from charge self-heating, so a battery run at room temperature gives the comparable figure. The fit rebaselines itself if this host's own clock is stepped.