• State Verified Answer
  • Replies 10 replies
  • Subscribers 67 subscribers
  • Views 11354 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 101688
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NRF51 time synchronize sensors

pascal defesche

Hello,

I have some questions regarding bluetooth low energy and the NRF51 series. [list=1]1) I have to synchronise maximum 17 sensors, so i will maximum need 4 masters: 3 piconets connected towards one master. Is this possible with ble? In my opinion i see 2 possibility's to synchronise the sensors: let the host advertise, if sensornodes receive the advertisement packet start a timer. Or each connection interval let the host write a timestamp(with acknowledge) and let the sensors send their data(1 packet/ 7.5ms interval). [/list]

[list=2]2) The NRF51 series can handle 6 packets transmitting or receiving, so is it possible to do one normal write (so with acknowledge) to get in the same interval the ack packet back or will this always be the next interval? For example i took the picture from the nordic tour presentations in my attachments. At the second interval one packet transmits from master to slave and immediately after this the slave transmits one packet (can this packet be the acknowledge?). Or should i take in account the next interval i can only send 5 packet transmissions and 1 reponse(the acknowledge)? [/list]

Regards, Pascal

connection_interval.png

Parents
  • 0

    Thanks for your response. I have one more question regarding time synchronizing the sensors in a bluetooth network with 8 connections. I'm not going to use the broadcast method for synchronizing the sensors as i wont know if each sensor will receive this broadcast(no ack to application). With setting the central as broadcaster i can not switch roles to receive data from the sensors. Instead im going to establish connections with the sensors and use a write operation. In this way i need to know what the maximum send/receive delay will be between all sensors in the network. To make this clear i've added a picture,

    Ta, Ts and Trt are the ones that will differ in each connection interval as the radio can be occupied and Ts and Trt are unknown. My questions:

    1. Regarding the acces time(Ta): I know the bluetooth protocol uses radio acknowledgement, but if a transmission fails how many times will it resend this packet? Is it true it will try to resend the message next connection interval, because the radio will then hop towards another channel? In this way if i've set a connection interval of 1 sec, the timestamp send at 1s will be received at 2s or later if the radio channel was occupied.

    2. Is the delay in Ts and Trt always the same for each sensor?

    timing_considerations.png

  • 0 in reply to pascal defesche

    You don't get any timing guarantees at all with BLE, so it may be problematic to get absolutely exact time synchronization with this protocol. All data transmission is synchronized to the connection events, so depending on when you queue the data, the delay until it goes on-air may vary.

    Also, if there are already data queued, the old data will be transmitted first. If a packet is lost, it is retried infinitely, until it either gets through, or the link is considered lost (the supervision timeout after last successful packet transmission).

    As you can see from this, it isn't really possible to give an exact number for any of the parameters in your figure, since they will all depend on so many factors, but primarily on the connection interval. Using a short connection interval, it should be possible to get fairly accurate time updates, but if you use a longer interval, there may be quite significant delays in case of packet loss.

    You may have use in taking a look at the Time Profile from Bluetooth SIG: https://developer.bluetooth.org/TechnologyOverview/Pages/TIP.aspx

Reply
  • 0 in reply to pascal defesche

    You don't get any timing guarantees at all with BLE, so it may be problematic to get absolutely exact time synchronization with this protocol. All data transmission is synchronized to the connection events, so depending on when you queue the data, the delay until it goes on-air may vary.

    Also, if there are already data queued, the old data will be transmitted first. If a packet is lost, it is retried infinitely, until it either gets through, or the link is considered lost (the supervision timeout after last successful packet transmission).

    As you can see from this, it isn't really possible to give an exact number for any of the parameters in your figure, since they will all depend on so many factors, but primarily on the connection interval. Using a short connection interval, it should be possible to get fairly accurate time updates, but if you use a longer interval, there may be quite significant delays in case of packet loss.

    You may have use in taking a look at the Time Profile from Bluetooth SIG: https://developer.bluetooth.org/TechnologyOverview/Pages/TIP.aspx

Children
No Data
Related