Radio PCNF1 register settings

[Hiihtaja]

Hello !

1. In some legacy code I have found that radio channel is configured twice

NRF_RADIO->FREQUENCY = channel;

 

NRF_RADIO->DATAWHITEIV = channel;

Can it be some tail from some old fixes of some anomalies ?

in our system Data-whitening is configured once via PCNF1 register once.

I think this line NRF_RADIO->DATAWHITEIV need to be deleted.

2. In my system I should receive short 64 byte frame and after that after some microseconds - long 255 byte frame.

Can I update MAXLEN value in PCF1 register so often. e.g every ime when I initiate RX or TX operation ? e.g every 1-2 ms ?

If MAXLEN is set to 255, I can suddenly receive long frame and it ruin my timing.

If receiving started, it should take 64 bytes and generate END event.

 

Are any problems to update MAXLEN so often ?

Eugene

[Jørgen Holmefjord]

Hi,

1. What legacy code are you referring to? For BLE, the specification states that the data whitening should be set to the BLE channel. If you are using a proprietary protocol, you can set the whitening as you please, as long as it is set to the same on both ends of the radio link.

2. How is your radio configuration? Have you set the PCNF0->LFLEN field to 0? Usually this field is used to determine the length of the received packets. The reception will then end when the full packet is received, regardless of the MAXLEN configuration. Either way, it should be fine to update the field between each time you start the radio receive mode.

Best regards,
Jørgen

[Jørgen Holmefjord]

Hiihtaja said:

1. Yes this is proprietary radio and whitening enabled on both side.

I look around and find code https://github.com/iot-chalmers/BlueFlood/blob/master/examples/nrf-glossy/nrf-radio-driver.c#L74

where channel is written  to DATAWHITEIV register. Have it sense or not for nRF52840 ?

Like I said before, as long as you use the same whitening/de-whitening technique on both sides, it should be fine. How to handle this is part of your proprietary protocol. See more in Data whitening.

Hiihtaja said:

2. I mean the next state machine. I would like to receive 64 bytes during known timeslot. I have timer what cancel RX state at the end of timeslot. But if RX is really started, I would like to have END event after 64 bytes as fast as possible. Other side can send 64 or 255 but I need 64 and not willing to wait when END is appears after 255.

Depending on the configuration, reception will stop after the specified length, regardless of the value of the MAXLEN register, or when it reaches MAXLEN.

Hiihtaja said:

What kind of registers have sense to program for  stop RX at 64 bytes. If 64 have valid CRC , sw moving to the next state,

If you want to have a static payload length, you should set STALEN and MAXLEN in PCNF1 register. If you want dynamic length, you should set S0LEN, LFLEN, S1LEN in PCNF0 register, and include the length of the packet in the position where the LENGTH field in the packet. See more in Packet configuration.

[Hiihtaja]

Hi !

1.

I think here : https://devzone.nordicsemi.com/f/nordic-q-a/11640/nrf51822-raw-transmit-receive-not-working

"

// I'll use a fixed frequency of 2407 MHz for now.

NRF_RADIO->FREQUENCY = 7;

// BLE sets the data whitening IV to the same as the frequency. I assume there is a good reason.

NRF_RADIO->DATAWHITEIV = 7;

"

Can I assume this is BLE recommendations ? But any other proprientary radio can send any other IV what have sense and it should be equal on both sides ?

Regards,

Eugene