How it is possible to send more than 66 bytes in one packet?

[ng91]

Hello everybody,
I'm new at this board, but this week I'm working all the time on my own library for RFM69HW.
I wrote a function which can transmit a data to FIFO, but the fifo is limited to 66 bytes.
Why? and how can I build a 255 byte message if I can send to fifo only 66 bytes one time?

Thanks everybody for answers
Niko

[ng91]

Sorry, I haven't noticed that there is solution in datasheet! page 56

[Felix]

Either disable encryption in packet mode and that allows you 255 bytes, or go in continuous mode - no limits but you would need to implement a flow protocol - but packet mode is just that and you probably want to stick with packet mode.

[vagyver]

Hello, this is my 1st post and before i say anything i have to thank you for you nice library!!!

In our subject now:
I disable encryption but it still sends only 62 bytes.

Should i make any more modification such as:
#define RF69_MAX_DATA_LEN       61
or
 /* 0x38 */ { REG_PAYLOADLENGTH, 66 },
or anywhere else?

Thank you in advance!!!

[Felix]

Thanks,

You will have to modify several things in the library to make that possible, including the buffers that hold the received packet.
To take up 255 bytes in a char array just for that seems unwise, especially for RAM limited devices like AVRs/atmega328p.

Also, sending long unencrypted packets increases the chance of sniffing your data, and/or corruption of the data stream (more dropped packets).

That is why I do not advocate the use of long packets.

[vagyver]

Thanks Felix for the reply!

I am talking about 85-90 bytes information, not close to 255. And btw, i am not using SendwithReply, but only Sent.
(i am redesigning my DIY weather station. The old used RFM22B-S2).
So, does it have high possibility for corruption with that length of data? (i will try to keep signal better and 15 db from noise).


And a 2nd question: Does the code do CRC checking or the encryption mechanism does it for us (when it is used)?
With encryption off, If it receives wrong data, then does it reject them (and miss the packet, which is ok for me) or it uses/displays the wrong received data?

Thank you in advance!

[Felix]

90 bytes is not too long. But the longer the packet, the greater chance the data is corrupted (interference, other factors causing bits to be flipped).

You will have to consult the datasheet for exact mechanisms of encryption, CRC and packet handling if you want to customize the library to your needs.

CRC is done by the packet handler regardless of whether you have encryption enabled.
See this blog for the latest packet structure of the RFM69 library. It shows which parts of the payload get encrypted and which are CRC checked.

Encryption just scrambles the data so an attacker would not be able to read it.
CRC ensures that the received payload bytes add up to a certain 2 byte checksum. It is possible (in fact it happens often!) that this checksum passes with received noise (frequency depends on how often noise actually triggers reception - this is based on radio settings). When that happens, the packet handler simply decrypts the gibberish payload - to unencrypted gibberish.

Ultimately it is up to the application layer (your code/implementation) to decide if a packet is valid or not.

[vagyver]

Your reply was real helpful to me!

I will keep reading the manual and keep studying your library! 

[fmc5046]

Hi I'm wondering if anyone was able to get this working and send packets larger than 66 bytes, I'm trying to do the same to make the max packet size ~100 bytes.  I changed the FIFO buffer size and packet size in the RH_RF69.h file but its still giving me issues with transmitting.  For the time being I did not enable encryption to get the basics working.  I did see that there was some info on this in the data sheet but its still a bit unclear to me. 
Thanks

[Felix]

fmc5046 - this cannot be done in packet mode unless you divide your data across multiple packets and reassemble when received.
You can use continuous mode but that is not supported in this library.
The RFM69 is usually appropriate for small chunks of data, not so much for large and frequent data.
There are various ways to send more data, encoding or compacting it, rather than send strings and such.