RAK7200 node, GPS tracker

Is it base64? When I look at the payload data in the console it looks like plain old binary LPP format. I wrote my own decoder and it parses the payload according to the link jchonig posted.

In that picture the encoded data is in base64 format as labeled. The raw data may be encrypted with the Device and Appllication keys.

Also, the data Pablo G highlighted is not part of the data from the Device. It’s data provided by the gateway that received the packet and the location is the location of that gateway.

What you say is true. However I think PabloG was wondering how to convert the binary LPP data and that is the data which is shown at the top of his picture. The TTN console has already converted the Base64 data to plain binary in the LPP format.

Yes.
If you see on the example, there is this:
06765f ⇒ 42.3519
That is right, but in my case, I received
FAB780
I want to decode that without TTN console, I want to understand how. The Tracker is 40m away from the Gateway.

0xFAB780 is the latitude in 24-bit format. Since the most significant bit (D23) is a one it is a negative number so convert to 32-bit number by adding 0xFF000000 to get 0xFFFAB780. Convert this number to decimal to get -326240. Then divide by 10000.0 (per LPP format) to get -32.6240. If D23 is zero then do not add 0xFF000000 and convert to decimal and then divide by 10000.0. In your example 0xF71253 is longitude and 0007DA is altitude. The altitude converts to 20.1 meters, so I do not know why your example shows it as 49.

0xFAB780 must be “-34.62…”
not “-32.6240”
About the altitud, it doesn’t matter for me yet, never is accurate.

You’re right, -34.6240. I fat fingered it. Sorry.

My LPP payload decoder is in Javascript and runs on my TTN console. I’m not an expert in that language and I didn’t find a way to test if D23 is a one so instead I convert the 24-bit hex to decimal and then use this function to convert it to a negative value if needed:

// Handle 24-bit negative numbers
function DoNeg24(num)
{
var rnum = num;

if (rnum >= 8388608)
{
// Handle negative numbers
rnum -= 16777216;
}

return rnum;
}

Thank you Robo.
I will try that.

Today I’m working with 4 Trackers and one 7249 Gateway. I see that one say is joined on the SERIAL PORT PROTOCOL but on the server not. What happen on that case, when the node assume that is joined but the Gateway lost it?, I mean if the node (tracker) need to have set the confirm to 1, or how the node retry to join again to the Gateway?
I don’t know if I’m on a mistake or something I don’t understand on the function of this.

Hi,@PabloG
Can you share your test log or screenshot?

This is the accuracy I am getting…
please look into it.
From smartifyworld private limited to coordinates given image.

Hi, please give a little bit more info. Are this points sent by node? What FW version and bootloader version are you using?
This is from RAK7200 on my desk, second floor under roof.

My position is in blue mark, red is from RAK7200. Around 10 meters error.

This is the data I am getting on TTN
Device is fully updated.
I am checking data on TTN using Cayenne LPP decoder.
](https://www.thethingsnetwork.org/docs/devices/arduino/api/cayennelpp.html)

Can you give me output of RAK SERIAL TOOL with RAK7200 connected? I need at+version output and then at+set_config=device:boot , again at+version.

Hm… the distance from coordinates that you gave is 16 meters.


So… it is not perfect , but it is good. My question is are you near to this coordinates or you are 500 meters from coordinates reported, as you stated in your other post?

These co-ordinates are near my office less than 10 meters.
But same co ordinates I am plotting on google maps show distance more than 100 meters.
and also I want to know which maps you are using?

I am using Google maps and your coordinates from the serial output. Tricky part here is that for data is used LPP standard. It allows only 4 digits after decimal point. And that is not precise.