arjanvanb
December 27, 2019, 4:24pm
6
wdebbaut:
The weird thing is, when I point to the values for the PM data with that loop you proposed; I get the values of 4096 for PM10 and 102.4 for PM25. When I point directly to the byte position 12 and 14, I get the right ones.
The order matters: the counter i will be zero at the start, and only after handling temperature, humidity, pressure, lux, all through UV , it will eventually become 12. So, decoding in TTN Console must be done in the same order as the encoding in the device, and must decode all values, when using such counter. Just like in the last bullet of my first answer.
Also, I’ve created:
opened 06:10PM - 27 Dec 19 UTC
I **assume** the following code is expected to nicely yield 3 bytes that can be … decoded using some simple shifting (like `decoded = bytes[0] | bytes[1]<<8 | bytes[2]<<16` rather than some weird `bytes[0] + 255 * (bytes[1] | bytes[2]<<8)`):
```cpp
message.addUint8(lux % 255);
message.addUint16(lux / 255);
```
However, when using modulo and division to get the LSB and MSBs, one should use 256 (or 0x100), not 255. Like `0x123456 % 255` yields the unexpected 0x9C, not 0x56. And `0x123456 / 255` yields 0x1246, not 0x1234.
Using 256 in the calculations fixes that. Other options would be:
```cpp
message.addUint8(lux);
message.addUint16(lux >> 8);
```
...or:
```cpp
message.addUint8(lux);
message.addUint8(lux >> 8);
message.addUint8(lux >> 16);
```
Note that https://github.com/sensebox/board-support-watterott-fork/tree/master/arduino/samd/libraries/LoraMessage also uses shifting for `writeUint16`, so encodes 0x1234 into the bytes 0x34 and 0x12 as expected.
But of course, please ensure that my assumption of your intentions is valid!
