GPS Flash device for precise timing

[SteveP]

Robin,

I'm interested in hearing your thoughts on the best way to integrate a GPS based flash timing device with Sharpcap. Maybe this is a feature request, maybe not. A few members of IOTA (International Occultation Timing Association) are working on a specific design of a GPS flash timing device which IOTA could build and sell (vs the current DIY designs). This new flash device, call it IOTA-GFT, would always be "driven" by a PC via a connection over a comm port. Our current thought is to control IOTA-GFT via an ASCOM driver. Several occultation observers already use Sharpcap sequences for their observations. In theory, the flash device might be included with an occultation observation sequence as follows:

WAIT UNTIL LOCALTIME "3:24 AM"
CAPTURE START
FLASH NOW
WAIT UNTIL LOCALTIME "3:26 AM"
FLASH NOW
WAIT 10 SECONDS
CAPTURE STOP

The IOTA-GFT device does have a few settings (e.g. flash duration, intensity, etc.). But, overall, it is a simple device. The sequence above assumes that Sharpcap knows how to interpret a set of "FLASH" commands as communication with the ASCOM driver for a "flash device".

Is this the best approach for controlling the flash device within Sharpcap? Does an ASCOM driver make sense (including the question of whether/how you would support this new ASCOM device)? Or would you recommend a different approach?

If you prefer to discuss any of this off-list, feel free to contact me via stevepr@acm.org.

Thanks in advance for your help,
Steve Preston
IOTA Board President

[admin]

Hi Steve,

sounds like an interesting device - I guess I don't quite understand yet how the flash helps pin down the timing of the video, but maybe that doesn't matter...

Depending on how you decide to implement the device as an ASCOM driver, you may find that you can already drive it from within SharpCap. I am thinking that the most likely you will use the ASCOM Switch Device interface, which SharpCap already supports. There is a sequencer step 'Set switch <NAME> to <VALUE>' that can already be used to adjust ASCOM switch devices. This could easily be put into a sequencer subroutine that performs the right steps to flash the device. Switch devices can also be adjusted via the SharpCap user interface if they are configured. Note that an ASCOM switch device can have multiple individual switches, so you can have duration, intensity, etc settings as switches as well as a master 'on/off' switch.

That approach would certainly give you the ability to test things out now without any changes to SharpCap. If that turns out not to work or to be clumsy to use then we could work out a custom step or another approach.

cheers,

Robin

[SteveP]

Robin,

Thanks for the quick feedback. The switch interface does sounds like good starting point. It is good to hear that you think the Switch device approach will work in this case.

Timing with a flash device:
The IOTA-GFT device logs the time of the flashes to the PC (via the device driver). The time stamps for the video file are generated later in a post-processing step which analyzes the IOTA-GFT timing log and video frames which contain the flashes.

Thanks again,
Steve

[admin]

Hi Steve,

ahh, that logging approach makes sense - you know the true timestamps of the flashed frames and can work from PC clock offsets in between

Let me know if you need anything else, but the switch device approach ought to get you started.

cheers,

Robin

[mcamilleri]

Robin, is there a place in the ADV format that could store the timestamps from the IOTA-GFT? Or failing that add it to the camera settings file? It would be great if it was all stored in one place directly from SharpCap.

Flux measurements across frames enable a calculation of how long the duration of the flash was in a partial frame. The start time of the GPS flash is precisely known so the time of the frame start or end can be calculated. The maths are simple, getting a reliable and accurate practical implementation is not so simple.

Here is a link to one method of doing it. Not the exact method the IOTA-GFT will likely use but the principle is the same.

http://www.nocturno.fr/acquisitiondelay ... 220915.pdf

[admin]

Hi,

ADV has start and end timestamps on a per frame basis that are designed to be populated with GPS sourced data, as well as a per-frame PC system time field to allow for data fill in if some frames are missing GPS data. You can also add arbitrary data on a per-frame and per-file basis. So, yes, the ADV file can store all sorts of information - just need to get it into the file and have software that can read it out again when processing.

When you say 'flux measurements across frames', would it be sufficient to record the average brightness of the frame into the ADV metadata for later processing, or does it need to be more subtle than that?

Do you have documents showing the 'build it yourself' option for the device you are planning? If it is as simple as the GPS based flasher in the linked paper (or close to that level) then I might be tempted to build one and have a play.

thanks,

Robin

[mcamilleri]

For ADV format the various software used for processing the light curves would need to be updated to use the information. I think it would be a per file basis as I don't think there is a reliable way to associate a flash with an individual frame since the PC clock will not be accurate to UTC and polling the ASCOM interface to detect when a flash was initiated could have time delays longer than the exposure time. It should be possible to flag a frame with the 'most recent/nearest flash occurred at time X' but it could be several frames behind or even ahead if the IOTA-GFT USB is faster than the camera USB transfer plus exposure time. Ultimately all we need to do is to identify which timestamp belongs to which flash/frame in the video and if that is a manual step or requires user confirmation that I think is fine. Simply having the timestamps in the ADV file would help with file management and processing.

FYI exposure times would typically be 40-160 ms, but sometimes shorter and sometimes longer.

Average brightness only works for a Global Shutter cameras. Rolling shutter cameras have line delays of roughly 10-20 ms from top to bottom of frame, depending on the camera and ROI. Average brightness might be useful to flag that a flash occurred in the frame but not, in general, for accurate timing. For accurate timing we track the target star (or line of target star) and measure the time delay on that specific line. That paper describes measuring the line delays in an asi224mc camera.

You can use a simple GPS flasher like in that paper, or simply the LED flash from a USB GPS receiver such as the VK172, however there is no error checking on the GPS and it is not 100% reliable, which is why Steve and IOTA are developing the IOTA-GFT. GPS time can go wrong and give errors of whole seconds or partial seconds especially when GPS reception is marginal or there is interference. If you have good GPS reception the 1 PPS pulse start should be dead on the UTC second, and that is good enough to have a play. You will need a GPS receiver with an external antenna if you want to do this indoors.

Michael

[admin]

Hi Michael,

interesting... thinking about it, there would be value in having the same device able to pass the GPS time to the computer via software to sync the PC clock. I would also be thinking about an 'irregular' sequence of flashes so that the gaps between them allow you to work out where in the sequence you are. For instance flashes at

0, 1, 12, 14, 24, 27, 36, 40, 48 and 53 seconds past each minute - the gaps are 1, 11, 2, 10, 3, 9, 4, 8, 5 and 7 seconds, meaning that any 2 flashes captured in video allows you to pin down the exact timings as long as the PC clock is accurate to within 30s.

cheers,

Robin

[mcamilleri]

A long series of flashes is impractical. Recordings are usually 2-3 mins long and the event time uncertainty can be tens of seconds so need to leave a 1.5 -2 min clear window. Also can't afford to be running around too much as it gets hard to coordinate. The flasher might also be handheld so could miss flashes, Having a single flash, say, 1 minute before the event and 1 minute after the event would be common practice.

The PC can be synced using NTP or a GPS time source, but one of the major reasons for the IOTA-GFT is to avoid having to keep accurate time on the PC or other camera or device. It is fairly easy to sync to <<1s.

Michael

[SteveP]

Sorry I missed some of this discussion. I haven't been back to this post in a while....

Robin,
Can you comment on the reliability of dropped frame detection with various cameras (notably ASI, QHY and other cameras which run a fast frame rates)? Dropped frames can affect timing and can be difficult to detect in the post processing stage. The libraries/drivers for some of these cameras may include dropped frame counts which can report frames dropped prior to arrival at Sharpcap. But I don't know if this is a reliable, or broad based, solution.

Thanks
Steve