RADIO registers and handler for proprietary protocol

[Elia_pell]

Dear all,

I'm currently implementing a new wireless protocol using SDK For Thread and Zigbee (4.1.0) (nRF52840DK) accessing the radio registers directly. Reading the example, it all seems quite easy.

I'm not using any softdevice, but implementing it from scratch. 

I'm implementing the transmitter side, and I define the RADIO_IRQHandler (assigning an interrupt priority = 1) to catch the event. The problem is that the packet is not sent (I'm debugging it with the receiver example: the radio configuration of my transmitter is the same of the example transmitter, so the packet must be received in the receiver side). In my opinion is a problem of interrupt priority, but not being an expert on this, I don't know how to move on.

Any hint on this?

I attach the code, in order to better understand the situation.

code:  /cfs-file/__key/communityserver-discussions-components-files/4/0081.transmitter_5F00_to_5F00_send.rar

Thanks to all,

Elia

[Håkon Alseth]

Hi,

 

Have you tried the radio examples in the nRF5 SDK (examples/peripheral/radio, transmitter and receiver)? It seems that you're enabling all NRF_RADIO->SHORTS now, which isn't a good approach. I would recommend that you get the communication between RX and TX running, then optimize afterwards.

 

PS: there's also a nrf_esb library which you can use, which handles things like auto-ACKing on-air etc.

 

Kind regards,

Håkon

[Elia_pell]

Dear Håkon,

I found out the problem: the BASE0 and PREFIX0 address of tx and rx were different, and this cause the receiver to not receive data. This behaviour is pretty strange, because, as you can see from the code, no DAP or DAB has been written. Why this behaviour?

Regards,

Elia

[Håkon Alseth]

Hi,

 

Elia_pell said:

I found out the problem: the BASE0 and PREFIX0 address of tx and rx were different, and this cause the receiver to not receive data. This behaviour is pretty strange, because, as you can see from the code, no DAP or DAB has been written. Why this behaviour?

If the addresses were different (BASE and PREFIX registers), that is the reason why it didn't work. This is not the same as DAB/DAP registers.

"Device address match" is an extension to the address bytes in the payload, which is used by bluetooth LE for instance:

https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/radio.html?cp=4_2_0_22_11#concept_s3y_z2j_4r

 

Kind regards,

Håkon

[Elia_pell]

Hi,

So, if I understand well, the NRF_RADIO->TXADDRESS of the transmitter must match with one of the NRF_RADIO->RXADDRESSES of the receiver? (Here I'm talking about logical address, but of course BASEn and PREFIXn must match)

Moreover, I notice that changing BASEn and PREFIXn change the performance of the receiver: I mean that if the address is shorter is more likely to collect garbage in the air. Is this correct?

Thank you very much,

Elia

[Håkon Alseth]

Hi,

 

.TXADDRESS points to a index, where it can be between 0 and 7. The index it points to is the on-air RF address, which consists of the BASE + prefix byte, as shown here:

https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/radio.html?cp=4_2_0_22_1#concept_hz4_cjl_4r

 

you can point to any of the addresses (the index is local to the transmitter only), but; on your TX you have to send using a on-air address that matches one that the RX device is listening for.

 

Elia_pell said:

Moreover, I notice that changing BASEn and PREFIXn change the performance of the receiver: I mean that if the address is shorter is more likely to collect garbage in the air. Is this correct?

The RF address chosen has an impact, as well as the length of it.

Try to avoid sequential bit patterns, like 0xFFFFFFFF / 0x00000000, as well as addresses that start with a preamble like pattern.

 

If you see garbage received, try enabling CRC.

 

Kind regards,

Håkon