Wireless Time Synchronization Project

Question

I am part of a team project involving baseball where we would like to determine whether a runner stepped his foot on the base (first base, for example) before or after a fielder (the first baseman) catches the ball, and then make the correct call of out or safe depending on which event happened first.

We know that relative time synchronization is the core of our project, and we also know that we will need 2 modules - one module on the first baseman's glove or wrist (to determine when the ball was caught), and another module on the first base itself (to determine when the runner stepped on the base). We plan on having an accelerometer in the glove module, and a force sensor on the base module.

My question is, what is the best way to wirelessly transmit the timestamps of the event between the two modules? In our scenario, we would like the glove module to transmit the timestamp to the base module (glove=sender, base=receiver), so we need some sort of wireless communication that also has very precise time syncing (less than 10 milliseconds accuracy, preferably).

At the moment, we are looking for some sort of microcontroller or development board that can accomplish this. Current candidates are the CC3220SF and CC2540, but if anyone knows of a better solution, it would be much appreciated.

Answer 1

You seek to determine the relative timing of two events by the usage of radio.

While one mechanism of doing this would be to synchronize clocks and transfer timestamps, to do that you would first needs a mechanism for synchronizing clocks by radio; and if you had that you could simply use the mechanism directly for the events of interest.

So imagine a transmitter, which at the instant of catching starts a local millisecond counter. It will then encode a series of packets, each containing both an event number, and the amount of time elapsed from the triggering event to a given packet, eg the first packet would be event 1, 10 millisecond delay. And then next perhaps event 1, 60 millisecond delay, then event 1, 110 milliseconds, and so on. Either send enough packets that you are sure that one gets through, or until you receive in response an acknowledgement from the other end of the radio link.

At the receiving end, you will also detect the time of an event, and record that time according to some local relatively rate-accurate clock, but with no need to know any absolute time. When you receive an event report, you record the time at which the packet is received. Then you subtract the since-event delay encoded in the packet, and also a calculated or pre-measured packet duration, and any pre-measured system latencies of significance. If your transmitter will keep sending until it gets an ack, then send it back an ack referencing the appropriate event number. Make a comparison of the calculated remote time to the local time, and declare the winner. The same idea can be used to compare two remote senders, instead of a remote with a local.

Hardware wise, you want a radio that has likely chance of covering the distance, can encode 5-10 bytes of information in a packet of short time duration, and ideally offers bi-directional capability so that you can send an ack back. In practical terms, it will be far easier to develop this with an SPI-connected digital packet radio chip, probably using some variation of FSK modulation. Additionally, to make the individual packet delay stamps work, you'll need direct control of the packet assembly at low level, rather than be handing application messages off to a stack (eg, you need something UDP-like rather than TCP-like).

There are a variety of candidate bands depending on regional regulations, eg 433 MHz, 868, 915, and 2.4 GHz. All of these are supported by a variety of radios, and many of those have some support in the "RadioHead" library which would be a good starting point for trying possibilities. Some particular ideas to consider would be an RFM69, or possibly a 2.4 GHz nRF24, at least in a module with a power amp. To some extent, the overall scheme can be radio agnostic and could be ported to different hardware.

BLE radios as mentioned by Mark Levitt are potentially a possibility, and do have the advantage that a smartphone could be used for scorekeeping. Yet they also present a few challenges. One is that they will have somewhat shorter range than a lower frequency system might. Another and perhaps more serious is that it may be hard to put a unique "time since catch" in each individual packet, as in connected modes the BLE stack would automatically retry something that didn't get through, with the exact same data as before. One might consider something like the vertically open source Apache MyNewt stack on nRF52 hardware rather than typically closed-source vendor BLE stacks. It may be relatively easier to "hack" a stack to use BLE advertisements to emit single unique packets - there is some published work on advertisement based BLE clock synchronization. It could also be possible to use a semi-custom 2.4 GHz scheme to work out the actual timing, and then turn around and use the same radio to send the results to a phone.

Another option that might enter into a conversation would be LoRa chips like the S127x/RFM9x which go for around $10 on a module. The actual LoRa modulation modes of these are generally for yet longer range needs with packets sent at a slower data rate, but something like SF6 at 500 kHz bandwidth is likely useably fast; the chips also support FSK modes comparable to those of an RFM69. Likely going this route simply increases cost with little benefit, though if cost isn't particularly a concern its worth mentioning that the multi-channel LoRa "concentrator" chips used in $100+ LoRaWAN gateways can receive multiple signals at the same time, and tag each packet in hardware with a microsecond timer, which would make comparison quite simple (for simultaneous reception you would be limited to SF7 @ 125 kHz as the fastest mode however). Apart from decreasing conflict between multiple senders (do you need to outfit the whole field team?) it's not obvious that this would be worth the money.

@CFCBazar mentioned NFC earlier, and while that wouldn't work for transferring data across even the infield, it could potentially be used as a sort of "proof of possession" of the ball. However even then, it may take some engineering to make a system which can't be cheated in terms of timing by slapping your glove just before catching and detecting an NFC tag in the ball.

That then raises the idea of putting one of of the timing transmitters in the ball itself. In a way this is cheaper, since you don't need to outfit the whole team, but it's probably fairly tricky engineering in practice, it's not entirely clear the reference crystal will survive the bat, and of course any pretense of being regulation equipment would be a long process of testing and approval away.

Answer 2

Thank you for bringing up an interesting, practical problem to solve! You have some interesting ideas in the comments, but here is the approach I would take.

1. Use Bluetooth Low Energy for your radio protocol. Adequate range, low power consumption for battery operation, software platform options from C to Javascript to Arduino, and a choice of packaging from breadboard-ready PCBs, modules, to bare chips. The Bluetooth chips have more than adequate CPU processing power and speed, and you won't need a separate MCU on either end.

2. All BLE chips have an internal clock with about a 30 microsecond resolution (they run at 32.768 kHz), which can drive an internal counter. You don't need to match these counters to actual time-of-day; they will report ticks since the device was booted up. When the sensor in the mitt is triggered, record the internal mitt clock time. When the sensor in the base is triggered, record the internal base clock time.

3. I'd make both devices BLE peripherals, reporting to an app on a smartphone that connects to both of them as a BLE central. When the app gets a report from both peripherals, note those two times. You don't have to worry about the latency of the transmission delay -- this only affects how quickly you get the report.

4. Now you just need a calibration approach. At the beginning of the game, whack the mitt against the base, so both sensors are triggered at the same time. In the app, observe the two clock readings, and memorize the difference. This is the "offset" when the sensors are triggered simultaneously. By subtracting it, you can tell the relative delay between the two events.

5. Will the clocks stay synchronized well enough? For typical +/- 50 ppm BLE 32.768 kHz clock crystals, this represents a potential error of +/- 0.18 seconds over one hour. So it might be best to repeat the calibration before each inning, which also tests that everything is working.