Long range arduinos - Synchronised to millisecond?

Projects General Guidance
1

Hi,

I am building a timing system for amateur racing. The idea is to have two arduinos some distance apart communicating wirelessly (one at the start, one at the finish).

For timing to be accurate, the arduinos must be in sync. Desired accuracy is 5ms.
if the race is to last 6 hours, (21,600,000 milliseconds) then desired precision would be 0.25ppm (a lot!)
Lets say the system could be re-calibrated every 2 hours - then the minimum precision should be 0.75ppm (still very precise!)

I have initially planned on using Real Time Clocks. I have never worked with one, but it seems they dont provide milliseconds - no good.

Then I came across this. Using an accurate PWM to make a clock:
Make-an-accurate-Arduino-clock-using-only-one-wire
I ran the test with two arduino NANOs and I have lost 1.27seconds in 1 hour
Although the drift was relativery precise and after correction it was reduced to 28ms - but still too much in just 1 hour.

There are similar systems - but how do they stay in sync?!:
Wireless drag timing system

Any ideas what approach I could take to sync the arduinos accurately?

Thanks!
Mike

2

Perhaps use a GPS module at each end and have them use satellite time?

edit... not sure of the precision though

3

A great idea, havent thought of that!

I will try it out, and will post the results here

Mike

4

If I understand some stuff I found correctly, GPS time is hhmmss.ss so 1/100th of a second.

The library for that adafruit module decodes the NMEA sentences, but you'll need to look into the precision it decodes. If the time's there to 1/100th it must be getatable somehow.

5

I suspect the GPS solution is the most practical - but I don't know if they expose their most accurate timing to the Arduino.

Another thought (which would need a lot of experimentation) is to use a pair of wireless modules like the nRF24L01+ (assuming the chosen modules can work over the desired range) and have the master send the value of millis() to the slave every second. Assuming their is constant latency in the wireless system the slave could figure out a correction factor for its own millis() and add or subtract that to keep in sync.

...R

6

Just saw adafruit library does have GPS.milliseconds as an accessible time, and I'm printing it now.

edit: GPS.milliseconds seems to be "85" all the time, regardless of the length of time I set my loop() to. I used some weird millisecond values in the loop() timer to try force it to produce a time of other than "85" but no luck so far. Will investigate a bit further.

Perhaps as Robin2 said, the GPS.millseconds value is not exposed to us? Needs looking into.

(I'm curious though, why you're in the realms of milliseconds in a 6-hour event?)

7

Ok adafruit's doc just says the milliseconds are there in the sentence, and doesn't say anything about restrictions, and I am getting some values other than 85.

The milliseconds are visible here in the output from adafruit's echo sketch, as for example 091007.289 which is 289ms after 09h10.07 GMT.

$GPGGA,091007.289,,,,,0,00,,,M,,M,,*74
$GPRMC,091007.289,V,,,,,0.00,0.00,060117,,,N*40
$PGTOP,11,2*6E
$GPGGA,091007.489,,,,,0,00,,,M,,M,,*72
$GPRMC,091007.489,V,,,,,0.00,0.00,060117,,,N*46
$PGTOP,11,2*6E
$GPGGA,091007.690,,,,,0,00,,,M,,M,,*78
$GPRMC,091007.690,V,,,,,0.00,0.00,060117,,,N*4C
$PGTOP,11,2*6E
$GPGGA,091007.890,,,,,0,00,,,M,,M,,*76
$GPRMC,091007.890,V,,,,,0.00,0.00,060117,,,N*42
$PGTOP,11,2*6E
$GPGGA,091008.090,,,,,0,00,,,M,,M,,*71
$GPRMC,091008.090,V,,,,,0.00,0.00,060117,,,N*45
$PGTOP,11,2*6E
$GPGGA,091008.289,,,,,0,00,,,M,,M,,*7B
$GPRMC,091008.289,V,,,,,0.00,0.00,060117,,,N*4F
$PGTOP,11,2*6E
$GPGGA,091008.489,,,,,0,00,,,M,,M,,*7D
$GPRMC,091008.489,V,,,,,0.00,0.00,060117,,,N*49
$PGTOP,11,2*6E
$GPGGA,091008.690,,,,,0,00,,,M,,M,,*77
$GPRMC,091008.690,V,,,,,0.00,0.00,060117,,,N*43

So this seems doable?

8

manor_royal:

(I'm curious though, why you're in the realms of milliseconds in a 6-hour event?)

Its for amateur racing events. It is usually a two-part event - slalom in the first half of the day, and drag-racing afterwards. Each one of them typically runs for up to 6 hours, and the system could be recalibrated in between them.

Having 0.005s accuracy would be nice. Hence 5ms deviation in a period of 6 hours :slight_smile:

Thank you for your advice, I happen to have an adafruitGPS module and will try it out!

P.S: I followed this guide to build IR gates - its really good!:

IR PhotoTrap

Mike

9

So a competitor's time isn't 6h like say an ultra-marathon, it's lots of starts/ends over a period of 6h, where because the start and finish are not coincident, you have two Arduinos.

Well I reckon if you capture the start time on one GPS, transmit that to the other end for subtraction from finish time as captured from the other GPS, your times will be exact as near as possible, and each competitor's elapsed time will be consistently good over the course of the day.

10

Why 2 Arduinos? One Arduino can give the start signal to the competitors, and watch the arrival of the cars. Then it's only a matter to calibrate the Arduino clock, using e.g. a RTC module.

Race times typically are measured in elapsed time, between start and finish, not in time-of-day units. I don't see any need for a long-term stable clock for such an application. For a TOD display only hours and minutes are of interest, as can be obtained from any RTC.

11

DrDiettrich:
Why 2 Arduinos? One Arduino can give the start signal to the competitors, and watch the arrival of the cars. Then it's only a matter to calibrate the Arduino clock, using e.g. a RTC module.

Because the start and finish may be 1/4 mile (400m) apart (drag racing) with no physical connection between them.

manor_royal:
You are exactly right! there may be 100 unique runs of 15seconds each in a span of those 6 hours.
And having 2 GPS modules seems like a good solution.

2nd one ordered already, will keep you updated.

Mike

12

MikasU:
DrDiettrich:
Why 2 Arduinos? One Arduino can give the start signal to the competitors, and watch the arrival of the cars. Then it's only a matter to calibrate the Arduino clock, using e.g. a RTC module.

Because the start and finish may be 1/4 mile (400m) apart (drag racing) with no physical connection between them.

How is the begin of a race started? A start condition can be sent over a dumb RF connection with a delay of less than a microsecond on the receiver side.

13

DrDiettrich:
A start condition can be sent over a dumb RF connection with a delay of less than a microsecond on the receiver side.

Yeah that does make more sense than sending the actual start time for subsequent subtraction.

14

Use the 1PPS gignal from a GPS, the rising edge (at least I think its the rising edge) should be within a few uS of the UTC time second change.

The normal GPS time will get you within that 1 second.

15

srnet:
Use the 1PPS gignal from a GPS...

The normal GPS time will get you within that 1 second.

+1!

Recording the millis() or micros() of the RISING edge will let you calculate the exact millisecond (within one second) of the IR trip event, and the GPS fix will give you the exact hour/minute/second of the event.

BTW, when you see milliseconds like 85 or 289, it's probably running off the internal RTC. It doesn't have a good "fix" yet (poor satellite reception or cold start). Once the GPS device has a good fix, it always synchronizes to the start of a second (i.e., millis will always be 0).

If you set the update rate to 5Hz, the millis will always be a multiple of 200ms. You don't need to do that, because the PPS is only 1Hz. The millis() or micros() function gives you the offset from that pulse.

You might be interested in my NeoGPS library. It's smaller, faster and more accurate than all other libraries, and it could be configured to parse only the time field from an RMC message. This would save even more program space, execution time and RAM. If you want to try it, you can also get it with the Arduino IDE Library Manager, under the menu Sketch -> Include Library -> Manage Libraries.

The NeoGPS examples are also structured better, and can usually be modified without breaking them. The Troubleshooting page describes why a poor program structure can prevent it from receiving GPS data correctly.

I would also suggest that you connect the GPS device to pins 8 & 9 so you can use AltSoftSerial. SoftwareSerial is very, very inefficient because it disables interrupts for long periods of time. This can interfere with other parts of your sketch or other libraries.

If you really can't use those two pins, you should use my NeoSWSerial library. It's almost as efficient as AltSoftSerial, and it works on any two pins. It only supports baud rates 9600, 19200 and 38400, but that's probably what your GPS device uses.

Cheers,
/dev

16

DrDiettrich:
A start condition can be sent over a dumb RF connection with a delay of less than a microsecond on the receiver side.

I am interested to know how.

I thought there would be several microseconds, maybe even a few millisecs of latency between the "go" button and the message being received and understood. Of course it may be that the latency can be a known constant and can be allowed for.

...R

17

You are right with network protocol transmissions, where the negotiation of packages will take some time. But like with RC model control, there exist means to transfer a single signal state without any time consuming overhead.

18

If your logging the the 'Events' to memory or SD card, which is what you would want to do anyway for resiliance purposes, then the speed or availability of an RF link is not an issue.

Setting up a timing system which depends on an RF link being immediatly available and fully working would not be a good idea in my opinion. RF links do fail due to noise, the antenna being kicked etc.

19

DrDiettrich:
But like with RC model control, there exist means to transfer a single signal state without any time consuming overhead.

Who knows (or cares) what latency there may be in RC model control so long as it is reasonably constant. And AFAIK the modern ones use nRF24 modules or equivalent.

More importantly, there is no guarantee that a single signal will be received and I don't think it would be appreciated if, at the end of a 1500 metres race, the contestants were told "sorry, the start signal never came through".

...R

20

Robin2:
More importantly, there is no guarantee that a single signal will be received and I don't think it would be appreciated if, at the end of a 1500 metres race, the contestants were told "sorry, the start signal never came through".

+1