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

[Jørgen Holmefjord]

Hiihtaja said:

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 ?

Yes, DATAWHITEIV is just the initial value which needs to be know by both sides in order to reconstruct the data. The BLE specifications say this should be set to the channel number. For other protocols, you can set it as you like as long as it is the same on both sides.

[Hiihtaja]

Hi !

I think data-whitening is important feature and need to be ON all the time. But in proprietary radio better to avoid compatibility with BLE. For example register can be set to NRF_RADIO->DATAWHITEIV = channel +1; 

I case of compatibility, radio starts to receive BLE packets with valid CRC and they should be rejected as some alien packets.

Is this have sense ?

[Hiihtaja]

Hi !

2. About MAXLEN usage in my case when I should send/receive packets with 2 known MAX sizes 64 or 250 bytes.

Ble_2mbit radio mode in use.

I have set those values t0

#define NRF_LFLEN_BITS (8)

#define NRF_S0LEN          (1)

#define NRF_S1LEN_BITS (0)

#define NRF_CILEN_BITS  (2)

#define NRF_STATLEN       (0)

 as result length of the packet in the position where the LENGTH field in the packet.

In case if TX operation, MAXLEN can be set to 250 and LENGTH is set to exact value what need to be send.

In case of RX, MAXLEN is set to 64 or to 250 for limit MAX size of received packet.

So I can change MAXLEN and LENGTH only.

Is this scheme looks OK ?

Regards,

Eugene

[Jørgen Holmefjord]

Hi,

Hiihtaja said:

I think data-whitening is important feature and need to be ON all the time. But in proprietary radio better to avoid compatibility with BLE. For example register can be set to NRF_RADIO->DATAWHITEIV = channel +1; 

I case of compatibility, radio starts to receive BLE packets with valid CRC and they should be rejected as some alien packets.

Is this have sense ?

If you want to avoid receiving BLE packets, you should rather use a different access address than what BLE uses (0x8e89bed6). Then you will avoid having to do de-whitening on the packets that you do not get an address match on.

Hiihtaja said:

2. About MAXLEN usage in my case when I should send/receive packets with 2 known MAX sizes 64 or 250 bytes.

Ble_2mbit radio mode in use.

I have set those values t0

#define NRF_LFLEN_BITS (8)

#define NRF_S0LEN          (1)

#define NRF_S1LEN_BITS (0)

#define NRF_CILEN_BITS  (2)

#define NRF_STATLEN       (0)

 as result length of the packet in the position where the LENGTH field in the packet.

In case if TX operation, MAXLEN can be set to 250 and LENGTH is set to exact value what need to be send.

In case of RX, MAXLEN is set to 64 or to 250 for limit MAX size of received packet.

So I can change MAXLEN and LENGTH only.

Is this scheme looks OK ?

Yes, this sounds fine to me.

Best regards,
Jørgen

[Hiihtaja]

Hi Jørgen !

1. Could you please and provide more info about address selection. I can see in PS chapter

6.20.2 Address configuration

some splitting for address what need to be written to BASE0 and BASE1 registres.

On practice everybody use standard BLE address or IEEE specific one.

But what address range can be used if we would like to be as far as possible from known standard radios

but we use standard BLE 1,2,125,500 and IEEE radio modes ?

Basically packets what have different addresses are rejected without any extra events and do not generate any RX not OK or wrong CRC .e.g without any events. BUT they still occupy time slot,

our packet interfere to other packet and packet will be corrupted or not even received.

What about Wifi ? Is any BLE registers can have special values what minimize impact from it ?

I think all of those actions should increase reliability of our radio.

Regards,

Eugene

[Jørgen Holmefjord]

Hiihtaja said:

some splitting for address what need to be written to BASE0 and BASE1 registres.

On practice everybody use standard BLE address or IEEE specific one.

But what address range can be used if we would like to be as far as possible from known standard radios

You should be able to select any address not used by BLE or one of the other known protocols. However, you should follow these guidelines:

In general it is bad practice to start an address with either 0x00, 0xFF, 0xA or 0x5. 0x00 and 0xFF because they contain no bit shifts, and 0xA or 0x5 because they form a continuation of the preamble (the preamble is either 0xAA or 0x55). 

IEEE 802.15.4 does not use the address fields, as you can see from Receive sequence. It uses a preamble with synchronization header. IEEE 802.15.4 also uses different modulation, datarate, and channels than BLE/proprietary modes.

Hiihtaja said:

Basically packets what have different addresses are rejected without any extra events and do not generate any RX not OK or wrong CRC .e.g without any events. BUT they still occupy time slot,

our packet interfere to other packet and packet will be corrupted or not even received.

If the other protocol transmits the packet on-air at the exact same time as your protocol, there is chance that the signal will interfere anyways, preventing you from receiving the packet correctly. 

The radio will only start receiving a packet once it gets an address match, meaning other protocols will not "take time" from your radio. Only when a valid address is detected, the radio will continue receiving the payload and check CRC, etc.

Hiihtaja said:

What about Wifi ? Is any BLE registers can have special values what minimize impact from it ?

Wifi uses different modulation, datarate, and channels. The on-air signals may interfere with your wanted signal, but it should normally not cause address matches in the radio. BLE have placed advertising channels on the outside of most used WiFi channels, and implements frequency hopping on connections, to limit impact from other protocols/signals.