Timestamp issue w/QHY174GPS

[procyon12]

Hello Hiroyuki,

When LEDCalibration is performed, it becomes "CSP=4224, CEP=10916", which is close to "CSP=4190, CEP=10930" on the QHY website. ..

Do you mean procedures from QHY websites? If so, you should not go this way. One result is the wrong exposure ...

On the other hand, the default value of SharpCap is "CSP=6301, CEP=1504297", which is greatly different from the LED Calibration value, but the Exp. value in GPS status is 19971.2us, which is close to the indicated value of 20ms.

Just tested with my cam - exactly the same values, and: in this case nothing was to calibrate, the predefinition did the job. If you had seen "BadCalibration ..." or some illogical output in the GPS status window, you would have had to calibrate manually.

To save a found calibration, you must work with SC's Capture Profiles (upper right in the GUI; see the help, if you are in doubt). You may have seen, that the actual calibration is also shown in the CameraSettings.txt file.

We have done some work to understand the QHY174GPS especially for occultations. Something is documented here: https://www.iota-es.de/qhy174gps_workshop.html. There is also a tutorial about SC's timestamp handling: http://www.iota-es.de/SC-Timestamps_01.pdf .
In addition, in the SC QHY sub-forum you can find a lot of background regarding the work/handling of the QHY174GPS (e.g. viewtopic.php?f=28&t=2802#p14626).

Cheers

Christian

[admin]

Hi,

I think that something changed in the way that cailbration works at some point in the QHY SDK. When I first had the GPS camera (several years ago), calibration was not critical to getting roughly the right figures from the exposure, and the calibration values did not need to go nearly so high (only up to a few x 10000). I expect that the documentation you are finding may relate to that old way of calibrating.

Robin

[watan_rockhand]

Hello, Robin, Christian,

Thank you for your useful advices.
I will check and implement it tonight.

Regards,
Hiroyuki Watanabe

[watan_rockhand]

Hello Robin,

I used a QHY174MGPS and recorded in AVI format with MONO 8,480x300, 1x1,30ms, USBTrafic=0, GPS=ON, Timestamp=ON.
But the machine readable timestamp shows an incorrect time even though the screen display appears to be correct.
Under the same shooting conditions, with GPS=OFF, the correct time was recorded.
I think this behavior is a bug, what do you think?
I'd like to use Limovie for metering, but at the moment it only reads AVI format, so could you fix SharpCap?
Here is a CSV file read by PyMovie and Limovie for your reference. In this AVI file, the stars are not photometric because they don't exist.

Regards,

Hiroyuki Watanabe

[procyon12]

Hi Hiroyuki,

If I understand your post right, I think there is no SC bug. You have in both cases a very high timestamp error rate (red marks), read with PyOTE 3.5.2.

gps_off.png (38.08 KiB) Viewed 2152 times

gps_on.png (39.74 KiB) Viewed 2152 times

I think you should first guaranty test files without timestamp errors (maybe exp. 100ms or so, also e.g. USB traffic 3 can work sometimes better than 0 - and the USB3 connection must be OK). Then it should work.

Incidentally, if I may put it this way, for occultations, one advantage of the QHY174GPS is the 12/16 bit output. And with AVI you'll have 8 bit only. Tangra and PyMovie are both well established photometry programs (however, LiMovie may have some additional features).

Cheers, Christian

[admin]

Hi,

SER mode would probably be a better choice as it allows high bit depth and has a built-in timestamp field for every frame. There is also ADV support coming up in SharpCap 3.3.

By the way, if you are taking relatively high speed images at high gain then there is probably no advantage in using 12/16 bit output files – the noise level involved will mean you are just sampling the noise at a higher resolution!

Cheers, Robin

[watan_rockhand]

Hello, Robin, Christian,

Thank you for your reply.
But what I would like to say is that the time is recorded back and forth at the "minute" level, not at the time error level issue.
Please read the time directly. Do you see this as the correct time stamp?

Regards,
Hiroyuki Watanabe

[procyon12]

Hi Hiroyuki,

The picture is strange indeed. Sorry, I overlooked that.

How did you get the PyMovie timestamps?

But the machine readable timestamp

Does this mean that you made some kind of OCR in PyMovie? And this gave good (for w/o GPS) and bad results with GPS on?
Or did you made "Manual timestamp entry" in PyOTE?

Maybe you should provide the AVI.

Cheers, Christian

[watan_rockhand]

Hello Christian,

Thank you for understanding.

How did you get the PyMovie timestamps?

We can read the time stamp of 8bit avi file with PyMovie as follows.

PyMovie-1-5.zip

(867.11 KiB) Downloaded 93 times

1. Open the avi file by click "Open AVI/SER/ADV/AAV file" button.
2. Click "Create AVI/SER/SDV//AAV-WCS folder from file" button.
3. Close "Help"dialog.
4. Click "Timestamp" tag.
5. Select VTI "SharpCap 8 bit avi"

But the machine readable timestamp

Does this mean that you made some kind of OCR in PyMovie?

=>PyMovie does not read the time displayed at the upper left of the SharpCap image with OCR, but the "time data embedded in the image".

And this gave good (for w/o GPS) and bad results with GPS on?

=>Yes.

Or did you made "Manual timestamp entry" in PyOTE?

=>No, I did not made "Manual time stamp entry".

Maybe you should provide the AVI.

=>Please see follow links.
https://www.4shared.com/zip/prF7F5yaiq/ ... PS_on.html
https://www.4shared.com/zip/ZrrVM0fYea/ ... S_off.html

Regards,
Hiroyuki Watanabe

[procyon12]

Hello Hiroyuki,

now it's a little clearer to me. I wasn't aware that PyMovie can read 8bit-AVI timestamps.

I have reproduced it with own AVI files (I could not download your's because accounts were required, for the next time for me e.g. GoogleDrive would be better): you are right, I saw exactly the same behaviour, with GPS ON the PyMovie written csv-timestamps are completely wrong as you showed it in the picture, whereas the visual in-farme-timestamps are OK. And with GPS OFF, PyMovie works right.

If you use later PyOTE's "Manual Timestamp Entry" it works also for GPS ON.

Initially I thought it is not a bug of SC but a problem with PyOTE. As I wrote, I do not know, when and why this feature was introduced. However, I also do not know if it can be related to SC too. Maybe Robin can say something.

Cheers, Christian