I would like to convert the data which is received from the Raspberry PI via UART with a Python script and convert the data so I can use it in my Magic Mirror project I am working on.
Now I have the problem, that I have not understood the way in which the data is provided to the PI.
In minicom I see the (decimal) data: OK 18 46 22 231 3 210 4 (-37) → ack
(binary) data: OKX 122E16E703D204 (3A) → ack
The node ID is 18, so this matches the beginning of the data above.
On my TinyTx nodes the data structure is as follows:
typedef struct {
int humidity; // Humidity reading
int supplyV; // Supply voltage
int temp; // Temperature reading
} Payload;
At first I thought the nodes have an issue, so I added a fixed value for humidity = 5678, supplyV= 999 and temp = 1234.
Based on this fixed data I was expecting to find the values above in the minicom received data
(decimal) data: OK 18 46 22 231 3 210 4 (-37) → ack
Can someone please help me to understand, how I have to interprete the sent data?
In the forum I found the topic: Output RFM69PI but this was not answering my questions.
I am working on a similar task: converting raw RFM69PI V3 data (from emonTx3) via python. The information is very scattered and difficult to find. Here is a good place to start: http://jeelabs.org/2010/12/07/binary-packet-decoding/
This explains the format of the messages being sent from an emonTx (which I think is the same format from your TinyTX?).
Note that we normally multiply by 10 or 100 to be able to send the data as a 2-byte integer instead of a 4-byte float, and still preserve some decimal information.
@nicklaws
That won’t help in this case - the problem is with decoding the data packet, not the entire message.
No, wrong. The next four bytes are the pulse count, and it’s an unsigned long integer. It’s decoded in much the same way: 0 + 0 × 256 + 0 × 2562 + 0 × 2563.
For information:
The history of this is - many people don’t use all of the temperature sensors. When there is a long string of zero bytes, the RFM receiver can lose lock and then the message fails. So we changed it to send an impossible temperature (300°C or greater) to indicate various errors (one of those is “no sensor”) and simultaneously break the long string of zeros.
The history about the 300 is interesting. I haven’t studied the RFM69, but I believe that the solution to this problem could be in the encoding of data, like the Manchester Code. But in any case, we do need an out of the band number to represent error conditions.