Hi,
I´m using the lora tracker for some tests with the LORA indoor gateway.
Using Cayenne LPP format i get a Longitude of 1669.0531 when it should be -7.xxx
Is there any solution excluding decoding myself the message?
That is a very odd value for Longitude. What RAK device are you using and what FW?
It is, i get a HEX value on the Longitude of FEAD63 which equals to the value shown before.
Firmware Version 3.0.0.12.H
This is probably a result of mistakenly treating a signed value as unsigned.
Eg 0xFEAD63 can be interpreted as -86685
However it’s quite possible that the actual error occurs in the encoding or at some point in the intermediate processing of bytes or reassembly of bytes into a larger value.
To really make sense of this, you’d need to show both the encoding and decoding code, and also ideally a serial log from the node giving the raw value put into it. And please don’t mask digits.
I think that is it!
Struggling to convert it dough, how did you do it?
Fix it at the source, not afterwards.
Show the encoding and decoding code.
The HEX i sent was the one sent directly by the tracker node no decoding.
The only thing i have in on the application the encoding/decoding type is HEXstring.
When i tried Caynne LPP the same value appeared on the longitude.
So maybe the issue is on the LORA tracker?
Again, if you want help, show the code on both node and infrastructure sides, so that this can get beyond guessing where the mistake is.
1 Like
The node is the Lora tracker :RAK5205 WisTrio LoRa® Tracker | The Things Network
I am using the RAK 7258 direct messaging with no encoding like shown below.
The message received are the known HEX, on which the longitude section i showing FEAD63. That is it, i want to provide all information but that is really it.
A “HEX” is a malevolent pronunciation by someone who purports to have magical powers.
Packets on the other hand consistent of bytes packed by software in some manner to represent useful values.
Without seeing the code in the node that actually creates the messages, and the code in the infrastructure which unpacks them, I can’t help you to identify and correct the actual issue. I suspect someone made a mistake out of confusion between signed and unsigned values, but without the actual code its impossible to say precisely what the mistake was or how to correct it in a way that works for the full intended range of values.
1 Like
Still to young to be a wizard 
But yess thats the only explanation…but in my seeing that is who coded the Lora tracker…or there is some bug in my unit.
As for what i know i have no acces to core code of the tracker right? And can only wait for the gods of RAK to access the situation.
Taking that out of the equation, the exercise of processing the hex packet i would sitll like to know.
I know the theory but having a hard time processing it in JavaScript.
Hi @bioshock2k , i tried your hex FEAD63 to the payload decoder that we provided on the user guide of RAK7205/RAK5205. Here is the link RUI_LoRa_node_payload_decoder/RUISensorDataDecoder_for_TTN.js at master · RAKWireless/RUI_LoRa_node_payload_decoder · GitHub
It works as expected. I got -8.6685 for the longitude.
I use TTN console to test the decoder with your hex. Also tried it in Datacake and it works the same 
Can you try to use that decoder link I send above and see if you’ll got your expected negative longitude?
Btw, the source code of the tracker is here Products_practice_based_on_RUI_v2.0/app_5205.c at master · RAKWireless/Products_practice_based_on_RUI_v2.0 · GitHub
The core code of RUI is not opensourced but the complete algorithm of the tracker code is there. You can see how variables are handled and casts from type to type. You can even create your custom tracker code via RUI 
This is perfect! I will look into it.
Just have to trasnlate that part to a Node-RED function node hehe.
But just adding that is odd, that Cayenne LPP decoder cant trasnlate that value correctly…i bet if it where positive i would have no issue hahahah
And completing the asnwer with the RUI code 
…I will look into it, when i have more time on my hand, i look forward to move to that type of implementations!
Thank you
I’m curious what the entire payload was.
I don’t tend to work with Cayenne, but it seems like format 0x88 is defined to be 3-byte values, while the code can generate either a 3-byte or a 4-byte value but gives the same identity prefix to both. Which occurred in your payload?
Also, using this format for such data is a bit inefficient. You have the device unique identified to know “what” it speaks, and LoRaWan already spends airtime transmitting a port number which can be used to distinguish payload types. I understand people like Cayenne because it is off-the-shelf, but you can actually save two bytes here by selecting the decoder based on device ID and LoRaWan port alone, without needing to spend two further payload bytes to characterize the contents.
What’s odd is that the code you linked can generate either that one with 3 bytes/axis, or one with 4 bytes/axis but still keeping the same 0x1 0x88 prefix.
1 Like
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.