• 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

    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.

Reply
  • 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.

Children
No Data
Related