After a storm came through, we've experienced about a 10 dB rise in the noise floor, which has extremely limited the range of most individual nodes (2.4 GHz, Channel -2). Your ideas as to possible causes/solutions are appreciated.
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
Joe AE6XE
There really isn't such a thing as an absolute signal value -- the hardware's ability to do this is not accurate. The 802.11 chip implementation basically say the received signal strength is relative based on a guesstimate of the noise floor. Showing the NF at -95dBm or -85dBm is somewhat arbitrary. A lot of this behavior is hidden in the qualcomm NDA, or not published anywhere. But some is readily reverse engineered from the code.
Long story short, keep an eye on it to see what happens. There's noise form somewhere or a hardware-water problem. If noise, a rock steady -85dBm would suggest somebody has a stuck interfering transmitter that the AREDN node is trying to get on top of.
Joe AE6XE
73 de bill n7ie .. .
There are brief periods where some links are usable, which indicates that whatever the offending source is coming from goes off the air or changes from time to time. We hae not attempted to really get serious about tracking this down, but will do some more investigating soon. This is observed from many stations that are 130 feet in the air pointed in all directions (3 sectors on each site). I'm thinking possibly some high power 2-way or broadcast system that could be spraying trash all over the band. This affects stations within 3 miles of the downtown area.
bill n7ie .. .
Here is a link describing the operation:
https://help.ubnt.com/hc/en-us/articles/204950584-airMAX-How-to-use-airV...
"How long would it take the system to recalculate/repopulate data across the mesh after the offending node is powered down"
Short answer, it should be order of seconds, not minutes. A "wifi scan" will force a noise calibration to be triggered.
Comments in the code that may shed light on this:
/*
* If beacons are stuck, the most likely cause is interference.
* Triggering a noise floor calibration at this point helps the
* hardware adapt to a noisy environment much faster.
* To ensure that we recover from stuck beacons quickly, let
* the baseband update the internal NF value itself, similar to
* what is being done after a full reset.
*/
In a 20Mhz channel, the hardware maximum noise is ~-95dBm. In 10Mhz it would be ~-98dBm (but I don't think the code compensates for channel width). See next comment on why we nearly always see -95dBm as the noise floor). To get a noise floor higher than -95dBm means the outgoing beacons are stuck, thinks the channel is always busy and can't xmit them = a lot of noise on the channel OR you're doing 5Mhz channel with firmware prior to 3.16.1.0 (was doing 10 beacons per second) in combination with a lot of nodes = too much contention for the channel. We lowered beacon rate in 3.16.1.0 to 2 per second.
/*
* Normally we limit the average noise floor by the
* hardware specific maximum here. However if we have
* encountered stuck beacons because of interference,
* we bypass this limit here in order to better deal
* with our environment.
*/
/*
* If the noise floor seems normal for all chains, assume that
* there is no significant interference in the environment anymore.
* Re-enable the enforcement of the NF maximum again.
*/
Given that things are back to normal after the wifi scan, this is probably what happened. This behavior may be good for client only connecting to a single access point--likely the scenario the original writers were thinking of most. But for multiple point connections, it's not desirable to tune out half the neighbors. The zillion $$ question is how to detect when something is noise vs a legitimate neighbor, particularly when there are a lot of varying signal strengths from all the neighbors.
Joe AE6XE
Joe AE6XE