You are here Issues

15 posts / 0 new
Last post
VK2IUW Issues

(moderator: moving to the new BETA TESTING forum)

Installed 3.15.1 Beta 4 on AirGrid M2
S/N Ratio is down by about 7db.
Signals are down and I can only see about half of the signals I normally see in the WIFI scan.
From my perspective, there still seem to be issues in the RX chain.



K5DLQ's picture
Is this in comparison to

Is this in comparison to beta2 or 3.0.2?

I took readings in 3.0.2 and

I took readings in 3.0.2 and then updated to Beta 4.




AE6XE's picture
The 7dBm lower received

The 7dBm lower received signal strength does not necessarily indicate it is a defect or a problem, this can be by design and an improvement.  let me explain...

This may be common when there are fairly strong signal.   The Ambient Noise Immunity (ANI) features in the driver purposely attenuates the signal to better handle and decode the data stream in noisy environments.  We have been digging into this ANI change in behavior with upgrade of OpenWRT (why we have a beta 04).   

The ANI logic follows error rates in the receiver and looks to minimize these error rates by tuning parameters, one of which is lowering  AGC (or received signal strength).  Unless you are noticing degradation in actually using the mesh network, or worse, a link no longer shows, then we've yet to known in this instance if there is a real problem of concern here.   One way to confirm, is to measure actual data thoughput across the link, then roll back to 3.0.2 and do the same to compare difference.

Follow-up update:   The signal strength calculated on these Atheros chips is measured in reference to the noise floor and is not an absolute measurement.  The ANI logic is controlling gain, sets levels affecting spurs, and weak-signal detection stuff.  It works along side noise floor calibrations.   Long story short, I see that triggering resets in these ANI levels and causing re-calibrations, the indicated received signal strength instantly changes, and sometimes dramatically,  by 10+ dBm.   It shouldn't be doing this, but it does.  Here's a good reference for anyone that wants to dig in further:  .   Things have certainly changed into this upgrade release of OpenWRT and signal strengths are determined or affected differently.   We have to be careful to compare with prior release.


Thanks for the great info Joe

Thanks for the great info Joe,

I have a single RF link to another node that is marginal at best, but we have managed to get a constant link.

After changing to Beta 4 the link is now worse and dropping out, and I can only see about half of the APs I normally see in the WIFI scan.

With the knowledge of you previous post, we will do further testing and let you know how things progress.

Thanks again.




AE6XE's picture
Hilary,  Just in case, Please

Hilary,  Just in case, Please check the 'distance' setting.  This was changed in the beta and we are finding that links and throughput are more sensitive than previously realized to this parameter.   Please tune it to slightly longer than actual distance in meters.  

AE6XE's picture
VK2IUW,  did your further

VK2IUW,  did your further testing turn anything up?   Are there any thoughput or performance issues detected?  

Also, just in case, please reference another post in Development->Beta forum with procedure to upgrade with "keep settings" from beta01 or beta02 to beta04.  An OTA patch needs installed first.  

k1ky's picture
AIRGRID M5 signal comparison b02 to b04

When I upgraded from 3.0.2 to AREDN B02, on my Airgrid M5 I noticed a 8+  db drop in my indicated signal strength on my established links. I also had to drop down to 10Mhz bandwidth where I was running 20Mhz reliably over a 35 mile path.  Noise floor is at -95 and I should be in the clear with regard to frequency.   What used to be a -70 signal (20Mhz b/w)  is now running around -78 (10 Mhz b/w).  I just upgraded this same unit from B02 to B04 and there appears to be no "improvement" in the indicated signal strength.

One thing that I did notice is that the units can now seem to operate down to a lower "spread" of S/N almost down to around 6 where it used to take around 15 to 20 db S/N in order for the link to perform reliably.  I'm thinking that nothing has really changed with regard to the signal strength and the decoding algorithms seem to be working better.  The proof in the pudding is obtaining overall reliability.

I have 3 more of the Airgrid units to update and I will report back if there are any different results.  Once I get all ends upgraded and stabilized I will attempt to change back to 20Mhz b/w and see what happens.




I updated to beta 4 from beta

I updated to beta 4 from beta 3 load on a airgrid M2 and it trashed my node.

Some very bizarre behavior:

  • Still radiates as “Mesh Node”
  • I can connect to it as a Wifi AP but can’t control it. 
  • It says its IP is if I connect direct via Ethernet but it won’t respond to a ping
  • Won’t respond to the browser at that IP either
  • It gives me an IP of if I connect direct so it’s DHCP seems to work
  • Won’t respond to either
  • Ran an IP scan tool and it says there is a Ubiquiti on 192.168.1.

I can try the reset, but it's up on the roof at the moment.


K5DLQ's picture
BTW, most of the newer POE

BTW, most of the newer POE adapters have a reset button on the bottom of the adapter, so, no need to climb the roof.

b04 update

I hit the reset on the POE and it dot take it back to a factory config but it did shock it back to life and it showed b04 was installed,

I just had to load my call and its working now.

K5DLQ's picture
glad to hear it

glad to hear it

KB5UGF's picture
More on Issues

3 observations/questions regarding beta 4:

1) To confirm another post, I also experienced a change in signal level/noise floor on receive, using channel 1 (2412 Mhz) @ 20 Mhz when compared to BBHN 3.1.0. Noise floor improved from -88 to -95, maybe better (-95 seems to be about the lowest measurable threshold(?). However, weak signals got even weaker and often disappeared. A link I had at -75 now reads -85-90db. Wifi scans turn up less than half the previous hits. It's been hard to quantify the change in lq but it does not seem improved on weak signals. The kind of links we have available are currently less than pristine so we rely on being able to “qrp”. The above link is 2.5 miles and not fresnel zone clear. Bullet/dish on this end, AirGrid on the other. Hopefully our club can soon put something up on an area water tower.

2) So, as I continue to work with the beta 4 on other devices, I reverted the above link to BBHN 3.1.0. I had no success using the AREDN admin console for this, had to tftp the “factory” bin. AREDN's update screen did not recognize the BBHN factory bin and only partially completed the sysupgrade version. Is this normal or am I doing something wrong?

3) After reverting to BBHN 3.1.0 there “appears” to be some persistence regarding the receive signals levels left over from the AREDN beta 4 flash. Do some parameters carry over from that flash? Can I ssh into a file somewhere and reset? Maybe reinstall the BBHN or even the factory UBNT first? When a unit is flashed, does it read the noise in its present environment and calibrate the new firmware accordingly? I ask that because the original BBHN flash was done in the “shack” at ground level, in a much lower noise environment, -95db. When put up at 42 feet it dropped to -87-88db with the same install. When remotely flashed at 42 ft with AREDN it improved to -95 and stayed there when reverted to BBHN 3.1.0.

Any insight on the above would be appreciated, as well as any advice on improving an analytical technique to assist in beta testing. I'm fairly new at all this so the learning curve is still pretty steep!


Sorry this will be a bit

Sorry this will be a bit short as im away from my computer

2) upgrades or even downgrades should always be done with a Sysupgrade file in the GUI, a factory file is only ever for TFTP loads and initial AIROS to AREDN loads.

I should note that BBHN 3.1.0 is actually older than our AREDN 3.0.2 build (BBHN 3.1.0 is based on what we tagged as 3.0.1)  you should be able to downgrade just don't check the "keep settings" box as that is a forward motion only.

3) With a TFTP or a non keep setting upgrade there is no persitance of anything, the entire file system is erased and nothing retained.  However even if data was retained, noisefloor and similar is calculated several times per second.  This sounds like something in the environment may have changed slightly around the same time as you flashed (other people's networks will affect the noise floor)  and yes visual display is capped at -95 because this is the spec of the chips however low level we can see lower in many cases.

AE6XE's picture
Brain dump on signal strengths

In digging into the signal strengths and noise floor issues, there's still a lot of confusion out there (in many forums).   My current take on how to interpret this is below.  I put it out here, for others to shoot down or confirm over time.

1) 'noise' is defined as internal to the receiver--a function of the design and technology.  This is often confused with interference from other signals or in the Atheros chip sets, dealt with in the software driver subsystem called "Ambient Noise Immunity" (ANI).  

2) The wifi software driver has noise hardcoded at -95dBm (and is generally the same as the hardware specs for receiver sensitivity at lowest protocol rate specs).    I take this to be the physical properties of the receiver.

3) The wifi driver, in the ANI subsystem, as a matter of normal behavior, recalculates a "noise floor".  I take this to be logic to handle the influence of interference from other signals, and also generally referred to as 'noise'.

4) The CMOS Atheros chip technology is not capable of measuring an absolute received signal value.    The signal strength is determined relative from the "noise floor", which is a moving target based on interfering signals.

5) There are multiple signal strengths that can be measured:

     a) At the antenna -- there are multiple antennas/polarizations, so multiple signal strength values.

     b) after combining the energy from multiple antennas with "Maximum Ratio Combining" (MRC).  This is when there's one spatial stream of data (and the transmitter used diversity to pick, if more than one antenna, which antenna will deliver the most energy to the receiver). With signal fading and morphing, using 2 antennas to receive can increase the combined received signal by up to 3dB compared to 1 receive antenna.

To put it all together, the software wifi driver will test the possible options of 2 antenna devices and protocol rates, to find which combination yields highest throughput.  There are some tradeoffs in using the hardware.    Jumping from 1 spatial stream of data to 2:    To jump to the 802.11n modes (MCS8+) that send 2 data streams on the 2 respective antennas, this means power is split across both antennas, so the tradeoff is 2 x 3dBm weaker signals.  Here's the statistics of 802.11n rate selections for a given Neighbor ('T' is 1st choice, 't' is 2nd choice):

root@AE6XE-Saddleback-RM5:/sys/kernel/debug/ieee80211/phy0/netdev:wlan0/stations/dc:9f:db:0a:4a:b2# cat rc_stats 
type         rate     throughput  ewma prob   this prob  retry   this succ/attempt   success    attempts
HT20/LGI     MCS0            5.6      100.0       100.0      3              0(  0)         1           1
HT20/LGI     MCS1           10.5      100.0       100.0      0              0(  0)         1           1
HT20/LGI     MCS2           14.8      100.0       100.0      5              0(  0)         1           1
HT20/LGI     MCS3           18.6      100.0       100.0      5              0(  0)         1           1
HT20/LGI     MCS4           25.1      100.0       100.0      5              0(  0)         5           5
HT20/LGI     MCS5            8.3       25.0       100.0      0              0(  0)         1           2
HT20/LGI  tP MCS6           28.2       77.9        33.3      5              0(  0)        18          25
HT20/LGI     MCS7            0.0        0.0         0.0      0              0(  0)         0           2
HT20/LGI     MCS8           10.5      100.0       100.0      0              0(  0)         1           1
HT20/LGI     MCS9           18.6      100.0       100.0      0              0(  0)         1           1
HT20/LGI     MCS10          25.1      100.0       100.0      5              0(  0)         2           2
HT20/LGI T   MCS11          30.3       99.9       100.0      5              1(  1)       296         302
HT20/LGI     MCS12          10.6       25.0       100.0      0              0(  0)         1           2
HT20/LGI     MCS13          21.8       44.7         0.0      6              0(  0)        31          62
HT20/LGI     MCS14           0.0        0.0         0.0      0              0(  0)         0           2
HT20/LGI     MCS15           0.0        0.0         0.0      0              0(  0)         0           2

Total packet count::    ideal 342      lookaround 22
Average A-MPDU length: 1.0


Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer