(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.
Hilary
VK2IUW
Is this in comparison to beta2 or 3.0.2?
I took readings in 3.0.2 and then updated to Beta 4.
Hilary
--
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: http://www.google.com/patents/US7245893 . 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.
Joe AE6XE
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.
Hilary
--
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.
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.
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.
T.D.
I updated to beta 4 from beta 3 load on a airgrid M2 and it trashed my node.
Some very bizarre behavior:
I can try the reset, but it's up on the roof at the moment.
BTW, most of the newer POE adapters have a reset button on the bottom of the adapter, so, no need to climb the roof.
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.
glad to hear it
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 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.
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
Joe AE6XE