synchronized stop watch application

[Johannes]

Hello,

I am rather new to BLE and the NRF5x.

I want to build the following application: a swim timing sytem. The system consists of master timer with a high precision RTC. Then there are 19 nodes which register external GPIO (basically a button push). one acts as a starter, the other 18 are act as stop buttons operated by humans.

The basic idea is that each node records the time when the button is pushed, and this can later be read out by a Android phone or tablet. One issue is to keep the clocks in each of the nodes synchronized down to < 5 ms.

Can this be done with 20x 51822 modules?

I assume the readout of the button time can be achieved with GATT, but what protocol would be appropriate for the clock synchonization? Can one of the nodes send out a broadcast every few seconds, and can the other nodes pick up this signal with a reasonably accurate timestamp to generate an offset to the internal RTC?

Any pointers will be appreciated.

[MartinBL]

Hi,

Readout of results can certainly be done with GATT, but the challenge is the synchronization. Here are my two cents:

• Your best option is probably to make your own proprietary radio protocol to get things synchronized at the begninning. The BLE specification will put several obstacles in your way introducing a lot of potential latencies in your system. With a proprietary system you can:

1. Send as many packets as fast and as often as you want.
2. Send the packets on whatever radio channel you want.
3. This makes it easy for you to make all the nodes listen for start or synchronization beacons. Latencies less than 5ms shouldn't be a problem.
4. After the system has started you can switch to BLE communication to receive data.
5. It is also possible to run BLE and proprietary protocols concurrently opening for possibilities of sending synchronization beacons at regular intervals while in a BLE connection.

• Use BLE advertising:

1. Set up your starter as a peripheral.
2. Configure it to advertise on a single advertising channel.
3. Have all your other nodes scan continuously on the same channel.
4. Start advertising with your starter the moment the button is pushed.
5. Assuming there are no packet losses then all nodes should receive the packet in sync.
6. In case any nodes miss the first advertising packet you will have trouble though, since you are only allowed to advertise every 20ms according to spec and there is a 10ms random time delay on top of that.

• Using BLE and GATT: I suppose it is possible to

1. Use your starter in central role and keep it connected to all 19 peripherals at all times.
2. When your starter button is pushed, start the central's RTC.
3. Use the lowest connection interval possible and service each peripheral in a Round Robin scheme.
4. As the RTC keeps running, let the central send updated RTC values to the peripherals.
5. Let the peripherals have their own RTC running, but update it on each connection interval when they receive an updated value from the central.
6. The uncertainties here will be: The time it takes from the central reads the RTC value until the value is transmitted, possible packet loss, the time it takes from the peripheral receive the packet until it updates the RTC counter.
7. The benefit is that your central and peripherals are synchronized multiple times making the system more robust against packet losses.

[MartinBL]

You are right of course. I forgot that the nRF51822 doesn't support ANT. Are you aware of the new nRF52810? It's a cheaper, reduced-feature-set version of the nRF52832. It has a larger footprint than the smallest nRF52832 though, if you worry about the size.

Yes, the S130 and nRF51 supports one observer concurrently with up to 7 BLE links. I don't know how you plan on doing it, but remember that you probably won't be able to have 19 concurrent BLE connections with an Android phone.

[Johannes]

Hi Martin I was making big progress over the last few days.

for the Time master broadcast, I tried using the radio notification feature which will give me a callback a few hundred milliseconds before a transmission occurs, and then I modify the advertising data to include a current time stamp. This seemed to work, even though I have not yet measured the latency on this just yet. I just wanted to confirm that this is the correct approach? I also noticed that the radio even seems to occur more often than the advertising interval would suggest. I am not entirely sure what is causing this, maybe the softdevice is responding to some external requests. Maybe you can give me some hints as to how to disable that

secondly, I got my GATT server with notifications working using MBED, but now I would like to also use the broadcast observer at the same time and I want to port this to Keil and softdevice. However I could not really find a suitable example in the sdk. Which one would you recommend?

It also seems that the links to the totorials in devzone are broken after the site migration which complicates matters at this moment

Johannes

[MartinBL]

Hi. Sorry for the late response. I have been out of office for a while.

Johannes said:

I just wanted to confirm that this is the correct approach?

I think this is a reasonable approach.

Johannes said:

I am not entirely sure what is causing this, maybe the softdevice is responding to some external requests.

You might get notifications both before and after radio events. Here is more info about the events and timings: Radio Notification.

Johannes said:

However I could not really find a suitable example in the sdk.

Maybe the Experimental: BLE Relay Example? It is probably a bit more advanced than what you need, but at least it shows you how can scan for device and while acting as a peripheral concurrently. 

Johannes said:

links to the totorials in devzone are broken

I'm not sure where they are located now actually, but you can search for tutorials in the search box. Here is a particularly relevant tutorial: Radio Notification.