RFM69PI V3 Output data decoding

Hello all,

I am new to the Community so at first I would like to thank you for the great forum and the great ideas and products.

I bought a RFM69PI V3 and I am using it on an Raspberry PI3. I build TinyTX nodes with a DHT22 Temp/Hum sensor based on the design of Nathan Chantrell - https://nathan.chantrell.net/tinytx-wireless-sensor/

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.

Thank you very much in advance.

Best regards

Hi Stefan,

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?).


The decimal numbers are bytes, the TinyTx is sending 2-byte integers, low byte first.

As you say, 18 is the Node ID. 1 byte.
The remainder are 2-byte integers - your struct tells you that.

46 + 256×22 = 5678
231 + 256×3 = 999
210 + 256×4 = 1234

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.

That won’t help in this case - the problem is with decoding the data packet, not the entire message.

1 Like

Thank you so much for your fast reply.
I changed my Python code accordingly and it worked.

See the other concurrent thread with Nick about decoding the data - remember that the integer values are signed.

1 Like

So, to fully decode this data:

OK 8 46 3 0 0 0 0 0 0 228 92 184 11 184 11 184 11 184 11 184 11 184 11 0 0 0 0 (-39)

The first ‘8’ is the node id.

The next sequence of two bytes are the CT1, CT2, CT3 and CT4 values, in my case I’m using the CT1, which leads to the following measurement:

46 + 3x256 = 814 Watts (that’s correct)

The next two bytes after the previous sequence is the voltage:

228 + 92*256 = 23780 (237.8 V, that’s correct)

After that, the next sequence of six two-bytes are the temperature:

184 + 11x256 = 3000 (30 °C, why it’s being reported if I’m not using temperature sensor?)

The next two sequences of two bytes are the pulse count, but I’m not sure how they are represented.
[No - see below (Moderator - RW)]

The number in parentheses is the signal strength.

Thanks for the decoding example.

It returns actually 300 degrees not 30, this is an error code see here: emontx3/src.ino at 29b117b3cdb4f6e95131bd91fd28eab047bcace7 · openenergymonitor/emontx3 · GitHub

1 Like

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.

1 Like

Thanks Robert!

1 Like

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.

1 Like

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.

Robert, in your text:

the RFM receiver can lose lock

Were you talking about the PLL?

The problem with Manchester is it doubles the message length, and if you have a large number of outstations, the band clogs up quicker.

From memory, the problem is marginally different clock frequencies.
Try this thread: Data loss due to RF packets getting corrupted | Archived Forum

1 Like