Skip to content

Comments

Use hardware channel activity detection for checking interference#1727

Open
weebl2000 wants to merge 1 commit intomeshcore-dev:devfrom
weebl2000:use-hardware-channel-activity-detection
Open

Use hardware channel activity detection for checking interference#1727
weebl2000 wants to merge 1 commit intomeshcore-dev:devfrom
weebl2000:use-hardware-channel-activity-detection

Conversation

@weebl2000
Copy link
Contributor

@weebl2000 weebl2000 commented Feb 18, 2026

Using RSSI isn't very reliable (it's disabled in the code for a reason). We might try hw channel activity detection. Since we are gonna TX anyway it shouldn't be too bad to listen for a few milliseconds first. Worst case we see there is a transmission and we wait a little while. Alternative is that we just TX anyway and intefere with others causing transmission collisions.

Would be great if people could test this on their repeaters & companions and see if TX becomes more reliable.

You can build firmware for you device using https://mcimages.weebl.me?commitId=use-hardware-channel-activity-detection

First impressions after flashing this on one of my repeaters that is high up & exposed to a lot of other repeaters is that it responds a little more consistently. Sometimes it's snappier, but often times it's slightly slower but it fails way less. I.e. less failed status requests & non-answered commands.

@towerviewcams
Copy link

Ok now this is very interesting. My house has LOS to 4 high level repeaters. I'll test this when I get back from work and see what happens. reminds me of busy channel lockout in shared 2 way radio repeaters back in the day before LTR / trunking. Could be onto something here for sure.

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.

2 participants