twisla/roro9stack
Public Access
1
0
Fork 0
Code Issues 48 Pull Requests 1 Actions Packages Releases 14 Activity

LoRa: the Cardputer's own noise costs about 15 dB of receive sensitivity #20

New Issue
Open
opened 2026-10-05 19:40:12 +00:00 by twisla · 2 comments
twisla commented 2026-10-05 19:40:12 +00:00
Owner
Copy Link
Copy Source

What happens

With nothing transmitting, the LoRa radio's noise floor is about 15 dB above what the chip hears on its own, and the source is the Cardputer itself. That costs range: at SF11 the weakest packet it can decode on LongFast is near -114 dBm, against about -130 dBm for a quiet receiver. In M3's listening hour (outside, on battery) it heard no packet and no header from the six Meshtastic nodes known within 30 km.

Measured (M3, 2026-10-05, docs/milestones/M3.md)

Noise floor at 125 kHz
Antenna switched off (expander P0 low): the chip alone about -115 dBm (-111.9 at 250 kHz)
Desk, USB, Wi-Fi on -100 to -102 dBm
Outside, battery, Wi-Fi off -99 to -100 dBm
Outside, battery, Wi-Fi on -96 to -99 dBm
  • The floor is flat across 863-870 MHz, with narrow peaks at the same frequencies on every Sweep pass: 863.2, 863.6, 864.4, 864.8, 865.9, 866.3, 867.8, 869.0 and 869.4 MHz, at -88 to -91 dBm. Several are 400 kHz apart. 869.4 MHz is the lower edge of LongFast's channel (869.4 to 869.65 MHz).
  • It follows the device outside and onto its battery, so it isn't the desk, the PC or the USB cable.
  • Wi-Fi accounts for 2 or 3 dB. The screen and the GNSS receiver make no measurable difference (each was switched off remotely).
  • 864.0 MHz is the 27th harmonic of the radio's own 32 MHz TCXO. A suspect, not a finding.

What's known

  • lora sweep on / lora sweep dump and the Scanner's Sweep view measure all of this; lora probe reports the floor at the Sniffer's frequency.
  • Not tried yet: the SD card idle or removed, the CPU at a lower frequency, the display's SPI clock, the backlight PWM, the speaker amplifier, the DC-DC converters, an antenna on a short coax away from the case, a different antenna.
  • Stock Meshtastic on the same hardware would make a useful comparison (does it hear the nodes this firmware doesn't?), as would a second node at a known distance.
  • The instantaneous RSSI reading itself hasn't been checked against a calibrated source.

Questions

  1. Which part of the Cardputer makes the noise? Switch things off one at a time and Sweep.
  2. Are the 400 kHz peaks a switching regulator, and can its frequency or load be changed?
  3. Does moving the antenna away (a short RP-SMA cable) recover most of it? That would be the cheap fix.
  4. Can the firmware avoid the worst of it: quieter while receiving (pausing SD writes or screen refreshes), or settings that sit between the peaks?
  5. Is this the same on other Cardputer ADV units with the Cap, or this one?

Related

docs/milestones/M3.md (Measured), src/services/radio_service.cpp (Sweep, probe), the blog post "The loudest thing it hears is itself".

## What happens With nothing transmitting, the LoRa radio's noise floor is about 15 dB above what the chip hears on its own, and the source is the Cardputer itself. That costs range: at SF11 the weakest packet it can decode on LongFast is near -114 dBm, against about -130 dBm for a quiet receiver. In M3's listening hour (outside, on battery) it heard no packet and no header from the six Meshtastic nodes known within 30 km. ## Measured (M3, 2026-10-05, `docs/milestones/M3.md`) | | Noise floor at 125 kHz | |---|---| | Antenna switched off (expander P0 low): the chip alone | about -115 dBm (-111.9 at 250 kHz) | | Desk, USB, Wi-Fi on | -100 to -102 dBm | | Outside, battery, Wi-Fi off | -99 to -100 dBm | | Outside, battery, Wi-Fi on | -96 to -99 dBm | - The floor is flat across 863-870 MHz, with narrow peaks at the same frequencies on every Sweep pass: 863.2, 863.6, 864.4, 864.8, 865.9, 866.3, 867.8, 869.0 and 869.4 MHz, at -88 to -91 dBm. Several are 400 kHz apart. 869.4 MHz is the lower edge of LongFast's channel (869.4 to 869.65 MHz). - It follows the device outside and onto its battery, so it isn't the desk, the PC or the USB cable. - Wi-Fi accounts for 2 or 3 dB. The screen and the GNSS receiver make no measurable difference (each was switched off remotely). - 864.0 MHz is the 27th harmonic of the radio's own 32 MHz TCXO. A suspect, not a finding. ## What's known - `lora sweep on` / `lora sweep dump` and the Scanner's Sweep view measure all of this; `lora probe` reports the floor at the Sniffer's frequency. - Not tried yet: the SD card idle or removed, the CPU at a lower frequency, the display's SPI clock, the backlight PWM, the speaker amplifier, the DC-DC converters, an antenna on a short coax away from the case, a different antenna. - Stock Meshtastic on the same hardware would make a useful comparison (does it hear the nodes this firmware doesn't?), as would a second node at a known distance. - The instantaneous RSSI reading itself hasn't been checked against a calibrated source. ## Questions 1. Which part of the Cardputer makes the noise? Switch things off one at a time and Sweep. 2. Are the 400 kHz peaks a switching regulator, and can its frequency or load be changed? 3. Does moving the antenna away (a short RP-SMA cable) recover most of it? That would be the cheap fix. 4. Can the firmware avoid the worst of it: quieter while receiving (pausing SD writes or screen refreshes), or settings that sit between the peaks? 5. Is this the same on other Cardputer ADV units with the Cap, or this one? ## Related `docs/milestones/M3.md` (Measured), `src/services/radio_service.cpp` (Sweep, probe), the blog post "The loudest thing it hears is itself".
twisla added the
kind
bug
area/lora
status
needs-design
priority
high
 labels 2026-10-05 19:40:12 +00:00
twisla added this to the M4 Mesh receive milestone 2026-10-05 20:07:25 +00:00
twisla commented 2026-10-06 01:45:21 +00:00
Author
Owner
Copy Link
Copy Source

The main source is found: the GNSS receiver on the Cap. On the s1 branch (70fb37e), not merged yet.

Debug Builds have a self-test, lora noise test: it changes one thing at a time, Sweeps 863-870 MHz for eight passes (568 readings), takes the median as the floor, and puts the thing back. It runs on the device by itself, since one condition pauses Wi-Fi. Results, dBm at 125 kHz, indoors on USB power:

Condition Floor
Antenna switched off (the chip alone) -117
Antenna on, GNSS in standby -106
Antenna on, GNSS running (as shipped) -98
  • GNSS running costs 8 dB. Three runs, the same each time. On LongFast the Sniffer's reading goes from about -93.5 to -101.5 dBm.
  • Not its serial line: one NMEA sentence a second instead of twenty (PCAS03), receiver still tracking: no change. It's the receiver's own electronics.
  • Within 1 dB, so not sources: the main loop spinning or resting (#40), the CPU at 240, 160 or 80 MHz, Wi-Fi on or off, the screen on or off, the SX1262's regulator as DC-DC or LDO, receive gain boosted or not. Checked with GNSS running and again with it in standby.

Answers to the questions above

  1. Which part: the GNSS receiver, for 8 of the 19 dB.
  2. The 400 kHz peaks seen outdoors in M3: none stood 10 dB above the floor in any of these runs (indoors, another day), so the test says nothing about them.
  3. An antenna on a cable: not tried, needs hands.
  4. Can the firmware avoid it: yes for GNSS. Settings > Pause GNSS for LoRa, off by default: the receiver waits in standby while the radio listens or sweeps, never during a Track, and has a Fix again about 7 s after the radio sleeps.
  5. Other units: unknown.

Still open

  • 11 dB remain between the antenna with GNSS quiet (-106) and the chip alone (-117). It comes through the antenna and nothing switchable changes it. Telling the surroundings from the Cardputer's own always-on parts needs another place, or the antenna on a short cable away from the case.
  • The default. The setting is off because GNSS on by default was decided in M2 (Q58). From M4 the radio listens all the time, so "pause while listening" would mean GNSS mostly off: a question for M4's design round (#23).
  • Whether a quieter GNSS mode exists (fewer constellations, a slower update rate) wasn't tried: the receiver's default settings can only be restored for certain by a power cycle, and nobody was awake to do one.
**The main source is found: the GNSS receiver on the Cap.** On the `s1` branch (`70fb37e`), not merged yet. Debug Builds have a self-test, `lora noise test`: it changes one thing at a time, Sweeps 863-870 MHz for eight passes (568 readings), takes the median as the floor, and puts the thing back. It runs on the device by itself, since one condition pauses Wi-Fi. Results, dBm at 125 kHz, indoors on USB power: | Condition | Floor | |---|---| | Antenna switched off (the chip alone) | -117 | | Antenna on, GNSS in standby | -106 | | Antenna on, GNSS running (as shipped) | -98 | - **GNSS running costs 8 dB.** Three runs, the same each time. On LongFast the Sniffer's reading goes from about -93.5 to -101.5 dBm. - **Not its serial line:** one NMEA sentence a second instead of twenty (`PCAS03`), receiver still tracking: no change. It's the receiver's own electronics. - **Within 1 dB, so not sources:** the main loop spinning or resting (#40), the CPU at 240, 160 or 80 MHz, Wi-Fi on or off, the screen on or off, the SX1262's regulator as DC-DC or LDO, receive gain boosted or not. Checked with GNSS running and again with it in standby. **Answers to the questions above** 1. Which part: the GNSS receiver, for 8 of the 19 dB. 2. The 400 kHz peaks seen outdoors in M3: none stood 10 dB above the floor in any of these runs (indoors, another day), so the test says nothing about them. 3. An antenna on a cable: not tried, needs hands. 4. Can the firmware avoid it: yes for GNSS. **Settings > Pause GNSS for LoRa**, off by default: the receiver waits in standby while the radio listens or sweeps, never during a Track, and has a Fix again about 7 s after the radio sleeps. 5. Other units: unknown. **Still open** - **11 dB remain** between the antenna with GNSS quiet (-106) and the chip alone (-117). It comes through the antenna and nothing switchable changes it. Telling the surroundings from the Cardputer's own always-on parts needs another place, or the antenna on a short cable away from the case. - **The default.** The setting is off because GNSS on by default was decided in M2 (Q58). From M4 the radio listens all the time, so "pause while listening" would mean GNSS mostly off: a question for M4's design round (#23). - Whether a quieter GNSS mode exists (fewer constellations, a slower update rate) wasn't tried: the receiver's default settings can only be restored for certain by a power cycle, and nobody was awake to do one.
twisla commented 2026-10-06 04:45:41 +00:00
Author
Owner
Copy Link
Copy Source

The self-test and the "Pause GNSS for LoRa" setting shipped in v0.8.1. Kept open for the 11 dB that remain and for the default, which M4's design round decides (#23).

The self-test and the "Pause GNSS for LoRa" setting shipped in v0.8.1. Kept open for the 11 dB that remain and for the default, which M4's design round decides (#23).
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/apps
Launcher and the apps in src/apps
 area/audio
Microphone, speaker, the codec, recording and playback
 area/build
PlatformIO, Docker, scripts, partitions, sdkconfig
 area/cluster
AtomS3 co-processors on Grove and the link protocol
 area/gemini
GeminiService, the Gemini App, Saved Pages
 area/gitea
The Gitea client: issues, releases, its TLS and its token
 area/gnss
GnssService, the GNSS App, Tracks
 area/ir
The infrared LED and the IR Remote
 area/irc
IrcService and the IRC App
 area/lora
The Cap LoRa-1262 radio and the mesh
 area/ota-debug
Updates, Probation, Safe Mode, Debug Console, crash reports
 area/power
Battery, PowerService, sleep
 area/scripting
Lua Apps from the SD card and their API
 area/ssh
The SSH client and its terminal
 area/storage
StorageService, the SD card, Storage page
 area/ui
Canvas, widgets, dialogs, Toasts, fonts, keyboard
 area/vpn
The WireGuard tunnel
 area/website
The project website and its docs
 area/wifi
WifiService, Wi-Fi Settings, Wi-Fi Tools
 concern/memory
May push the heap towards its floors; measure on the device
 concern/security
TLS, signing, the debug token, trust on first use
kind
bug
Something that doesn't work as it should
kind
chore
Refactors, tooling, CI, scripts
kind
docs
README, CONTEXT, milestones, ADRs
kind
feature
Something new the device can do
priority
high
Next up
priority
low
Some day
priority
medium
Soon
status
blocked
Waiting on something else
status
needs-design
Needs a question round (Qnn) before code
status
ready
Designed; can be started
No labels area/lora
kind
bug
priority
high
status
needs-design
Milestone
No items
No Milestone M4 Mesh receive
Assignees
Clear assignees
twisla (Clément Martin)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: twisla/roro9stack#20