Hy there,
the live data in TTN V3 console show an RSSI for the message, but if a message ist routed by multiple gateways (which is often the case), this is only the RSSI of the first gateway. As the order of the messages is not fixed and may change, the value is more or less random.
I would recommend to show always the RSSI of the strongest gateway to have a quick information about the current setup. We have a gateway nearby that reports about -50dB, but the console tells us -119 dB.
If you look at the metadata for a given uplink in the console it will show all the receiving GW’s or if appropriate show PacketBroker if routed through there. Even signal received each time by the same gw may show some rssi variance, though usually within a few db (say +/- 10), but if LOS between node & gw obscured (e.g. passing traffic, even woodland - which may have weather or seasonal variance) this can be significant change - decades of db.
Note also if signal is too strong it may get distorted and mishandled (channel bleed across or distorted/overloaded front end - a bit like if I shouted in your ear) and whilst reported may not get used for actual message handling beyond console reporting… -50 should be ok …I usually worry if I see better than -45 or -40, but then I have lots of GW’s in range (in office/lab and neighbourhood) that are far lower that I know will process ok. Perhaps put a few meters more distance betwee node &gw or add some absorption (a wall?) and see if that gw starts showing results…
Personally I’m agnostic as I analyse the overall RF health of the device - what if a temporary gateway gets setup for a while - you get a misleading figure.
You’ll need to file a GitHub issue for your recommendation to have any consideration by the development team.
Thank you for the recommendation. I assume there are more important issues to solve, but maybe a hint here could help somebody who is wondering about RSSI-changes in the console.
We are just thinking to make better use of the gateway information during comissioning, to see all used gateways on a map, monitor RSSI and data losses for some time and so on. Maybe this would be a tool of common intrest to be be filed on Guthub…
There’s no point in asking us if it’s worth considering, we may say it’s a good idea, but the engineering work involved and the usefulness to the stack overall is in the hands of the TTI engineering team - so best post your idea on GitHub issues.
I have the same “problem” with SNR/RSSI. There is already an issue posted on github about it. You can try and upvote it, and maybe if it get’s enough awareness TTI might take a look at it if they find it necessary, and have the resources for it.