Multiple Peripherals accepting a packet from Central

[Royan]

I am building a WSN has several peripherals (custom nRF51822) and one central device (PCA10031 in serialisation connected to a PC and using the nrf51-ble-driver_win_0.4.0 driver). Each peripheral runs an accurate timebase derived from Timer 1. Once all peripherals are connected to the central, I need to synchronise the timebase of all peripherals to an accuracy of +-1ms. The timebase of all peripheral had been tested to be very accurate over prolong periods.

The best (and easiest) way under non-BLE situations to synchronise the timebase of all connected peripherals is for the central to send a single synchronisation packet as a "broadcast" to the peripherals. The peripherals would respond and react to the packet, but will not reply/acknowledge.

At present I am using S110 for the peripherals and S120 for the central. The synchronisation packet is sent to each peripheral, one after another, with a suitable offset computed for each peripheral (central starts a high resolution timer, sends a synchronisation packet to one peripheral with offset 0, waits for BLE_EVT_TX_COMPLETE, sends a synchronisation packet to the next peripheral with the timer value as offset, and repeats the sequence until all peripherals received the synchronisation packet). Unfortunately due to the many layers of software involved (especially on the Windows side), I am only getting +-5ms accuracy at present. Note that I can easily get sub-1ms accuracy in non-BLE conditions (I have been developing WSN systems for over a decade).

Based on what I have read here (excellent source of information) and other sources, it seems that the potential way to do so is to use S130 on all devices. Before trying this potential route (I am unsure if it would work) which is likely tedious to implement (the Windows driver does not even support S130), I would like to know if there are other way(s) of sending a packet from the central that would be accepted by all peripherals? Would using the L2CAP work?

Thanks in advance.

[Hung Bui]

@Royan: Using connection event to synchronize you may have to deal with the chance that the packet is retransmitted due to packet lost. In that case you won't have a very accurate time sync. From the applicatoin there is no way to detect if the packet is sent for the first time or it's a retransmited packet.

Could you let me know why you don't want to use proprietary protocol to synchronize the slave before switching to BLE ?

I assume your plan is to let the slaves run in scaning mode and receive advertising packet from the master to sync before switching back to normal role. I can see some challenge with this approaches:

• As described at section 4.4.2.2 Advertising Interval at Vol 6 Part B of Bluetooth Core Spec v4, there is a random delay added when advertising to avoid interference. The application has no control over this.

• You need to make sure you update the advertising packet with new timing on every advertising event.

My suggestion is either to use radio directly to send the synchronize packet, it could be either proprietary packet or could be a BLE advertising packet. You send and scan for advertising packet using the radio directly.

There is no protocol in BLE for the central to send packet to all peripherals it is connected to.

[Hung Bui]

@Royan: Bluetooth Core Spec v4.2 is already published.

I think for your application if you simply want to use the phone to sync the time on the peripherals what you can do is to leave the peripheral to advertise its current time (with no random delay), the phone capture the packet, compare the time on the peripheral with the current time on the phone. Then the phone connects to the peripheral, send back the time correction needed so that they can be synced.

I think doing it this way could eliminate the uncertainty (of retransmission when in connection) or random delay (of advertising).