We have multiple gateways with GPS on vessels in the Dashboard location is updated properly.
But in the rxInfo metadata of the sensors the location will not change only when manually go to the gateway click on gateway and then just click on update gateway then it changes.
1 Like
Any suggestion how we can fix this ?
Just confirming I’ve got the same problem and can manually correct it in the same way by updating the gateway each time it has been moved
Hopefully it can be resolved somehow
LoRa WAN implies static installation of gateways and moving endnodes, but not vice versa. The update of the gateway status is also regulated by the timing of the update of the gateway status in its configuration.
Hi @eugenev thank you for your response we are not newby’s in LoRaWAN World so we know that it’s normaly visa versa but we are still tying to find a solution for this. We are one of the biggest smart city builders but we are also expending to big vessels. 2.4Ghz is also part of that solution and also promoted by Semtech for vessels.
But i think there are plenty of scenarios where a gateway could also be moving but it’s important to visualize it properly.
this is gw task, but not Chirpstack.
I Think you don’t understand what we are meaning.
As we already mentioned and what’s mentioned by others is that the gw is sending its location and its even updated on the dashboard but but being updated in the metadata of the received packages from the node.
No, that is a mistaken conclusion.
Gateways with GPS report the location at the stats interval, usually around 30 seconds or so - and OP is reporting that they actually see this changing in Chirpstack’s gateway view, so it is working and being captured.
But there is no location data in a raw gateway uplink report, so assigning location information to gateway in the decrypted application-level uplink reports requires tossing the gateway locations as they are received in the stats updates into a dictionary and then looking each gateway which heard an uplink up in that to see if there’s a known location.
It would appear that is what is not updating. OP can wade into the chirpstack code to try to change it, or they can subscribe to the raw gateway MQTT feed, cache the locations themselves and put those back in to the processed uplinks themselves.
Either way the issue remains that the air behavior of LoRaWAN is not designed to work with moving gateways - ADR in particular is going to badly misbehave in that situation, so it would be necessary to make sure that these gateways are not part of a network serving any ADR-enabled nodes, or to somehow blacklist them from the ADR algorithm.
@cstratton and @eugenev,
Thank you for your explanation we expect that a professional outdoor gateway should include this also inside the uplink report. But then it looks like that’s not the case.
Are we someway able to change this inside the chirp stack code so also gateway status reports can update the dictionary ?
No, it shouldn’t, because the backhaul protocol doesn’t define it being there, but instead only in the periodic gateway stats report.
It probably doesn’t define it being there because it would be wasteful in a network designed around the idea that gateways don’t move.