RFM69CW Tx Duration

[shailesh]

Hello all,

I have been a passive reader of this forum for a long time and am finally at a stage where I need some expert opinions

I am working on an RF link which is showing basic functionality. I must add here that I am not using the library directly but am following the structure as shown here. I am currently optimising timings for my code and came across some major delays that I cannot explain. Let me summarize the situation.

We have a setup where we are sending a 64 byte packet at a data rate of 38400 bps. Accordingly we have configured the interrupt to trigger after the packet is sent. For the 512 bits at the above rate, one would expect a transmission duration of about 13.33 ms. What we measure though is around 110 ms. This factor of nearly 8 or 9 is consistent for data rates up to 300000 bps. The time measurement is triggered after the rfm69 enters TX mode and stopped when the interrupt goes high. Thus, the time required to write the FIFO is not included here (It is anyway of the order of 5 ms)

Is there any explanation for this behavior or has anyone else noticed this or something similar? The result is of course that our throughput suffers greatly. Am I missing any settings? I am using the default library settings for 38400 bps.

Any help / suggestions would be welcome.

Best regards,
Shailesh

[perky]

Just checking you don't have any printfs in there that are blocking do you? Printfs can really mess with timings...

Mark.

[shailesh]

Hello Mark,

there are no printfs. Like I said, the timing measurement is triggered once the module enters TX mode i.e. the mode ready flag in the corresponding register is set. The measurement is stopped when the DIO0 interrupt occurs. The measurement is stopped in an interrupt handler so any other functions blocking the code is unlikely.

Are there any internal oscillator settings for the RFM69 that I might be missing?

Shailesh

[perky]

Several things I would look for:

1)Are the serial bit rate registers actually set to 38400?
2)Are you using variable packet size or fixed size? Does the radio know where the end of packet is?
3)Is the final packet size with any other parameters too big to fully fit in the FIFO?
4)Are you sure there's no large preamble being sent?
5)Are you using AES encryption?
6)What happens if you poll the sent bit rather than use an interrupt?

I would try to reduce the problem down to a very simple small non-encrypted fixed packet and do the tests again, if that seems correct increase the size. We may need to see some basic register settings and your simplified code to debug further.

Mark.

[shailesh]

Hello Mark,

thanks for the pointers. I came across one of your tips on the forums for another product but that did the trick. The problem was that in variable packet size mode, the packet length in the first byte was not equal to the number of bytes I was writing to the FIFO. I calculated that fo every extra byte in the FIFO, there was a delay of around 260 micro seconds. I was writing 64 bytes to the FIFO and sending only 7 so that explained the 15 ms delay.

I have fixed the problem for now and things are going as expected.

Regards,
Shailesh

[perky]

Glad it's working. You can use larger packet sizes, but you have to then use the FIFO levels to determine if there's space to write to it during transmission and you also have to unload the FIFO dynamically the other end in a similar way before it fills up.

Mark.

[shailesh]

Hello Mark,

I saw that but my application is working fine with FIFO sized packets so there is no urgent need to change that.

I have noticed on another thread, a few steps that you have mentioned for calculating register settings for other bit rates. I managed to get my radios working at a rate of 76.8 kbps with that. I could follow the calculations but am a radio newbie. could you maybe point me to some resources so that I can improve my technical grasp of the basics behind RF radio?

Regards,
Shailesh