I have an odd problem using Mike's RFM22 library. I have two boards send messages and listen when not sending. Messages are sent periodically based on a random wait. The messages are fixed in length.
Things run fine but after some time (short, long, in between) it appears that the message returned by the library has the bytes out of order. For example, a normal message looks like:
The messages are being sent using send() and recv(). The units use the default address. I have seem the same failure pattern using sendTo the broadcast address.
I suspect the problem is caused by the fact I am doing a waitAvailableTimeout() call. It seems, from my reading of the lib and chip specs, that one could start receiving a packet and then exit during the receive if the timeout happens. This would then lean to buffer corruption, or a resumption of read on the next waitAvailableTimeout() with the buffers getting filled with parts of another packet.
The addition of the fifo reset after the recv would solve that problem. Also, if I were to wait w/out the timeout (something I cannot do with my application because of how it must work) that should prevent the problem.
When i started with this modules and when i do not use the Mesh library, at my library every time that i got byte to read at the RX buffer, first i ask to the module that tell me how many bytes are ready to be reeded, and only then read exactly the bytes quantity, copy then to the RX buffer. Al this task will be done at a time slot, if the data was reeded at that time slot the packet is valid.
I think that some procedure needs a little bit more time to process the buffers, remember that we are a using this FIFO with a handshake procedure, so this procedure will be fast that the procedure that fills the TX buffer.
May be including a delay at the moment when the Tx FIFO is filled, other thing is that i was using 63 bytes and not 64, and only this help a lot. In fact my RX procedure don't care about how many byte the FIFO sends, it accumulate them always that the time slot is alive using the Rx register as index for the buffer management.
At my application the library works great but for some reason after 1 hour the module desynchronise and do not receive more data. Even i reset it
using the init() function, this some times work and sometimes not. Depends too about how long is the TX buffer.
Very small issues! for this complex library, what i don't know is if using temp() or other procedure to test if the module is alive and if not use the HW reset and start over.
I got a non-mesh code for several of this modules and they have more than 4 month transmitting/receiving with any issue, i mean the RFM hardware do not fails, i'm using FRM22, RFM31 and RFM43 without issues.