Understanding the content of MQTT topic event/up

Hello everyone,

I set up the ChirpStack application server on my RAK DevKit v2 (Pi4 + RAK2287).
My current project needs to build a sniffer using the GW as I can’t have access to the keys or to the LoRaWAN network, also I’m not interested in the content of the payload coming from the sensors.

I am currently able to receive packets by subscribing to the MQTT topic: gateway/(gateway ID)/event/up.
I want to work on the packets received by using Node-RED. In particular, I’m interested in saving the device address and the GPS coordinates of the GW as my project includes a moving GW.

So my questions are: how frequently are the GPS coordinates updated? (Is it the standard 1Hz update or less?)

Where do I find the GPS coordinates inside this frame? I was already able to decode some info on the device address and maybe the altitude but I’m not figuring out the rest of the data. Is there an explanation of the whole packet somewhere? (I tried by looking into brocaar’s Github but I’m not familiar with the Go language)

Here is the hex code reported on the image:
“0A 1D408D D6 B8 01 801F 0207F5 A5 04 60 B7B6 24 BF 04 4E 8F 4B 9463 CA A3F8 77 84 BF12 11 08 E0 E9 84 9E 03 1A 09 08 7D 10 07 1A 03 34 2F 35 1A 5A 0A 08 E4 5F 01 FF FE 38 80 FE 12 0C 08 E7 E7 AD 90 06 10 90 92 AC EF 02 1A 0C 08 93 ED D8 F9 04 10 80 89 95 EF 02 28 AC FF FF FF FF FF FF FF FF 01 31 9A 99 99 99 99 99 C9 3F 38 01 40 01 7A 04 CB 38 0D FA 82 01 10 74 18 3F A0 77 BC 4F 3B A1 21 98 65 85 47 A4 46 88 01 02”

Any help would be greatly appreciated thank you.

The location of the gateway (which you will find in the rxInfo is updated on every stats message provided by the gateway (given it is provided by the gateway).

For understanding the LoRaWAN packet format, the LoRaWAN specification would be the best source :slight_smile:

1 Like

Hello, thank you for your reply.
I understand that the information on the location is presented in rxInfo, but could you be more specific about where do I get this information in the packet I extracted from the MQTT topic gateway/(gateway ID)/event/up?
I’m not really interested in the content of the LoRaWAN packet but the main thing for me is to get the data about the location of the GW every time the packet is received. Is this information contained in the quoted hex packet? For example, could you help me understand what’s after the MIC bytes that I have highlighted in the image?
Thanks for your help.

First you need to be clear about the distinction between information which the gateway receives from the node, which is passed on unprocessed and unparsed, vs information that the gateway adds itself, that ends up as part for the uplink report.

It sounds like you’re trying to reverse engineer the protobuf encoded uplink report the hard way by studying the raw data of its encoded form (and blurring the distinction between the received packet and the gateway added information), rather than by running it through a protobuf decoder routine informed by knowledge of what’s supposed to be there.

However, the Semtech Packet forwarder code does not wastefully put the gateway’s location information in every signal report, rather it is only sent in the gateway status messages (and only if it’s actually able to be determined).

So to have gateway location information for uplink signal reports, you’ll have to decode and parse both receive reports and status reports and retain the location information by gateway, so that when you get a signal report your own code can add the most recently known location for that gateway. In theory you might want to expire your gateway location knowledge after some multiple of the usual gateway stats period.

1 Like

Thank you for your help, I’m starting to understand now.

Could you be more specific on how to implement this? Maybe I could find the correct decoder in the Github of the Chirpstack platform?

And how about the status reports? Where can I get the information on how to decode them? I’m interested to get the gateway location at every packet received or with a frequency of 1 second and I’m not sure if I can make it work using the Chirpstack platform.

Thanks.

Gateways are really not supposed to move, having them do so would spoil the ADR algorithm (and no, you can’t really adapt to gateway movement, since you don’t have sufficiently frequent opportunities to communicate knowledge back to the node).

Packet forwarders only typically transmit gateway location information at the stats interval. Nevermind that more frequent information is likely useless for the reason above, if you wanted it you would have to modify the settings of the packet forwarder; you may find that reducing the stats interval that dramatically could cause conflicts that might need some design changes, or inventing a sort of “location only” kind of packet that shortcircuited from the GPS NMEA sentence straight to a report, without going through all the usual steps of gathering stats.

Thanks for the explanation, I will be recording the gateway position in another way, it looks to be the better solution. I still have to grasp how to decode the protobuf I presented in the original post, do you have any advice for this?
Thanks.