Troubleshooting
SDR timing, clock, and gain problems
Fix the SDR-layer problems that produce inconclusive verdicts: sample-rate mismatch, clock drift, gain saturation, USB throughput, and calibration.
7 min read
SDR problems masquerade as protocol problems. Learn the four signatures and you stop chasing NAS bugs that do not exist.
| Signature | Meaning | Fix |
|---|---|---|
| 'U' / 'O' spam in logs | Underrun / overflow — host cannot keep up | Lower sample rate, use a hosted lane build |
| 'L' / 'D' characters | Late packets / dropped bursts | Timing problem; re-check master_clock_rate |
| Corrupt SIB decode at high RSRP | Receiver saturation | Reduce rf.rx_gain by 10-15 dB |
| Slow drift then loss of sync | Clock offset (no GPSDO) | Request a GPSDO-equipped lane |
Correct clock rates
texttext
B210, 20 MHz NR, 30 kHz SCS : master_clock_rate=23.04e6 B210, 10 MHz LTE : master_clock_rate=11.52e6 LimeSDR USB, 20 MHz NR : sample_rate=30.72e6, oversample=2
Lane calibration
bashbash
aeon lanes describe --id eu-west-1/lime-03 # sdr: LimeSDR-USB fw: 22.10 gpsdo: yes calibrated: 2026-07-13T22:04Z aeon lanes calibrate --id eu-west-1/lime-03 # ~90 s, free
noteLanes auto-calibrate every 24 h and after any firmware change. Every report records the calibration timestamp, which is what makes a cloud verdict defensible.
Run this against a real SDR lane
The tester is a service, not a box. Push a build, reserve a lane, get a verdict.