Loss of connection between rf24 transmitter & receiver

RE: Loss of connection between rf24 transmitter & receiver

Håkon Alseth — Tue, 13 Apr 2021 13:50:10 GMT

Hi Mike,

I am glad to hear that the problems have disappeared!

[quote user="mikebyrne"]- in former “p_out()” subroutine (subr), I swopped the order of the open_tx_pipe(A1) and stop_listening() subrs (so that Open now proceeds Stop). I don’t know whether this had any effect, but please comment if it could have.[/quote]

You normally want to configure the device before starting the specific mode (it being TX or RX). For this specific routine, it does not matter much.

[quote user="mikebyrne"]

- the unnecessary CRC() subr was removed, with CRC for 2 bytes set in the init_radio() subr.

- I changed the any_rx() subr from interrupt scanning on the RX_EMPTY bit in FIFO_STATUS to scanning on the RX_DR bit in STATUS.

- in former “p_in()” subr, I (a) swopped the order of the open_tx_pipe(A1) and stop_listening() subrs (so that Open now proceeds Stop), (b) added a check on the received packet length to be <32 bytes using R_RX_PL_WID with a break out of the infinite loop if >32, (c) encapsulated the Receive() subr in a loop testing for more than 1 received payload per interrupt .. by using a loop test on RX_EMPTY in FIFO_STATUS.

I therefore note that for my code to have started working, is that my PTX completes a (PWR_UP & PTX) state mode followed by a (PWR_DOWN & PRX) state mode cycle. Whereas my PRX always stays in a (PWR_UP & PRX) state mode. Of course, it’s possible that further code modification might also be successful, but I don’t have the time to explore further.

Thank you again for your detailed interest and help!!

[/quote]

Always happy to help!

Good to hear that you added checks for handling the dynamic payload approach. This will save you debugging hours in the future.

[quote user="mikebyrne"]PS – once my particular nRF24L01+ application has been completed, I might investigate using some of your other similar products, so I would find a copy of your algorithm for the C based API for the whole nRF24L-series devices very helpful if your offer is still valid.[/quote]

Its just a simplistic API, and the real work is getting the logic up-and-running, with catching the corner-cases (like >32 byte payload), which the API does not show. I would recommend that you stick with the setup that you already have running, and rather contact us if any issues/questions pop up.

Cheers,

Håkon

RE: Loss of connection between rf24 transmitter & receiver

mikebyrne — Mon, 12 Apr 2021 20:00:11 GMT

Dear Håkon,

It seems that my re-coding has worked and I now have a working system! I made several changes that resulted in this but, unfortunately because of time pressure, I can’t be sure whether one change in particular did the trick or just the whole combination of minor changes.

I’ve stopped using the ping-pong format and have made my Sensor_unit a dedicated PTX and the Base_unit a dedicated PRX. This avoided the possibility of the TX missing a response from the RX in the infinite loop example of the ping-pong sequence.

1) Code changes to the PTX:

- in former “p_out()” subroutine (subr), I swopped the order of the open_tx_pipe(A1) and stop_listening() subrs (so that Open now proceeds Stop). I don’t know whether this had any effect, but please comment if it could have.

2) Code changes to the Rx:

- the unnecessary CRC() subr was removed, with CRC for 2 bytes set in the init_radio() subr.

- I changed the any_rx() subr from interrupt scanning on the RX_EMPTY bit in FIFO_STATUS to scanning on the RX_DR bit in STATUS.

Thank you again for your detailed interest and help!!

PS – once my particular nRF24L01+ application has been completed, I might investigate using some of your other similar products, so I would find a copy of your algorithm for the C based API for the whole nRF24L-series devices very helpful if your offer is still valid.

RE: Loss of connection between rf24 transmitter & receiver

Håkon Alseth — Thu, 08 Apr 2021 07:10:03 GMT

Hi Mike,

[quote user="mikebyrne"]i) One of your previous points was "Those routines seems to flush RX + TX FIFOs, then also clear all interrupt flags" - I'm unclear as to whether you think that this was good or bad?[/quote]

My apologies, that is good.

[quote user="mikebyrne"]iii) I don't know what would make my PTX miss a payload send, but I take your point. I'm not yet sure whether I can easily change my coding to test your hypothesis above... still thinking on this! However, as this code is representative of my intended application, (PTX sends 'data_out' & PRX responds with 'data_back') I could think about setting a timer within the Receive loop to escape the loop if the return 'pong' has not been received within an acceptable time.[/quote]

Wireless applications will lose a packet every now and then. This is true for all wireless protocols; wifi, bluetooth, GPS, satellite TV, etc.

You do not need to change your code to test the scenario; you need to reproduce the issue and examine the registers state and/or check the current consumption of the nRF radio using a ampere-meter.

If the issue is reproduced and identified; you can move on to solving the issue in code.

Note that this is not an issue on the receiver side logic, but on the transmitter side logic, which assumes that it will receive a packet every time it sends one. Its OK that you continuously poll the status (or FIFO_STATUS) register to see if you have received a payload on a primary receiver, as it is expected that this one shall be in RX most of its life-time.

[quote user="mikebyrne"]

iv) Yes, I did notice the ACK payload" option in the data sheet, but I don't feel that I want to go there yet.

[/quote]

Good that you were aware of this! It is a logical next step if you need bidirectional communication, but I understand that you want to take this step-by-step.

[quote user="mikebyrne"]1) I will select and fix the CRC at start up and remove my "set_CRC()" subr - just to eliminate this as a potential problem source. I don't understand the case between using 1 or 2 CRC bytes (perhaps you might know?) but I will use the latter.[/quote]

1 byte = 256 combinations

2 byte = 256*256 combinations

2 byte is much stronger in terms of getting a random matching CRC. I would strongly recommend that you use 2 byte CRC.

[quote user="mikebyrne"]

2) My code has been responding to the INTERRUPT using the RX_EMPTY bit in FIFO_STATUS in subr "any_rx()", so I'll change this to use the RX_DR bit in STATUS.

[/quote]

If you choose to check the STATUS or the FIFO_STATUS register, it does not make a huge difference when you are polling the nRF radio.

Its usually a bit more convenient to use the STATUS register, as it is shifted back on MISO by-default.

[quote user="mikebyrne"]3) I will also re-code to reflect the full RX handling procedure described in the RF24 datasheet's table 27, STATUS register footnote (c), which I now realise I didn't implement fully. This should deal with more than one RX packet per Interrupt.[/quote]

Good! Given that you flush the FIFOs after each reception, your logic handles this scenario eventually; but I guess you're interested in the other payloads that might be queued up as well.

[quote user="mikebyrne"]4) My Receive code has not been using R_RX_PL_WID to check packet width, even though my code only ever transmits 3 or 4 bytes at a time, but I will now add this check into my receive subroutines in case an event somehow produces > 32 bytes and causes a problem[/quote]

You seem to have dynamic payload length disabled, and use a static length.

While I always recommend to have this check implemented (precaution for when you choose to enable dynamic payload length) ; it should not have caused any troubles for you, as you currently use a static payload length.

[quote user="mikebyrne"]I will re-code to do the following and let you know how I get on (this might take me a couple of days!)[/quote]

Let me know how it goes!

Cheers,

Håkon

RE: Loss of connection between rf24 transmitter & receiver

mikebyrne — Wed, 07 Apr 2021 16:23:43 GMT

Dear Håkon,

Thank you again for spending the time on this with me - I really do appreciate it !

To answer your points:

i) One of your previous points was "Those routines seems to flush RX + TX FIFOs, then also clear all interrupt flags" - I'm unclear as to whether you think that this was good or bad?

ii) I guess that the p_in() function could block if a non-ideal packet is received...so I will change my Receive code on this (see below)

iii) I don't know what would make my PTX miss a payload send, but I take your point. I'm not yet sure whether I can easily change my coding to test your hypothesis above... still thinking on this! However, as this code is representative of my intended application, (PTX sends 'data_out' & PRX responds with 'data_back') I could think about setting a timer within the Receive loop to escape the loop if the return 'pong' has not been received within an acceptable time.

iv) Yes, I did notice the ACK payload" option in the data sheet, but I don't feel that I want to go there yet.

v) Thanks for your comment about an algorithm, but I think that you're right, let's stay with trying to debug my code for now.

My next step:

Taking on your helpful comments, I will re-code to do the following and let you know how I get on (this might take me a couple of days!):

1) I will select and fix the CRC at start up and remove my "set_CRC()" subr - just to eliminate this as a potential problem source. I don't understand the case between using 1 or 2 CRC bytes (perhaps you might know?) but I will use the latter.

2) My code has been responding to the INTERRUPT using the RX_EMPTY bit in FIFO_STATUS in subr "any_rx()", so I'll change this to use the RX_DR bit in STATUS.

3) I will also re-code to reflect the full RX handling procedure described in the RF24 datasheet's table 27, STATUS register footnote (c), which I now realise I didn't implement fully. This should deal with more than one RX packet per Interrupt.

4) My Receive code has not been using R_RX_PL_WID to check packet width, even though my code only ever transmits 3 or 4 bytes at a time, but I will now add this check into my receive subroutines in case an event somehow produces > 32 bytes and causes a problem

Kind Regards,

Mike Byrne

RE: Loss of connection between rf24 transmitter & receiver

Håkon Alseth — Wed, 07 Apr 2021 11:43:31 GMT

Hi Mike,

[quote user="mikebyrne"]

while True:

# Main loop does one full ping-pong cycle

if not PRX:

# start as PTX

p_out("ping") # send ping

p_in() # go into receive mode and wait for reply

else:

# start as PRX

p_in() # receive and display msg

p_out("pong") # send pong

sleep(10) # delay before starting next ping-pong cycle

[/quote]

p_in() function seems to be blocking until it receives a payload. Are you sure its not stuck in that utime.sleep()?

If the PTX misses a payload, then the whole logic seems to go into a bad state where both act as PRX awaiting a PING/PONG from each other. If you can read back the registers on both devices, you should be able to check if my hypothesis is correct or not.

Alternative can be to check the current consumption of each nRF-radio when it enters the bad state. If both show ~13 mA, then they're likely in RX.

Note that there's a possibility to use "ACK payload" to piggy back information back to the PTX device, from the PRX device. How to enable and use this feature is mentioned more in-depth in the nRF24L01+ datasheet, chapter 7.4.1. If you look into this option, you do not have to switch the roles every time, but you would have to send in total two payloads to the PRX device (one for preparing the ACK payload, and one for fetching the ACK payload).

[quote user="mikebyrne"]You've kindly spent some time looking at my code, but would it be more efficient in your time/effort if you could send me some example code (based on the simple code format that I'm trying to use here) which I imagine you engineers must have which demonstrates the very simple point-point communication that I'm trying to achieve? That way I could hopefully work out where my lack of understanding is by comparing the code and minimize wasting your time.[/quote]

The nRF24L01+ is a pure SPI based radio transceiver, which means that you can hook it up to any platform that has SPI master capabilities and start controlling it. This is also one of the drawbacks when me and you are debugging, meaning that there's so many different possibilities of host controllers that is capable of driving the nRF24L01+. The code that we have is in the nRFgo SDK, and uses a common C based API for the whole nRF24L-series devices, while you are using a python based API on your own system.

I could provide you a algorithm, but it would be much faster if we debug specifically towards your implemented platform.

Kind regards,

Håkon

RE: Loss of connection between rf24 transmitter & receiver

mikebyrne — Tue, 06 Apr 2021 15:54:55 GMT

HI Håkon,

Thank you for replying today (Tuesday 6/4/21). As you can probably guess, I've no previous experience with these radios and I don't have the means (or understanding how) to send the state of the rf24 registers when the communication freezes. Sorry! In answer to your points today:

1) OK, so there's no link as such... I feel like I have to assume that the CRCs are ok as data does flow successfully until all stops. I don't know how to prove otherwise. I initialise the RF24s in RF channel 108...could this matter?

2) my code doesn't do anything specific with the interrupts except the Rx code polls for receipt using the subroutine:

def any_rx():

return not bool(reg_read(FIFO_STATUS,nop) & RX_EMPTY) # Lo if data in FIFO

3) Over the last weekend, I lost confidence in, my code, so I reverted to code that "ping-pongs" brief 4 byte messages between the PTX & PRX at regular intervals...which I kept increasing until the communication froze again (it got up to about 40 mins). Perhaps my code is flushing buffers at the wrong time and this eventually causes the comms to freeze. I simply don't know? But, as you can see with the above subroutine, my code is checking the FIFO_STATUS.

The code that follows is my 'ping-pong' code - the same code for the PTX and PRX microcomputers but a button press on each device at start up determines which RF24 starts the sequence as PTX and which starts as PRX. Maybe you can spot where my code is in error.....obviously this code is as simple as I can make it.

*** SUGGESTION ***

You've kindly spent some time looking at my code, but would it be more efficient in your time/effort if you could send me some example code (based on the simple code format that I'm trying to use here) which I imagine you engineers must have which demonstrates the very simple point-point communication that I'm trying to achieve? That way I could hopefully work out where my lack of understanding is by comparing the code and minimize wasting your time.

___________________________________________

Here's my simple 'ping-pong' code:

# nRF24L01+ registers:

CONFIG = const(0x00)

EN_AA = const(0x01)

EN_RXADDR = const(0x02)

SETUP_AW = const(0x03)

SETUP_RETR = const(0x04)

RF_CH = const(0x05)

RF_SETUP = const(0x06)

STATUS = const(0x07)

RX_ADDR_P0 = const(0x0A)

TX_ADDR = const(0x10)

RX_PW_P0 = const(0x11)

FIFO_STATUS = const(0x17)

DYNPD = const(0x1C)

# CONFIG:

EN_CRC = const(0x08)

CRCO = const(0x04)

PWR_UP = const(0x02)

PRIM_RX = const(0x01)

# STATUS register

RX_DR = const(0x40) # RX data ready; write 1 to clear

TX_DS = const(0x20) # TX data sent; write 1 to clear

MAX_RT = const(0x10) # max retransmits reached; write 1 to clear

# FIFO_STATUS register

RX_EMPTY = const(0x01) # 1 if RX FIFO is empty

# constants for instructions

R_RX_PL_WID = const(0x60) # read RX payload width

R_RX_PAYLOAD = const(0x61) # read RX payload

W_TX_PAYLOAD = const(0xA0) # write TX payload

FLUSH_TX = const(0xE1) # flush TX FIFO

FLUSH_RX = const(0xE2) # flush RX FIFO

nop = const(0xFF) # use to read registers

payload_size = const(0x04) # 4 bytes for ping-pong tests

channel = const(0x6C) # chan 108 - above WIFI chans

A1 = b'\x78\x78\x78\x78\x78' # data pipe0 address

# 0x7878787878 - doesn't work

# my buffers:

buf_out = bytearray(1)

buf_in = bytearray(1)

rx_buf = bytearray(payload_size)

def init_radio():

utime.sleep_ms(5)

reg_write(SETUP_AW,0b11) # addr width to 5 bytes

res = reg_read(SETUP_AW,nop)

if res != 0b11:

display.scroll("E1") # check comms with hw

sleep(1000)

reg_write(EN_AA,0x01) # enable auto ack on pipe0 only

#reg_write(SETUP_RETR,0x68) # auto re-tx delay 1750us & count 8

reg_write(SETUP_RETR,0xFF) # auto re-tx delay 4ms & count 15 attempts

reg_write(RF_CH,0x6C) # rf chan 108

reg_write(RF_SETUP, 0x22) # 250KB, -12dBm low power

#reg_write(RF_SETUP, 0x26) # 250KB, 0dBm max power

reg_write(DYNPD,0) # disable dynamic payloads

set_crc(2) # CRC 2 bytes

reg_write(STATUS,RX_DR|TX_DS|MAX_RT) # clr flags

flush_rx()

flush_tx()

def flush_rx():

buf_out[0] = FLUSH_RX

pin16.write_digital(0)

spi.write_readinto(buf_out,buf_in)

pin16.write_digital(1)

def flush_tx():

buf_out[0] = FLUSH_TX

pin16.write_digital(0)

spi.write_readinto(buf_out,buf_in)

pin16.write_digital(1)

def set_crc(length):

config = reg_read(CONFIG,nop) & ~(CRCO | EN_CRC)

if length == 0:

pass

elif length == 1:

config |= EN_CRC

else:

config |= EN_CRC | CRCO

reg_write(CONFIG, config)

def open_tx_pipe(addr):

#EN_AA & SETUP_AW already set in init_radio for pipe0 & 5 byte addr width

# reg_write(EN_RXADDR,0x01) # enable data pipe0

reg_write(RX_PW_P0,payload_size) # RX payload bytes in pipe0

reg_write_bytes(RX_ADDR_P0,addr) # set pipe0 rx addr

reg_write_bytes(TX_ADDR,addr) # set tx addr to same

def open_rx_pipe(addr):

#EN_AA & SETUP_AW already set in init_radio fro pipe0 & 5 byte addr width

reg_write(EN_RXADDR,0x01) # enable data pipe 0

reg_write(RX_PW_P0,payload_size) # RX payload bytes in pipe0

reg_write_bytes(RX_ADDR_P0,addr) # set pipe0 rx addr

# reg_write_bytes(TX_ADDR,addr) # set tx addr to same

def start_send(data):

# transmit pipe0 should already be set up

reg_write(CONFIG,(reg_read(CONFIG,nop) | PWR_UP)) # set PUP

sleep(2) # wait for 1.5msec start up time

# now in Standby-I mode

reg_write(CONFIG,(reg_read(CONFIG,nop) & ~PRIM_RX)) # set TX mode

utime.sleep_us(150) # wait for TX setting time

load_TX_FIFO(data)

# now transmit data

pin12.write_digital(1) ### set CE for Active Tx Mode ###

utime.sleep_us(15) # needs to be >10us

pin12.write_digital(0) ### reset CE Chip Enable ###

def end_send():

# end send mode

reg_write(STATUS,RX_DR|TX_DS|MAX_RT) # clr flags

reg_write(CONFIG,reg_read(CONFIG,nop) | PRIM_RX) # Set RX mode

reg_write(CONFIG,reg_read(CONFIG,nop) & ~PWR_UP) # power down

flush_rx()

flush_tx()

def start_listening():

# receive pipe0 should already be set up

reg_write(CONFIG,reg_read(CONFIG,nop) | PWR_UP) # PUP

sleep(2) # wait for >1.5 msec

# now in Standby-I mode

reg_write(CONFIG,reg_read(CONFIG,nop) | PRIM_RX) # Set RX mode

reg_write(STATUS,RX_DR|TX_DS|MAX_RT) # clr flags extra

flush_rx() # needed?

flush_tx() # needed?

pin12.write_digital(1) ### set CE Chip Enable to start active RX mode ###

utime.sleep_us(150) # wait Rx setting time

def stop_listening():

pin12.write_digital(0) ### reset CE Chip Enable ###

utime.sleep_us(150)

# returned to Standby-I mode

reg_write(STATUS,RX_DR|TX_DS|MAX_RT) # clr flags extra

flush_rx()

flush_tx()

def any_rx():

return not bool(reg_read(FIFO_STATUS,nop) & RX_EMPTY) # Lo if data in FIFO

def receive(reg,rx_buf):

buf_out[0] = reg

pin16.write_digital(0) # CS Lo

spi.write_readinto(buf_out,buf_in) # send reg

rx_buf = spi.read(payload_size) # get code

pin16.write_digital(1) # CS Hi

reg_write(STATUS,RX_DR)

return rx_buf

# now ready for entering TX or RX mode or power down mode

def p_out(code):

# Enter Tx mode:

open_tx_pipe(A1)

stop_listening()

sleep(1000) # wait for receiver to display previously received msg

display.show(">")

sleep(500)

display.clear()

start_send(code)

end_send()

def p_in():

open_rx_pipe(A1)

start_listening()

while not any_rx():

utime.sleep_us(10)

res = receive(R_RX_PAYLOAD,rx_buf)

display.scroll(str(res,'UTF-8'))

# Initialise:

init_SPI()

init_radio()

if button_b.is_pressed(): # using input as Tx/Rx mode selection

PRX = True

else:

PRX = False

if not PRX:

display.show('t')

sleep(3000)

display.clear()

else:

display.show('r')

sleep(3000)

display.clear()

while True:

# Main loop does one full ping-pong cycle

if not PRX:

# start as PTX

p_out("ping") # send ping

p_in() # go into receive mode and wait for reply

else:

# start as PRX

p_in() # receive and display msg

p_out("pong") # send pong

sleep(10) # delay before starting next ping-pong cycle

_____________________________________________________

It's the last line - sleep() which I increase until the comms freezes.

If you're unable to send me some example code, then I hope that you can spot what I'm doing wrong!

Kind Regards

Mike Byrne

RE: Loss of connection between rf24 transmitter & receiver

Håkon Alseth — Tue, 06 Apr 2021 13:38:49 GMT

Hi,

My apologies for the late reply. Its been Easter holiday here in Norway.

[quote user="mikebyrne"]i) Given that I haven't yet had the time to run this for, say, 24 hours between RF24 code transmissions, I'm not yet confident that the RF24 link will stay up that long without any activity. My hope is that the RF24 system could go for days between brief transmissions.[/quote]

There's no "link" in that sense. These are quite simple radio protocols, as long as the on-air physical parameters match, and the CRC is OK; the payload is received, regardless of when this was received in time.

[quote user="mikebyrne"]2) Also, although I now suspect it, I have no understanding of how the Base unit's second radio might interfere with RF24 radios. The pattern was that it's the Sensor unit which freezes far more often than the Base unit (although both are side by side on the bench within radio range of the second radio system during this development phase).[/quote]

It would be very informative if you were able to get a readback of the nRF24L01+ registers when the radio locked up. There was not much radio handling in the code that you posted, for instance; how do you handle the interrupt from the radio? Do you poll the radio or use the IRQ pins?

[quote user="mikebyrne"]3) Thirdly, I use the following subroutines to set the RF24 radios into Tx or Rx mode. But I've added the "open_tx/rx" and 'start_listening/stop_listening' subrs into the start of the Main loop code.......I think that this helps but I'm not sure! I'd welcome your advice on this please.[/quote]

Those routines seems to flush RX + TX FIFOs, then also clear all interrupt flags.

Its hard to say what exactly can be the problem here, especially without seeing the logic for interrupt/radio payload handling, but it sounds like the RX FIFO is filled up without your host controller reading/clearing. Note that the RX FIFO is 3 levels deep, meaning that for one interrupt you can have up to 3 payload queued up. You can read the "FIFO_STATUS" register to see if you have more payloads that needs to be read out.

Kind regards,

Håkon

RE: Loss of connection between rf24 transmitter & receiver

mikebyrne — Mon, 29 Mar 2021 17:59:57 GMT

Hi Håkon,

Just to report that after the RF24 link staying alive this morning for a couple of consecutive periods of 1 hour and 1.5 hours between brief transmissions, it eventually failed again sometime over a 3 hr 20 minute period this afternoon - despite no transmission activity from my Base's second radio source!! This time it was the Base unit which froze and requiring a re-boot to start responding to the Sensor transmissions again (itself not needing a reboot this time). Dissapointing but somehow not a surprise. Hopefully you will know better, but to me that suggests that the second radio source may not be the cause of the problem, whatever help my re-coding did to try to separate the transmissions of the two radio systems may have had. Will I really need to get my Sensor unit to send a regular 'heatbeat' transmission to keep the link alive?

RE: Loss of connection between rf24 transmitter & receiver

mikebyrne — Mon, 29 Mar 2021 10:03:42 GMT

Morning Håkon,

I decided to explore my problem further over the weekend before replying and have some extra information for you. Firstly, I don't have a register dump - but I'm fairly confident that the registers have the correct values. Each RF24 is initialised with the same subroutine code: which includes setting the CRC for 2 bytes:

def init_rf24_radio():
utime.sleep_ms(5)
reg_write(SETUP_AW,0b11) # addr width to 5 bytes
res = reg_read(SETUP_AW,nop)
if res != 0b11:
display.scroll("E1") # check comms with hw
sleep(1000)
reg_write(EN_AA,0x01) # enable auto ack on pipe0 only
reg_write(SETUP_RETR,0x68) # auto re-tx delay 1750us & count 8
#reg_write(SETUP_RETR,0xFF) # auto re-tx delay 4ms & count 15 attempts
reg_write(RF_CH,0x6C) # rf chan 108
reg_write(RF_SETUP, 0x22) # 250KB, -12dBm low power
#reg_write(RF_SETUP, 0x26) # 250KB, 0dBm max power
reg_write(DYNPD,0) # disable dynamic payloads
set_crc(2) # CRC 2 bytes
reg_write(STATUS,RX_DR|TX_DS|MAX_RT) # clr flags
flush_rx()
flush_tx()

My code tries to keep both units in Standby-I mode, so neither uses the PWR_UP = 0 command.

I tried reducing the SETUP_RETR values (above) from their maximum, but I don't think this changed matters. The CRC subr is called, but as I only use 2 bytes, I could just replace with it a single command, but the CRC subr is:

def set_crc(length):
config = reg_read(CONFIG,nop) & ~(CRCO | EN_CRC)
if length == 0:
pass
elif length == 1:
config |= EN_CRC
else:
config |= EN_CRC | CRCO
reg_write(CONFIG, config)

Secondly, I reduced the code in both the Sensor (PTX) and Base unit (PRX) and run just the RF24 relevant code - and this *seemed to have worked* - well as least kept the RF24 link up in point-point mode for intervals of up to 1 hour. I had my Sensor unit send one (3 byte) transmission every hour. ....This apparent progress led me to realize an important admission from my original problem description: Namely that my base unit has a second different radio transmitting source, also working on the 2.4GHz band, but not on the same channel - RF24 chan is 108 (2508MHz) and the 2nd radio on chan 7 (2407MHz). This led me to change my code so that instead of having both radios simultaneously receiving/transmitting, the Base Unit now disables the 2nd radio while the main code loop allows the RF24 to receive (listen) for an incoming code, and then when one is received, the RF24 is stopped listening and the 2nd radio turned on long just enough to transmit its code before being switched off again for the RF24 to go back into its listening mode. So far.. as of this morning.. the Sensor is working in a stable manner, succesfully transmitting a code every hour to the Base station ......

However,

i) Given that I haven't yet had the time to run this for, say, 24 hours between RF24 code transmissions, I'm not yet confident that the RF24 link will stay up that long without any activity. My hope is that the RF24 system could go for days between brief transmissions.

2) Also, although I now suspect it, I have no understanding of how the Base unit's second radio might interfere with RF24 radios. The pattern was that it's the Sensor unit which freezes far more often than the Base unit (although both are side by side on the bench within radio range of the second radio system during this development phase).

3) Thirdly, I use the following subroutines to set the RF24 radios into Tx or Rx mode. But I've added the "open_tx/rx" and 'start_listening/stop_listening' subrs into the start of the Main loop code.......I think that this helps but I'm not sure! I'd welcome your advice on this please.

PRX Base Unit :

A1 = b'\x78\x78\x78\x78\x78'

# RF24 Base unit starts in Rx mode
reg_write(CONFIG,(reg_read(CONFIG,nop) | PWR_UP)) # set PUP
sleep(2) # wait for 1.5msec start up time
# now in Standby-I mode
reg_write(CONFIG,reg_read(CONFIG,nop) | PRIM_RX) # Set RX mode
utime.sleep_us(150) # wait for TX setting time
open_rx_pipe(A1)
start_listening()

def open_rx_pipe(addr):
#EN_AA & SETUP_AW already set in init_radio for pipe0 & 5 byte addr width
reg_write(EN_RXADDR,0x01) # enable data pipe 0
reg_write(RX_PW_P0,payload_size) # RX payload bytes in pipe0
reg_write_bytes(RX_ADDR_P0,addr) # set pipe0 rx addr

def start_listening():
reg_write(STATUS,RX_DR|TX_DS|MAX_RT) # clr flags extra
flush_rx()
flush_tx()
pin12.write_digital(1) ### set CE Chip Enable to start active RX mode ###
utime.sleep_us(150) # wait Rx setting time

PTX Sensor Unit :

A1 = b'\x78\x78\x78\x78\x78'

# RF24 Sensor unit starts in Tx mode
# PUP & set Tx mode, then go into Standby I mode
reg_write(CONFIG,(reg_read(CONFIG,nop) | PWR_UP)) # set PUP
sleep(2) # wait for 1.5msec start up time
# now in Standby-I mode
reg_write(CONFIG,(reg_read(CONFIG,nop) & ~PRIM_RX)) # set TX mode
utime.sleep_us(150) # wait for TX setting time

def open_tx_pipe(addr):
#EN_AA & SETUP_AW already set in init_radio for pipe0 & 5 byte addr width
reg_write(RX_PW_P0,payload_size) # RX payload bytes in pipe0
reg_write_bytes(RX_ADDR_P0,addr) # set pipe0 rx addr
reg_write_bytes(TX_ADDR,addr) # set tx addr to same

def stop_listening():
pin12.write_digital(0) ### reset CE Chip Enable ###
utime.sleep_us(150)
# returned to Standby-I mode
reg_write(STATUS,RX_DR|TX_DS|MAX_RT) # clr flags extra
flush_rx()
flush_tx()

def flush_rx():
buf_out[0] = FLUSH_RX
pin16.write_digital(0)
spi.write_readinto(buf_out,buf_in)
pin16.write_digital(1)

def flush_tx():
buf_out[0] = FLUSH_TX
pin16.write_digital(0)
spi.write_readinto(buf_out,buf_in)
pin16.write_digital(1)

I hope that this is enough information for you to assess my problem, but please let me know if not. Thank you again for looking into this for me.

Kind Regards

Mike Byrne

RE: Loss of connection between rf24 transmitter & receiver

Håkon Alseth — Fri, 26 Mar 2021 10:33:02 GMT

Hi,

Can you share your configuration? Address used, crc configuration, and so forth.

[quote user=""]

As far as I can tell, my code correctly implements the RF24 state diagrams, the registers appear to be correctly

configured and the TX-FIFO & RX-FIFO are flushed as necessary.

[/quote]

Do you have a register dump of the expected values, and when the issue occurs?

Kind regards,

Håkon

RE: Loss of connection between rf24 transmitter & receiver

mikebyrne — Fri, 26 Mar 2021 09:11:42 GMT

To be clear, i should have added that my hope is for the PTX & PRX to be on continuously, that the TX is only likely to send a dozen or so transmissions a day, each transmission will only be 3 ASCII chars long. In fact, following initial power up, my code only uses the command: CONFIG write PWR_UP = 1 once, and (now) I never use the command PWR_UP = 0 in order to keep both devices in Standby I mode the whole time unless transmitting or receiving. I also enable the maximum Auto Retransmit delay (4 msec) & maximum Auto Retransmit count (15).

I can only assume that there is something fundamental about basic point-point operation that I don't understand, so I welcome some guidance please!

Kind Regards

Mike