QHY 174 GPS Calibration LED issue // USB Traffic weirdness

procyon12
Posts: 253
Joined: Tue Jan 14, 2020 11:32 am

Re: QHY 174 GPS Calibration LED issue // USB Traffic weirdness

#81

Post by procyon12 »

Hi Fil,

For your table, can you specify what settings you used (USB traffic, binning, field size, 8 or 16bit) and which OS?
This particular camera has not yet been connected to any GPS antenna
Does this mean you test without GPS signal? If so, I think you should work with GPS (there are cheap antenna extension cables for indoor testing). Or does it mean the camera hasn't been used until your tests?

Cheers, Christian
Jean-Francois
Posts: 360
Joined: Sun Oct 13, 2019 10:52 am
Location: Germany

Re: QHY 174 GPS Calibration LED issue // USB Traffic weirdness

#82

Post by Jean-Francois »

Hello,

I do some additional tests. I use an old laptop and I found USB 2.0 on my desktop computer :roll:

A) Desktop computer (new, January 2020): W10, Ryzen 3950X, ASUS Prime X570-P with USB 3.2 and USB 2.0 (on the back of the housing)
B) Laptop (~ 2012 ?): HP EliteBook 2570p, W7 and only USB 2.0
C) Laptop (2016): Medion Erazer P7643, W10 with USB 3.0 and USB 2.0

I can confirm that all the computer with USB 2.0 give the same result for the StartPos and EndPos (+/- 20 difference).
But ... all the USB 2 are different from the USB 3 !!

It means that all the long work performed for the automatic Start/End Position (or my script) are only usable with the USB 3 connection.

Also now the big question ? => How many people use computer with only USB 2 connector ?

I will say ... If less than 5 people use only USB 2, then I will not start to do ~50 hours of tests and analysis.
May be can Robin find a simple solution ... I find that on my computers the USB 3 with traffic = 86 is like the USB 2 with traffic = 0.
It is may be a constant ... but what is with larger traffic with USB 2 ?

But, Robin, do you have a response on your question ? (viewtopic.php?f=28&t=2241&start=60#p15612)
Concerning the connection origin (USB 2 or USB 3) in SC.

Concerning the question from Kai (viewtopic.php?f=28&t=2241&start=60#p15623)
I investigate the LED calibration with the help of my script.
Means ... I use the SC automatic values as starting values for my (first) script, then my script start a more precise LED calibration (it search the mid-intensity of the LED illumination). Then with a lot of measurement, I search a new set of equations. Now the last version of my script ignores the SC starting values and uses my equations (see below).
For the "BadCalibrationReduceEndPo" problems ... do you remark the following after the LED calibration with locked status ?
- click on EndPos (for example +10 then -10)
- switch-off the LED and switch-on the LED ... result "BadCalibrationReduceEndPo"
- click on StartPos (for example +10 then -10)
- switch-off the LED and switch-on the LED ... result "Locked"
Why ?

Concerning the StartPos and EndPos calculation (for USB 3 connection):
(here the equations from Robin viewtopic.php?f=28&t=2241&start=30#p11849)

I have the following:

For MONO8:
Limit_Time = (USB + 5.6) * (0.001067 * Height + 0.0421) [ms]
StartPos for exposure time shorter than Limit_Time:
StartPos = ((0.0000637116*Height - 0.1436327)*Height - 74917.1066)*ms+((-0.00358619*Height + 86.459717)*Height + 1607.70533)*USB +(-0.019717898*Height + 483.579932)*Height + 9199.23345
StartPos for exposure time longer than Limit_Time:
StartPos = 1120 * USB + 6276

EndPos for exposure time shorter than Limit_Time:
EndPos = ((-0.0035558*Height + 86.4002344)*Height + 1360.007826)*USB + (-0.0199132*Height + 483.84284)*Height + 7591.707861
EndPos for exposure time longer than Limit_Time:
EndPos = ((-0.0000118685*Height + 0.0201366)*Height + 74992.72194)*ms + ((0.0000136924*Height - 0.022276)*Height + 773.9233)*USB +(0.0003354606*Height - 0.5725338)*Height + 4421.8013


For MONO16:
Limit_Time = (USB + 9.76) * (0.001067 * Height + 0.0421)
StartPos for exposure time shorter than Limit_Time:
StartPos = ((0.0000390615*Height - 0.070123)*Height - 74967.66526)*ms + ((-0.0035966*Height + 86.4884205)*Height + 1635.68176)*USB +(-0.03440389*Height + 842.6668063)*Height + 16080.628624
StartPos for exposure time longer than Limit_Time:
StartPos = 1120 * USB + 10939

EndPos for exposure time shorter than Limit_Time:
EndPos = ((-0.0035558392*Height + 86.4002017)*Height + 1360.009956)*USB + (-0.0347116673*Height + 843.4836578)*Height + 13250.53035
EndPos for exposure time longer than Limit_Time:
EndPos = ((0.0000163613*Height - 0.0133432)*Height + 74999.19033)*ms + ((0.0000067656*Height - 0.01705296)*Height + 735.04566)*USB +(-0.0007104888*Height + 0.710555)*Height + 7515.87826

Where the USB = USB traffic, Height = the ROI height, ms = exposure time in millisecond.

Also a little bit more complicated as the equations from Robin (and Christian) :D .

Concerning the first message from Filipe ... I do not really understand what you do.
But for some test (or practice) with the LED calibration, you do not need the GPS antenna or the GPS could be Off.
You will need a GPS antenna for later imaging for the precise timing of the images.
If you really want to understand more ... read the (pptx) presentation from this link: viewtopic.php?f=28&t=2241&start=60#p15623 ... you will have very good detailed information (do not use the presentation mode, but read the notes in the lower window).
Filipe ... in short: you have to play with both controls (if you want to synchronize precisely the exposure time with the GPS).
In other words, the StartPos and EndPos controls the switching of the LED at the beginning or at the end of the exposure.
The electronic commanding the LED is different as the electronic for the exposure, but the timing of the LED switch on/off is known very precisely with the GPS time.
What I understand is ... you find the "third transition" (Kai wording) and the transition is at 46280.
But please, say more details (8 or 16 bit, ROI, USB traffic ... and USB 2.0 or 3.0 connection).


Best regards,
Jean-Francois
procyon12
Posts: 253
Joined: Tue Jan 14, 2020 11:32 am

Re: QHY 174 GPS Calibration LED issue // USB Traffic weirdness

#83

Post by procyon12 »

It is slowly becoming an independent field of science ... :o

Christian
procyon12
Posts: 253
Joined: Tue Jan 14, 2020 11:32 am

Re: QHY 174 GPS Calibration LED issue // USB Traffic weirdness

#84

Post by procyon12 »

Hello,

Joke aside. I repeated my USB2 tests with USB3, same machine (W7-64 i7 16GB, SC 3.2.6441 pro, FW upgraded cam):

USB2 as published above already:
Mono 8; 1920x1200; USB trfc 0; bin 1x1; 640ms; immediately locked with default StP 6301, EndP 48004297
Mono 8; 1920x1200; USB trfc 0; bin 1x1; 320ms; immediately locked with default StP 6301, EndP 24004297
Mono 8; 1920x1200; USB trfc 0; bin 1x1; 160ms; immediately locked with default StP 6301, EndP 12004297
Mono 8; 1920x1200; USB trfc 0; bin 1x1; 80ms; immediately locked with default StP 6301, EndP 6004297 USB2 limit, only ~8fps

USB3:
Applying "AutoCalibration", all cases initially showed the message "Bad Data Reduce EndPos". This done (LED to max brightness - histogram) I got:
Mono 8; 1920x1200; USB trfc 0; bin 1x1; 640ms; StP 6301, EndP 48004017
Mono 8; 1920x1200; USB trfc 0; bin 1x1; 320ms; StP 6301, EndP 24004207
Mono 8; 1920x1200; USB trfc 0; bin 1x1; 160ms; StP 6301, EndP 12004117
Mono 8; 1920x1200; USB trfc 0; bin 1x1; 80ms; StP 6301, EndP 6003997

To meet my criteria outlined above, a small reduction in EndPos was all that had to be done.

In general I think that USB2 is not relevant for this camera.

Cheers, Christian
Filipe Dias
Posts: 10
Joined: Sun Nov 15, 2020 3:11 pm
Location: Portugal

Re: QHY 174 GPS Calibration LED issue // USB Traffic weirdness

#85

Post by Filipe Dias »

Sorry!
details are: 32bit version of SharpCap version 3.2.6442.0
capture: 16MONO mode, bin 1x1, 1920x1200, USB TRaffic = 0
embarrassing info: cooler at 100%, long going below +6ºC, camera housing at about 30~35ºC <-- the ring holding the camera was covering the air intake -- Oooops, big mistake!
Does this mean you test without GPS signal? If so, I think you should work with GPS (there are cheap antenna extension cables for indoor testing). Or does it mean the camera hasn't been used until your tests?
It means both things! I got two cameras. One I had used last week with GPS though uncalibrated (whatever start/end values it had were kept the same) because I only wanted relative timing between frames. The second camera I had not used before..

My mistake covering the air intake, and heating up the camera to "do_not_try_this_again" temperature values made me think if keeping any quartz crystal inside the camera some degrees away from its design temperature could actually make the clock drift a tiny bit... (wikipedia warns that this depends on shape the crystal is cut, but mentions a possible drift of -0,04 parts per million for each ºC of temperature, which would mean 0.3 microseconds for my exposures, still unnoticeable).. Anyway, I hope to not repeat this again.

Jean-François, Ok let me try to explain what I was doing.. I was attempting to understand the behavior of when the LED becomes visible or not. For this I needed to think in a way that only one action from me could show a result.. The way I thought of this was following Kai's explanation in the signal/time diagram: exposure starts - exposure ends, LED-on - LED-off, and a single value that offsets these "signals" in the diagram. Thinking like this, I hove only one parameter to play with: this "offset"!
So, I started playing with it, using only the "LED_Start_Pos"... after playing for a while with it, I took note of the numbers for when the LED would start to be visible, and finish to be completely visible, and vice-versa... Next I repeated this for the End_Pos and the values were exactly the same! So a miniture-Eureka was heard inside my head :-)

I think we are human beings with a very natural way of testing things according to how things are presented to us... In other words, SharpCap's user interface is suggesting us how we should test things, and this can be making our exploration more difficult. We should remember hat SharpCap user interface is not there to make testing easier, but instead it is there to make defining parameters easier for when you want to use the camera! This is a very subtle difference :-)
So we should separate the two moments: when we want to play with values in order to understand a behavior, and when we need to put in values we already know in needed places.

One thing I noticed to be good in clicking values into the Start/End interface is to write the number with leading zeros 000046280, or grous some numbers.. For instance, if I need to enter "46280" The quickest way to get there (because small buttons annoy me: I have bad eye sight) is to start with "50000", and then go down with 4 clicks to 46000, then up with three to 46300, and two clicks down to 46280... But for his to work it is essencial that I correctly start with "50 000" and not "500 000" or "5 000". So a good interface suggestion for Robin is to add a tiny space as "thousands separator"!
The above trick of clinking-and-waiting up and down on the buttons of next least-significant number is also handy to search for where the LED is visible/not in the next frame.
But all this I am writing took me two weekend days to make sense of... So... It might not be simple.. And, I used USB traffic = 0, which may be hiding "black magic" effects...

Cheers,
Fil.
Jean-Francois
Posts: 360
Joined: Sun Oct 13, 2019 10:52 am
Location: Germany

Re: QHY 174 GPS Calibration LED issue // USB Traffic weirdness

#86

Post by Jean-Francois »

Hello Christian and Filipe,

Thank you for the last tests.

First Christian ...
For USB2 ... you write "immediately locked" ... you mean the GPS status message.
But ... do you verify that the StartPos is the correct one ... mean with a small lower StartPos value, the LED should disappear and with a small above StartPos value, the LED should be full illuminated.
I think that Kai or Robin already mentions that ... the GPS "locked" status says only that the GPS receiver has sufficient information for the time, the position and the altitude."Locked" has nothing to do with the correct LED calibration.

For me (same camera settings) and all the computer I use ... I have the LED all the time switch-ON from StartPos = 0 to 30370 (= "Third transition"), the LED is then switch-OFF between 30370 and the "real" starting position ... for me ... for 640/320/160 ms => 102540, 80 ms => 3171300.
For the EndPos ... I have similar values for 640/320/160 ms, but I have 9147650 for 80 ms.

The StartPos and EndPos are some values for the 75'000'000 Hz quartz crystal.
In my case for 80 ms ... 9147650 - 3171300 = 5976350 and 5976350/75000000 = 0.0796847 s = 79.68 ms.
In your case for 80 ms ... 6004297 - 6301 = 5997996 and 5997996/75000000 = 0.07997328 s = 79.97 ms. It seems OK ... but it is not ;)

Christian, please test for USB 2, the StartPos value = 0 ... is the LED switch-ON or OFF ? ... The correct point for the StartPos is that the LED illumination goes from dark to light when the value is larger.

I have like you ~8.3 fps with the different computer.



Second Filipe ...
Thank you for the camera settings information ... but you forget one important information ... do you use USB 2 or USB 3 connection with the camera ? For a lot of discussion, we see some discrepancies between the use with USB 3 and (for some few user) with USB 2.

You mention an important point concerning the cooling of the camera. I remark and I really do not like when any software starts the cooling of the camera with full power. No, I want the control from the beginning on the cooling of the camera. Sometimes I plug the camera and some minutes later I start SharpCap ... then I see that the camera detector is already by 0°C or lower. I do not need each time the full power cooling and when I need a cooling, then I do it with small temperature steps over ~ 10 minutes.
SharpCap seems to remember the last temperature settings point ... it is maybe not optimal. I think that ideal is to have no cooling at the switch-on of the camera.

The question concerning the crystal stability depending the temperature ... a good electronic of the crystal is temperature calibrated or compensated. But I think that is not a problem ... the PPS counter and/or the SC "GPS Freq stabilization" can reduce the effect of the crystal.
Is that correct (Robin, Kai, Christian) ?

One thing can be confusing at the beginning ... SC shows 2 numbers ... StartPos and EndPos, but we see (or not) on the image the illumination of the LED. The important point is ... if you click on the number for StartPos, then the electronic commands the LED at the beginning of the exposure (and not at the end). And if you click on the number for the EndPos, then the electronic commands the LED at the end of the exposure (and not at the beginning). We can see both numbers at the same time, but the electronic "fires" the LED only at the beginning or at the end of the exposure, never both at the same time. (OK, it could be possible with long exposure that we can see both on only one image. I think that Kai explains this in his presentation).


Concerning an independent field of science ... Christian ... look at my calculations in the following PDFs :D
QHY_GPS_LED_calibration_MONO8_EndPos.pdf
(513.18 KiB) Downloaded 77 times
QHY_GPS_LED_calibration_MONO16_EndPos.pdf
(513.19 KiB) Downloaded 102 times
QHY_GPS_LED_calibration_MONO16_EndPos.pdf
(513.19 KiB) Downloaded 102 times

Regards,
Jean-Francois
Attachments
QHY_GPS_LED_calibration_MONO16_StartPos.pdf
(772.5 KiB) Downloaded 79 times
Filipe Dias
Posts: 10
Joined: Sun Nov 15, 2020 3:11 pm
Location: Portugal

Re: QHY 174 GPS Calibration LED issue // USB Traffic weirdness

#87

Post by Filipe Dias »

Hi Jean-François, I connected on the "blue" USB 3 port.
The issue with the cooling was my fault. I covered the camera, air did not circulate properly, so effectively the camera was not being able to cool down. Naturally, as the set temperature was not being reached, SC/Camera pushed the cooling to the maximum. This heated up as the peltier was working hard and no air dissipated the heat. (SharpCap made some beeping sounds.. Could this have been a warning I ignored?)
procyon12
Posts: 253
Joined: Tue Jan 14, 2020 11:32 am

Re: QHY 174 GPS Calibration LED issue // USB Traffic weirdness

#88

Post by procyon12 »

Hello,

Because of some occultation events pending this night I cannot answer in detail / make tests.

But some points:
For me (and I think for most of the users of this cam in the occultation community) the cam is only a tool among a lot of other things. And this tool must work - and it works using the "AutoCalibration" maybe in combination with predefined setting profiles. I know that a remarkable number of these cams is used - and I noticed that nobody of the occultation community reacts here, despite I shared the link to this current discussion - obviously the users have no problems with the camera.

As I wrote above, from the practical view of occultation observers this will be/is sufficient viewtopic.php?f=28&t=3135#p16338:
For occultation work the users normally have working previously created profiles. Working means in this sense (I think you should also work with GPS on): From the GPS status window you have a GPS lock, the exposure time is near the chosen one, the sys clock does not differ very much wrt the GPS time. Then you may have a look at the framerate at the bottom of the SC GUI and to be absolutely safe you record a short video and look for dropped frames (maybe with PyMovie/PyOTE and or Tangra).
Mostly you change near the predicted occultation time the exposure time only. And normally then the "autocalibration" works well. In some cases you are said "BadCalibrationData - Reduce EndPos". Then usually a very little correction of the EndPos will be sufficient.

Only in the above sense the calibration is interesting for the observation of occultations. Bear in mind that the Swiss DVTI-camera (same sensor) doesn't need any calibration. There can be other reasons for QHY implementing the calibration.
And in this sense, Jean-Francois, if the above criteria are fulfilled, this
But ... do you verify that the StartPos is the correct one ... mean with a small lower StartPos value, the LED should disappear and with a small above StartPos value, the LED should be full illuminated.
doesn't play a role. In the real occultation work somewhere in the nature with strong conditions you do not have the time to check the LED. Mostly the "AutoCalibration" meets all criteria, not only "GPS locked".

On the other hand, there are our experiments and tests for a long time now (and yes, they are of scientific grade when I look at your PDFs, Jean-François) ... I'm further interested in searching and improvements, but as all of you know that is a very time consuming job.

Cheers, Christian
Filipe Dias
Posts: 10
Joined: Sun Nov 15, 2020 3:11 pm
Location: Portugal

Re: QHY 174 GPS Calibration LED issue // USB Traffic weirdness

#89

Post by Filipe Dias »

Errr.... Just when I thought I was understanding....

Now I am not being able to replicate my numbers!! :o :(

MONO16, 1920x1200, 50ms, USB traffic 0,

the number of 46280 no longer makes the transition from On to Off.... Now that number is between 4180 and 4210 !!!
Start_Pos is around 10920~10960
End_Pos is around 3757350~3757380

The differences is the GPS antenna is now connected?? :shock: (badData)
Jean-Francois
Posts: 360
Joined: Sun Oct 13, 2019 10:52 am
Location: Germany

Re: QHY 174 GPS Calibration LED issue // USB Traffic weirdness

#90

Post by Jean-Francois »

Hello Christian and Felipe,

Felipe ... if you open my PDF files (MONO16...), then you can compare your camera with my camera ...
The matrix has in the first column the exposure time, in the next columns the results for USB traffic 0, 5, ... 20.

My script founds 10939 and 3757366 also very, very near your average: 10940 and 3757365 (well done :D )
It is very surprising, that 2 different cameras on 2 different computers give the same results !

For the explanation of the GPS status, read this: viewtopic.php?t=2802#p14540


Christian ...
With USB 3 and MONO8: Yes, the SharpCap "autocalibration" is good.
With USB 3 and MONO16: No, I remark sometimes large (>4000) calibration difference of the StartPos (SC = 6301, real StartPos = 10939). But, it could be good enough.
This can be correct by Robin in a future version of SC.
For MONO8: StartPos = 1120 * USB + 6276 (with USB = USB traffic)
For MONO16: StartPos = 1120 * USB + 10939

With USB 2 : No, the SharpCap "autocalibration" does not find the StartPos. The EndPos is near (~63000 difference) the good one.
But not for 80 ms ... here, the difference is 3143352 ! (SC automatic EndPos = 6004298, real EndPos = 9147650)
The timing difference is small (or very small, I do not calculate it). But, the LED calibration is not OK.

The USB traffic value "slows down" the connection between the camera and the computer.
USB 3 with traffic = 0 is the best with full capacity.
USB 2 with traffic = 0 is the best possible for USB 2, but it is on my computer like USB 3 with traffic = 86.
If I look my measurements ... higher traffic gives higher StartPos value (for MONO8, 1920x1200, 1x1, 50 ms) 6276, 11876, 17476 for traffic = 0, 5, 10. Also the value 6301 can not be the StartPos for you camera with USB 2.

For the calibration with the LED ... I write 2 scripts ... one script calculates a list of exposure time and export the result in a text file. The other script was planed to be used one time after the setting of all other camera parameters. The idea was to have this script in the SC menu line.
I do it, but it was some difficulties, I need to modify something and try again. (The script in the SC menu line starts after the start of SharpCap. That is a problem if no camera is selected or the ROI is not selected, or ... ) The idea was to have a simple click for the automatic (per script) LED calibration. For this .. it could be a problem with the covering (or not covering) of the camera/telescope or the background illumination.


One another point ... that, I think never discussed ... the master/slave capability of the camera with the GPS timing.
It is possible to define a precise starting time and period of the exposure. On the NASA website, we can read that for an occultation, a set of cameras were controlled in the "slave" mode.
https://www.nasa.gov/feature/new-horizo ... yby-target
https://www.nasa.gov/feature/nasa-s-new ... -argentina
Does somebody know the software they used ?


Best regards,
Jean-Francois
Post Reply