AFC Not Working/Flaky in RF69HCW

[jwketchum]

I have AFC turned on.  Are you saying that having it turned off would mess things up?

Started inserting print statements to try to track down the issues; added a print statement at the end of the interrupt handler, and couldn't get receive to fail anymore.  One thing is clear, looking at the code in RFM69.cpp is that receiver gets set to standby all over the place and it isn't clear to me that setting sleep mode just at the beginning of receiveBegin is going to have the desired effect.

The other suggestion that you had in the thread with kolaf was to redefine standby mode to sleep mode; he reported that didn't have any effect, but just setting to sleep mode in receiveBegin did have the desired effect..  That seems strange to me.  I am going to try making that change and see what happens.

[jwketchum]

Another data point.  When I inserted kolaf's code at the beginning of setMode, to set sleep instead of standby, RSSI of -128 is returned for received packets (should be in the range of -40 to -60),as kolaf reported.  However, when getting RSSI in canSend while checking for clear channel to send ACK, appropriate RSSI values are returned, i.e., between -100 and -110.

[perky]

OK. AFC could mess it up I think if you have it set to not set the AfcAutoclearOn and AfcAutoOn bits in RegAfcFei. I would turn AFC off while sampling RSSI and the turn it back on before receiving anything just in case.

BTW it's important to read the RSSI immediately you get a PAYLOADREADY as the very first thing you do and not after the FIFO has emptied or any mode change.

Mark.

[jwketchum]

Currently, the link has been running continuously for at least 12 hours without a failure. 

I think part of what makes debugging difficult here is that for whatever reason reprogramming configuration registers on the RF chip seems to be unreliable, so it is never entirely clear what the actual operating configuration is, unless I dump the entire register set.  I found that when I was initially trying to get AFC working, I had to power cycle the chip in order to disable AFC, after having it running.  These smaller changes may be taking a couple of upload cycles to actually take effect.

I am using the interrupt routine in RFM69.cpp.  There is a commented-out line there reading RSSI at the beginning, and instead he is doing it at the very end, after the FIFO has been emptied into the receive buffer.  Doesn't seem to be causing any problems, but I will make the change that you suggest, and see what happens.

Not sure I get your point about AFC messing things up.   What will get messed up by having AFC on while doing RSSI read when checking if the channel is clear?   Currently AFCAuto and AFC Autoclear are both set.  Are you suggesting that I should clear these before readRSSI when checking for clear channel?

Thanks,
John

[perky]

Another data point.  When I inserted kolaf's code at the beginning of setMode, to set sleep instead of standby, RSSI of -128 is returned for received packets (should be in the range of -40 to -60),as kolaf reported.  However, when getting RSSI in canSend while checking for clear channel to send ACK, appropriate RSSI values are returned, i.e., between -100 and -110.

....

I found that when I was initially trying to get AFC working, I had to power cycle the chip in order to disable AFC, after having it running.  These smaller changes may be taking a couple of upload cycles to actually take effect.

I am using the interrupt routine in RFM69.cpp.  There is a commented-out line there reading RSSI at the beginning, and instead he is doing it at the very end, after the FIFO has been emptied into the receive buffer.  Doesn't seem to be causing any problems, but I will make the change that you suggest, and see what happens.

Not sure I get your point about AFC messing things up.   What will get messed up by having AFC on while doing RSSI read when checking if the channel is clear?   Currently AFCAuto and AFC Autoclear are both set.  Are you suggesting that I should clear these before readRSSI when checking for clear channel?

If the rado is being put into sleep before the RSSI is read then potentially it might reset the register, which is what will happen if RSSI is read at the end rather than at the beginning. So reading the RSSI immediately you get a PAYLOADREADY should stop that, you should find with kolaf's code that the RSSI should give good values. Also if rx is restarted when the fifo empties then the restart mechanism could potentially unfreeze the RSSI register.

If you're trying to measure the RSSI to determine whether the channel is free then the centre frequency should remain stable, the danger is that AFC will change it and potentially on every restart of RSSI measurement. If the AFCAuto and AFC Autoclear are both set you should be OK as this will clear the FEI on each measurement (this is not the radio power up default BTW), if they weren't you'd possibly face the problem of noise changing the centre frequency and not resetting it which could mean the measurements are done over the wrong frequency.

Mark.

[jwketchum]

OK, got it. Thanks for the clarification.

[jwketchum]

And yes, you are right, moving the readRSSI to the beginning of the interrupt routine now enables wholesale replacement of idle mode with sleep mode.

Big progress here, with your help.

[perky]

Nice! Let's hope it continues working ;

Mark.