QHY GPS Updates in 4.1.12174

[admin]

I have made a couple of updates to the GPS code this time around - I don't think they will have significant effect in the 'happy path' everything is working fine case, but they may change how problem situations are reported/dealt with.

First, the 'Set PC Time to GPS Time' button no longer requires SharpCap to be run 'as administrator'. Setting the PC time still requires administrator permission, but now SharpCap has a small helper application that does the actual changing of the PC time and this helper application will need to run as administrator. Basically, if you press the button, you will get prompted to allow 'SharpCap TimeSync' to make changes to your computer. Allow the changes and the PC time will be set to the GPS time. There is no need to try to be quick when allowing the changes - the code deals with the fact that it might take you a few seconds (or even longer) to confirm admin access.

Secondly, I have changed the behaviour where there is a locked GPS signal but the GPS time is more than 1 day out from the PC time. Previously, SharpCap flagged this as 'Bad Data' and did not use the GPS data. Now it is flagged as 'PC Time Mismatch' and the GPS data will be used. Of course, SharpCap can't really tell whether the PC time is wrong or the GPS is giving bad data, so if you see this status then it's worth checking an independent time source.

cheers,

Robin

[Jean-Francois]

Hello Robin,

Thanks to mention that you have done some changes.

Concerning the QHYGPS camera ...

- I asked few weeks ago if it was possible to shift some pixels down the timestamp on the QHYGPS camera image.
So that the GPS information will be visible above the timestamp. (in the case that somebody will check the timestamp relative to the GPS information)

- is it possible to use the Banding Suppression with the GPS information activated ?

- "Set PC Time to GPS Time" ... script function ?

Regards,
Jean-Francois

[Jean-Francois]

Hello Robin,

I just tested it.

It works ... but ...
With the user without admin right, then it is necessary to enter the admin password.
I found a problem ... if the user cancel the admin password query ... it crashes SharpCap.

The delay between the GPS time and the PC time seems to stabilise to 20 ms.
With the old way, it was around 5 ms, sometimes below.
Not that it is important ... the computer time will shift.
If the delay is constant (and for different computer), then you could take in account.

Regards,
Jean-Francois

[admin]

Hi Jean-Francois,

oops - I didn't test with a username/password needed, only to press 'No' on the allow changes. I can fix that by handling the error.

Interesting that the resulting offset is slightly different. I am doing the same calculation on the SharpCap side to work out how much offset needs to be applied between the GPS time and the system time, and then I pass the offset across to the new process so that it doesn't matter how long you spend confirming admin access. The only thing I can think of is that because the work is being done in a separate, new, process, maybe some DLLs need to load (or similar) when trying to set the system time, which means that it is not set as quickly as it would be in SharpCap where everything is already loaded. As you say, a small residual offset of a few ms is not really important... the issue we are trying to deal with is the system clock being hours (or even days) out.

For the overlay timestamp, it would probably be OK to move it down a couple of pixels if there is GPS data. If you have a really narrow ROI, it might still overwrite the extended data, but that's a bit of an edge case on an edge case...

You should be OK to use banding suppression as the suppression is applied after the GPS data is extracted from the frame. You would find that the GPS data in first pixels of the frame is likely to be corrupted though if you try to read it later in a separate application - similarly hot pixel correction or other image processing will potentially break the embedded binary GPS data.

cheers,

Robin

[Jean-Francois]

Hello Robin,

OK for the offset. Ideally is to have the PC time as precise as possible ... in the case that the GPS signal is lost or perturbed.
In this case, the image time will be set by SharpCap/PC Time.

For the timestamp and a small ROI ... for the occultation analysis, it is necessary to have several comparison stars. Depending on the telescope focal and the exposure time, sometimes you have only few stars. So an extreme small ROI is practically not possible.

I did yesterday some additional tests.

I used Tangra for the view of the timestamp.
Now, I do not know when the time information is coming.
I used the banding suppression and/or the timestamp in the film.

What I remarked ... the timestamp digit number changes if the GPS is activated or not.
Millisecond without GPS activated and 1/10 microsecond with GPS activated.
So I think that without the GPS activated, the time is coming from the PC .. and so only to 3 digits.
With the GPS activated, then SharpCap reads the pixel coded time and generates the timestamp.
While the time is very precise, it is shown with 7 digits.

I remarked something strange, but it could be a problem in Tangra.
At the opening of a file in Tangra, the software ask for the exposure time and the jitter.
I tested with a wrong exposure time ... it had fast no effect ... only a small variable offset on all the images.
Now ... Tangra uses which time information ? ... the pixel coded time from the GPS signal or the frame timestamp that SharpCap reads ?
Now I guess that is the second case.

For the timestamp ... is it necessary to have it on the top ? A top or bottom position choice could be sufficient.

Regards,
Jean-Francois

[admin]

Hi Jean-Francois,

yes, you are right about the digits of precision for the on-image timestamp... that change was made some time back to give more precision when GPS is available. I have changed the code to move the on-screen timestamp down one pixel line if the GPS data is there. That was already active for the 8 byte machine readable timestamp that usually goes in the first 8 bytes of the frame, so I went for consistency. I think that at one point the in-image timestamp only drew the light pixels, so the blank first line of the font used to let the GPS data survive, but then that got changed...

Presuming you are using an ADV file, I would expect tangra to be taking all the timings from the frame metadata in the ADV file, not from the in-image GPS data - although I don't know for sure... To be honest, I've only used Tangra a handful of times just to check that ADV files are readable, so I don't have much idea about how it is supposed to work.

cheers,

Robin

[Jean-Francois]

Hello Robin,

OK for the timestamp location.
For the timing in Tangra ... I did my test only with SER files. I will check again with ADV.

It is interesting to know which time info is used by Tangra (or other analysis software).
If it is all the time the SER or the ADV "timing" without looking at the binary pixel coding, then it would be not a problem if the binary pixel coding is corrupted.

The question is when SharpCap reads the timing from the frame ? ... dark/flat subtraction and other image processing ?
(you mentioned that the banding suppression is performed after the GPS data is extracted.)

Jean-Francois

[procyon12]

I don't think any of the usual programmes (Tangra, PyMovie) use the binary pixel display for timing.

Christian

[admin]

Hi,

just to confirm that the GPS data extraction from the in SharpCap frame is performed first, before any image processing, so the fact that image processing may change the data (or the timestamp overwrite it) is not going to be an issue.

cheers,

Robin

[Jean-Francois]

Hello Robin,

Thanks for the confirmation.
That is what I observed with my different tests.

Jean-Francois