Decoder for GPS6digitPrecison is broken

[Dardrai]

Hi RAK Team

I found a bug in the GPS6digitPrecision Decoder for TTN. If I use it as you published here in the git
https://github.com/RAKWireless/RUI_LoRa_node_payload_decoder/blob/master/RUISensorDataDecoder_GPS6digitPrecison_for_TTN.js

With the Payload: 01 88 07 29 C2 01 22 7B 00 D8 72 08 02 01 87 03 71 00 27 FF 86 04 12 05 86 00 40 00 7C FF C4 09 02 08 52 0A 02 00 0F 0B 02 F8 35

The out put will be:
{
"altitude": "19131274.2m",
"latitude": "120.177153°",
"longitude": "578.486488°",
"magnetometer_y": "0.15μT",
"magnetometer_z": "-19.95μT"
}

With the standard decoder it is - this one https://github.com/RAKWireless/RUI_LoRa_node_payload_decoder/blob/master/RUISensorDataDecoder_for_TTN.js:
{
"acceleration_x": "0.039g",
"acceleration_y": "-0.122g",
"acceleration_z": "1.042g",
"altitude": "554.1m",
"battery": "3.91V",
"gyroscope_x": "0.64°/s",
"gyroscope_y": "1.24°/s",
"gyroscope_z": "-0.6°/s",
"latitude": "46.9442°",
"longitude": "7.4363°",
"magnetometer_x": "21.3μT",
"magnetometer_y": "0.15μT",
"magnetometer_z": "-19.95μT"
}

I did found the error in the JS file and it is in the case 0x0188:// GPS - The decoder should not change the Substring value! The Payload size is always the same - as defined by the openmobilealliance.org the precision is only for the decoder

[Dardrai]

RUISensorDataDecoder_GPS6digitPrecison_for_TTN.txt

Here is my fixed js File just changed the str = str.substring(28); to str = str.substring(22); and now it works.

BTW your Payload is not 100% openmobilealliance.org compliant I would believe - I would change this, this can help the customer to implement it with different libraries etc.

08 02 01 66 - is not the correct standard for Voltage transmission

According to openmobilealliance voltage should be send as this bytestream:
08 74 01 66

In my last project I used this Library for the CayenneLPP Payload - https://github.com/ElectronicCats/CayenneLPP

and here is the link for the official definition of Cayenne LPP Payload - http://openmobilealliance.org/wp/OMNA/LwM2M/LwM2MRegistry.html#extlabel

[RAKWireless]

RUISensorDataDecoder_GPS6digitPrecison_for_TTN.txt

Here is my fixed js File just changed the str = str.substring(28); to str = str.substring(22); and now it works.

BTW your Payload is not 100% openmobilealliance.org compliant I would believe - I would change this, this can help the customer to implement it with different libraries etc.

08 02 01 66 - is not the correct standard for Voltage transmission

According to openmobilealliance voltage should be send as this bytestream:
08 74 01 66

In my last project I used this Library for the CayenneLPP Payload - https://github.com/ElectronicCats/CayenneLPP

and here is the link for the official definition of Cayenne LPP Payload - http://openmobilealliance.org/wp/OMNA/LwM2M/LwM2MRegistry.html#extlabel

Hi，dardrai
Thanks for your advice.

1. The GPS6digitPrecision script is used for the scene that user change the payload size of GPS at Node with AT command. If you didn't execute the Corresponding AT command, you should use the normal script.
2. I will read the openmobilealliance.org documents and discuss with my team to change the script to be compatible with openmobilealliance.org.

[Dardrai]

1. The  GPS6digitPrecision script is used for the scene that user change the payload size of GPS at Node with AT command. If you didn't execute the Corresponding AT command, you should use the normal script.

Oh thank you for your replay but then I have to ask, which AT command I should use there? Because I did not see any AT Commands that would improve the precison on the GPS Readouts in your Commands list: https://doc.rakwireless.com/rak7200-lora-tracker/configuring-the-rak7200-lora-tracker-using-at-commands

Thank you for considering the changes to be more compliant to the openmobilealliance.org - formerly IPSO. Just to give you and your team a good reason to do this - and yes I know it will be a lot of work :) - You can maybe also reduce the payload size of each message - with the usage of "better encoded" values - and thus reduce the air time needed to transmit the messages. And this can then also improve the battery performance.
My example of this reduction in payload size would be the coulor object - lpp.addColour(1 , 64, 128, 255); -- which I provided in to the library mention above. This allowed me in my project to reduce the payload from: 00 01 40 01 01 80 02 01 FF to just 01 87 40 80 FF - so from 9 Bytes to 5 Bytes. It is a small improvement but it is nearly for "free", if you think about the additional advantiges that it will have.

[RAKWireless]

1. The  GPS6digitPrecision script is used for the scene that user change the payload size of GPS at Node with AT command. If you didn't execute the Corresponding AT command, you should use the normal script.

Oh thank you for your replay but then I have to ask, which AT command I should use there? Because I did not see any AT Commands that would improve the precison on the GPS Readouts in your Commands list: https://doc.rakwireless.com/rak7200-lora-tracker/configuring-the-rak7200-lora-tracker-using-at-commands

Thank you for considering the changes to be more compliant to the openmobilealliance.org - formerly IPSO. Just to give you and your team a good reason to do this - and yes I know it will be a lot of work :) - You can maybe also reduce the payload size of each message - with the usage of "better encoded" values - and thus reduce the air time needed to transmit the messages. And this can then also improve the battery performance.
My example of this reduction in payload size would be the coulor object - lpp.addColour(1 , 64, 128, 255); -- which I provided in to the library mention above. This allowed me in my project to reduce the payload from: 00 01 40 01 01 80 02 01 FF to just 01 87 40 80 FF - so from 9 Bytes to 5 Bytes. It is a small improvement but it is nearly for "free", if you think about the additional advantiges that it will have.

You can use command “at+set_config=device:gps_format:1” to change gps precise.

Thans for your advice. But I have a question: Can the "better encoded" values can be recognized by the Cyenne platform? Could you tell me where I can find the document. I want to have a look.

Thank you in advance.