LowPowerLab Forum
Hardware support => RF - Range - Antennas - RFM69 library => Topic started by: eddy6098 on February 02, 2017, 02:11:03 PM
-
Hi all,
I have a payload which is greater than 66 bytes i.e close to 1000 bytes. I want to implement filling FIFO on the fly. I went through the datasheet but I didn't understand clearly. Any pointers would be appreciated.
-
The RFM69 has what's called the continuous mode, I think a few folks have tried this but I can't remember who/when, but I am sure joelucid's bootloader may be close to that mode at least.
With that your radio is becoming a FIFO in TX mode, and any CRC and missed data will need to be handled at the end. Naturally you cannot do full duplex data transfers since the radios can only be in RX/TX at 1 time.
The RFM69 library does not currently support this mode. Maybe something I will consider later, anyone who can share work they already did in that area would boost this effort.
-
I don't use continuous mode. Just packet mode with a couple of tricks like keeping the radio in tx while sending a batch of packets and ack'ing not each packet individually, but a batch at a time. Those approaches give you the best of what you could expect with very large packets without the downside: larger packet error rates (since a constant BER means more corrupt packets with larger packet size).
-
Thanks joe for keeping me honest :)
I know you shared some code but not if you shared any code related to this above topic anywhere?
-
@joelucid - Could you please share the code? it would be helpful
-
@joelucid - Could you please share the code? it would be helpful
Oh I don't think it would help you much, since it's using my own library implementation etc. But here's how it works in principle:
Say you want to send a 8k packet from the gateway to a node. Instead of sending a huge packet you tell the node that you have 8k data available. Break that down into a number of smaller packets that can be transmitted in one 61 byte packet. Now the node requests the first n such packets from the gateway - consider that request to be the ACK to the request from the gateway.
The gateway now sends all n packets in one packet burst of n separate packets. An optimization is to not even leave TX between packets but that is not strictly necessary and not straightforward to do with the RFM69 lib. Client waits until it received the last packet or timeout and sends the next request for n packets to the gateway, re-requesting packets it didn't receive. This dance continues until everything has been sent.
Big advantage: you get to transmit a full burst without waiting for an ACK. The roundtrips are what usually slows you down. I transmit 28kb in ~2.5 seconds and that includes flashing the data.
Joe
-
An optimization is to not even leave TX between packets but that is not strictly necessary and not straightforward to do with the RFM69 lib.
Joe,
- what do you think the % gain in overall time savings would be when you do that?
- in trying to fiddle with transmitting multiple packets while not leaving TX, ie it looks like once you enable TX there will be 1 packet preamble and possibly many bytes of payload, but not separate actual RF packets - the DS also mentions this (http://www.semtech.com/images/datasheet/sx1231h.pdf) in section 5.5.6. Handling Large Packets.
Since you mentioned about this stay-in-TX optimization, I wonder:
- do you actually do leave TX into STANDBY while refilling FIFO then re-enable TX to trigger a new RF packet?
- Or you just used the payload to fragment your "packets"? (That would also mean the receiver has to be in continuous RX mode until the whole "long" fragmented packet is done?)
I hope my Qs make sense...
-
Hey Felix,
I use multiple packets but never leave tx. When a packet is sent the radio starts sending preamble until the fifo has data again. Then it sends the next packet. I've used it without encryption - the datasheet says you need to fill fifo in standby for aes. If I recall correctly though someone got this to work with encryption by setting the fifo thresh > 16 to ensure enough data is always there to encrypt one block.
I don't use large packets. That obviously costs some overhead but helps when link quality is less than ideal. I'm not sure how big the savings were. I did get a full install below 3s - this optimization might have shaved a second off.
Joe
-
Thanks Joe,
I've been trying it with AES. Without the ACKs its still much faster than with ACKs for each packet. Shaving an extra second by not leaving TX is probably not worth it IMO, since I can do it with the RFM69 lib and sending around ~17K can happen in ~2.5sec.
But still the problem is interesting. So you're saying that it will keep sending a preamble until it gets more data, at which point it sends a full packet again?
I'm wondering if continuous mode has some advantages over that approach.
Anyway I'm pretty happy with the gains as is.
-
Yeah, better ack handling is definitely the bulk of the gain. I don't know that the continuous steam was really worthwhile. Those were my first baby steps in radio land so I just enjoyed tuning the dials :-). This did come in very useful for the Listen mode wake-up packets though.