• State Verified Answer
  • Replies 10 replies
  • Subscribers 67 subscribers
  • Views 11359 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

  • 0

    There is currently no way to make a network of 17 nRF51822s using Bluetooth low energy. Our Central softdevice can connect to 8 Peripherals simultaneously, but is a pure Central device and can not also be a Peripheral. Max network size with this is hence a total of 9 devices.

    However, S120 can scan in addition to these 8 connections, so if you can do with only receiving broadcasts, you may be able to get something working. Also, if you can instead use a proprietary protocol, creating a network of 17 devices with Gazell or ESB should not be a problem.

    No matter which protocol you use, there isn't any built-in mechanisms of synchronizing time, so this is something that you'll most likely have to implement on your own anyway.

    As for the latter question, this depends on what kind of ack you mean. All packets sent over a BLE link is radio-level ack-ed, and this ack will always be done with the next packet over the link. However, if you mean the application-level ack that you get with Write Requests (i.e. the Write Response), or with Indications (the Handle Value Confirmation), these are sent by the application, after it has received the Request/Indication. Passing the packet up the application and getting the Response/Confirmation back will take some time, and this will not happen in time for same-event transmission. Such will hence only be transferred in the next connection event.

  • 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

  • 0

    i have one more question about the attached picture. Is it possible for the master to TX/RX(1,25ms) with multiple devices within one connection interval? for example having a connection interval set to 10ms the master should be able to communicate with 8 devices(multiple connection events in one connection interval)? Or is it only possible to TX/RX with one device within a connection interval? So after 80ms all devices have been communicated to.

  • 0

    Thanks for the link and support! I've posted one more question regarding BLE as a comment in my first post, hope someone can explain this to me.

Related