Technology

A full embedded product, in something the size of a plectrum.

Three sensors, a Bluetooth stack, a signed update chain and a power policy, inside a sealed body with no debug access and a battery that has to last a practice session. This page is the engineering view — written for the technical reviewer a prospective buyer sends in first.

Hardware

Silicon and board

The parts were chosen for a product, not a prototype: a pre-certified radio module to keep regulatory cost down, and sensors whose on-chip FIFOs and low-power modes do the work the processor would otherwise burn battery doing.

Rev 3.3 — fitted parts

SoC / module: Nordic nRF52832 on a Murata WSM-BL241 moduleCortex-M4F with Bluetooth Low Energy, in a pre-certified module — the radio approvals come with the part rather than with the board.
Motion: Bosch BMI270 six-axis IMUAccelerometer to 1600 Hz and gyroscope to 400 Hz, read through the sensor FIFO on a hardware interrupt rather than polled.
Environment: Bosch BMP390 barometric pressure sensorSampled at 25 Hz while the device is active, asleep with its configuration retained while it is not.
Battery: Maxim MAX17048 ModelGauge fuel gaugeState of charge without a sense resistor, with a low-charge alert line wired into the power path.
Sensor bus: I²C at 400 kHz, DMA-drivenThe standard 100 kHz cannot sustain a motion FIFO drain at full rate.
Board revision: Rev 3.3, fabricated and assembledRev 2, 3.1 and 3.2 exist as history; a Rev 3.4 change set is documented and not yet fabricated.

Dimensioned drawing of the Pickatto pick — Dimensioned geometry for the moulded body — the envelope every revision of the board has had to fit inside.

Successive hardware revisions of the Pickatto pick side by side — Hardware evolution across revisions, ending at the Rev 3.3 board that exists today.

Firmware

Modern firmware, on hardware, proven.

The firmware is Rust on Embassy over Nordic's SoftDevice. It replaced the original C implementation the product first shipped on, matched it feature for feature, and was verified on real hardware — including a live over-the-air update that installed it onto a device already in the field. The C line is retired and no longer maintained.

Rust on Embassy

APPLICATION

Async tasks, one per sensor, over Nordic's S132 SoftDevice. Every piece of logic that can be tested away from the hardware — wire formats, sensor configuration arithmetic, unit conversions — lives in its own crate with host tests, because that is where the bugs had been.

Tested where testing is cheap

CONFIDENCE

The portable crates run their suites on a development machine in seconds, so a wire-format or scaling regression is caught before a board is involved. What is left for the bench is the part that genuinely needs hardware.

Scheduling built around the sensor, not the clock

Motion data is drained from the IMU's hardware FIFO when the sensor raises a watermark interrupt, and telemetry is served from whatever that drain produced. The earlier firmware read the sensor a second time to answer telemetry; the two reads collided on the shared bus often enough to lose a third of the samples.

A watchdog with per-task channels sits under all of it, and the timing margins are enforced by compile-time assertions rather than left as comments — slow a poll past a quarter of the watchdog window and the build stops, instead of a device in a drawer becoming a reset loop.

Active → idle, per subsystem

Accelerometer: 1600 Hz, performance filter → 50 Hz, low-power path
Gyroscope: 400 Hz → off
Barometer: 25 Hz → asleep, configuration retained
Advertising: 187.5 ms → 1 s
Telemetry: 50 Hz → stopped
Wake trigger: A summed per-axis change over 0.25 g, or a phone connecting

Update chain

The only way into a sealed device.

Units are enclosed after manufacture and the debug header is inaccessible, which makes over-the-air update not a convenience but the sole route in. Everything about how it is built reflects that.

Signed, dual-bank, validated

DFU

A new image is written to the second bank, checked against a cryptographic signature and a stored CRC, and only then swapped in. An image that fails either check never runs, and the device keeps the firmware it had.

A one-way version floor

ANTI-ROLLBACK

The bootloader refuses any package numbered below what is installed, which blocks downgrade attacks and accidental regressions. There is one version space per device, and the shipped floor is recorded by hand because a sealed unit cannot be read.

Reproducible to the byte

VERIFY

The bootloader build was moved off a 141-second, 581 MB vendored toolchain onto a 1.3-second one, with byte-identical output as the acceptance criterion and a committed hash that fails the build if it moves. Even the original's odd compiler flags were reproduced, because they are what shipped.

Flash map — fixed, and shared by every fielded device

Range	Contents	Owner
0x00000	Master boot record and SoftDevice S132 7.2.0	Nordic binary
0x26000–0x76000	Application slot	Application firmware
0x76000	Boot log — append-only power-event record	Application firmware
0x7F000	Bootloader settings — image CRC and version floor	Bootloader

Dual-bank update halves the usable slot, so the practical image budget is about 162 KB — checked by a script on every build rather than discovered at release time.

Interface

A documented wire protocol, not an ad-hoc one.

Sensor data goes out as protocol-buffer messages over a vendor Bluetooth service. The definitions in the firmware repository are the single source of truth, and both the companion app and the bench tool are written against them. Neither end negotiates the contract at runtime, so it is documented and tested at both ends rather than assumed — a mismatch here produces a plausible wrong reading, not an error.

GATT services and characteristics

Vendor base UUID: 8fa3xxxx-81b5-0452-db0d-890911794324
0xFE59: Nordic buttonless DFU — registered first so firmware update always holds the lowest handles
8fa31501-…: Environment — 18-byte protobuf, notify
8fa31502-…: Motion — 38-byte protobuf, notify
8fa31503-…: Fuel gauge — 38-byte protobuf, notify
8fa31504-…: Capture control — record, upload or abort
8fa31505-…: Capture data — chunked upload, sequence-numbered

High-rate capture, and why it exists

Classifying a pluck has to happen on the device: six axes at 1600 Hz is roughly 38 kB/s, and Bluetooth Low Energy here carries nothing like that. But the thresholds a detector needs can only come from real waveforms on a host.

So the device records a 1.28-second window — 2048 accelerometer and 512 gyroscope samples, about 15 KB — into RAM at full rate, then uploads it slowly once the playing stops. The blob is self-describing: a magic number, sample counts, sensor timestamp, output rates and full-scale ranges, ahead of raw sample triples.

That is a labelled-dataset pipeline, already built. It is what a buyer would use to train on-device gesture and technique detection — and the reason the next feature set is an engineering exercise rather than a research one.

// capture header, 20 bytes

"PIK1" · accel_count · gyro_count

sensor_time · odr · full_scale_range

// then int16 triples, accel then gyro

Tooling

Everything needed to work on it is in the box.

A technology handover fails on tooling more often than on the technology. The development environment here is small, fast and documented, and none of it depends on a person.

Bench tool

MACOS

Talks to the device over the Mac's own Bluetooth radio — no phone, no Xcode, no signing. Scanning and signal strength, service inventory, live streaming, CSV logging, labelled capture recording, update triggering, boot-log readout and a full-screen dashboard.

Fast, hermetic builds

BUILD

The bootloader builds in 1.3 seconds from a 5.9 MB checkout with nothing but make and a compiler. The application firmware builds and runs its host test suite from one script, and flashes over a probe with a single command that also writes the settings page the bootloader validates against.

Documentation written for a successor

DOCS

Each repository carries a long-form document covering the parts that bite: startup ordering that cannot move, the bus faults and what each symptom accuses, the hardware errata and the behaviour that exists to work around them. Written to be read by whoever comes next.

Hardware errata are documented rather than discovered. Thediligence sectionsets out the known Rev 3.3 fault, its root cause and the fix.

Acquisition & licensing

Send your engineer.

The fastest way to evaluate this is to put a technical reviewer in front of the repositories and a board. We will do that under NDA, with whoever wrote it on the call.

Request the data room See the asset inventory