Anybody else notice that the Air RSSI seems to bounce with a value of 5 difference in a sawtooth pattern ? The pattern is amazingly consistent…here’s a short snippet zoomed in for a one-hour period.
1 Like
how do you get to see this data?
(somehow it would make sense if it used the lowest possible power to transmit its data reliably, to save some battery. it might be trying to do just that, but that is just speculation from my side)
I get it from the UDP status messages, saved to a database. The Sky does not exhibit the same sawtooth RSSI pattern, nor does the Hub (which can periodically get some really odd RSSI values)
1 Like
Since the Air isn’t sending 3-second (15-second in power save mode) rapid_wind packets like the Sky does, I wonder if this is just a symptom of the Air’s firmware shutting down the radio to save battery between 1-minute observations???
1 Like
i’ll have a look at mine.
Both the Air and the Sky power down to almost a nill. It is my understanding from David, that the radios do go offline.
1 Like
i just grabbed 15 minutes of data using TCP/UDP Testtool, from google play store. My values are pretty stable between -44 and -45. So it isn’t showing your behavior.
But I’m wondering how you get that many data points. My hub only sends air status once a minute.
Isn’t it that you graph is just pretending to have a lot of data points, that makes it look like a saw-tooth?
Your actual values might be just -56 and -50 between it jumps at random. I don’t know why it would do that, but at least that is less worrisome then the saw-tooth pattern.
2 Likes
The air and sky send once per minute, the hub sends every 10 seconds.
I see the sawtooth pattern on the sky and hub too periodically as well, but the air was very very consistently doing it. Of course today it wasn’t for a few hours, but it’s doing so again.
Everything works, just to be clear, it’s just a surprising thing I notice when playing with the data in grafana and zooming in and out. The air seems to bounce between RSSI that are 5-6 apart. The other gear less so (unless the hub takes one of its occasional spikes).
1 Like
Hub status is indeed more often, but I think it reports one value, (which in my case is pretty stable - 56). I asume that this is the hubs value for the WiFi channel. I don’t know how to see the air value that often (which is what you are talking about, isn’t it?)
I have no idea what you are trying to say at this point.
Hub status is broadcast every 10 seconds. Air/Sky status are broadcast every 60 seconds. I listen on the wifi for those UDP messages and save them to a database.
I’m not making up data, I’m just saving whatever is broadcast by the WF gear, whenever the WF gear broadcasts the UDP messages.
He is asking which RSSI value you are using. Hub to Wi-Fi, Hub to Air or Air to Hub.
My hub reports a value, but I think that this isn’t the air rssi value, it is the hub rssi value. That one is updated often. The value reported by air unit is only reported every minute. So I’m wondering how you get air rssi values more often.
I just don’t know exactly, but I get the impression that your software plots the air value, which it gets once a minute, and just interpolates between those, giving you the impression that it reports more often. That would explain the nice sawtooth pattern.
I’m confused by his graphic s his text. The Hub status comes every 10 seconds and is the RSSI value to the Wi-Fi access point. Yet the text says Air and the Air does not report rssi.
I think you guys are overthinking this one.
-
The rssi in the hub status is the quality of the wifi signal between the hub and the LAN access point, measured by the hub and reported in its status message.
-
The rssi in the air/sky device status is the quality of the non-wifi signal between the WF device and the hub, measured by the air/sky and reported in ‘their’ status messages.
-
The hub_rssi in the air/sky device is a measure of the connection between hub and air/sky measured from the hub side, yet reported in the air/sky status message (unfortunately), except the air value for this is always zero due to a bug that David explained in the other thread.
To answer Gary’s question, the original thread here was talking ‘rssi’ elements of the status messages. I was ‘not’ mentioning hub_rssi at all, which according to David has little if any value anyway.
so yes, the rssi in the hub is the wifi (reported once every 10 seconds) , the rssi in air/sky is non-wifi (reported once a minute).
in your original message you were talking about air rssi values, and the graph label does show that. but by now it should be clear that these are reported only once a minute. So your graph only shows exact values only once every minute, all the intermediate values are NOT real, they are interpolated!
We are not over thinking it. Your graph has more points per minute so it looks like it is coming from the Hub Status.
Which RSSI value is represent in the graph?
It’s not a bug, The Air does not have this in the firmware. It was an after thought after the Air was released.
oh for heaven’s sake c’mon guys - is it THAT confusing that I’m just hiding the dots for ease of showing the trends ?
Take any of the following ways to display the same air status rssi data. It’s pretty darn clear to me that there is one observation per minute and the values bounce between -48 and -54 in this 15 minute or so snippet.
Pick any way of graphing the data that makes you less confused. I give up.
Connect the dots…
Show just the dots…
Show just the dots, otherwise zero…
ok that’s pretty clear. You are not worried about the sawtooth pattern at all, you are wondering why it jumps by a value of 6 or 5 in rssi value. (it doesn’t seem to do it all the time). I have no answer to that. in any case, my system doesn’t do it
1 Like
Okay, now it’s clear that it is the RSSI value from the Hub to the Air.
It’s also clear that it is not the Air RSSI but the Hub RSSI to the Air.
i’m not sure why this is marked as ‘solved’. It’s just a different problem than you made us believe in the first place. These large jumps in rssi value are still puzzling.
2 Likes