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.

[Johannes]

Hello Martin,

thanks for the very fast and detailed response. here are some follow up questions:

1. I didnt even think it feasible to make my own protocol. How much work is that, and are there examples available? I guess the protocol could be very simple since all it needs to accomplish is the time synchronization.

2. I just now found that ANT has some kind of time synchonization feature, so that would be an option, but I need to rely on off-the-shelf hardware and there are less choices available that support that

3. I am not really worried about latency or packet loss in the advertizing scenario, since I don't want the starter to be the master. Instead, I want to use a separate master to do the broadcasting. Therefore, any latency becomes irrelevant since all the nodes (both the start and the stop nodes) will presumably have the same offset to the master, eliminating this from the equation. Each node would calculate the offset from it's internal RTC to the master RTC and make this available through GATT so the android device can correct the raw values. The packet loss can be addressed by periodically broadcasting the synchronization message and then averaging the result on the receiver side. In this design, there is no communication from the start node to the stop node since each of them will be independently read out from the android device through GATT

There are some details to consider however:

1. when the master sends the advertizing packet, can I include the current time stamp in each subsequent broadcast so the clients know if they missed a packet
2. when the advertisement is received in the timer nodes, is there a straightforward way to get a precise time stamp when the packet was received by the radio? Again, it does not need to be accurate on an absolute scale, but the time should be reproducible in each node.
3. is is straightforward for each node to be both a GATT server and an advertizing receiver at the same time?
4. Since the nodes have to be paired with the android device which does all the further processing of the data, I guess the nodes have to also advertize themselves (at least until they are paired and connected with the android device). Can this also be done concurrently or does the device need to switch roles?

Thanks again!

[MartinBL]

Hi Johannes,

1. Depends how experienced you are I guess. You can probably look into ESB, but there is a challange in that it only supports 8 slaves. So you will possibly need to create 3 different networks.
2. The entire nRF5 series supports ANT.
3. I think we are about on the same page here.

Additional details:

1. Yes, you can update your advertising packets whenever you want.
2. Here is an overview of what kind of latencies you can expect to be induced by the softdevice. But as you can see the latency is <1ms. If all the nodes work in the same manner and don't service other asynchronous interrupts then this is probably the only latency you will get and it should be equal on all nodes.
3. Yes and no. I was writing my first reply under the assumption that you were using nRF52, but I see now that you ask about nRF51. The flagship Softdevice for nRF51, the S130, supports only 8 concurrent links. The nRF52 with the S132 Softdevice however, supports up to 20 concurrent links. You can also have one Advertiser or Broadcaster and one Scanner or Observer concurrently with the Bluetooth low energy connections.
4. Yes. The S130 can maintain one peripheral link and up to 8 central links concurrently. The S132 can maintain as many peripheral and/or central links as you want as long as the sum of the links is 20 or below.

[Johannes]

Thanks Martin, I was preferring the nRF51 due to larger variety of available form factors but I can switch to nRF52 if required. But, I thought that ANT is not available on the 51822, it requires a 51422 which is uncommon in off-the-shelf components.

So as far as concurrent connections go, I guess I am looking at the following situation:

1. The master node will be in broadcast mode all the time
2. the start and stop nodes will advertise themselves until they have the GATT connection to the android device, then they can stop advertising
3. the start and stop nodes need to be able to receive the broadcasts at the concurrently while communicating over GATT.

So the real question is can I have an Observer concurrently with with the GATT communication on the nRF51 or does this require nRF52

[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.