Skip to content

Dynamic CAD sensitivity - #2916

Open
weebl2000 wants to merge 2 commits into
meshcore-dev:devfrom
weebl2000:dynamic-cad
Open

Dynamic CAD sensitivity#2916
weebl2000 wants to merge 2 commits into
meshcore-dev:devfrom
weebl2000:dynamic-cad

Conversation

@weebl2000

Copy link
Copy Markdown
Contributor

Probe every 4 seconds to measure actual channel activity. If channel seems busy we adjust CAD to be less sensitive. If channel seems empty maximum CAD sensitivity.

Build here: https://mcimages.weebl.me/?commitId=dynamic-cad

Based on conversation in #1727 - this should make a busier node be less senitive to preambles. Tagging @recrof and @syssi would be interesting to see how this changes behavior.

You can use get cad and it will show stats for actual preambles detected during idle periods.

@usrflo

usrflo commented Jul 20, 2026

Copy link
Copy Markdown

@weebl2000 : I tested in my setup with 5 weakly connected nodes, 50 direct messages in 10s intervals, interference by a LoRa node sending local adverts every 6 seconds and a successful delivery counted if the last node ACKs.

Looks good: the problems I saw with 7c8e092 disappeared.

My results:

  • cad off with this branch: 37/38 ACKs for 50 messages
  • cad on with this branch: 39/40 ACKs for 50 messages
  • cad on with this branch plus the latest dev commits: 42/36 ACKs for 50 messages

Attached you can find the monitoring logs.

dev-50-wo-cad.txt
dev-50-with-cad.txt
dev-50-wo-cad-2.txt
dev-50-with-cad-2.txt
dev-50-with-cad-latest-dev.txt
dev-50-with-cad-2-latest-dev.txt

@usrflo

usrflo commented Jul 20, 2026

Copy link
Copy Markdown

I wonder why using dynamic CAD together with repeated sending #2670 decreases deliverability significantly. Resending happens relatively often, but following nodes seem not to react. May the CAD analysis create too much deafness? I wonder why I didn't see this effect when running the same test without the sending repetition.

dyn-cad-on-rep.txt

Probe every 4 seconds to measure actual channel activity. If channel
seems busy we adjust CAD to be less sensitive. If channel seems empty
maximum CAD sensitivity.
@ignisf

ignisf commented Aug 5, 2026

Copy link
Copy Markdown

I've been running this for a while now on a companion in a network with 80+ repeaters in Sofia. I've noticed no ill-effects and I think it should be merged sooner rather than later to complement the release of CAD.

@Magalex2x14

Magalex2x14 commented Aug 5, 2026

Copy link
Copy Markdown

I've also been using this on my repeater since publishing. For now, I can only say that the repeater seems to have become more responsive, but flag 2 is still set quite quickly for 8 seconds CADFailMaxDuration (about 40 neighbors, 15-19 of them with positive SNR). I increase CADFailMaxDuration and observe. Raised it to 16 seconds (4->8->16) just now. CoreScope shows that in our network the packet propagation time reaches 20 seconds...

@ignisf

ignisf commented Aug 9, 2026

Copy link
Copy Markdown

@IoTThinks consider adding this patch to your PS 17.

@IoTThinks

Copy link
Copy Markdown
Contributor

@ignisf We will explore this PR.

How does it help you in your usecase?

syssi added a commit to syssi/MeshCore that referenced this pull request Aug 9, 2026
Probe channel activity every 4 seconds and adjust CAD sensitivity
accordingly: less sensitive on a busy channel, maximum sensitivity
when the channel is idle. Builds on PR meshcore-dev#1727 (hardware channel
activity detection).

Squashed from upstream PR meshcore-dev#2916 (open, by
weebl2000):
- 4b02a86 Dynamic CAD sensitivity
- fe1925e Reduce probe interval on less busy channels
@IoTThinks

Copy link
Copy Markdown
Contributor

IMO, all devices should have CAD on always.
Else, everyone will try to have more TX power and pollute the air.

Since CAD is an option, eventually, people will set it off.

@recrof

recrof commented Aug 9, 2026

Copy link
Copy Markdown
Member

IMO, all devices should have CAD on always. Else, everyone will try to have more TX power and pollute the air.

before we set CAD on for everyone, we need to have good auto-detection for dtPeak/dtMin that won't run every 4 seconds. then we need to have option to manually override those 2 parameters for corner cases. when testing this with radios that have very sensitive LNA, it caused lot of trouble - that's why we still have it disabled by default.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants