LoRaWAN encoding format

JesperR

Hi,
Do LoRaWAN payload encoders typically represent numerical values in the payload (e.g. sensor measurement) with numeric data types (such as uint, int, long, float or double) or do they have a lexical representation in text?

For instance, would a device reporting the value 464 ppm CO2 typically be encoded as (maybe) an integer, or floating-point value rather than as a string "464"?

Are there any LoRaWAN-related standards or industry conventions that prescribe any aspect of payload formatting, or do vendors typically invent their own formatting based on the capabilities of the device and use-case requirements?

Jesper

It differs, some encodings pack as much data as possible into as small frame as possible. But the root is usally uint/int/byte. Sometimes for boolean values each bit can represent a single error for example. I have also seen uint based on 6 bits, so that 3 bytes would be four values. For decimals the values are often calculated using a formula. Since a temperature probe never report less than -50, it is possible to decode values and remove 50 to get below zero using an uint. Most temperature probes have a calibration for 0.1 or 0.01. So there is no need to send a double/float. Instead the value is multiplied, 23.4 = 234 as an example.

Our experience is that all manufacturers have their own format. Sometimes even different between sensor models or firmware versions. There is no standardization of the pyaload format. The LoRaWAN standard is only a communications standard, it does not describe how data values are formatted and can be used for different things. There is a chat-protocol based on LoRaWAN called Meshtastic as an example where text is transmitted.

JesperR

Jesper Does this mean that constraining the memory footprint of the data type is often prioritized over the range and precision of the sensor measurement value in LoRaWAN applications? (In exchange for a measurably longer battery life, that is?) And if so, is it a rule of thumb that vendors always keep the payload as small as possible?

In a case where, like you described, a vendor uses truncated octets to pack a bunch of uints more tightly together, the range of reported values would be reduced from 256 distinct values to 64 distinct values. Was the actual measurement range small enough to always fit a sampled value within 6 bits, or could there have been a value overflow if the measured (and offset) value exceeded 64?

Are things like range, offset and precision (number of decimal digits for integers) for the sensor usually documented somewhere?

Jesper

Elsys is one of many manufacturers that have their decoder available online.

https://www.elsys.se/en/elsys-payload/

If you understand Javascript code you can read a bit about how they send values.

Jesper

In general I would say no. As most truncation is done with attention to the accuracy of the sensor. Most temperature sensors use an uint16, with accuracy of about 0.1-0.3 this means that values (*10) is enough in the data format used. In the 6-bit example that was enough to store the full value without overflow.

I would say that the vendors typically pack as much data as possible into a single frame. Since LoRaWAN does not handle split frames very good, and that the max frame size is determined by network settings (Data Rate, Spreading Factor etc. if I remember correctly). The information about how frames are put together and the precision of each sensor is usually specified in the manual or data sheet from the manufacturer.