Parallel Asynchronous-Data DSSS Receivers — the measurement record¶

The dated record behind the design page: what each number there was measured by, with the run. Section numbers are shared, so a §3.1 cited on the design page, in an issue or in a code comment is the same entry here. The tables come from two runs of shipped tools, at one commit: the lock validator, native/validation/async_dsss_receiver_lock.c, and the C benches of the three objects. A third run, of the same validator, draws §3.2's figures, and is held to the first instead: each of its stories must match its sweep trial's carrier, arrival and symbol-lock time. Every table below, and every number the design page quotes from them, is rendered from their data, committed beside this page in async-dsss-parallel-measurements/ by its record.py, whose --check (in make docs-invariants) fails when either page differs from the data.

The operating point throughout: Gold-1023 (CCSDS #365) at 3.069 Mcps, two samples a chip, so one code epoch is 2,046 samples, 333.3 µs, and 1/T_E is 3 kHz; asynchronous BPSK at 2,700 sym/s. The receiver is the searching flavor at the binding's defaults, its own search over ±1/T_E, its lock detector the shipped lockdet at the header's settings, read as it reports: locked or not. The emitter is the shipped continuous-DSSS synth carrying the validator's own data bits, with no data-free window, and the validator checks the synth is sending them: every lock measurement is taken where the symbols transition, and each row's "data flips" is the fraction of symbol boundaries that flip around its event, counted from the bits. The noise is the shipped awgn, and an arrival or a dropout cuts the signal only. A fraction carries its 95% Wilson interval.

3.1 Symbol lock through a dropout¶

The validator's dropout trials. Each draws its carrier over ±1/T_E, and is fed until the receiver tracks with symbol lock up for 200 epochs in a row, then up to 10 ms more, then cut at a random sample of the next epoch. A draw that has not held lock that long within 4 s, or whose lock is down at the cut, is excluded and counted (§5.1 says why a draw can miss); trials are drawn until 20 settle, so the intervals' fixed-n assumption is approximate. The receiver's state at the cut is saved and every case resumes from it on the same noise, so they differ only in the dropout: the validator checks that the restore is exact, every case's lock reading the for-good case's until its signal returns. Symbol lock is read after every epoch, so every time is to 0.33 ms. The receiver stays tracking throughout (lost_confirm_s = 0): a lock that falls comes back by itself.

The hold, by dropout length. Each trial is run through a dropout of every length from one epoch to two past its own drop, each from the saved state: held means symbol lock stayed up through the dropout and 60 ms after it.

The hold is not one number per draw. In many trials a longer dropout held after a shorter one fell (the last column): the lock average, an exponential average over 30 symbols, sinks under the detector's drop level in the dropout and climbs back too late after it, and where it lands depends on the noise of those few milliseconds. So the hold is reported as a fraction per length, never as an edge.

3.2 A receiver through a signal's life¶

The validator's lifecycle stories (--telemetry DIR): two of §5.1's arrival trials, each run on past its own end as one receiver's whole life. Its first second is the trial sample for sample, and the table holds each story to its trial. Then the signal is cut for 10, 20 and 50 ms at 1.0, 1.3 and 1.6 s, every cut mid-data, and leaves for good at 2.0 s; the run ends at 2.4 s. Each figure is the receiver's own telemetry from that run, drawn by scripts/plot_capture.py. Grey is where the signal was off, read from the stimulus the validator records beside the receiver's probes (stim.on), not drawn from the schedule above. stim.on is emitted every block from the first, so the shared time axis starts at the first block; the receiver's own traces start where its live chain starts, not at the arrival (none of them reports before then; the search's rx.acq.* are captured, not drawn).

At 10 dB symbol lock rides out the 10 and 20 ms fades, falls in the 50 ms one and comes back after it, and falls for good at the departure, as do the carrier and code flags; the code flag falls in every fade. At 5 dB symbol lock rides out only the 10 ms fade. The demodulator's timing flag (demod.sync.locked) falls in none of them: it stays up through every fade and long after the signal has gone (#2409).

The record's run at 9c386aad5 had a third story, lifecycle-5db-no-lock: seed 5 at 5 dB, whose refine seed was 444 Hz off, further than the carrier loop pulls in, so the carrier loop never declared and symbol lock never came, while the code loop tracked and the timing flag came up and stayed up. Its figure is in that commit. Since the Dll's output is divided by a slowly tracked level (#2495), that draw's seed lands 106 Hz off and it locks in 296 ms, and no 5 dB arrival trial of this run misses, so this run has no story that never locks.

5.1 Arrival to tracking, and to symbol lock¶

The validator's arrival trials: noise alone for a uniform 0 to 20 ms, so the signal starts at any sample of an epoch and any code phase against the feed, then the signal at a carrier uniform over ±1/T_E, for 2 s after it arrives. Times are from the arrival sample, to the first epoch the receiver reads tracking and to the first after which symbol lock is up.

What decides the lock: the refine stage's carrier. The same trials, by how far the refine stage's carrier estimate, read when the receiver first tracks (get_doppler_hz(), frozen from then), lands from the truth: the residual the carrier loop must pull in. That loop's acquisition bound is bn / m, 60 Hz at this front end, and costas_pullin.c measures it acquiring every draw inside the bound, still reliably to twice it, and dead by four times (async_dsss_receiver_core.h); doppler#982 found the refine handing over outside it. The whole receiver is more forgiving than the loop alone: lock time grows with the seed error, and the 200–300 Hz row still locks, past four times the bound and slowly. The seed-edge block below gives the largest locked error and counts the draws at 250 Hz or more, of which this run has none. The error is read when tracking starts, which need not be the residual the loop finally pulls in; rx.car.nco (#2412) now shows what the loop pulls in, and read as a residual it is not yet measured (doppler#2409).

6. What a receiver costs¶

The C benches, jm_bench.h's wall clock over its rounds (min, mean and max per row), each round a whole dwell (the engine) or a block of samples (the receiver). The engine's work per 2,046-sample epoch depends on its tile count and its coherent depth, not on the chip rate, so a row timed at another chip rate is this design's state by its tiles: one tile is acq::native (3.069 Mcps, no Doppler search), ±1/T_E is the 3-tile op5M_U5k, and its slow-time search is that row at D = 154, deeper than the 94 this design's 500 Hz/s rate allows, so it bounds it. The engine rows are sized at the bench's own C/N0, 37.31 dB-Hz (bench_acq_core.c), which sets their dwell, not their cost per sample. The tracking row is the receiver bench's held cell receiver at 1,023 chips, which that bench reads as the searching flavor's steady state. The real-time factor is the mean per sample times 6.138 MSa/s; the four-thread row is wall time, the CPUs it spends are more. The machine's load either side of the bench is in the stamp.

7. The pool as built¶

The same run's pool bench (twelve slots, one emitter tracked, the searcher's 31-epoch window) and the engine at the pool's design point of async-dsss-receiver.md §6.1, ±50 kHz, at the ends of its chip-rate range: 21 tiles at 5 Mcps with D = 154, 53 at 2 Mcps with D = 61. Each is at the rate it was timed at; a threaded row is wall time.

The pool's mean push carries its searcher's dwells: its fastest push is the receivers' work alone, and its slowest is a dwell (the min and max in the row). The bench's rounds are not a whole number of dwells, so the mean is approximate to within one dwell's share. So a mean near 1x real time does not say the pool keeps up: between runs the mean moves by that share while the fastest push, the receivers' own work, holds still (a same-host, interleaved comparison across two earlier runs of this record moved it under 1%, #2484). Read the fastest push for the receivers' cost and the slowest for a dwell's.