You are here

SNR archive plots go full scale (0 dBm) instead of down to noise floor?

19 posts / 0 new
Last post
NM7B
SNR archive plots go full scale (0 dBm) instead of down to noise floor?

I've noticed what appears to be a change/bug in the latest 3.20.3.0 where the SNR archive plots show signal dropouts as full scale instead of down at the noise floor.  For nodes that are intermittent or marginally in range, this results in a rather eye-catching sawtooth plot.   Is this a known/reported bug?
 

K6CCC
K6CCC's picture
Been that way as long as I
Been that way as long as I have been involved.
 
NM7B
It changed

It definitely changed.  I've included SNR plots for pre-3.20.3.0 and 3.20.3.0.  Thankfully I only have a couple paths that are marginal, but it happens.

Image Attachments: 
K6CCC
K6CCC's picture
Interesting
Interesting.  My only comparison is when I first set up the first path at work - which was most likely version 3.18  It definitely would go to top of the scale when there was nothing received.  Drove me nuts until I figured out what it was doing.

 
N7TZK
Not a welcome change
Yes, I noticed this with 3.20.3.0 as well.  I don't usually use nightly builds, but I haven't experienced this with previous release versions.  It isn't a welcome change IMHO.

 
k1ky
k1ky's picture
SNR archive plots go full scale (0 dBm) instead of down to noise
I've noticed this for quite a while now. Not sure if it still happens with the latest nightly builds, but I'll investigate further.
NM7B
Thank you!
Thank you for looking into it!  The sawtooth plot was quite a sight to see when I pulled the archive up :-)
AE6XE
AE6XE's picture
I wouldn't have expected
I wouldn't have expected there to be a change in behavior from release to release.  I had thought these values all came right off the hardware wireless chip.  We had some discussions early on, there was a situation where the returned RSSI value is a "0" (or 1 mW ) and the Atheros chip docs say it is unknown or some state that is not absence and not a measured value.  So the dilemma has been what to show in the charts when this is the case.  Should it show as an absence of a signal, e.g. no data?  Should the prior measure be used to guess and pad it in? other?    Possibly openwrt has an update that is changing this value before we obtain the data?

Joe AE6XE 
k1ky
k1ky's picture
SNR issue
Could this be a result of new behavior introduced by implementation of the Auto Distance feature?  Possibly something happening when the distance value changes during signal fluctuations?
AE6XE
AE6XE's picture
It would not be related to
It would not be related to auto distance, rather directly related to how the chart logic interprets the RSSI value.   This is a  value defined in the 802.11n specification between 0 and 255.  It is a relative value, not an absolute measure of power.   The process in openwrt ath9k driver is to measure the ambient noise background, a "Clear Channel Assessment" (CCA), then whatever this measured value is, call it -95dBm @ 20Mhz channel, the theoretical noise.   Cisco is known to only use this range to be between 0 to -100, Atheros 0 to -127.  The usage of this value range is different between chip manufactures.  This is then interpreted as 0dBm (1 mW) down to -127 dBm below the hardware noise levels. 

The spikes to 1 mW in the chart would have to be because a value of '0' is in the data, or close to '0' for some reason.  There is a data file in /tmp for snrlog that you can inspect to confirm and see this data.  The code needs reviewed to handle the logic of what to do when this 0 value is encountered.    A '0' is not believable in normal operating use and IMO should be considered bogus.   Although, on the bench, one could probably achieve this signal strength between devices.   Possibly, the data shows a new range of values between 1 and 10, also not generally believable and if so, in this case bogus.  I thought the chart code handled '0's before, but maybe this is a new data range we weren't seeing before.

Joe AE6XE
NM7B
Would uploading the specified file help?
Would uploading the /tmp snrlog files help root-cause what is going on?  Let me know what file to snag and I'll be happy to retrieve them and upload some samples.

73's,
Collier
NM7B
 
AE6XE
AE6XE's picture
in the folder /tmp/snrlog,
in the folder /tmp/snrlog, look for a filename for each neighbor.   tar, zip, etc. this file for one of these interesting charts and upload here.

Joe AE6XE
NM7B
How to get files off of the node
I see the files, but am drawing a blank on how to download the file from the node to my Windows computer that I have used to telnet into the node.  Do you have suggestions on how to retrieve the files of interest?

Thank you!
 
AE6XE
AE6XE's picture
NM7B, assuming windows 10,
NM7B, assuming windows 10, start up a windows "PowerShell".  Here is an example below.

caution:
1) linux is case-senstive on file/host names
2) the filename in linux is not allowed in windows, so this command renames it.  be sure the wildcard, in this example, "*W6LY*" does not match more than one filename.
 
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.
 
Try the new cross-platform PowerShell https://aka.ms/pscore6
 
PS C:\Users\jayers> cd C:\temp
 
PS C:\temp> scp -P 2222 root@ae6xe-saddleback-rm5.local.mesh:/tmp/snrlog/*W6LY*  w6ly.txt
dc:9f:db:0a:4a:b2-W6LY-RM5-RDish-LWV-SB.local.mesh                                    100%  115KB  84.2KB/s   00:01
PS C:\temp> ls w6ly*
 
 
    Directory: C:\temp
 
 
Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----        5/26/2020   6:28 PM         118003 w6ly.txt
 
 
PS C:\temp>




 
NM7B
Archive plots and snrlogs attached

Thank you--that worked perfectly.  I saved your directions off in my AREDN notes for future reference.  

I have attached three sample plots and RSSI logs.  It looks like "null" is plotted as 0 dBm.  

73's and thank you!
Collier
NM7B
 

AE6XE
AE6XE's picture
NM7B,
NM7B,

Can you copy down this file and then upload to your node?

download this file:  https://drive.google.com/file/d/1HeJS9HluTr73YrO7NJKv5x-roKNR9q-z/view?u...

To upload to your node:
PS C:\Users\jayers> cd .\Downloads\
PS C:\Users\jayers\Downloads> scp -P 2222 ./snrlog root@hostname.local.mesh:/usr/local/bin/

reboot the node and let it run overnight to see what the chart now looks like.   

Joe AE6XE
NM7B
No apparent change in plots

I identified two nodes that have archives that consistently should be plotting zero SNR and put the snrlog you supplied in the /usr/local/bin directory.  Unfortunately I'm still seeing plot points going all the way up to 0 dBm.  I have attached updated screenshots and snrlog files.

Thank you for looking into this!
73's,
Collier
NM7B

Support File Attachments: 
AE6XE
AE6XE's picture
NM7B,  the data file still
NM7B,  the data file still has "null" captured as a data point.   the code was supposed to see this and convert it to -95dBm so there would not be a spike showing.   Ether the code is bad or it didn't take effect for some reason on your node.  i'll investigate on the code side...

Joe AE6XE
NM7B
Seen on archive plots, not sure if on real-time plots
Thanks, Joe, for looking into this.  To clarify: I have seen this on the archive plots, but have not verified if it also appears on the real-time plots.

Also: To ensure I was looking at the nodes with the test version of snrlog, I had renamed the original version of snrlog to "oldsnrlog", and I verified that these old versions were in the nodes I examined later to see if the plot bug went away to mitigate the chance I was looking at a node without the test version of snrlog.

73's,
Collier
NM7B

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer