View this page on MeshCore Docs.
RAK3401 radio2 SF5/BW500/preamble384, 23 October 2026
Status: COMPLETE, VALID MEASUREMENT, DELIVERY FAIL. Radio2 received 100/100 packets at SF5/BW500/preamble384, but the same scanning RAK missed 3/100 primary packets at SF7/BW62.5/preamble32. Both fixed receivers received all their applicable packets. No firmware was changed or flashed. The sanitized receipt binds the counters, settings, independent audit and debugger capture hashes.
Physical setup and scope
| Role | Installed firmware source | Frequency MHz | BW kHz | SF | CR | Preamble |
|---|---|---|---|---|---|---|
| RAK3401 Full unified Repeater, primary scanner | adb11e7b |
917.000 | 62.5 | 7 | 5 | 32 |
| Same RAK3401, secondary scanner, RX mode | adb11e7b |
918.000 | 500 | 5 | 5 | 384 |
| RAK WisMesh Tag Companion, sender | 08650f64 |
Both tuples, one at a time | Both | Both | 5 | Both |
| T1000-E Companion, fixed primary witness | 08650f64 |
917.000 | 62.5 | 7 | 5 | 32 |
| Heltec T096 Companion, fixed secondary witness | 4773ac42 |
918.000 | 500 | 5 | 5 | 384 |
The sender used 2 dBm and sent 200 fresh 92-byte RAW_CUSTOM payloads, each 94 bytes on air including its direct, zero-hop route header. Ten seeded pairs of ten-packet batches produced 100 packets per profile. Profile order within each pair was shuffled. These are successive transmissions from one sender, not concurrent traffic on two frequencies. The requested minimum gap after physical TX_DONE was randomly 0.5-0.9 seconds; retunes increased actual gaps to at most 3.416 seconds. The RF window lasted 201.569 seconds. Only 917.000 and 918.000 MHz were commanded for the measured packet set.
Every transmission required one acceptance and exactly one advancing direct physical TX counter. There were no retries, replacement packets or floods. The scanner and both witnesses observed the same physical packet set. RAK USB logging matched full raw packet bytes; Companion witnesses matched both custom-payload pushes and independent raw-frame pushes. These two Companion observations count as one delivery. No channel or contact changes were needed. This test does not qualify message decryption or forwarding.
Results
| Receiver | Primary received / 100 | Secondary received / 100 | Result |
|---|---|---|---|
| RAK3401 scanner | 97 | 100 | FAIL primary; PASS secondary |
| T1000-E fixed witness | 100 | Not applicable | PASS |
| T096 fixed witness | Not applicable | 100 | PASS |
The missing primary packets were P022, P044 and P070, corresponding to global zero-based ordinals 51, 93 and 139. Every one reached the primary witness. There were no duplicates, opposite-profile witness deliveries, log drops, framing losses or collector errors. All three receivers transmitted zero packets during the RF measurement. All four radios accumulated zero new receive/CRC errors. Thus the three scanner misses are supported by independent same-packet witness evidence; their cause is not established by correlation.
RAK, Tag and T096 already had historical core flag 0x08 before this test;
T1000-E had zero. Those values were unchanged throughout the completed run.
No error flags were cleared. RAK soft/hard radio watchdog counters remained
0/0, queues were empty and uptimes remained continuous. This is not a claim
that the radios had zero historical errors.
Switch timing and CPU observation
For the current pair, the firmware reported a 1,176 us guarded switch budget. This is the 1,069 us sampled maximum plus a rounded-up 10% margin. nRF52 dual-profile timing uses RTC2 at 32,768 Hz, approximately 30.52 us per tick. This measures the guarded RX-to-RX path, including activity checks, standby/FS transition, frequency and changed modem/preamble parameters, and restarting receive. It is not a bare PLL retune measurement or an average.
The derived visits were 9421,20995 us and the recommended preambles were
32,200. The requested radio2 preamble384 exceeds that estimate. Its 100/100
delivery does not explain the three primary misses despite primary meeting
the displayed recommendation. The separately displayed lifetime maximum
3906us is not reset with the pair's timing self-test and cannot be assigned
to a particular lost packet from these counters.
The attached debugger completed a 300.008-second nonhalting memory-AP capture with 27,118 samples. Before/after hardware identity matched. No debug enable, halt, stepping, interrupt masking, lockup or reset was observed; capture integrity passed. SWD did not set breakpoints, stop the CPU or flash anything. It sampled CPU status, not per-hop instruction traces.
Only eight samples observed sleep, a weighted sampled fraction of 0.0307%.
This is not a CPU sleep qualification: Full Repeater deliberately inhibits
CPU power saving during an active USB data session, which was needed here
for exact RF logging. A saved powersaving on preference does not bypass
that gate. The existing nRF52 scanner idle path requires more than 48 RTC2
ticks, approximately 1.465 ms, remaining before it admits a task delay; the
roughly 2 ms practical idle-budget consideration is separate from retune
time. An unplugged-USB, SWD-only sleep experiment would be a separate test.
Source inspection found concrete speed candidates, without changing this baseline: RAK currently uses the default 2 MHz byte-at-a-time SPI path, although a buffered nRF52 HAL exists; the retune path also queries the modem during setup and repeats the IQ workaround. Its custom airtime override already uses cached parameters and does not issue a second modem query. Their individual costs were not measured by this capture. Faster switching and any receiver repair need fresh source-bound RF validation before a qualification claim.
Controller correction and restoration
An earlier, separate attempt stopped after 50 transmissions because its fixed 2.1-second wait ended while the sender still reported pending settings. Those packets are excluded from every final count. Its settings and gateway were restored. The corrected private controller polls for the exact active tuple and preamble before any next transmission, retains partial evidence on abort, and waits for live radio2 shutdown during cleanup. The firmware was unchanged. The completed run used fresh nonces and a new receipt.
All four nodes passed final settings preservation. Temporary radio leases were removed, RAK live radio2 status returned to off, original TX power and USB logging were restored, and the gateway service reacquired its radio with its configuration unchanged. The independent offline audit reproduced the three missing primary packets and reported no measurement confounds.
See the fast-switch follow-up for buffered SPI measurements, the 16 MHz readback failure and subsequent qualification results.