This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

BLE timing questions

Hello,

I'm trying to time synchronize sensors with Bluetooth low energy. I've read a lot of theory in the bluetooth core v4.0 document and several other documents on internet but couldnt find the following things:

1) when master is connected with a slave and for example has a connectioninterval of 40ms. In this 40ms connection interval i can send / receive with a connected device(s) in multiples of 1.25ms.
At radio level there will be an acknowledgment with the SN, NESN bits. will this acknowledgement find place within this 1.25ms? so at master after TX the RX(after 150us(IFS)) contains the acknowledgement? 

2) Lets say if the channel is occupied and there could not take any transmission place resulting in a not acknowledgement. Now the next 1.25ms this packet will be resend? For how many times this process can take place? So how many times will the old packet be resend before it is considered lost?

I need to know this as i'm trying to send a timestamp from master towards slave, if this timestamp received at the slave will take for example 20ms because the current radio channel was occupied the timing will not be considered synchronous. Other sensors could be able to receive the timestamp within 1.25ms causing a ΔT between the sensors. All help will be appreciated.

I'm not using broadcast method were the master has to send a timestamp towards multiple sensors because afterwards the master needs to receive data from the sensors(this is not possible as the master should switch role).

Regards,
Pascal

  • Hi Pascal,

    1) During a connection event, you can send one packet at a time and the peer device must acknowledge (at Link Layer) this packet. If MD bit was set in the packet, it can send the next packet after the peer device has sent acknowledged which happens approximately 600us later (May be what you a referring to).

    2) If the transmission was unsuccessful, no further transmission will be made on this particular connection event (as the channel is probably bad). The next connection event happens based on the connection interval, which is 40ms in your case.

    Only one channel is used for a single connection event.

    Best Regards

    Joakim

  • Ok thanks for your very fast response!

    1) Lets say i'm connected with 8 devices within this 40ms interval. If the first packet towards sensor 1 was unsuccessfully transmitted, the packets towards the other 7 sensors will also be transmitted next connection interval? If so time synchronisation within millisecond range seems impossible with BLE.

    2) So next connection interval the packet will be retransmitted as it got nack before. Lets say the next channel is even occupied. How many times will this process take place before its considered lost? 

  • Hi Pascal,

    1) You cannot be connected to 8 devices with 40 ms connection interval. Each connection have it's own connection event, so you'd have to have a connection interval that allows one connection event for each slave during the connection interval. This is in a round robin fashion. If the packet is lost during one connection event for one slave, it will be transmitted on the next connection event for that particular slave (on another channel). Time synchronisation within singe digit millisecond range would be impossible in your case, i'm afraid.

    2) A packet will never be lost, it will be transmitted for every connection event until it's successfully ack'ed by LL of the peer device.

    Best Regards

    Joakim

  • Hi Joakim,

    Thanks for your support, this helps me a lot. I meant within each connection interval(40ms) the master can communicate with 8 slaves. If the old "lost" packet will be retransmitted next connection interval while a new timestamp packet was already available will the new timestamp packet be queued or considered lost?

    Regards,

  • Hi Pascal,

    If a data packet is sent from application layer after the (not sucessful) transmission of the "lost" packet,  the data packet will be queued after the "lost" packet. If the "lost" packet is successfully re-transmitted (now with MD bit set), the new data packet will also be transmitted in this same connection event.

    Best Regards

    Joakim

  • Thanks a lot for your explanation! Very well explained, could not specifically find it in the core V4.0.

    Regards,
    Pascal