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.

  • \$\begingroup\$ You could do worse than transmit the raw accelerometer audio probably as FM from a pair of cheap 433ish MHz transmitters, and record both channels on a laptop. Start by simply displaying the waveform in Audacity. Time diffs should be easy to see. \$\endgroup\$
    – user16324
    Oct 7, 2020 at 18:43
  • \$\begingroup\$ I think it will be hard to get this device to work. You can use 2 NFC chips with better quality, this way the devices on the players will not require a battery, but you will need a detector, which has to know the line and when its crossed. \$\endgroup\$
    – CFCBazar
    Oct 7, 2020 at 18:51
  • 1
    \$\begingroup\$ Like I said, start by ... Having got there, you have a laptop to run a program making the decision on. I didn't think I needed to point that out. \$\endgroup\$
    – user16324
    Oct 7, 2020 at 18:55
  • 2
    \$\begingroup\$ You don't need to send a time "stamp" just send the event, radio and software are so fast compared to sports actions, and if you are really concerned you can just back up the apparent received time by the calculated packet duration and any fixed delays measured in a lab. The regenerative 433 Mhz systems are horrible, if you want 433 Mhz get an SPI-based radio, either something like an RFM69 or an nRF24 with the power amp (may even work without). \$\endgroup\$ Oct 7, 2020 at 19:46
  • 1
    \$\begingroup\$ If you're worried about lost packets, repeat the message several times after the event with a count that indicates the delay, eg, 0 = immediately 1 = 100 ms later, 2 = 200 ms later, etc. Also send an event number just to avoid confusion. \$\endgroup\$ Oct 7, 2020 at 19:48

2 Answers 2


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.

  • \$\begingroup\$ Thank you for your very detailed answer and breakdown of the different options, this is very helpful for our team, and we will now dig deeper into the usage of radio and attempt to make it work as you stated. We appreciate your help! \$\endgroup\$
    – vr86
    Oct 9, 2020 at 14:42

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.

  • \$\begingroup\$ The 32 kHz crystal typically has nothing to do with any microsecond clock. You'd need software to discipline one vs the other. And this whole thing is overcomplicated - the problem doesn't actually need synchronized timestamps when it has radio. \$\endgroup\$ Oct 8, 2020 at 13:22
  • \$\begingroup\$ How did you get 1.5mSec of drift? For 8 hours and 50ppm, I got 1.44 seconds which is way too much for this application \$\endgroup\$
    – Pangus
    Oct 8, 2020 at 13:22
  • \$\begingroup\$ The real key, if you want to use BLE (which would only be worthwhile for phone compatibility, and possibly marginal in range in the real world) would be to be able to get your fingers deep enough into the embedded side of the stack, that you could avoid retry transmissions being mistaken for originals so that you can actually have unique-in-time messages. A custom radio protocol more easily avoids that. \$\endgroup\$ Oct 8, 2020 at 14:28
  • \$\begingroup\$ No, all BLE setups do not have such a kHz watch crystal clock. The actual system and protocol runs off the main MHz clock. A slow clock is an optional add-on for things like an RTC or lower power during extended sleep. Pretty much any BLE chip has the on-chip oscillator, but that doesn't mean the board has the crystal or the software is making any use of it. And manual calibration is an unnecessarily oppressive requirement, which comes about only as a result of not leveraging what the radios can actually do. \$\endgroup\$ Oct 8, 2020 at 15:18
  • \$\begingroup\$ @ChrisStratton, you're right that the CPU clock isn't synced to the 32 kHz crystal. I've edited my answer to reflect that the timestamp should come from the 32 kHz timer chain, but that resolution of 30 uSec is still more than adequate. I don't agree that retry delays are an issue. Once the timestamp is saved in the device, it doesn't matter how many tries it takes to get it to the base or smartphone. I would argue that BLE protocol is far more interference-resistant than analog radios and outdoor range will be 100 ft or more. \$\endgroup\$ Oct 8, 2020 at 15:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.