Possible timestamp error in SER files?

[mcamilleri]

Thanks.

Do not change anything for ADV recording of GPS cameras!

Hristo can be contacted by email hristo_dpavlov@yahoo.com but may be slow to respond. Otherwise info@occultations.org to find someone in the occultation community.

Mark Simpson has developed the Astrid camera/control module for occultations and has a new RAVF format based on ADV - not suggesting you use it but he knows the ADV format well. https://github.com/ChasinSpin. That sites has links to Hristo's ADV documentation http://www.hristopavlov.net/adv/index.html

My request was for ADV recording to be an option for other non-GPS cameras with the start and end times of frames derived from the system time. Currently can record ADV for, say, ZWO cameras but it does not have the start and end times in the meta data so cannot be read automatically by TANGRA. ADV should be more reliable as the start and end times come directly from the metadata and are tagged, whereas in SER files the user must know what the metadata timestamp refers to which can lead to mistakes. My assumption is that it would be a minor change to implement. As long as the change has no impact on the recording of GPS cameras.

Michael

[admin]

Hi Michael,

yes, all I was proposing was the possibility of using the system timestamps in the frame start/end when no GPS is available. But... I feel that somewhere else in the metadata I should record the fact that the frame timestamps are PC system time generated, not hardware generated. So far, I have failed to find a good place to record that. The spec (thanks for the link) does not have a defined tag name for the 'Time Source' or similar, which seems to be an omission.

I would be tempted to add a per-frame metadata tag - perhaps named 'TIME-SOURCE' - that would contain info on where the primary start/end timestamps came from (GPS or system clock). Is that OK?

Robin

[mcamilleri]

If you want to change the format for GPS cameras then please consult the ADV working group. Any changes you make might affect processing and could cause major problems.

Perhaps use the accuracy field in the ADV file and put in a large dummy value to indicate it is not GPS. So perhaps set the clock frequency to 1,000 Hz (ms clock steps) and accuracy of 999 (0.999s).

Perhaps the SatelliteFixStatus fields could be used -‘1’ for internal time keeping in a condition of a no fix after establishing a previous time or position fix so effectively means using the adjusted time. Or use '0' for now fix.

How about you just leave ADV alone for now. No doubt there will be discussion amongst IOTA members about this issue and out of that a request might come to change how ADV is done for non-GPS cameras.

[admin]

Hi,

thanks for the suggestions. Any changes I make will leave the current GPS metadata for ADV files entirely alone, so I am not going to be risking breaking GPS data.

cheers,

Robin

[admin]

Hi,

is there a tool to view the metadata on an ADV file? I was expecting Tangra to show me this, but it doesn't show all of the metadata, just bits and pieces.

I am planning on the following

Non GPS camera changes

* Start/end times filled in for each frame
* Timestamp accuracy set to 1,000,000,000ns - 1s
* Extra file metadata field 'TIME-SOURCE' set to 'PC System Clock'

GPS Cameras

* Extra file metadata field 'TIME-SOURCE' set to 'Camera GPS'

Mind you, if I can't find any software that shows the 'TIME-SOURCE' metadata then no point in adding it

cheers,

Robin

[procyon12]

Hi Robin,

is there a tool to view the metadata on an ADV file?

Maybe this helps? - Open adv in Tangra, then Tools > ADV/AAV tools > FSTS File Viewer > a new window opens (Tangra must be closed before). There is a lot of information ....

Christian

[admin]

Hi Christian,

yes, that's the sort of thing I was looking for... I can now see the metadata I am adding. Looks like I was close, but need to set the clock accuracy to something horrible on the main stream for PC timings.

cheers,

Robin

[mcamilleri]

The timestamp changes and bug have been reported to IOTA and onto the various IOTA groups with guidance of how to find errors in previous observations and how to use the right SharpCap version. Groups are in Europe/Asia/US/Australia so it is worldwide. At this stage we don't know how many observations have been affected and will need to be reprocessed.

It has stimulated a lot of debate and discussion (and a few choice words) about the accuracy of timing and the various systems people are using. So out of that should come a greater awareness of issues that could affect timing and hopefully improved practice.

One observer, Lionel, said he had asked you to change timestamps around version 3.2? It seems there might have been changes in timestamps between 3.2 and 4.0. If so then this could affect users who updated from 3.2 to 4. What is the history of timestamps for older versions?

Any and all versions of SharpCap could be used by occultation observers as some maintain older OS and software to avoid issues with some legacy systems breaking with updates.

[mcamilleri]

Before you deploy any changes to ADV would you please consult IOTA. I can inform the current group dealing with the timestamp issues about the proposed changes.

I could be a tester.

Michael

[admin]

Hi,

please see this preview version : viewtopic.php?t=7470

this version fills in the timestamps for ADV from the system clock, whereas in previous versions they would be blank. Aside from a top level time source field in the metadata, there are no other changes, so there is no risk of existing use cases failing.

cheers,

Robin