Hello, I want to know if it is possible to access through MQTT the data that the keep alive of the gateway sends, I am interested in the gps data, since it is a mobile gateway.
1 Like
Please donât connect mobile gateways to TTN.
They cause terrible issues with the automatic adjustment of data rates, since nodes which move to faster shorter range modes can take hours to days to fall back to longer range modes when that gateway moves out of ideal range.
Unfortunately, TTN doesnât have any way to accept ârandom contributionsâ from a LoRaWan gateway, without assuming that said gateway will remain in operation at the same location.
When movement (or even de-activation) of the gateway makes that assumption invalid, performance of the communicate network seriously suffers.
Thanks for your answer, first I use a the things stack, lorawan private server, second that the nodes move with the gateway, I cannot give more details since it is a private product.
So is there a way to access the metadata of the gateway?
That kind of stretches the mission of this forumâŠ
@kapotik no you have to use GW server for that via web API
But having GW meta data via MQTT would be very nice to have
Sorry Chris but no option other than to do that especially when trialing different potential deployment sites around a given area or if doing location surveys - by definition the GWâs then become mobile as they change location - sometime may change 2/3 times in a day or may get deployed for months on end to test under different load conditions & check local environment - also some Solar GWâs may need different placements to optimise sun supply and test over seasons before changing - but still effectively then âmobileâ! 
I often get called in by Systems Integrators or potential end users (Local/County Councils, business park owners, university campuses, industrial sites etc.) to carry out a few days, weeks or months of LoRa/LoRaWAN surveying & trials - will often deploy a fully integrated âboxâ to act as combined GW/NS/APPS etc. but most often will hook up to TTN to demonstate value of TTN and/or TTI and try to get client to consider adding their infrastructure to benefit the community longer term vs just staying private Sorry but these are then temporary/moble deploymentsâŠI also typically add a disclaimer in TTN Console description that location may change and not get (quickly) updated in the Console if its is temporary or mobile if someone checks out the GW after say a TTN Mapper session.
There are also use cases for mobile/lone workers/small teams where they may travel to area swithout a GW - by equiping their vehicle with a (by definition) mobile GW they can take coverage with them when they then wander off for say forestry, agritech or dam inspection work etc.
I am simply asking how to extract the metadata of the gateway from the stack of things, I do not see that it is breaking any rules here
There are definitely use cases for mobile gateways. In fact, weâre already seeing production deployments with gateways on ships, trains and even satellites. We have an open issue about ignoring mobile gateways in the ADR algorithm: Data pushed by mobile gateways should be excluded from the ADR algorithm · Issue #545 · TheThingsNetwork/lorawan-stack · GitHub, and with that we donât have to worry so much about mobile gateways potentially messing with network performance.
To answer the original question: If your gateway uses an authenticated connection and sends location updates in status messages, The Things Stack will store the latest location in the database. Furthermore, if you set the location of your gateway to âpublicâ, it will be added to the metadata of each uplink message.
You can not use MQTT to subscribe to location updates specifically.
1 Like
I understand, but I depend on the time in which the end node transmits to update the position, that is why I wanted to access the metadata of the gateway, since it sends its keep alive more often
This is also valid for The things Industries, private lorawan server?
This will, when implemented, land in all The Things Stack editions and deployments.
So what solution will be given to gateways located for example on a ship? Will they be rejected by the server? Or will they just not update their position but if they will continue to upload messages from the end nodes? Could you please clarify this for me.
This particular issue is about marking a gateway as âunreliable for ADRâ. That doesnât mean uplinks will get rejected, or downlinks will not be scheduled on this gateway. Just that the signal quality reported by this gateway will not be used to optimize the data rate of end devices around it. This will mostly be useful in public networks. Since you already indicated that youâre using a private server, you can decide for yourself if it makes sense for you.
If weâre considering the example having a gateway on a ship, connected to a private network server, with end devices measuring shipping containers or something, it does in fact make sense to enable ADR, because those end devices may be on the ship for hours/days/weeks, and youâd want them to optimize their data rates. So in this case, you wouldnât use that âunreliable for ADRâ indicator.
If weâre considering @Jeff-UKâs example, with a gateway connected to a public network, that is only at a given location for a short time, it doesnât make a lot of sense to try optimizing the data rate of end devices around it. In this case you would set that âunreliable for ADRâ indicator.
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.