Skip to content

Developer Documentation Index

Every developer document in the repository, grouped by the code that owns it. The types and the rules for writing each are in the documentation guide. The end-user manual is separate, under host/docs.

A type or status in italics follows any entry that is not a current README or design document.

Project

  • Repository README — Top-level CMake options, prerequisites and build commands for host tools and firmware on Windows, macOS and Linux, and installing a macOS release.
  • Developer Documentation Guide (procedure) — Where each kind of developer document lives, the front matter it carries, and how the index and portal are generated.

Architecture

  • Architecture — How the tags, the host tools and the recorded data fit together.
  • System Overview — One-page map of the system -- tag firmware, the SWD monitor through a base, the shared protobuf schema, flash logs, download to SQLite, and the host applications -- with links to where each part is documented.

Bench and Hardware Verification

  • Bench Procedures — Hardware procedures for verifying firmware changes, measuring power, debugging, and capturing a tag's state.
  • Capturing a Tag (procedure) — Capturing a tag's state over SWD before anything resets it, rebuilding a download from the capture, and keeping that rebuild in step with the firmware.
  • Debugging a Tag (procedure) — Ways to see inside a tag (the retained SRAM2 scratchpad and single-store probes, GDB over SWD, current, GPIO markers, the monitor) and what each costs or disturbs.
  • Power Testing (procedure) — The shared procedure for measuring a tag's current with the Joulescope -- rig setup, the server, flashing and attaching, taking a trustworthy number, supply voltage, the qualification tools, and what to record.
  • Verifying a Firmware Change (procedure) — How to verify a firmware change -- confirm what compiled, rebuild cleanly, compare disassembly rather than checksums, measure idle after power-path changes, and distrust host tools and checks until they are shown right.

Build

  • Build — The firmware and host build model; setup steps per platform are in the root README.
  • Build Worklist (worklist) — Open gaps and questions in the reproducible firmware build: provenance not in the image, unrecorded qualification hashes, uncollected bench manifests, the old board path, and pending pins.
  • Tag Firmware Build Reproducibility — The reproducible firmware build as implemented: distributed-tag scope, committed generated sources, per-image SHA-256 manifests, configure-time checks, CI, and how to maintain it.
  • Toolchain inventory (procedure) — Every tool the tag-designs work depends on across all five repositories, with version, install path and what it serves; written for rebuilding a macOS workstation.

Decision Records

Investigations

  • Investigations — Where dated fault investigations and measurement campaigns are kept, and how they are closed.
  • Firmware build reproducibility: findings (2026-09) (investigation, closed) — How the nanopb runtime and generator were found disagreeing, and the first end-to-end release-firmware CI run, its toolchain-checksum failure and its 15-of-15 hash verification.
  • Offline Log Reconstruction (investigation, closed) — Whether fw-v0.0.3 downloads can be rebuilt from an SWD capture plus the release package, tag by tag, with the gaps and firmware defects the reading found.
  • probe-rs evaluation (2026-10) (investigation, open) — Whether probe-rs could replace tagcore's ST-LINK layer, the SWD recovery primitives and STM32CubeProgrammer in qtprogram - what its source says, and what a spike against the tag bases found.

Release

  • Release — Qualifying, programming and publishing firmware and host tool releases.
  • Releasing Tag Firmware and Host Tools (procedure) — How to qualify a firmware image on the bench, program and record a field tag from a release, and cut a signed host tools release.

Shared Contracts

  • Shared Contracts — The contracts host tools and tag firmware both compile against, and where each is documented.
  • Magnetometer and Accelerometer Axes — Tag firmware rotates each magnetometer and accelerometer part into a common tag frame, and the host orientation code assumes one fixed magnetometer-to-accelerometer alignment; what each family applies, and how to check a capture against it.
  • Shared Binary Log Formats — Conventions for the packed C log structs in include/ that host and firmware both compile: naming, packing, size and endianness checks, nanopb buffer coherence, and copy-not-cast host decoding.
  • Shared Contracts Worklist (worklist) — Open work on the contracts host and firmware share, starting with the monitor transport's stale VC_CORERESET after a timeout.
  • Tag Configuration Model — How a tag's configuration is defined, which fields each tag supports (its default config, read by tagcore's ConfigShape), how qtmonitor shows and writes it with fixed panels per tag type, how files are merged, the fields with tag-specific meanings, and how all of it is checked without hardware.
  • Tag Monitor Interface — Reference for the monitor transport as implemented: L4 DebugMonitor and U3 shared-memory attach, calls, detach, and sleep interaction.

Shared Contracts / Proposals

  • Skipped Pages in a Data-Log Download (proposal, proposed) — The tag marks a hole in its data log with a new Ack.Err value, DATASKIPPED; every other reply without records ends the log, so host downloaders follow one rule and no longer read Status data counts, whose units differ by family.
  • Tag-Reported Configuration Presence (proposal, proposed) — Deferred. Let each tag report which Config fields it supports, through proto3 optional fields and a config_schema marker, instead of the host reading it from the tag's default config; tags already in the field keep working by falling back to the default config.

Shared Contracts

  • Proto Directory — The protobuf schema shared by host tools and tag firmware, how each side compiles it, and which tool turns a tag's default-config JSON into C.

Embedded

  • Embedded Source Layout — Orientation to the embedded tree: boards, proto-c, bases, tags and loaders, and how CMake ties firmware targets to them.

Bases

  • Embedded Bases — Layout, CMake shape and descriptions of the base and programmer board firmware targets: MCU, board and SWD implementation of each.
  • Bases Worklist (worklist) — Open work on the base and programmer firmware: SWD fault diagnostics for field bases, unbuilt SPI SWD sources, and SWD speed ideas for a future base.
  • Embedded Base Build Sources — Inventory of repo-local C and header files compiled into each active base firmware target, extracted from dependency files.

Bases / Investigations

Boards

  • Embedded Boards — How board directories generate ChibiOS board files, which firmware targets consume each board, and how to rename or check boards.

Boards / IMUTagNandv1

Boards / IMUTagNandv2

  • IMUTagNandv2 Standby Pin Bias — Standby pin bias for the IMUTagNandv2 board, and why the FLASH_PWR load-switch enable is lost across a reset.

Boards / Tools

  • Board configuration tools — The JSON-customized board generation tools: input format, LSE bypass, standby masks, standalone fmpp workflow and CMake integration.

Boards / Tools / example

Loaders

  • External Flash Loaders — SRAM-resident external flash loaders for STM32L432 NOR and STM32U375 NAND tags; layout, per-board naming, building, use with STM32CubeProgrammer, adding a loader and bench testing.
  • Loader Runtime Design — The external loader contract as traced on hardware and the runtime rules it imposes -- no startup code, interrupts or OSAL sleeps, rescue erase, Serve() -- for the STM32L432 NOR loaders and the STM32U375 SPI-NAND loader.
  • Loaders Worklist (worklist) — Open work on the external flash loaders: the L432 state-capture script, watchdog refresh in the ST entry points, untested MassErase, and NAND loader distribution.

Loaders / Investigations

Loaders / Proposals

Loaders / RV3028_PresTagv3

Tags

  • Embedded Tag Firmware — How tag targets are assembled from modules, families and local sources, diagnostics, the template tag directory and local override rules.
  • Embedded Tag Build Sources — Inventory of repo-local C and header files compiled into each tag firmware target, extracted from dependency files.
  • Tag custom.h Build Defines — Reference of custom.h defines per active tag target, module-generated TAG_ feature switches, and retired defines.
  • Tag Firmware TODO (worklist) — Open tag firmware work -- defects found by reading code, low-power and recovery questions, NAND bring-up, the next release's remaining items and their host counterparts, and cleanup.

Tags / BitTag

  • BitTag Power Measurement Log (results) — Append-only log of BitTag power measurements -- build, board, supply, config, numbers and interpretation per session.
  • BitTag Power Test Plan — Idle, Running and Finished Currents (procedure) — BitTag power qualification -- what the firmware draws in each state, the configs, the phases and the pass/fail gates for IDLE, RUNNING and FINISHED at 2.5 V.
  • BitTag TODO (worklist) — Open BitTag power-qualification work -- tool support, unmeasured phases, and a release-check bound.

Tags / BitTag / Investigations

  • BitTag First Power Qualification: Observations (2026-10) (investigation, closed) — What went wrong during the first BitTag power qualification (2026-10-03) -- an empty earlier attempt, four config and procedure defects, the immediate start, and the failing first attach to a sleeping tag.

Tags / Common Firmware

  • Common Tag Firmware Code — Map of shared tag firmware code by ownership: core, sensors, storage, rtc and test, with maintenance rules.

Tags / Common Firmware / core

  • Core Runtime — Contents of the core runtime: state machine, monitor handlers, persistent state, power and bus ownership, and the bus layer split.
  • stopMilliseconds() LPTIM ARR-Match Delay Design — How STM32L432 stopMilliseconds() delays on a single LPTIM1 autoreload match at 1024 Hz, with spurious-wake filtering.
  • I2C Backend Model — How tag I2C controllers select hardware or software backends through descriptors, the pin policy, and how the RTC binds to a bus.
  • I2C Bus Recovery — Why a reset mid-transaction wedges the shared I2C bus, and the bus-clear recovery, its call sites and pin-mode rules on STM32U3 IMUTag targets.
  • LPTIM System Timer Design (proposal, proposed) — Proposed LPTIM3/LPTIM4-backed ChibiOS system timer that keeps time through Stop modes; not built. Its Sleep-while-alarm fallback is what the U375 targets use.
  • Restart Recovery — How a tag recovers after a reset -- reset classification, reattach versus failure, the IDLE-means-empty-log invariant, header and page recovery, ECC-checked reads, storage bounds and the external erase sweep.
  • STM32U375 Low Power — How STM32U375 tags sleep -- Stop 3 as the terminal sleep, Stop 2 or Stop 1 between IMU wakes, Sleep as the idle default, scoped STOP around SPI transfers -- the monitor guards, the layout sensitivity, and what to measure after a change.

Tags / Common Firmware / core / Investigations

  • 2026-09-u375-standby-forum-post (investigation, closed) — Forum post draft describing the layout-dependent STM32U375 Standby entry fault, register state at the WFI, and every mechanism excluded.
  • Boot Cleanup Claimed IDLE Over a Non-Empty Log (investigation, closed) — How boot cleanup asserting IDLE over a non-empty marker log made every second IMUTag collection fail, and the two defects fixed on 2026-09-02.
  • Latched Flash Error Flags and STM32U3 Low-Power Entry (investigation, closed) — The 995 uA STM32U3 idle fault attributed to a latched flash ECC flag on 2026-09-02, how the flag gets latched, and why the clear was later found not to be on the cause.
  • STM32U375 Standby Entry Depends on Image Layout (investigation, closed) — Why STM32U375 Standby entry depended on image layout -- every perturbation, compiler setting and register comparison tried, the flash-flag and SRAM2 retention side findings, and the reverted page-skip commit.

Tags / Common Firmware / core / Proposals

  • A more robust monitor for the STM32L4 tags (proposal, proposed) — Make the STM32L4 tags' monitor as robust as the STM32U3 path - first by adding the U3's fast status answer and BUSY reply to the L4 DebugMonitor handler, then optionally by moving L4 tags onto the U3 shared-memory mailbox, chosen per image by a marker in the vector table - with what each step needs, what it would and would not fix, and how to check it on the bench.

Tags / Common Firmware / modules

  • Tag Common Build Modules — How the makefile module system selects shared sources, include paths and TAG_ feature switches for each tag.

Tags / Common Firmware / rtc

  • RTC Support — Common RTC API and RV3028 descriptor binding, older RTC drivers, and the remaining descriptor-ownership todo.

Tags / Common Firmware / sensors

  • Sensor Drivers — Layout of reusable sensor drivers and the descriptor, register-device and shim patterns they follow.

Tags / Common Firmware / sensors / imu

  • LSM6DSV16X Driver Design Assumptions — The LSM6DSV16X driver contract: descriptor model, modes, trigger ownership, ODR-triggered FIFO policy, environmental samples and self-test.

Tags / Common Firmware / sensors / mag

  • Magnetometer Drivers — AK09940A and BMM350 magnetometer driver files and BMM350 descriptor, session and compensation maintenance notes.

Tags / Common Firmware / storage

  • External Storage — The descriptor-based external flash API, per-part storage modules, the SPI transaction framing layer, and planned cleanup.

Tags / Common Firmware / test

  • Shared Self-Test Driver — How the shared monitor self-test dispatcher maps test requests onto device hooks supplied by modules and families.

Tags / Families

  • Tag Families — What tag families are and the variant, family, module search order that lets variants override family files.

Tags / Families / BitPresTag

Tags / Families / BitTagNG

  • BitTagNG Family — What the BitTagNG family shares and what its variants keep local; the LIS2DU12 variant is archived.

Tags / Families / CompassTag

  • CompassTag Family — What the CompassTag family variants share, where family-specific drivers live, and links to design notes and the host simulation.
  • CompassTag Power Measurement Log (results) — Append-only log of CompassTag power measurements -- the Standby-after-attach fault before and after its fix, and the production CompassTagAT25 validation.
  • CompassTag Power Test Plan (procedure) — CompassTag power test plan -- qualifying a CompassTagAT25 release image for idle, running and finished current, with the Standby-after-attach regression as a standing gate; calibration must survive the flash.
  • CompassTag TODO (worklist) — Open CompassTag power and monitor items left by the 2026-09 Standby-after-attach work.

Tags / Families / CompassTag / Investigations

Tags / Families / CompassTag / test

  • CompassTag Datalog Simulation — How to build and run the CompassTag datalog host simulation that checks the resume-cursor, partial-page and mid-block halt fixes.

Tags / Families / IMUTag

  • IMUTag Family — What the IMUTag family shares between IMUTagNand and IMUTagNandBmp581, with an annotated list of family design notes.
  • IMUTag Family: Open Items (worklist) — Open questions for the IMUTag family -- cell voltage, supply noise on the SMPS board, the idle split, the 3.7 V projection trend, and timing-metadata gaps.
  • IMUTag Internal Header Checkpoints — Sparse internal-flash checkpoint headers that let NAND-backed IMUTag tags find their external log cursor after a reset.
  • IMUTag Power and Runtime (results) — Measured IMUTagNandBmp581 current at 3.7 V on the SMPS board per sample rate, and the battery and storage runtime each rate implies.
  • IMUTag Sample Timing — How IMUTag sample times are produced -- a jitter-free raw 32.768 kHz sampling clock, a smooth-calibrated STM32 RTC, 1024 Hz page anchors with resync flags, and host reconstruction from sample count.

Tags / Families / IMUTag / Investigations

  • IMUTag Orientation Error Budget (2026-10) (investigation, open) — Datasheet error budget for BMM350 and LSM6DSV dip, heading and field-strength estimates after qtcalibrate, 2026-10-12 -- magnetometer offset drift with temperature dominates, and calibrating at bird temperature or re-fitting the offset at the release site removes most of it.
  • IMUTag Start Aborts: Evidence and a Proposal for Persistent Failure Detail (investigation, closed) — The intermittent IMUTag abort at start -- evidence, the marker detail word added to diagnose it, and its two probable causes (a wedged I2C bus, a latched flash ECC flag), both now fixed.
  • IMUTagNand Regulator and Sleep-Mode Sweeps (2026-09) (investigation, closed) — Superseded IMUTagNand power history -- datasheet estimates, the Stop 1 era, and the LDO-versus-SMPS sweeps at 2.5 V and 3.3 V (2026-09) that produced the 3.7 V projection.
  • IMUTagNandBmp581 First Breakout Bring-Up (2026-08) (investigation, closed) — First bench validation of the IMUTagNandBmp581 target on the BMP581 breakout -- NAND and BMP581 self-tests and a short 400 Hz collection.

Tags / Families / IMUTag / Proposals

Tags / Families / PresTag

  • PresTag Family — PresTag family members and their log formats, with links to the power test plan, results, open items and host simulation.
  • PresTag Power and Schedule Test Plan (procedure) — PresTag power and schedule test plan -- what the firmware does in each state, the configs, the resting-state, period-sweep, schedule and data phases, the power model and the gates.
  • PresTag Power Measurement Log (results) — Append-only log of every PresTag power measurement with build and conditions, plus the campaign's fit, lifetime, schedule and data verdicts -- the source for figures quoted elsewhere.
  • PresTag TODO (worklist) — Open PresTag items -- the unchecked config write (F3), the silent Stop 2 no-op (F2), the brownout regression test, and measurements the hourly hibernation alarm made stale.

Tags / Families / PresTag / Investigations

  • PresTag Log Cursor Round-Up (2026-09) (investigation, closed) — How the PresTag log cursor round-up and hibernation gate used 120 instead of 60 samples, why a brownout with an odd page count desynchronised the log, and the fix (329f1e52).
  • PresTag Power Campaign and Stop 2 Diagnosis (2026-09) (investigation, closed) — The 2026-09-08/09 PresTag power campaign -- why Stop 2 looked broken (a floating PA2 input and the LPTIM arming cost), the bench incidents, and both executions' findings.

Tags / Families / PresTag / test

  • PresTag Datalog Simulation — How to build and run the PresTag datalog host simulation for both download formats, checking the last partial page and mid-page resets.

Tags / IMUTagNand

  • IMUTagNand Maintainer Notes — Hardware shape and module selection of the IMUTagNand STM32U375 target with LPS22HH pressure and 1 Gbit GD5F NAND.

Tags / IMUTagNandBmp581

Tags / Investigations

  • A Non-Failure Reset During RUNNING Aborted the Run (investigation, closed) — A non-failure reset during RUNNING aborted PresTag runs under 10 s and every IMUTag run; fixed 2026-10-02 by treating an external reset with valid retained state as a reattach.
  • Attach-Storm Failures, September 2026 (investigation, closed) — Four attach-storm failures chased in September 2026 -- non-monotonic timestamps, refused downloads, STATE_UNSPECIFIED after reset, and an unserviced stop -- three host-tool faults and one firmware fix.
  • Next-Release Fixes: Specification and Verification (investigation, closed) — How the post-fw-v0.0.3 defect fixes (A1-A3, A7) and the identity record and session facts (B1, B2) were specified and verified, on hardware and in host simulation, October 2026.
  • The internal ADC, and PresTag's resting floor (investigation, closed) — Two ADC defects dating to the initial commit, found because one breakout reported 3.9 V and 100 C; the sweep that sized the fix; its verification on three tags; and a 2.2x drop in PresTag's resting floor that is measured, bounded, and still unexplained.

Tags / Proposals

  • Field Data Extraction (proposal, proposed) — Two unbuilt changes so a returned tag's data decodes and explains itself - a session superblock in the data region, and gaps closed in the flash marker log.
  • The stored-configuration write is unchecked on every tag but IMUTag (proposal, proposed) — writeStoredConfig() ignores whether the flash write succeeded on every tag but IMUTag, so a refused program leaves a stale configuration running while the host reports the new one. A cheap fix catches it; the full fix needs a page per target.

Tags / UIUCTag

  • UIUCTag Data Collection Integration Plan (proposal, superseded) — Plan, now built, for the UIUCTag record format, write sequencing, cursor recovery, host decoder and download, with where implementation diverged.
  • UIUCTag Design — What UIUCTag is, how its hardware differs from BitPresTag, and the record layout, timing and firmware/host contract of its pressure and activity log.
  • UIUCTag Power Measurement Log (results) — Append-only log of UIUCTag power measurements -- resting states measured and good; the 2026-10-06 run verdict was retracted after the apparent fault proved to be the measurement.
  • UIUCTag Power Test Plan (procedure) — UIUCTag power test plan -- qualifying a release image for idle, running and finished current on a tag that wakes once a minute and stores one block every five.
  • UIUCTag Test Strategy — How the UIUCTag log path is tested layer by layer, from shared format helpers and host simulation to hardware, and what it does not cover.
  • UIUCTag TODO (worklist) — Open UIUCTag items from the 2026-10-04 bench session -- a run that stored nothing, a self-test that fails, and the internal-ADC fix that came out of it.

Tags / UIUCTag / Investigations

  • UIUCTag Bring-Up Report (investigation, closed) — UIUCTag bring-up sessions: six bugs found and fixed, wake timing, extended power measurement and deployment battery projections.

Tags / UIUCTag / Proposals

  • UIUCTag Minute Sampling with 8-Byte Records (proposal, proposed) — Proposal to change UIUCTag to a pressure/temperature reading every minute, stored as one 8-byte record (6 raw BMP585 bytes plus three 5-bit, 20-second activity counts), with an internal checkpoint every 32 minutes anchoring one 256-byte external page.

Tags / UIUCTag / test

  • UIUCTag Sequencer Simulation — How to build and run the host simulation of the UIUCTag acquisition sequencer and datalog against stubs and a fake flash.

Host

  • Host Software — Host tree layout by role, dependency direction, CMake entry points, packaging notes and maintenance guidelines.
  • Linux Packaging — How the Linux x86_64 host tools package is laid out, built, deployed and tested -- a relocatable tag_tools tarball carrying Qt 6.10.3, made on CI from the linux-vcpkg configuration and tested in clean containers under Wayland and X11.

Applications

Applications / qtcalibrate

  • qtcalibrate — qtcalibrate source layout, runtime flow, sample capture and replay, calibration constants and menus.

Applications / qtmon

  • QtMonitor — qtmonitor live and fixture screenshot modes, screenshot commands and sizing.
  • qtmonitor architecture — How qtmonitor's code is divided - a Qt-free core (command rule, start checks, monitor model, configuration document, download loop), a tag session whose worker thread owns the tag, and a window that only draws the model and sends commands - with the data flow, the threading rules, and how each part is checked.
  • qtmonitor: Configuration Editor, Menus and Start Checks — qtmonitor is a configuration editor as well as a tag monitor -- one document from defaults, a file or a tag, commands as actions in in-window menus, a status strip with Approved, Start and Stop, and Start checks (clock within 2 s, self-test ALL_PASSED, Approved) that warn and let the user continue or cancel.

Applications / qtmon / Proposals

  • qtmonitor: engine, model and views (proposal, historical) — Restructure qtmonitor into an engine that owns the tag on its own thread, a Qt-free model that holds every rule (action states, start checks, the configuration document), and views that only draw the model and send commands - done in Qt first, step by step under the existing goldens, so a Rust and Tauri port becomes a translation of each layer.

Applications / qtmon / Proposals / config-form-mockup

  • qtmonitor Configuration Form Mockup — A web mockup of qtmonitor's Configuration tab split the proposed way - the panels as a data spec, a stand-in engine owning the document and every rule, and a generic renderer that only draws field kinds and exchanges messages.

Applications / qtmon / tagconfiguration

  • QtMonitor Configuration Panels — How qtmonitor's Configuration tab is built from fixed panels selected by tag type, how panels read and write Config, the cross-check against the tags' default configs, and adding tags, fields and panels.

Applications / qtmon / test

Applications / qtprogram

  • qtprogram — qtprogram (Tag Programmer) source layout, how it chooses the internal-flash erase from the image's linker symbols, its program sequence, its command-line modes, and its remembered settings.
  • qtprogram as a batch programming station — qtprogram is a batch programming station -- it finds STM32_Programmer_CLI, the base and the tag itself, offers verified GitHub firmware releases, identifies tags and images by their identity records, programs and tests each tag, and records every attempt in a CSV.

Applications / qtprogram / test

  • qtprogram Offline Checks — How to build and run qtprogram_checks, the offline checks of the CLI parsers, the record CSV, the release-archive member filter, the release list, and the download-extract-verify path.

Applications / sensorviz

  • sensorViz — What sensorviz does, its architecture, design rules, data model, plotting rules, preferences, transforms, documentation capture hooks, known limitations and build check.
  • sensorViz TODO (worklist) — Open sensorviz work - validation, load warnings, transform registry, session files and GUI tests.

Applications / sensorviz / Proposals

  • A Toolkit-Neutral Core for sensorviz (proposal, proposed) — Split sensorviz into a Qt-free core (Session, StreamCatalog, ViewModel, TransformRegistry, PreferenceStore over sensordata) and thin front ends, so the Qt app and a possible webview app are both clients of one implementation; all phases are built, with the as-built differences and checks recorded per phase.
  • Decimating Backend Measurements (results) — Measured memory, load time and view-query cost of current sensorviz and of a decimating-backend prototype on a synthetic full-NAND IMUTag log (19.7M accel+gyro samples).
  • Decimating Data Backend for sensorviz (proposal, proposed) — A Qt-free decimating data backend for sensorviz - one-pass columnar loading, a min/max pyramid and per-view M4 envelopes - with a memory and performance analysis of the worst-case IMUTag log (4.8 GB originally, about 1 GB proposed); all phases are built.
  • SensorViz Documentation Screenshot Capture Plan (proposal, historical) — Plan, largely built, for fixture logs and capture hooks that generate sensorviz user-guide screenshots.
  • sensorviz: Leaving Qt (proposal) — The path for sensorviz, the last Qt-only host application, to a Rust/Tauri front end on the shared UI kit - finish the Qt-free C++ core first (toolkit-neutral-core phases B-F) with the Qt app shipping throughout, a plot spike that chose uPlot in the page and jsPDF for printing, then a C interface, the Tauri app, and retiring Qt from the packages.

Applications / sensorviz / test

  • sensorViz Offline Checks — How to build and run catalog_check, plotspec_check, preference_check, transforms_check and viewmodel_check, the Qt-free checks of sensorViz's log reader, plot policy, preference files, display transforms and view state, and session_cli, sensorViz without Qt.

Applications / sensorviz-rs

  • Tag View: sensorViz (Rust) — Tag View (tagview), sensorViz in Rust - the Tauri port of the Qt sensorviz over sensorViz's C++ core: the engine, the shell and the uPlot page; how to build, run and package it, how it differs from the Qt app, and what the plot spike that chose uPlot and jsPDF showed.

Applications / tagcalibrate-rs

  • Tag Calibrator (Rust) — Tag Calibrator in Rust, the port of qtcalibrate, shipped as tagcalibrate - its window on the host UI kit, the engine over the C++ calibration session, the Tauri shell, how to run it, how it is packaged, and how it is checked against qtcalibrate.
  • Tag Calibrator (Rust): UI/engine contract — The contract between Tag Calibrator's Rust engine and its web UI - the threads, where the calibration runs, the view state the engine publishes, the prompts that replace qtcalibrate's dialogs, and the commands and queries the UI sends.

Applications / tagmonitor-rs

  • Tag Monitor (Rust) — Tag Monitor in Rust, the port of qtmonitor shipped as tagmonitor - what is ported, how it is checked against the C++ app's oracles, and how to build, run and test it.
  • Adding a tag type to Tag Monitor (procedure) — How to make Tag Monitor (Rust, and qtmonitor with it) support a new tag type - the TagType value, the default configuration, the panel table, a new panel when the tag has new fields, the probe cases and goldens, downloads, and the checks that say it is done.
  • Building and packaging Tag Monitor (Rust) — How Tag Monitor in Rust is built and shipped - the cargo workspace, the CMake target that wraps cargo and links the C++ log writer (tagcore_c), the per-platform install layout, the CI build, the third-party notices, and what it shares with Tag Programmer's packaging.
  • Tag Monitor (Rust): architecture and source map — How Tag Monitor in Rust is put together - the three layers and two threads, a roadmap of every file and the qtmonitor code it ports, how a command and a form edit travel through the code, where to make common changes, and what keeps it in step with qtmonitor.
  • Tag Monitor (Rust): UI/engine contract — The contract between Tag Monitor's Rust engine and its web UI - the threads, the view state the engine publishes, the prompts that replace qtmonitor's dialogs, and the commands and queries the UI sends.

Applications / tagprogram-rs

  • Tag Programmer (Rust) — Tag Programmer in Rust - qtprogram's station and programming session ported to a toolkit-free engine, programming through probe-rs instead of STM32CubeProgrammer, with a Tauri shell over a web front end.
  • Building and packaging Tag Programmer — How Tag Programmer is built and shipped - the cargo workspace, what build.rs stages and why, the CMake target that wraps cargo, the per-platform install layout and signing, the CI build, the third-party notices, and the platform pitfalls each of those choices answers.
  • qtprogram (Tag Programmer v2.0): functional and visual specification (results) — A functional and visual specification of qtprogram (Tag Programmer v2.0), read from its source and manual, that the Rust port reproduces.
  • Tag Programmer engine — How Tag Programmer's engine works - one thread that owns all state, the message loop and its deadline timers, worker threads for slow work, the station's checks and attach path, the programming session's step machine, and the hazards a maintainer must not reintroduce.
  • Tag Programmer: UI/engine contract — The contract between Tag Programmer's engine and its web UI - the view state the engine publishes, the commands and queries the UI sends, the prompts - and the model API the engine is built on.

Command Line

  • Command-Line Tools — Distributed and bench-only command-line tools, with usage notes for tag-capture, tag-xflash, tag-sramcall, tag-rebuild, tag-log-import, tag-txt-import, tag-cal-write and dataprocessing.
  • Command-Line Tools TODO (worklist) — Open command-line tool work - dataprocessing tests, further processors and SensorViz support for processed files.
  • DataProcessing Post-Processing Application Design — How the dataprocessing CLI copies a SQLite log and adds calibrated CompassTag streams and IMUTag orientation with provenance, and how the work is split with sensoranalysis, qtcalibrate and SensorViz.

Command Line / Proposals

  • DataProcessing Implementation Plan (proposal, historical) — The original refactoring steps and implementation phases for the dataprocessing CLI, kept for the record now that the tool is built.

Command Line / test

  • tag-txt-import Check — Offline check of tag-txt-import - anonymised fixtures of each legacy .txt variant and repair, and the script that converts them and asserts each conversion report.

commandline-rs

  • Tag command-line tools (Rust) — Rust ports of the tag command-line tools built on tagcore-rs - which tools exist, which are not ported yet and why, how they differ from the C++, and how they were checked.

Common

  • Host Common Qt Helpers — Small shared Qt helpers used by host applications through the host_common target.

Libraries

  • Host Libraries — Table of host libraries and their dependency direction.

Libraries / calibsession-rs

  • calibsession (Rust) — calibsession, a safe Rust wrapper over the tag calibration session and compass display angles in tagcore_c - so a Rust program calibrates exactly as qtcalibrate does; building, the API, and the replay test against qtcalibrate's own figures.

Libraries / sensoranalysis

  • SensorAnalysis Library — Contents of the UI-free sensoranalysis library for compass calibration and orientation.

Libraries / sensoranalysis / test

  • sensoranalysis Offline Checks — How to build and run the offline sensoranalysis assertion checks for the magnetometer and accelerometer calibration metrics.

Libraries / sensordata

  • sensordata Library — The Qt-free sensordata library - columnar loading of tagcore SQLite logs, min/max pyramids, M4 view queries and exact read-back - and how to build and check it.

Libraries / sensordata / test

  • sensordata Offline Checks — How to build and run sensordata_check, the offline assertion program for the sensordata library, and what it covers.

Libraries / sensorui

  • SensorUI Library — Contents of the sensorui library of reusable Qt and QML sensor widgets.

Libraries / sensorviz-session-rs

  • sensorviz-session (Rust) — sensorviz-session, a safe Rust wrapper over sensorViz's Qt-free core through tagcore_c's svz_* functions - so a Rust program opens and shows a tag log exactly as the Qt sensorViz does; building, the API, the JSON the interface carries, and the tests.

Libraries / tagcore

  • TagCore Library — tagcore responsibilities - USB and monitor communication, log writers, configuration shapes, SWD capture and recovery code, offline checks - and links to its design documents.
  • SWD Capture and Recovery Library — How the tagcore SWD capture and recovery library works - attaching without booting, what a capture holds, the per-MCU rules, the identity record and the Serve() loader protocol.
  • tagcore TODO (worklist) — Open work in tagcore - taking btviz out of the standard build, hardware verification of the monitor side channel, keepalive and LastError added for the tag server proposal.

Libraries / tagcore / Investigations

  • Cost of a gRPC Server in the Host Build (2026-10) (investigation, closed) — Measured cost of a gRPC server in the host build on macOS arm64 - official gRPC C++ (+12 MB per executable, over an hour of cold dependency build, a c-ares failure on the static triplet) against grpcxx (+0.24 MB, half a minute), with a Python grpcio client working against grpcxx.
  • SWD Capture Library Bring-up (investigation, closed) — Dated build log of the SWD capture library, 2026-09-30 to 2026-10-02: what each implementation step measured on bench tags, the C_MASKINTS stall, and how the resetCause question was settled.

Libraries / tagcore / Proposals

  • A Fake Tag for Testing the Command Line Tools (proposal, proposed) — Test the command line tools without hardware by linking them against a fixture-driven fake of tagcore's Tag class in a check-only build; shipped binaries are unchanged, and the runtime fake backend the Python binding needs is left to that work.
  • Deployment Metadata for Processing (proposal, proposed) — Record, inside each SQLite log, the few deployment facts that change how it is processed - location, time zone, mounting, on-animal interval, elevation or reference pressure, and an optional declination - all optional, read and written through a Qt-free tagcore layer, edited with a small host app (tagmeta) and a command-line twin, and used as defaults by sensorviz, the filter and dataprocessing.
  • Recovery Library: Identification, Rescue and Python (proposal, proposed) — The unbuilt parts of the SWD recovery library - identifying older images by hash and strings, the rescue-erase procedure, and the Python binding - with the check that ends each.
  • Retiring the Text Log Format and btviz (proposal, proposed) — Retire the legacy .txt sensor-log format and btviz - convert the existing BitTag and PresTag .txt collection to SQLite with a command-line importer that round-trip-verifies every conversion, use the conversion and a dual-format field download to prove the SQLite writer on real experiments, then delete the text writer, btviz and their docs; actograms and filtering move to general-purpose tools reading SQLite.
  • Rust host applications over the C++ libraries (proposal, proposed) — How Rust (or other non-Qt) host applications should use the C++ libraries they depend on - what is already Qt-free, one C interface library over them (prototyped for the SQLite writer with a Rust tag-dwnld), shared against static linking measured, and where leaving Qt actually costs.
  • Simulated Tags and a Tag Server for Testing (proposal, proposed) — Two testing capabilities - Qt applications and command line tools running in-process against a simulated tag, and Python (or any gRPC language) driving a real tag through a standalone grpcxx-based tag-server that mirrors the Tag API and adds a memory read/write side channel; shipped applications gain no new dependency.
  • TagCore Python Interface Design (proposal, proposed) — Proposed Python binding for tagcore: API, protobuf boundary, shared download service, threading, packaging and tests; not built.

Libraries / tagcore / recovery

  • tagcore/recovery TODO (worklist) — Open work on the SWD capture, loader and offline-rebuild code in tagcore/recovery.

Libraries / tagcore / sqlitelog

  • SQLite Log Writer — How the SQLite log writer decodes UIUCTag and IMUTag downloads into rows, and a known BitPresTag activity-geometry inconsistency; the schema itself is in the user reference.

Libraries / tagcore / test

  • tagcore Offline Checks — How to build and run the tagcore offline assertion checks — UIUCTag format, decoder and end-to-end, and ConfigShape.

Libraries / tagcore-c

  • tagcore_c (C interface) — tagcore_c, a C interface to the C++ SQLite log writer, the calibration session and sensorViz's core for Rust and other languages - the tlw_, tcs_ and svz_* functions, the shared and static builds, symbol hiding, and how it was checked.
  • tagcore_c and taglogwriter: architecture — How Rust tools write tag SQLite logs through the C++ writer, calibrate through the C++ calibration session, and view logs through sensorViz's core - the layers (tag-dwnld, taglogwriter-rs, calibsession-rs, sensorviz-session-rs, tagcore-c-sys, tagcore_c, SqliteTagLogWriter, CalibrationSession, sensorviz::Session), the tlw_* contract, how the static and shared libraries are built and linked per platform, the Rust safety model, and what a maintainer must keep in step.

Libraries / tagcore-c-sys

  • tagcore-c-sys (Rust) — tagcore-c-sys, the one Rust crate that links the tagcore_c library and declares its C functions (tlw_, tcs_, svz_*), so the safe wrappers over it - taglogwriter, calibsession, sensorviz-session - can be used together in one program.

Libraries / tagcore-rs

  • tagcore (Rust) — Rust port of tagcore's tag interface (Tag, TagMonitor, LinkAdapt) and ConfigShape - layout, how it maps to the C++, where it deliberately differs, and how to build and test it.
  • tagcore-rs design — How the Rust tagcore is put together - the three layers and who owns the USB link, the concurrency model, how failures are reported and logged, the generated protobuf types, and the rules for keeping the port in step with the C++ tagcore.

Libraries / taglogwriter-rs

  • taglogwriter (Rust) — taglogwriter, a safe Rust wrapper that writes tag SQLite logs through the C++ writer in tagcore_c - building and linking it (shared or static), its API, and the log-import check.

Libraries / tagprobe-rs

  • tagprobe (Rust) — tagprobe - programming, connect checks and flash read-back for tags through a base, on probe-rs, with a field-safe ST-LINK driver for bases whose firmware predates the identify command.
  • tagprobe design — How tagprobe programs tags through probe-rs - choosing a driver from the base's identity, how the field-safe driver maps probe-rs's DAP model onto the commands every base supports, one session per operation under reset, the program sequence (erase plan, verify, PEMPTY, start), and the threading and base-sharing rules callers must keep.

Proposals

  • A Linux Release Package for the Host Tools (proposal, historical) — The plan, now built, for a Linux x86_64 host tools package -- a relocatable tarball built on CI against the same aqt Qt and static vcpkg libraries as Windows and macOS, with udev rules for the ST-LINK base.

python / tagclient

  • tagclient — tagclient, the Python client for tag-server - installing it, using TagClient and TagServerError, and running its tests with and without a tag.

python / tagclient / examples

  • tagclient Examples — Python counterparts of tag-info, tag-start, tag-stop, tag-reset, tag-dwnld and tag-peek, plus a live status monitor, written against tag-server with tagclient.

python / tagsim

  • tagsim — tagsim, the Python tool that replays a recorded ArduPilot flight into a genuine IMUTag SQLite log plus a ground-truth file, prototypes the post-processing attitude and altitude filter, scores estimates against that truth and exports both for UAV Log Viewer - installing, running, testing, and what it does not model yet.
  • Compass Baseline Results (results) — Append-only log of tagsim scores on the recorded pattern flights - dataprocessing's single-sample IMUTag compass, the baseline a post-processing filter has to beat, and the navigation filter prototype against it - with the build, settings and conditions of each run.
  • IMUTag Navigation Filter (Prototype) — tagsim's Python prototype of the IMUTag post-processing filter - a multi-rate error-state EKF over attitude, gyro bias, scale and misalignment, accelerometer bias, a magnetometer offset, relative altitude and vertical velocity, with an RTS smoother and a fitted magnetometer clock - how it orders the sensors' events, its updates and initialisation, its storage, and what it does not model.
  • tagsim User Guide (procedure) — A plain-language guide to tagsim for its users - how a recorded flight becomes a simulated IMUTag log with ground truth, how the post-processing filter estimates attitude and altitude from that log, how to run a simulation, filter and score it, and how to run the tests.
  • tagsim: How It Works — How tagsim turns an ArduPilot flight into an IMUTag log - glitch repair, the attitude and position splines, the sensor model and its axes, the datasheet sensor errors, magnetometer timing, page packing, the truth file - and how it scores an orientation estimate and exports truth and estimate for UAV Log Viewer.

python / tagsim / flight-comparison

  • Pattern-Flight Comparison: Filter Against Truth (results) — Testing the IMUTag post-processing filter on simulated IMUTag data from recorded aerobatic flights - the purpose and approach, per-flight results under three sensor-error levels with side-by-side attitude visualisations, how the 25 Hz ArduPilot Kalman-filter output becomes simulated sensor logs and the sensor error models, the filter and its handling of asynchronous sampling, and where this leads (2026-10-22).
  • Rebuilding the Pattern-Flight Comparison (procedure) — How to rebuild the pattern-flight comparison - the tools it uses (tagsim's run, filter, score, compare and batch commands, tag-log-import, dataprocessing, scripts/flight_comparison.py), their setup, and the exact commands that produce its simulated logs, filter runs, pages, tables and supporting figures.

python / tagsim / Proposals

  • tagsim: Synthetic IMUTag Logs from Pattern Flights (proposal, proposed) — A Python test tool, tagsim, that replays R/C pattern-aerobatics flights through a simple IMUTag sensor model and writes genuine IMUTag SQLite logs plus ground truth, chiefly to test the future post-processing orientation filter.

spikes / probe-rs-spike

  • probe-rs spike — A probe-rs experiment against the tag bases - what each subcommand does and where the results are written up.

tagserver

  • tag-server — tag-server, the tagcore Tag API over gRPC on a local socket for test programs - building it, running it, its calls and error codes, and what it does not do.

ui-kit

  • Host UI kit — The host UI kit - a macOS-native look in plain CSS, Preact components that draw it, and a small script for the engine connection, menus, dialogs and file pickers, shared by the host applications' web front ends.

User Guide Tooling

  • Host User Guide — The end-user host manual - how to preview, build and package it, how its sources are laid out, and how its screenshots are generated from fixtures.

User Guide Tooling / fixtures / qtcalibrate

  • QtCalibrate Documentation Fixtures — The qtcalibrate replay fixtures (a CompassTagAT25 and an IMUTagNandBmp581 capture), the axis check each must pass, and the commands that replay them and generate the documentation screenshots.

User Guide Tooling / fixtures / qtmonitor

  • QtMonitor Fixture Captures — How to capture and maintain qtmonitor fake-tag fixtures, identity policy, fixture shape and screenshot replay.

User Guide Tooling / fixtures / sensorviz

  • SensorViz Sample Logs — Inventory and metadata of the sensorviz fixture logs and the screenshot capture commands.

User Guide Tooling / Investigations

  • QtCalibrate Quality Replacement: Measurements (investigation, open) — Measurements behind the qtcalibrate quality replacement, 2026-10-10: the two reference captures, the leverage retention comparison, the 76 mg accelerometer zero-g offset and the 1.1 degree of dip spread removing it bought.

User Guide Tooling / Proposals

  • Host User Guide Screenshot Automation (proposal, historical) — Pilot plan for deterministic qtcalibrate screenshots and generated annotations; the screenshot hooks were built, the qtcalibrate_docshots target and annotation renderer were not.
  • QtMonitor Documentation Screenshot Automation Design (proposal, historical) — Plan, largely built, for qtmonitor fake-tag fixtures and per-tag configuration and state screenshots.
  • Replacing qtcalibrate's Calibration Quality Code (proposal, proposed) — Replace the inherited magcal/quality.c with owned code: a leverage-based retention policy, robust residual statistics, an accelerometer dip-consistency check, and a heading-accuracy headline metric.

Other

LICENSES

  • Licenses — The project's MIT license, which shipped programs and firmware are distributed under GPL-3.0 and why, the third-party inventory behind the notice files, and how to keep them current.
  • Licensing Worklist (worklist) — Remaining licensing follow-ups from the 2026-10-06 inventory.