567 lines
30 KiB
Markdown
567 lines
30 KiB
Markdown
# Measurement notes
|
||
|
||
The lab notebook for this rig: what was measured, when, on what, and what it
|
||
changed. [README.md](README.md) documents how the code works *now*; this file is
|
||
the record of how that was arrived at, and it is append-mostly — an entry is
|
||
corrected rather than deleted when a later measurement supersedes it.
|
||
|
||
Every capture cited here predates the current header format and has been
|
||
deleted (`*.csv` is gitignored). The numbers stand as measurements; the files
|
||
cannot be re-loaded. Re-record before relying on any of it.
|
||
|
||
**Rigs.** Two hosts appear below. *Bench* is bare metal. *VM* is a
|
||
resource-limited virtual machine with virtualised USB passthrough, shared cores
|
||
and background load; every host-side ceiling measured there is pessimistic and
|
||
labelled as such.
|
||
|
||
---
|
||
|
||
## Superseded conclusions
|
||
|
||
Read this first — these appear as firm recommendations in earlier entries and
|
||
are no longer right.
|
||
|
||
| Earlier conclusion | Superseded by | Now |
|
||
|---|---|---|
|
||
| "400 kHz measured best; use 400" | three-run repetition at each speed | 750 kHz is fastest and is the default. The 4% edge for 400 kHz sat inside the run-to-run spread of a single short run |
|
||
| "Pair cycle count with a TMRC step: 200/0x94, 400/0x95, 800/0x96" | the cycle-count rate model | Hold TMRC fast and use cycle count as the only rate knob. The pairing advice exists only because the rate was being set by TMRC |
|
||
| "Abort the run on a missed measurement" | placeholder rows | The run continues and writes a `MISSED` row, keeping `sample_index` contiguous |
|
||
| `~84,333 / cc / 3` for the sensor ceiling | fitting overhead separately | `1 / (3 × (cc/90,000 + 68.7 µs))`. The naive constant is not constant — it drifts from 84,429 at cc=100 to 89,191 at cc=1200 |
|
||
| "3.3 V vs 3.0 V — indistinguishable" | interleaved A/B at two cycle counts, 2026-08-23 | Indistinguishable in *noise*, yes. But the **scale differs by 7.1%** and the **sample rate by 4.94%**. The earlier entry could not see it because the sensor had moved and the two effects were confounded |
|
||
| "60 Hz is 25× the noise floor and dominates every sd figure" | the same session, at 285–299 Hz | True at ~35 Hz where it folds to 9 Hz. At the default rate mains is resolved in band at only **1.7–1.8×** the floor. At cc=400 the dominant line is not mains at all but an **fs/4 artefact** |
|
||
| "68.7 µs per-axis overhead" | solving the model per supply | Right in order, wrong in value for this unit: **40.6 µs at 3.006 V, 38.1 µs at 3.353 V**. And the divisor does not hold either — solving both freely gives **88,546 counts/s** at 3.006 V and **92,889** at 3.353 V. Holding it at 90,000 and solving for the overhead alone gives 58.9 µs at cc=100 and 113.6 µs at cc=400, fitting neither. Both terms are per-unit and supply-dependent; `calibrate.py` carries them |
|
||
| "`× (1 + rate_error)` corrects gain, cutting the spread to 3.1%" | referencing the correction to a measured oscillator | **The 3.1% was two errors cancelling.** `rate_error` is measured against the *nominal* model, whose error is cycle-count dependent (+0.84% at cc=100, −0.99% at cc=400, same supply), and that partly cancelled the cycle-count gain difference. Referenced properly the figure is **4.9%**. The matched-cycle-count contrasts are unaffected either way |
|
||
| "gain ∝ V^−0.65, i.e. rate^−1.47; mechanism unresolved" | freeing the gain offset | **The 1.47 was absorbing a gain-offset error.** Table 3-1's `0.3671·cc + 1.5` implies gain ∝ (cc + 4.086) counts; measured on this unit it is 0.90 (LDO) and −0.09 (3V3). With the offset free, an exponent of exactly **1** is fully consistent — which is what an oscillator-clocked collection interval predicts. Correcting both leaves **2.48%**, inside the 2.3–3.1% movement floor |
|
||
| "the per-axis overhead is constant in counts (0.7σ) and changes as a time (2.8σ)" | propagating the thermal drift properly | Those σ came from a half-drift error bar chosen without justification. Propagated, the overhead is 3.60 ± 0.30 counts against 3.54 ± 0.15, and neither reading is excluded. The clean test is the supply rate ratio across cycle counts: oscillator-clocked sits **0.3σ** from it, fixed-time **1.2σ**. Favoured, not proven — drift is the limit |
|
||
| "the within-run drift could be used to correct gain in post-processing" | the coupling test, then σ_y(τ) | **Closed — do not reopen.** Gain does not follow the within-run rate: the measured slopes are **+0.08 to +0.35** where gain ∝ 1/f demands **−1**. The mechanism is that gain is set by the *ratio* of the MagI2C internal clock to f_LR, both on the same die, so a thermal shift is common-mode and divides out. That is what PNI's "stable over temperature" claim in §2 actually protects, and it is why 1241 ppm of rate drift produces no measurable gain drift. The drift is real and well resolved; it simply does not reach the gain |
|
||
| "the rate measurement is limited by host read jitter, so a longer window is always better" | σ_y(τ) on the four captures | Wrong in both halves. White jitter predicts σ/rate = √12·σ_t/(√n·T), or sub-ppm at 30 s; measured, σ_y bottoms out at **8–14 ppm around τ = 2–10 s** and then *rises*. The floor is correlated host-side noise, 10–30× the naive figure, and past ~10 s a longer window makes the estimate worse, not better — it starts measuring the drift instead of the rate |
|
||
|
||
---
|
||
|
||
## First working capture
|
||
|
||
10 s, cycle count 200, TMRC 0x96, sensor stationary on a desk beside a PC.
|
||
|
||
```
|
||
349 samples over 10.02 s -> 34.8 Hz
|
||
X: mean +6.473 uT sd 177 nT
|
||
Y: mean +50.914 uT sd 106 nT
|
||
Z: mean +18.944 uT sd 396 nT
|
||
|B|: mean 54.709 uT sd 245 nT
|
||
sample interval: 28.78 ms, sd 1.52 ms
|
||
```
|
||
|
||
- **Rate.** 34.8 Hz against a nominal ~37 Hz is in spec: §5.2.1 quotes roughly
|
||
7% one-sigma tolerance on the update rate.
|
||
- **Magnitude.** 54.7 µT sits inside the 25–65 µT band for Earth's field, which
|
||
is the real confirmation that the gain and the int24 decode are right.
|
||
- **Noise** is well above the 15 nT Table 3-1 quotes for cycle count 200, and is
|
||
not a driver problem — most likely proximity to a PC and the USB adapter.
|
||
- **Drift.** All three axes fell monotonically over the 10 s (Z most, ~1.3 µT),
|
||
so |B| went from 55.5 to 54.3 µT. Consistent with thermal settling after AVDD
|
||
is first powered; coil DC resistance moves 0.4 %/°C (Table 3-3). Allow a
|
||
warm-up before trusting absolute values.
|
||
|
||
Nothing here is calibrated: these are raw sensor outputs with no hard- or
|
||
soft-iron correction, so individual axis values reflect local distortion as much
|
||
as Earth's field.
|
||
|
||
---
|
||
|
||
## Supply A/B: 3.3 V adapter vs 3.0 V LDO — indistinguishable
|
||
|
||
> **Superseded in the noise conclusion only, and wrong on scale.** The
|
||
> interleaved re-run below finds the scale differs by 7.1% and the sample rate by
|
||
> 4.94%. This entry could not separate either from the sensor having moved.
|
||
|
||
Two 60 s captures on the bench, cycle count 200, TMRC 0x96, 400 kHz.
|
||
|
||
| | 3V3 adapter | 3.0 V LDO |
|
||
|---|---|---|
|
||
| \|B\| | 40,345 nT | 42,731 nT (**+5.9%**) |
|
||
| sd \|B\| absolute | 35.4 nT | 38.5 nT (+8.8%) |
|
||
| sd \|B\| **fractional** | **878 ppm** | **900 ppm** (+2.5%) |
|
||
|
||
**Compare noise fractionally, not absolutely.** The measured scale moved 5.9%
|
||
between the runs, and a scale change carries the noise with it, so most of the
|
||
absolute sd difference is an artefact. Normalised, the two supplies differ by
|
||
2.5% — indistinguishable on single 60 s captures.
|
||
|
||
That is the expected outcome. Table 3-5 allows 50 mV<sub>PP</sub> of supply
|
||
ripple and the LP5907's ~6.5 µV RMS sits roughly 1000× inside it, as did the
|
||
adapter rail most likely. Supply quality was never the binding constraint; the
|
||
magnetic environment is.
|
||
|
||
**The 5.9% scale change cannot be attributed to the supply from this data.** The
|
||
sensor also moved: the field direction rotated 6.16°, and the per-axis ratios
|
||
(X 1.136, Y 1.051, Z 0.870) spread by 26.6%, where a pure gain change would
|
||
scale all three identically. |B| is preserved under rotation but not under
|
||
translation through a field gradient, so movement and gain are confounded here.
|
||
|
||
There is still reason to expect 3.0 V to read *more accurately*, but it comes
|
||
from the datasheet rather than these captures: Table 3-1 footnote 1 establishes
|
||
every specification — including the gain fit behind `tesla_per_count` — at
|
||
3.0 V, noting that performance "will differ" elsewhere. At 3.3 V the gain is an
|
||
extrapolation off the calibration point.
|
||
|
||
This experiment is what `compare.py` was written for; it refuses to attribute a
|
||
magnitude difference to gain unless both movement checks pass.
|
||
|
||
### Designing an A/B supply test
|
||
|
||
- **Clamp the sensor and never touch it.** Swapping supplies must not disturb
|
||
it. This is the single thing that invalidated the first attempt.
|
||
- **Interleave A/B/A/B**, never all of A then all of B. Drift over a session is
|
||
large enough to swamp the effect, and only interleaving lets adjacent pairs be
|
||
differenced.
|
||
- **Repeat 3–4 times per configuration.** With one run each, a 2.5% difference
|
||
is indistinguishable from run-to-run variation.
|
||
- **Let it thermally settle** before each run. Coil resistance moves 0.4 %/°C
|
||
(Table 3-3), so an unsettled sensor drifts through the measurement.
|
||
- Record the configuration with `--note`, so the comparison does not depend on
|
||
filenames surviving:
|
||
|
||
```bash
|
||
./.venv/bin/python logger.py --duration 300 --note "3V3" --output a1.csv
|
||
./.venv/bin/python logger.py --duration 300 --note "3V0 LDO" --output b1.csv
|
||
./.venv/bin/python compare.py --group note *.csv
|
||
```
|
||
|
||
---
|
||
|
||
## 60 Hz mains folds into the band
|
||
|
||
At ~35 Hz the largest spectral feature by far was a line near 9 Hz reaching
|
||
100–125 nT/√Hz against a 4–5 nT/√Hz broadband floor — **25× the noise floor**.
|
||
|
||
> **The 25× is specific to that rate and that site.** Measured at 285–299 Hz on
|
||
> 2026-08-23, with mains resolved in band rather than folded, the 60 Hz line
|
||
> reaches only **1.7–1.8×** the floor, and at cycle count 400 the dominant line
|
||
> is an fs/4 artefact rather than mains. The mechanism below is unchanged; the
|
||
> "dominant term" framing is not general.
|
||
|
||
It is 60 Hz aliasing, proven by making it move:
|
||
|
||
| capture | fs | observed peak | predicted 60 Hz alias |
|
||
|---|---|---|---|
|
||
| 3V3 | 34.7565 Hz | 9.5063 Hz | 9.5129 Hz |
|
||
| 3.0 V LDO | 34.5557 Hz | 9.0725 Hz | 9.1114 Hz |
|
||
| long run | 34.5783 Hz | 9.1764 Hz | 9.1566 Hz |
|
||
|
||
A real 9 Hz magnetic signal would sit still. This one moves with the sample
|
||
rate: `fs` changed by 0.20 Hz and the peak moved 0.43 Hz — the ×2 sensitivity of
|
||
a second-order fold, exactly as predicted.
|
||
|
||
The RM3100 has **no anti-alias filter** — cycle-count integration is a boxcar
|
||
with a poor stopband — so out-of-band interference folds in freely.
|
||
|
||
**Sampling faster resolves it instead.** At 150 Hz (Nyquist 69.3 Hz) mains lands
|
||
in band and the strongest line sits at **59.923 Hz**, observed directly. At
|
||
75 Hz it folds to 9.304 Hz against a 9.233 Hz prediction, with only 4 nT/√Hz
|
||
left at 60 Hz because that frequency is no longer sampled. This is why the
|
||
default configuration runs at ~282 Hz: at that rate mains *and* its second
|
||
harmonic are inside the band and can be notched afterwards, which no amount of
|
||
filtering can do to an alias.
|
||
|
||
---
|
||
|
||
## Overnight run: 13.2 h, 1.63 M samples
|
||
|
||
Cycle count 200, TMRC 0x96. **Acquisition integrity was perfect** — sample index
|
||
contiguous across all 1,635,055 rows, system clock monotonic with no NTP steps,
|
||
no malformed rows, no int24 saturation, no missed measurements (worst DRDY
|
||
bracket 11.0 ms of 27.03 ms, 41% of margin). Both problems in the data were
|
||
outside the logger.
|
||
|
||
**1. The first ~1.5 h and the last ~1 h are contaminated by handling.** |B|
|
||
reaches 198,268 nT — five times Earth's field — in bursts around t+0.44 h.
|
||
Hourly |B| sd tells the story:
|
||
|
||
| hours | \|B\| sd | usable |
|
||
|---|---|---|
|
||
| 0–1 | 3,750 nT | no — handling |
|
||
| 2–10 | **34–40 nT** | yes |
|
||
| 11–12 | 41–68 nT | marginal |
|
||
| 13 | 247 nT | no — activity resumed |
|
||
|
||
A 5-minute slice from the middle of the quiet window gave |B| = 42,132 nT with
|
||
sd 32.5 nT (771 ppm).
|
||
|
||
**2. A single rate does not describe a 13-hour capture.** One slope across the
|
||
whole run leaves a residual sd of 5.3 s and a 22.8 s span. Hour-by-hour fits
|
||
show the oscillator speeding up monotonically:
|
||
|
||
| hour | fitted period | vs run mean |
|
||
|---|---|---|
|
||
| 2 | 29.0187 ms | +1254 ppm |
|
||
| 6 | 28.9794 ms | −102 ppm |
|
||
| 12 | 28.9187 ms | −2195 ppm |
|
||
|
||
That is ~2,500 ppm of rate variation across the quiet hours — thermal, as
|
||
expected of an RC oscillator. So **long captures cannot be given a single
|
||
frequency axis**; spectra must be computed on windows short enough that the rate
|
||
is constant, via `Capture.restrict()`.
|
||
|
||
This is what `drift_limited` and the separate reporting of read jitter and fit
|
||
residual exist for. Over 5 minutes the residual is 3.7 ms; over 8.5 hours it is
|
||
2,356 ms — while read jitter stays 0.21 ms in both. Conflating the two would
|
||
have read as a 20,000× worse host.
|
||
|
||
**Drift-limited beyond a second.** A 769 s window of the same run: per-axis sd
|
||
rises to 214–284 nT while the broadband floor barely moves (5.1–5.7 nT/√Hz). The
|
||
extra spread is low-frequency drift, not broadband noise — the Allan deviation
|
||
bottoms at ~13 nT near τ = 0.12 s and climbs steadily after.
|
||
|
||
---
|
||
|
||
## Host-side rate ceilings
|
||
|
||
Two fixes roughly doubled the achievable rate.
|
||
|
||
### 1. Two USB round trips per register read → one
|
||
|
||
Reading a register as a pointer write plus a separate read — the form the manual
|
||
draws (§4.5.2, §5.8.4) — costs two round trips. The part accepts a **repeated
|
||
START**, so `ch347.write_read()` does it in one. Measured at 400 kHz:
|
||
|
||
| | separate | combined |
|
||
|---|---|---|
|
||
| `data_ready()` | 0.652 ms | **0.350 ms** |
|
||
| `read_raw()` | 0.838 ms | **0.548 ms** |
|
||
|
||
### 2. The GIL, not the OS scheduler
|
||
|
||
Even after that, `logger.py` stalled ~10 ms at 150 Hz while the *same sampling
|
||
loop with no writer thread* peaked at 3.1 ms (p99.9 = 2.9 ms, zero threshold
|
||
crossings in 2079 samples). The sampler releases the GIL inside each USB
|
||
transfer and must re-acquire it, waiting up to Python's default **5 ms** switch
|
||
interval while the writer holds it. Setting `sys.setswitchinterval(0.0005)` cut
|
||
the worst bracket from 9.96 ms to 5.65 ms and made 150 Hz pass.
|
||
|
||
Worth remembering generally: with a latency-sensitive loop and a helper thread,
|
||
the default GIL switch interval *is* the jitter floor.
|
||
|
||
### 3. Splitting the writer off the sampling thread
|
||
|
||
The same 60 s capture yielded 22,558 samples (376 Hz) with inline writing and
|
||
28,864 (481 Hz) with the writer split off — about **28%**.
|
||
|
||
### Measured ceilings (VM, cycle count 50, 400 kHz)
|
||
|
||
| TMRC | Nominal | Result | Worst DRDY bracket |
|
||
|---|---|---|---|
|
||
| 0x92 | 600 Hz | fail | 1.86 ms of 1.67 ms (112%) |
|
||
| 0x93 | 300 Hz | fail | 3.45 ms of 3.33 ms (104%) |
|
||
| 0x94 | 150 Hz | borderline | 5.65 / 5.95 / 6.53 / 7.19 ms of 6.67 ms |
|
||
| 0x95 | 75 Hz | clean, 69.2 Hz | 2.63–5.16 ms of 13.33 ms (20–39%) |
|
||
| 0x96 | 37 Hz | clean, 34.7 Hz | 3.30–8.56 ms of 27.03 ms (12–32%) |
|
||
|
||
> **These ceilings are host-specific and pessimistic** — VM, virtualised USB,
|
||
> shared cores, load average 2.76 at the time of the one 150 Hz failure. The
|
||
> *shape* carries over (the limit is host round-trip latency, not I²C bandwidth
|
||
> or the sensor), but the numbers must be re-measured on the machine that will
|
||
> run the capture. The "% of margin used" line `logger.py` prints after every
|
||
> run is the number to watch.
|
||
|
||
### The bus is never the constraint
|
||
|
||
Per sample the bus carries a DRDY poll plus a results read — 150 bit-times —
|
||
against a host cost 2–3× larger.
|
||
|
||
| | 400 kHz | 100 kHz |
|
||
|---|---|---|
|
||
| bus time per sample | 0.375 ms | 1.50 ms |
|
||
| as % of a 28.86 ms period (37 Hz) | **1.3%** | 5.2% |
|
||
| as % of a 7.21 ms period (150 Hz) | **5.2%** | 20.8% |
|
||
| measured host cost | 0.89–0.98 ms | — |
|
||
|
||
That puts the bus-limited ceiling near 1100 Hz, roughly double the sensor's own
|
||
562 Hz three-axis maximum at cycle count 50 — so absent host stalls, zero misses
|
||
is always achievable. Every miss observed has been a host stall.
|
||
|
||
### Bus speed, three runs each at cycle count 228
|
||
|
||
| bus | bus time | host cost | implied USB overhead |
|
||
|---|---|---|---|
|
||
| 100 kHz | 1.500 ms | 2.03–2.19 ms | ~0.63 ms |
|
||
| 400 kHz | 0.375 ms | 0.88–0.95 ms | ~0.55 ms |
|
||
| **750 kHz** | 0.200 ms | **0.78–0.80 ms** | ~0.59 ms |
|
||
|
||
Host cost is `bus time + ~0.6 ms` of fixed USB round-trip latency, so a faster
|
||
bus helps but cannot go below that floor. An earlier note claimed 400 kHz
|
||
benchmarked faster than 750; that rested on a single short run whose 4%
|
||
difference was inside the run-to-run spread and does not survive repetition.
|
||
400 kHz remains a sane fallback if 750 proves marginal on long wiring.
|
||
|
||
---
|
||
|
||
## Timing: how the miss detector was arrived at
|
||
|
||
**The read-to-read interval is not a usable threshold.** On the VM it reaches
|
||
37 ms against a 28.8 ms period — a 29% overshoot from host stalls alone — while
|
||
the DRDY bracket stays under 10 ms. The first implementation thresholded the
|
||
interval and aborted a perfectly healthy capture at sample 88.
|
||
|
||
**Period calibration is worth 100×.** Counting how many grid points passed
|
||
unseen inside a bracket needs the real period, and the TMRC table value is 6–9%
|
||
out on this unit:
|
||
|
||
| | period | error |
|
||
|---|---|---|
|
||
| nominal (TMRC table) | 27.03 ms | −6.4% |
|
||
| **calibrated (1 s)** | **28.8849 ms** | **0.068%** |
|
||
| whole-run fit (25 s) | 28.8653 ms | — |
|
||
|
||
**Counting needs the interval, detection needs the bracket.** Fit residual after
|
||
adopting the two-signal scheme:
|
||
|
||
| capture | lost | residual |
|
||
|---|---|---|
|
||
| 37 Hz clean | 0 | **0.019 periods** |
|
||
| 150 Hz clean | 0 | 0.082 periods |
|
||
| 150 Hz under CPU load | 0 | 0.444 periods |
|
||
| 300 Hz | 10 | 1.241 periods |
|
||
|
||
The load case is the one that shows the design paying off: the bracket reached
|
||
119% of threshold, so a stall genuinely occurred, but the interval showed only
|
||
one period had elapsed — nothing was lost. The older `int(bracket/period)`
|
||
estimator would have inserted a spurious placeholder and slipped the index from
|
||
there on. At 300 Hz the ambiguous counter fired 19 times.
|
||
|
||
**Run-to-run stability.** Fitted periods land 6.0–6.6% below nominal, and two
|
||
consecutive 60 s runs agreed to **0.017%**, so a single-slope drift correction
|
||
is sound over at least a minute.
|
||
|
||
---
|
||
|
||
## Rate sweep
|
||
|
||
`sweep.py` end to end. Every target from 1 to 128 Hz landed within 0.1%
|
||
(columns as of the run; the current tool also prints duty):
|
||
|
||
```
|
||
target measured err cc LSB/uT nT/count noise bus use
|
||
1H 1.00H +0.0% 29769 10929.7 0.091 1.21n 0.0%
|
||
8H 8.01H +0.1% 3718 1366.4 0.732 3.41n 0.3%
|
||
32H 32.00H -0.0% 927 341.8 2.926 6.83n 1.2%
|
||
128H 127.99H -0.0% 229 85.6 11.687 13.75n 4.8%
|
||
256H 249.23H -2.6% 113 43.0 23.265 19.57n 9.3% 2 lost
|
||
```
|
||
|
||
256 Hz is where the VM gives out; everything below it is exact. Noise past cycle
|
||
count ~400 is extrapolation — Table 3-1 ends there.
|
||
|
||
**Cycle count sets the ceiling, not TMRC.** Measured at 400 kHz:
|
||
|
||
| Cycle count | Measured | Table 3-1 predicts |
|
||
|---|---|---|
|
||
| 200 | 152 Hz | 147 Hz |
|
||
| 100 | 297 Hz | 283 Hz |
|
||
| 50 | 538 Hz | 533 Hz |
|
||
|
||
**The manual contradicts itself here and Table 3-1 is the correct one.** The
|
||
§5.2.1 note claims cycle count 200 allows a "~430 Hz" three-axis update rate;
|
||
Table 3-1 gives 440 Hz *single-axis* and says to divide by 3, i.e. ~147 Hz.
|
||
Measurement backs Table 3-1 at all three cycle counts.
|
||
|
||
**When the cycle count governs, TMRC is irrelevant** — cc=400 gave 73.85 Hz at
|
||
TMRC 0x92 and 73.86 Hz at 0x94. Varying only cc at TMRC 0x94:
|
||
|
||
| cc | measured | governed by | duty |
|
||
|---|---|---|---|
|
||
| 50 | 138.53 Hz | TMRC | 25% |
|
||
| 200 | 138.84 Hz | boundary | 99% |
|
||
| 400 | 73.83 Hz | cycle count | 100% |
|
||
| 800 | 37.09 Hz | cycle count | 100% |
|
||
|
||
**Idling costs sensitivity.** Reaching ~130 Hz two ways:
|
||
|
||
| | rate | cc | duty | ASD |
|
||
|---|---|---|---|---|
|
||
| TMRC-governed (cc=50, 0x94) | 138.5 Hz | 50 | **23%** | 3.42 nT/√Hz |
|
||
| cycle-count-governed (cc=228) | 128.5 Hz | 228 | **98%** | 2.39 nT/√Hz |
|
||
|
||
Same chip, same field, same per-sample physics — the difference is idle time,
|
||
and it is why the current model holds TMRC fast and uses cycle count alone.
|
||
|
||
**Equal duty means equal noise.** Two configurations at ~100% duty and very
|
||
different rates:
|
||
|
||
```
|
||
cc200 @150Hz 138.77 Hz LSB 13.35 nT ASD 2.98 nT/rtHz (66% bracket margin)
|
||
cc800 @37Hz 34.72 Hz LSB 3.39 nT ASD 3.26 nT/rtHz (10% bracket margin)
|
||
```
|
||
|
||
Near-identical spectral density, as the equal-duty argument predicts — so the
|
||
choice between them is bandwidth versus resolution, not noise.
|
||
|
||
**Low cycle counts are dominated, not fast.** cc=50 reached the same 138.8 Hz as
|
||
cc=200 on the VM — both host-limited, not sensor-limited — while idling 75% of
|
||
the time and quantising 3.8× more coarsely. Its extra sensor speed is capability
|
||
the host cannot collect.
|
||
|
||
---
|
||
|
||
## 60 s capture at maximum rate (office rig, historical)
|
||
|
||
28,864 samples, 481 Hz, cycle count 50, 400 kHz. The sensor was nudged by hand
|
||
at t ≈ 41 s, so statistics are split around that:
|
||
|
||
| Axis | sd, 0–40 s | sd, 47–60 s | step across the event |
|
||
|---|---|---|---|
|
||
| X | 84 nT | 85 nT | +280 nT |
|
||
| Y | 388 nT | 376 nT | +217 nT |
|
||
| Z | 187 nT | 198 nT | +232 nT |
|
||
| \|B\| | 369 nT | 358 nT | +313 nT |
|
||
|
||
- **The step was the sensor being physically moved**, confirmed at the time, not
|
||
an electrical artefact. A norm shift does not by itself imply an external
|
||
source changed: |B| is preserved under rotation in a uniform field, but a
|
||
translation through a gradient samples a different local field. Near a PC the
|
||
gradients are steep (§4.2.2: field falls off as 1/distance³), so a few
|
||
centimetres is ample for the +313 nT seen here. Treat a |B| change as "not a
|
||
pure rotation", nothing more.
|
||
- **Noise is strongly axis-dependent** — Y is 4.6× X (388 vs 84 nT) and stable
|
||
across the event, so it is not a consequence of the disturbance. The coils are
|
||
nominally identical, so this points at orientation relative to a local noise
|
||
source rather than a sensor fault. X at 84 nT is within ~3× of the 30 nT
|
||
Table 3-1 quotes for cycle count 50; Y is ~13×.
|
||
- **Timing was jittery**: intervals averaged 2.08 ms (481 Hz) with sd 1.09 ms
|
||
and a 19.6 ms worst case. This capture predates the chip-grid time base, so it
|
||
is unsuitable for spectral work without resampling. A capture taken today
|
||
carries an exact grid regardless of read jitter.
|
||
|
||
---
|
||
|
||
## Supply ripple: what the manual does and does not say
|
||
|
||
Table 3-5 gives a flat 50 mV<sub>PP</sub> ripple limit on AVDD and DVDD with
|
||
**no frequency qualifier**, and no transfer function from ripple to field error
|
||
— no µT-per-mV, no PSRR, no ripple-vs-noise curve.
|
||
|
||
Slow drift should matter less than fast ripple, though this is inference from
|
||
the described architecture rather than an explicit claim. §4.1 describes the
|
||
output as "the difference in the time to complete the measurement for each
|
||
bias" — a differential measurement across forward and reverse coil bias — and §2
|
||
claims measurements are "stable over temperature and inherently free from offset
|
||
drift". Anything common to both half-measurements largely cancels, so supply
|
||
variation slower than one measurement cycle should be rejected far better than
|
||
noise near the ~180 kHz LR oscillation.
|
||
|
||
Unverified on this rig: whether the breakout carries local decoupling, and what
|
||
the CH347's 3V3 rail ripple actually measures against the 50 mV limit.
|
||
|
||
---
|
||
|
||
## Interleaved supply A/B, 2026-08-23 — the scale factor, measured
|
||
|
||
Four captures, LDO / 3V3 / LDO / 3V3 at cycle counts 100, 100, 400, 400, ~6
|
||
minutes each, rails measured at the board: **3.006 V** and **3.353 V**. Full
|
||
write-up, figures and raw output in
|
||
[Noise_Floor_Testing/NOISE_FLOOR.md](Noise_Floor_Testing/NOISE_FLOOR.md); this is
|
||
the summary and the things that changed the tooling.
|
||
|
||
**The oscillator moves with the supply.** +4.94% from 3.006 V to 3.353 V,
|
||
measured independently at two cycle counts and agreeing to **0.04%** — V^+0.44.
|
||
This is the cleanest number in the session because, unlike |B|, it cannot be
|
||
contaminated by the sensor moving.
|
||
|
||
**|B| moves the other way, by −7.1%** (−3,245 nT), consistent across both cycle
|
||
counts to 0.74%. Exactly ratiometric with the rail would be V^−1; measured is
|
||
V^−0.65, and correcting by the rail overshoots by +3.5 to +4.3% against a
|
||
run-to-run reproducibility of 2.3–3.1%. Correcting by the **measured sample
|
||
rate** instead leaves −2.6 to −1.9%, inside that floor — and needs nothing
|
||
external, since the logger already calibrates the period every run. Applying both
|
||
corrections is clearly wrong (+8.7%): the rate change *is* the supply change seen
|
||
through the oscillator, so stacking them counts it twice.
|
||
|
||
**The sensor still moved**, 2.8–23° of rotation between pairs. |B| survives a
|
||
rotation, so this does not invalidate the above, but translation through a
|
||
gradient would, and only a clamped re-run can bound that.
|
||
|
||
**Cycle count 400 carries an artefact that cycle count 100 does not.** Tones at
|
||
exactly fs/4 and fs/2 of each capture's *own* rate — the two cc=400 runs differ
|
||
by 4.9% in rate and each peaks at its own fs/4, so it is locked to the sampling
|
||
rather than to any frequency. On one axis it reaches 2.43 nT at 25.7σ. Mechanism
|
||
unresolved; it is not a host-side period, since 4 samples is 52.1 ms at one rate
|
||
and 54.7 ms at the other.
|
||
|
||
It also **grows with the supply**: comparing the rotation-invariant vector
|
||
magnitude of the tone, 3V3 is **1.217 ± 0.086×** the LDO, agreeing between the
|
||
fs/4 and fs/2 harmonics. That excludes a fixed digital pattern (which would be
|
||
1.000, +2.5σ) and external pickup (0.935, +3.3σ), and sits between V and V²,
|
||
which two rail voltages cannot separate.
|
||
|
||
**Every capture drifts through its own thermal warm-up** — 186 to 1241 ppm,
|
||
monotonically downward, measured by re-fitting the rate on sub-windows
|
||
(`calibrate.rate_stability`). That is the error bar under every timing figure
|
||
here, and the reason the collection-interval mechanism is favoured rather than
|
||
established. Let the rig settle before a run that matters.
|
||
|
||
**That drift is the sample rate, not the field**, and the distinction is worth
|
||
keeping because the natural explanations for "drift" on a magnetometer are
|
||
geomagnetic. `dt_true` is fitted from the host clock against sample index, so
|
||
nothing magnetic can reach it, and the pattern confirms it: every run starts high
|
||
and ends low, then the *next* run starts high again. A diurnal trend would run
|
||
continuously across the session; this resets at each `logger.py` invocation.
|
||
|
||
The **field** drift within a run is separate and probably is diurnal: |B| moves
|
||
−1.4 to −1.8 nT/min in three of the four runs, in a consistent direction, which
|
||
is the right order for Sq variation. It cannot be the 2.48% residual — that is
|
||
1,166 nT against ~40 nT of diurnal across the whole 26-minute session.
|
||
|
||
**The sensor moved during a run, not only between them.** LDO/cc400 rotates
|
||
**0.49°** across its own run, ten times the quietest, and that is the same run
|
||
carrying 485 nT of Z drift at nearly constant |B| — which is rotation, not field.
|
||
The rig was not restrained and had to be handled to move the 3 V jumper between
|
||
runs, so this is expected rather than surprising; it is why the residual is
|
||
attributed to movement.
|
||
|
||
**Filtering and decimating a fast capture matches sampling slowly**, which the
|
||
README had been asserting without evidence. Decimating a cc=100 capture by 4
|
||
changes its own broadband floor by **+0.3 to +0.5%** — a comparison with no
|
||
second run in it, so no gain or position difference to confound it. It is also
|
||
strictly better: the decimated path carries none of the fs/4 artefact, and a
|
||
proper anti-alias filter removes 60 Hz before it can fold, which sampling slowly
|
||
cannot.
|
||
|
||
**The dither question is settled at cycle count 100.** 0.65–0.81 LSB per sample,
|
||
and averaging 1,024 samples reaches 0.035–0.050 LSB — within 1.5–2.1× of ideal.
|
||
A comb in the residual histogram is not evidence against this: the residual of an
|
||
integer-valued signal is a comb at one LSB by construction, and its sharpness
|
||
tracks only how far that axis drifted.
|
||
|
||
**What this changed in the tooling.** Four estimator bugs surfaced, all of which
|
||
would have biased a supply comparison:
|
||
|
||
- `compare.py` scored each capture over its own band, so a 299 Hz run was judged
|
||
over 3–135 Hz and a 73 Hz one over 3–33. One common band now, chosen to sit
|
||
inside the slowest path compared *including decimated ones*.
|
||
- Welch segments were a fixed sample count, so captures at different rates got
|
||
different numbers of segments; the median of a Welch estimate is biased low by
|
||
an amount that depends on that count. A fixed 20 s segment duration now.
|
||
- Broadband noise was reported only in absolute nT/√Hz, which credits a low gain
|
||
as a low noise floor. Reported fractionally too, and the figures are fractional.
|
||
- `characterize.py` autoscaled every panel, so a quiet capture and a noisy one
|
||
drew identical-looking plots. Fixed axes now.
|
||
|
||
---
|
||
|
||
## Open questions
|
||
|
||
- Re-run the LDO comparison with the sensor **clamped**, and in an order that is
|
||
not degenerate. The 2026-08-23 session used L,3,L,3 against cycle counts
|
||
100,100,400,400, which makes `t = supply + 2·cc` exactly — supply, cycle count
|
||
and a linear drift cannot all three be fitted. L,3,3,L breaks it.
|
||
- Identify the **fs/4 artefact** at cycle count 400. A cc=200 run at both
|
||
supplies would say whether it scales with cycle count or appears at a threshold.
|
||
- Fix `rm3100.AXIS_OVERHEAD_S`: 68.7 µs against 38–41 µs measured on this unit,
|
||
which puts the cc100:cc400 rate ratio 1.9% out.
|
||
- Compare |B| against IGRF/WMM for the capture site (39.661262° N,
|
||
82.604173° W, 255 m). Not a calibration standard — indoor hard and soft iron
|
||
are unknown and nothing here is corrected — but it is the only absolute
|
||
reference available, and it would say which rail reads closer to right.
|
||
- Deal with 60 Hz coupling at source — standoff distance, then a repeat
|
||
characterisation — rather than only sampling fast enough to see it.
|
||
- Reliability over extended runs on bare metal, where the VM ceilings above do
|
||
not apply.
|