Problems in the Implementation of TDMA Protocol with nrf52832

[liang]

HI devzone

     We now use NRF52832 to implement TDMA protocol.

     In our application, there is one primary node and six sub-nodes.The communication process is as follows:

      After a primary node broadcasts a packet of data, all six sub-nodes receive the data of the primary node and reply to the data in different timeslot. This timeslot we now use 200us to transfer 30 bytes of data. The data rate is 2m bit/s.

      The problem is  that the primary nodes can not receive all the data reply from the sub-nodes. There are always 2 or 3 sub-nodes data can not be received.

    We can confirm that the interval between replies of the sub-nodes is accurate. We can not find out what's problem is, so help us, please!   

               Thanks!!!

[Håkon Alseth]

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

[liang]

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! 

[Håkon Alseth]

Hi,

 

 

liang said:

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

[liang]

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. 

[Håkon Alseth]

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