Problems in the Implementation of TDMA Protocol with nrf52832

RE: Problems in the Implementation of TDMA Protocol with nrf52832

Håkon Alseth — Mon, 10 Dec 2018 09:17:51 GMT

When you start up the nRF24L radio, it will use 130 us to start up the PLL and other radio logic, before entering either TX or RX mode. Please see figure 4 in the nRF24L01+ datasheet for more detailed information about the different states in the radio.

Kind regards,

Håkon

RE: Problems in the Implementation of TDMA Protocol with nrf52832

liang — Fri, 07 Dec 2018 02:51:44 GMT

HI,

When the one node's radio is sending data, can other node radio go to ramp-up state?

Would you please to give us a brief description of the Radio ramp-up process?

RE: Problems in the Implementation of TDMA Protocol with nrf52832

Håkon Alseth — Thu, 06 Dec 2018 10:36:18 GMT

For nRF24L-series devices, the Radio ramp-up time is 130 us. You will use approx. 130 us + (0.5 us * 8 bit * 37 bytes) = 278 us to transmit/receive per payload.

Try extending your timeslot even further.

Kind regards,

Håkon

RE: Problems in the Implementation of TDMA Protocol with nrf52832

liang — Thu, 06 Dec 2018 02:41:28 GMT

HI,

1、The primary node broadcast a packet every 10 ms. After broadcasting the primer nods will transfer form TXIDLE state to RX state.

After receiving the broadcast packet, all the slave nodes will take 2ms to transfer from RXIDLE state to TXIDLE state. So it is not necessary to consider about the impact of the clock drift. Beacause the clocks of all the slave nodes are synchronized with the primary node every 10ms.

Repy to Q1：Yes, expending Rx window will improve the scenario，but there are still some nodes packets can not be received. We expend the time-slot to 250us.

Reply to Q2：Packets of some nodes are always not received in one package, while packets of the other nodes can be received in all. Pretty weird !!

Q1: Is the Rx packet Address matching done before the address event, or after? We are not sure.

Q2: We use Nrf24l01 as slave nodes, and nrf52832 as primary node.It seems that the communication is ok.

RE: Problems in the Implementation of TDMA Protocol with nrf52832

Håkon Alseth — Wed, 05 Dec 2018 10:32:46 GMT

Hi,

[quote user="liang"][/quote]

But We can not certain if there is a limit by 52832 radio config?

Would you please tell us if there are some default radio config that may cause this situation?

If the radio is in RX, and the configuration is equal on transmitter and receiver (ie: same channel, etc) and you are within range of each other, then it should receive the packet. You might ofcourse miss a packet every now-and-then, as there's no guarantees in wireless communication. This all depends on your own protocol is setup.

30 bytes in 200 us time frame is very short. Given that clocks drift over time, this window seems very low. If one clock source (transmitter) has a drift of -30 ppm, and the receiver has a drift of +30 ppm, this will account for a total drift between them of 30+30 us over a timeframe of one second.

30 bytes + address/preamble/CRC overhead + radio ramp-up time (40 us fast ramp-up, 130 with slow ramp up) will exceed (200-60) us.

Q1: Could you please try to expand your RX window on the nodes to see if this improves the scenario?

Q2: Does the other nodes always miss the packet, or is it "once every now and then" that they miss it?

Kind regards,

Håkon

RE: Problems in the Implementation of TDMA Protocol with nrf52832

liang — Wed, 05 Dec 2018 04:01:27 GMT

HI,

Thanks for your reply!

Yes, We can certain that all the sub-nodes can receive the broadcast at the same time.

We think that it's possible to transfer 30 bytes in 200 us if the data rate is 2m bit/s.

But We can not certain if there is a limit by 52832 radio config?

Would you please tell us if there are some default radio config that may cause this situation?

Thanks!

RE: Problems in the Implementation of TDMA Protocol with nrf52832

Håkon Alseth — Tue, 04 Dec 2018 12:40:50 GMT

Hi,

It sounds like there is a timing issue in the synchronization routine for each node. Are you certain that they are all in RX mode when the broadcast occurs?

A slot of 200 us might be too low. Have you tried extending this to see if this has an effect on the reception between the nodes?

Kind regards,

Håkon