Trying to understand packet structure

[iggardo]

Hi.

I'm trying to put together and understand the available info from 3 sources:

-Github sourcecode.
-the bottom of the official blog page: http://lowpowerlab.com/blog/2013/06/20/rfm69-library/#more-917
-Post about  correction regarding the max message length: https://lowpowerlab.com/forum/rf-range-antennas-rfm69-library/rfm69-lib-correction-regarding-the-max-message-length-(addressed)/

I have made a picture with my assumption summarizing what I understand, but I must be missing something, because there are certain inconsistencies with the code:



What is wrong with my assumptions? What are I'm missing?

Regards.

[Felix]

Did you see this post?

[iggardo]

Thanks Felix.

I didn't notice that post.
As far I can see, both tables look the same.

According to the table, max Payload length is 65 bytes, so doing maths:

RF69_MAX_DATA_LEN = MAX PAYLOAD LEN - DestID(1byte) - SenderID(1bte) - CTL(1byte)
RF69_MAX_DATA_LEN = MAX PAYLOAD LEN - 3bytes
RF69_MAX_DATA_LEN = 65bytes- 3bytes
RF69_MAX_DATA_LEN = 62

If that is true, why is RF69_MAX_DATA_LEN defined as 61 in the code ?
In RFM69::interruptHandler() function PAYLOADLEN is adjusted to a maximun of 66 instead of 65, and DATALEN  is calculated as DATALEN = PAYLOADLEN - 3; instead of DATALEN = PAYLOADLEN - 4;
Is max Payload length == 65 a wrong assumtion?

[Felix]

If you look at the diagram there are 4 fixed header bytes, and 61 useful data bytes. Total max is 65.
So useful data is max of 61 bytes.

[iggardo]

If you look at the diagram there are 4 fixed header bytes, and 61 useful data bytes. Total max is 65.
So useful data is max of 61 bytes.

That makes sense, and agrees with the diagram, but not with the code of the library (I may be wrong).

I think these lines from RFM69.cpp are not correct:

Code Select Expand

...
#291     SPI.transfer(bufferSize + 3);
...
#319     PAYLOADLEN = PAYLOADLEN > 66 ? 66 : PAYLOADLEN; // precaution
...
#331     DATALEN = PAYLOADLEN - 3;

To make them agree with the diagram, they should be

Code Select Expand

...
#291     SPI.transfer(bufferSize + 4);
...
#319     PAYLOADLEN = PAYLOADLEN > 65 ? 65 : PAYLOADLEN; // precaution
...
#331     DATALEN = PAYLOADLEN - 4;

I don't have moteino or similar to test the code with the debugger, but I will try it in a few days when my new Raspberry Pi comes

Sorry if I missing something.

[Felix]

In the datasheet P52 (section 5.5.2.2) the max payload length is 66 bytes, when hardware addressing is enabled.
The RFM69.cpp has this disabled so max payload length is 65 bytes. The payload length byte is not included in that count so the actual check should be 64 not 66.
So I think you are correct about the code in the IRQ. I need to revisit that and test changes. Right now the side effect would be truncation of any longer message than 61 bytes, and essentially nothing is changed even if I make the change from 66 to 64, it works the same.
In other words, it's not causing a logical error as it may look. For instance it you try to send AAAA_AAAA_AAAA_AAAA_AAAA_AAAA_AAAA_AAAA_AAAA_AAAA_AAAA_AAAA_123456 (66 bytes), only the expected 61 bytes are received: AAAA_AAAA_AAAA_AAAA_AAAA_AAAA_AAAA_AAAA_AAAA_AAAA_AAAA_AAAA_1
Thanks for bringing this up though.

[iggardo]

Hi Felix.

Finally I have been able to test your library with real hardware.
Modifying the code to make it match the diagram simply does not work.
I have not found the reason, so I left the code as it was (original library).

If I get a proper debugger, I'll try to find more.
Thank you for your time and for such a great library.

[perky]

If you have CrcOn=1 normally PayloadReady won't go active unless the CRC passes, you can force PayloadReady to trigger even if ithe CRC fails by setting CrcAutoClearOff=1.

If you've not got CrcOn set on the receiver then no CRC check is done, and then CrcOk is invalid (and could well be 1 by default).

I can't explain what's going here. In variable packet mode the first byte read out of the FIFO on reception is the length as that's part of the packet, so you should be reading 7 bytes rather than 6, but that doesn't explain what you're seeing. Maybe sync word is all zeros and causing premature reception or something. We'd need to see a register dump for both transmit and receive, suspect this might come down to more than one error conspiring to give strange results.

[stern0m1]

Could I send and receive raw bits with a moteino not conforming to any particular protocol?

[Felix]

You'd need to use a modulation type (not necessarily a protocol - and by protocol I mean an application layer rather than physical), otherwise how can you transmit anything?
The modulation is referring to the physical layer.

Without modulating your 'bits', is like speaking words or letters without using a particular sound.
Even if you do that, without a certain pattern (here a protocol starts to make sense), they would be more like noise to a receiver which could not really distinguish the real data from background gibberish that might exist on the same frequency. That is why in digital comms the "protocol" is designed to raise attention that real data is incoming (ie preamble and transmission "structure").