GPS Disciplined Clock for Arduino

[raptor1956]

I'm toying with the idea to make a camera (DSLR) controller using an Arduino module but with the addition of a GPS disciplined clock so I can fire the shutter within a few msec of a specified time.  More precisely, to be able to take a sequence of images at a set interval and within a few msec of a whole second relative to GMT.  So, the only piece I need some info on at this point is the GPS disciplined clock and what options are there.  Can a handheld GPS receiver be counted on to be within a few msec and to remain that way over time?  What about a cheap module that I can wire up to comm with an Arduino?  Again, I need a few msec so nsec or even msec is not needed, but it needs to always be within a few msec. 


Brian

[hamster_nz]

Yes, it should de possible. Most GPS modules have a pulse per second (PPS) output that is very accurate (much better than a millisecond, and even microsecond).

If I was to attempt this, my first attempt would be to watch the serial output to check that the module is locked and then look for a timestamp in the stream that arms the trigger, causing it to switch over to watching for  the PPS output,.  Once it sees the rising edge it wpuld then fire the trigger the required number of.ms later (based on local MCU's clock)'.

Latency within the SLR would be a big  unknown though...

What do you need millisecond accuracy for?How do you know what you a photographing? Satellite/ISS transits of the sun?

[iMo]

With cheapo modules like NEO-7M you may set 1 - 10 time information strings per second (nmea text or ublox binary). The default Tx speed is 9600, I would set it at least to 115k2 to get more time for parsing the string.

[james_s]

It just so happens I've been working on a GPS disciplined clock the past few days. Mine is based closely on this.


 http://w8bh.net/avr/clock2.pdf

[hamster_nz]

Nice clock!

Are you syncing with the PPS pulse, or the serial stream (that is slightly delayed)?

[iMo]

It just so happens I've been working on a GPS disciplined clock the past few days. Mine is based closely on this.


 http://w8bh.net/avr/clock2.pdf

By the time the data is received and decoded, it is already old!
Even the fastest microcontroller and display are at the mercy of this delay

Nice project!
You may limit the amount of information a GPS module sends out periodically. I think the "parsing time and date information" with the slowest arduino cannot take more than 1ms. With Tx baudrate set to 115k2 (for example) you may get 997ms of free timespace each second.

[james_s]

Nice clock!

Are you syncing with the PPS pulse, or the serial stream (that is slightly delayed)?

It syncs with the 1pps signal, it decodes the time string, adds 1 second, then updates the display the moment the 1pps signal occurs. It's bang on within the precision of anything I have to compare it to. I'm working on another version that displays tents of a second on an LED display.

[raptor1956]

It just so happens I've been working on a GPS disciplined clock the past few days. Mine is based closely on this.


 http://w8bh.net/avr/clock2.pdf

Thanks James, that is very helpful. 


Brian

[raptor1956]

Yes, it should de possible. Most GPS modules have a pulse per second (PPS) output that is very accurate (much better than a millisecond, and even microsecond).

If I was to attempt this, my first attempt would be to watch the serial output to check that the module is locked and then look for a timestamp in the stream that arms the trigger, causing it to switch over to watching for  the PPS output,.  Once it sees the rising edge it wpuld then fire the trigger the required number of.ms later (based on local MCU's clock)'.

Latency within the SLR would be a big  unknown though...

What do you need millisecond accuracy for?How do you know what you a photographing? Satellite/ISS transits of the sun?

I can't be more specific just now, but, yes, the latency of the DSLR would have to be taken into account.  First off you shoot in manual exposure and focus modes so that doesn't effect the latency, and then it's a matter of actually measuring what the latency is.  I think having an LED array that strobes through at a known rate and synced with the clock would do that -- I would not trust an LCD display for this.  The value could then be refined with a little pinching, but, again, a few msec is sufficient.


Brian

[hamster_nz]

What sort of.shutter do DSLRs have nowdays? Whrn I was keen on photography my SLR  had shutter that uncovered.the.film,.and another followed shprtly after to cover the film.

Short exposures would actually be more like a moving slit, causing odd artifacts with very fast moving objects (e.g. propellers).

A quick google finds : https://www.premiumbeat.com/blog/3-tips-for-dealing-with-rolling-shutter/

[Domagoj T]

What sort of.shutter do DSLRs have nowdays? Whrn I was keen on photography my SLR  had shutter that uncovered.the.film,.and another followed shprtly after to cover.the.fil.

It's the same.


Advice for OP, if it's possible, you may get (much) better timings by putting your subject in total darkness, opening the camera shutter before the intended moment of image capture, and when the moment arrives, trigger a flash, then close the shutter and you've got your image.

[james_s]

Using that technique with an air flash tube that produces an extremely short pulse of light can create some stunning stop motion photos.

[NivagSwerdna]

Short Answer:

NEO-6 modules are cheap now and offer...

Accuracy for Timepulse signal RMS 30 ns
99% <60 ns

You can use the serial i/o to get the time and then the PPS to get the following edge

Long Answer:

If you start caring about very small time differences then factors such as antenna cable length, satellite views and position-hold start creeping in.  There are receivers eg the 6T which are optimised for time transfer.
 
Sounds fun. Please keep updating as your project progresses.

[Domagoj T]

Using that technique with an air flash tube that produces an extremely short pulse of light can create some stunning stop motion photos.

Yeah, but air gap flash gets comfortably into scary territory. Regular xenon speedlights are still fine for high speed photography. They won't catch bullets, but will capture BBs and pellets from an air gun. Water droplets are also a good subject.

Anyway, I only mentioned the technique because I think triggering a flash is faster than triggering a camera, but since we don't know the purpose of the project, we can only guess...

[raptor1956]

What sort of.shutter do DSLRs have nowdays? Whrn I was keen on photography my SLR  had shutter that uncovered.the.film,.and another followed shprtly after to cover the film.

Short exposures would actually be more like a moving slit, causing odd artifacts with very fast moving objects (e.g. propellers).

A quick google finds : https://www.premiumbeat.com/blog/3-tips-for-dealing-with-rolling-shutter/

Yes, a modern DSLR uses the reflex mirror and then a dual curtain shutter (one to open and the other to close) and for short duration exposures the shutter is never fully open as the curtains move in unison providing a slit that varies with the shutter speed.  And yes, that could effect things and should be tested to understand better.  An array of ten LED's providing a 10-bit counter operating a 1kHz would allow you to see what the latency is and by moving the array to different parts of the FOV would allow you to calculate the actual shutter speed -- the speed the shutters move at.

The newer mirrorless cameras do away with the mirror and some also do away with the mechanical shutter, but the read out of the CCD/CMOS sensor isn't instantaneous either. 

I should mention that the thing of interest will likely be no more than 10% of the vertical and 7% of the horizontal FOV so if the shutter takes, say, 20msec to travel the slit would traverse the object of interest in a couple msec.


Brian

[texaspyro]

Here are the results of measuring the difference between the time code in
a GPS receiver time message and the arrival time of the last byte of
the message.  POSITIVE values mean that the receiver sends the timing
message AFTER the 1PPS pulse that it describes. The table also shows the
standard deviation of the message arrival times.



The test configuration was a Compaq N610C laptop (2 GHz Pentium, hardware
serial port) running Linux Ubuntu Mate 15.10).  The time of the message
arrival was from the system clock synced to NTP.  The receivers were tested
in native binary protocol and, if supported, NMEA.  The com port was running
at the default value for the receiver.  If not specified that was 9600:8:N:1
Data was collected after the receiver had been tracking satellites for at
least 1 hour and averaged over 4 hours.  The timings were also checked and
agree with those on a Raspberry PI 3 and a quad-core 3 GHz box.



Although measuring the arrival time of the first byte of the timing message
makes more technical sense (less variation due to timing message length and
baud rate) these measurements are of the last byte of the message.  This was
chosen to assist people trying to sync a clock to a GPS receiver without
relying on the 1PPS pulse.  They are also useful to people that want to know
how long they have to process a timing message (like to set a sawtooth
compensation delay line) before the next 1PPS pulse comes out.



A few receivers appear to not fully sync their timing message to some reference
clock.  This causes the timing message arrival time to follow a ramp curve.
The ramp size is fairly small in most receivers.



Device         Protocol         Firmware          (msg-arrival)  sdev

                                                     (msecs)

=============  ============    ================      =========   =====

Thunderbolt     TSIP            App:3.0 GPS:10.2        43.7 *    6.2   (gold box)

Thunderbolt     TSIP            App:2.22 GPS:10.2       54.6 *   10.2   (red box)

Resolution-T    TSIP            GPS:1.26                99.4 *    5.4

Res-T SMT       TSIP            GPS 2.7                393.2 *   63.7

Res-T SMT       Motorola(12ch)  HW 3010 SW:0.03.0      519.7 *   49.1

Starloc II      TSIP            App:1.10 GPS:1.2       266.0 *    7.2

Nortel NTBW50AA TSIP            GPS 10.4                60.8 *    1.2   (made by Trimble)

Nortel NTGS50AA TSIP            GPS 10.5                50.8 *    2.4   (made by Trimble)

Nortel NTPB15AA TSIP            GPS 10.1                62.8 *    1.4   (made by Trimble)

Nortel NTPX26AB TSIP            GPS 10.1                59.8 *    1.4   (made by Trimble, aka Nortel GSPR)



NVS NC08C-CSM   BINR 115.2K     CSM24 04.08 20/10/14    40.7 *    7.3


Brandywine GPS4 ASCII/NMEA                             750.1

HP5370          SCPI                                   330.0

TruePosition    ASCII                                   32.5

Nanosync 380    ASCII                                   65.0

RFTG-m          TSIP                                   -663.

Star-4          ASCII                                  215.0

SV6             TAIP                                   -175


Ublox LEA-6T    binary          6.02 (36023)           206.0 *    4.4

Ublox LEA-6T    NMEA            6.02 (36023)           144.5 *   11.1

Ublox Neo6M     binary          7.03 (45969)           197.1 *    9.3

Ublox Neo6M     NMEA            7.03 (45969)           137.6 *    8.4

Ublox 7         binary          1.00 (59842)           178.4 *    2.6

Ublox 7         NMEA            1.00 (59842)           146.2 *    7.9

Ublox NEO-8M    binary          2.01 (75350)           207.7 *    9.1

Ublox NEO-8M    NMEA            2.01 (75250)           181.2 *    8.0


V.KEL SIRFIII   binary          GSW3.2.5               417.0 *    6.1

V.KEL SIRFIII   NMEA            GSW3.2.5               385.0 *    5.0


Navspark Mini   bin+NMEA 115.2K 1.7.27 15.8.18         170.8 *    7.1

Navspark NS-T   bin+NMEA 115.2K 2.1.05 15.1.29         153.8 *    7.1  (Venus 822T)

Venus 838T      bin+NMEA 9600   2.1.05 15.1.27         208.3 *    7.5  (Venus 838T)

LTE-Lite        NMEA            (newer firmware)       252.1 *   27.7


Adafruit Ultimate  NMEA                                461.9 *   49.8


Skylab SKM53    NMEA                                   149.0 *   37.8  (actual value is not stable -100 .. -500 seen)


Jupiter-T       Zodiac          93.07                 1245.5 *    3.3

Juptier-T       Motorola(8ch)   93.07                  284.5 *    3.2

Jupiter Pico    Zodiac          14.00 11/28/05        1232.2 *    0.4  (ramps -1225 .. -1245 over 130 minutes)

Jupiter Pico    Motorola(8ch)   14.00 11/28/05         295.1 *    1.8


Motorola UT+    Motorola        R5122U1112             260.5 *    3.7

Synergy M12+    Motorola        P273T12T11             208.5 *    1.4 


Z3812A          SCPI            X98-4-A               -949.6 *    0.8  (ramps 945 .. 955 over 16 seconds)

Z3801A          SCPI 19.2K      3543A                 -979.8 *    2.0

Symmetricom     UCCM-P 57.6K    1.0.0.2-01             127.1 *    3.6  (ramps -122 .. -132 over 10 seconds)

Trimble UCCM-P  UCCM-P 57.6K    2.0.1.6-01             281.0 *    3.2

Trimble UCCM    UCCM 57.6K      3.0.0.11-0             286.2 *    3.1

[NivagSwerdna]

I have played a lot with VP Oncores in my time and the specification defines the relative position of the PPS and the serial data.  Indeed where the receiver is due to send multiple serial messages during a 1 second interval some messages may be deferred into the following seconds (when the data exceeds 750 bytes).   The first byte of the message is sent somewhere between 0 and 50ms after the measurement period but the time message @Ea itself may be ordered after(?) other messages.
There is probably more to this than meets the eye... i.e. I would not expect at @Ea message to get deferred due to other traffic but the specification is vague on that point.
The upshot of this is that you need to detect to PPS edge otherwise you are subject to large amounts of jitter.  If your requirement is +/- 1 second then you can use just the messages

[iMo]

With cheapo modules like NEO-7M you may set 1 - 10 time information strings per second (nmea text or ublox binary). The default Tx speed is 9600, I would set it at least to 115k2 to get more time for parsing the string.

Except that you may, for example, configure the NEO-7M which messages will be sent out (configuration via the ublox control center app). You may send out, for example, 16-20bytes of payload only, up to 10x per second, the message should include (except the time info) the fractional part of a second in ns. Thus you may predict when the 1PPS comes out. Moreover, you may set the 1PPS to any value from 0.25Hz-12MHz (with some issues we discussed in an another thread).

[hamster_nz]

Just had a look at specs for a Nikon D5300. The flash sync speed (the speed at which the entire sensor is exposed at the same time, so you can use a flash) is 1/200th of a second.

At higher shutter speeds the entire sensor will never be exposed at the same time.

Measuring when the hot-foot for the flash fires would be a good way to determine the camera's latency to the external trigger, without needing to resort to taking photos of LED arrays.

[tooki]

Just had a look at specs for a Nikon D5300. The flash sync speed (the speed at which the entire sensor is exposed at the same time, so you can use a flash) is 1/200th of a second.

At higher shutter speeds the entire sensor will never be exposed at the same time.

FWIW, the D5300 is a fairly low-end camera, most DSLRs have 1/250s x-sync. But with digital, the mechanical shutter can be combined (or altogether replaced) with an electronic shutter. The D70/D70s and D40 do this to allow 1/500s x-sync officially, but if you defeat the flash “smarts” (by covering the data contacts) and use it as a dumb hot shoe, you can use flash x-sync all the way to 1/8000s!

Measuring when the hot-foot for the flash fires would be a good way to determine the camera's latency to the external trigger, without needing to resort to taking photos of LED arrays.

You mean hot-shoe? (That did make me chuckle, though! )

But regardless, using the x-sync contact to identify the shutter lag is a brilliant idea!!!! The only potential “gotcha” is the trigger voltage, which can be quite high, in theory. On newer cameras, they expect to be used with a matching smart flash unit, and those tend to use 5V or less. Nonetheless, I’d try and measure it somehow.

[eliocor]

table reformatted for an easier reading:

Code: [Select]

Device         Protocol         Firmware          (msg-arrival)  sdev
                                                     (msecs)
=============  ============    ================      =========   =====
Thunderbolt     TSIP            App:3.0 GPS:10.2        43.7 *    6.2   (gold box)
Thunderbolt     TSIP            App:2.22 GPS:10.2       54.6 *   10.2   (red box)
Resolution-T    TSIP            GPS:1.26                99.4 *    5.4
Res-T SMT       TSIP            GPS 2.7                393.2 *   63.7
Res-T SMT       Motorola(12ch)  HW 3010 SW:0.03.0      519.7 *   49.1
Starloc II      TSIP            App:1.10 GPS:1.2       266.0 *    7.2
Nortel NTBW50AA TSIP            GPS 10.4                60.8 *    1.2   (made by Trimble)
Nortel NTGS50AA TSIP            GPS 10.5                50.8 *    2.4   (made by Trimble)
Nortel NTPB15AA TSIP            GPS 10.1                62.8 *    1.4   (made by Trimble)
Nortel NTPX26AB TSIP            GPS 10.1                59.8 *    1.4   (made by Trimble, aka Nortel GSPR)

NVS NC08C-CSM   BINR 115.2K     CSM24 04.08 20/10/14    40.7 *    7.3

Brandywine GPS4 ASCII/NMEA                             750.1
HP5370          SCPI                                   330.0
TruePosition    ASCII                                   32.5
Nanosync 380    ASCII                                   65.0
RFTG-m          TSIP                                   -663.
Star-4          ASCII                                  215.0
SV6             TAIP                                   -175

Ublox LEA-6T    binary          6.02 (36023)           206.0 *    4.4
Ublox LEA-6T    NMEA            6.02 (36023)           144.5 *   11.1
Ublox Neo6M     binary          7.03 (45969)           197.1 *    9.3
Ublox Neo6M     NMEA            7.03 (45969)           137.6 *    8.4
Ublox 7         binary          1.00 (59842)           178.4 *    2.6
Ublox 7         NMEA            1.00 (59842)           146.2 *    7.9
Ublox NEO-8M    binary          2.01 (75350)           207.7 *    9.1
Ublox NEO-8M    NMEA            2.01 (75250)           181.2 *    8.0

V.KEL SIRFIII   binary          GSW3.2.5               417.0 *    6.1
V.KEL SIRFIII   NMEA            GSW3.2.5               385.0 *    5.0

Navspark Mini   bin+NMEA 115.2K 1.7.27 15.8.18         170.8 *    7.1
Navspark NS-T   bin+NMEA 115.2K 2.1.05 15.1.29         153.8 *    7.1  (Venus 822T)
Venus 838T      bin+NMEA 9600   2.1.05 15.1.27         208.3 *    7.5  (Venus 838T)
LTE-Lite        NMEA            (newer firmware)       252.1 *   27.7

Adafruit Ultimate  NMEA                                461.9 *   49.8

Skylab SKM53    NMEA                                   149.0 *   37.8  (actual value is not stable -100 .. -500 seen)

Jupiter-T       Zodiac          93.07                 1245.5 *    3.3
Juptier-T       Motorola(8ch)   93.07                  284.5 *    3.2
Jupiter Pico    Zodiac          14.00 11/28/05        1232.2 *    0.4  (ramps -1225 .. -1245 over 130 minutes)
Jupiter Pico    Motorola(8ch)   14.00 11/28/05         295.1 *    1.8

Motorola UT+    Motorola        R5122U1112             260.5 *    3.7
Synergy M12+    Motorola        P273T12T11             208.5 *    1.4

Z3812A          SCPI            X98-4-A               -949.6 *    0.8  (ramps 945 .. 955 over 16 seconds)
Z3801A          SCPI 19.2K      3543A                 -979.8 *    2.0

Symmetricom     UCCM-P 57.6K    1.0.0.2-01             127.1 *    3.6  (ramps -122 .. -132 over 10 seconds)
Trimble UCCM-P  UCCM-P 57.6K    2.0.1.6-01             281.0 *    3.2
Trimble UCCM    UCCM 57.6K      3.0.0.11-0             286.2 *    3.1