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

#111

Post by procyon12 »

Hi,

I've expanded my yesterday's measurements basing on the new formula, see Excel file. The settings are now USB tr. 3, ROI height 300 px, 16 and 8 bit, exp. 2 - 20 - 200 - 2000 ms.

Christian
Attachments
newCal_02.xlsx
(19.6 KiB) Downloaded 80 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

#112

Post by Filipe Dias »

procyon12 wrote: Wed Dec 09, 2020 11:48 am Really reached 0.01 ms or are these theoretical values only? If really measured what were the settings and machine, no dropped frames (PyMovie/PyOTE) ?
I should clarify... I made no "measurement". Laptop is not the best (intel i3, harddrive is an SSD almost full, got a lot of dropped frames)
I observed the lowering in brightness (that I assumed would result only from a shorter exposure), I also pointed the camera with a 50mm@F/1.8 photo lens to different lightsources, including my ceiling fluorescent lamp and the screen on my laptop. The fluorescent lamp clearly blinks, as sampled by the camera, then when this could no longer be used as an empirical distinguishing factor, I pointed to the screen, and some flickering started to show up with really smaller exposures. At a certain point I had the gain of the camera at maximum, and could not distinguish by eye what could be flickering and what could be noise. Luckily, this happened around the time I could no longer notice a drop in brightness, so I used that as the "roughly-lowest exposure possible".
The exposure time values I mentioned are the values I inputted to SharpCap, they are not direct measurements.
expected "blinking" frequency of the fluorescent bulb is around 100 Hz (twice the 50Hz of 220V A/C electricity socket)
expected "blinking" frequency for the back illumination of my laptop monitor would probably be just under the kHz range, due to the inverter that powers the backlight... An exposure length that is "small", would sample light in a narrow-enough time so that the flickering appears like "on-off" with only "two intensities" (not brightening-dimming).
And yes, I experimented with adjusting monitor brightness to notice differences in the aspect of the flickering too, as the monitor controls brightness by modulating how much time the screen is lit vs not-lit :-) Fun to notice this, and a clue to relate observed flickering to the phenomenon and not other factors like dropped frames!

So my conclusions that the exposure time was effectively changing between trials came from noticing changes in the flickering pattern and changes in brightness of the image in SharpCap. I make no claims on how precise they are.

One of the uses I have in mind for this camera IS related to the behavior of these light sources, so I will attempt some sort of measurement in future! :geek:
procyon12
Posts: 253
Joined: Tue Jan 14, 2020 11:32 am

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

#113

Post by procyon12 »

Thanks, Filipe, for the explanation.

Christian
User avatar
admin
Site Admin
Posts: 13173
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

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

#114

Post by admin »

Hi folks,

Thanks folks for testing the new calculations - so far all the results that I've reviewed seem to be in fair to good agreement with the new formula, which is promising. Please shout loudly if you find USB3 calibration values that are very different from the new formula.

I have some partial data now for USB2, but will not do anything with that just yet. QHY have committed to adding an SDK method for me to tell if the camera is on USB2 or USB3.

I will put this update into a SharpCap 3.3 beta build shortly.

I am also considering having SharpCap remember adjustments from the auto configured position during an imaging session - for instance if you adjust start to +100 from the autoconf value then change the exposure, the +100 would be applied to the value for the new exposure. At some point if the difference is too large (> 5000?) then it would abandon that approach. Any thoughts on this? Would it help or be confusing? Would it be better to have separate manual offset controls?

cheers,

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

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

#115

Post by procyon12 »

Hello Robin,
I will put this update into a SharpCap 3.3 beta build shortly.
... sounds good.
I am also considering having SharpCap remember adjustments
From my point of view it can be good. But in a first stage I would prefer an additional possibility to disable it, so one can compare.

A wish: Can you change the calibration buttons to move automatically when held down? At least in the test phase, this would be good for the hands ;)

Thanks, 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

#116

Post by Jean-Francois »

Hello Robin and Christian,

I do some tests today and here the results ...

LED_calibration_new_formel.xlsx
(215.55 KiB) Downloaded 87 times

The Excel file analyses only the StartPos values. With the new LED calibration, the EndPos analysis is trivial.

Here some comments:

- the new StartPos equations are OK, but sometimes with large difference to the measurement (~ 9700 difference).
- the new equations are linear (with few parameters)
- my equations are with some second order and have a smaller difference to the measurements (~ 1200 difference).

Robin, are you now sure that the EndPos values are quasi constant and lower than the StartPos ?
Do you have information from QHY concerning the StartPos/EndPos "swap" from the QHY document (table in preceding message) ?

I modify an automatic script with the new EndPos equations (for MON8 and MONO16 with USB 3.0 connector).
Note, I test today only with the USB 3.0 connection.

In my analysis, I calculate the intersection line between the two region of the StartPos value.
Then I use one equation for the exposure time shorter that the intersection line or the other equation when the exposure is longer.

Your (QHY ?) new method calculates both region completely and then "use" only the larger value with the max() function.


MONO8-USB 3.0:

New StartPos:
long exp start = 6276 + 1120 * USB
short exp start = (combined) 80.003*H*USB + 4298.25*USB + 448.1*H + 23976 + (-0.02849*H - 74965.14)*ms
=> StartPos = max(long exp;short exp)

New EndPos:
=> EndPos = 2861 + 320*USB


MONO16-USB 3.0:

New StartPos:
long exp start = 10934 + 1120 * USB
short exp start = (combined) 79.994*H*USB + 4355.85*USB + 780.93*H + 41662+ (-0.01928*H - 75018.587)*ms
=> StartPos = max(long exp;short exp)

New EndPos:
=> EndPos = 4191+ 320*USB


But ... with start difference up to ~ 9700 (look at page 9 from the PDF StartPos, the deviation is growing with the USB traffic). If you want to reduce the difference, then you have to use the second order equations (not the preceding equations).


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

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

#117

Post by procyon12 »

Does binning no longer play a role in the new formula(s)?

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

#118

Post by Jean-Francois »

Hello Christian,

The binning plays no role in the old or new formula. It has never play a role.
Set the LED calibration (old or new EndPos value) with 1x1 binning and then change to 2x2 binning.
You can see that the LED disappear at the same value when you change +/- 10.

I check that now with my camera. I test manually or with my old script or a modified new script.

And ... I had a chock ... the camera does problems ... first SharpCap lost the connection, then no more recognized after plugin the USB cable.
Then after repeating plug/unplug of the cable and with extern 12V power, the camera reappear in SharpCap ... but first with some problems with the calibration of the LED ... nothing was the same. Then SharpCap lost all the setting of the camera at the start.
The cooler was set each time at the maximum (I hate that from the camera/software) and other parameters was "reset".
It was not simple/clear to have the wanted settings at a new start/connection of the camera.
After several tests and de-connection (full: USB and 12V power) and restart of SharpCap ... it was possible to have the camera running back. (Pfuh!)

Regards,
Jean-Francois
User avatar
admin
Site Admin
Posts: 13173
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

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

#119

Post by admin »

Hi Jean Francois,

thanks for taking the time to perform a more detailed analysis - what we need to understand now is if there is any variability between cameras, since I think I was seeing some different values from your measurements when I looked at some of the earlier data. I do have documentation from QHY that confirms the end pos should be smaller than start pos in all cases.

@Christian - I don't recall testing/using GPS with binning previously - I had no special code in SharpCap to deal with binning in the previous formulation, so if it worked it was just luck!

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

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

#120

Post by procyon12 »

Hello,

Up to now I thought binning would be the 5th parameter - this is obviously wrong (?). In my IOTA presentations/workshop I wrote that binning is relevant, and Kai Getrost also did so.
Binning is often used in the occultation community (so far I do not know of problems with binning under the old calibration procedure).

"variability between cameras" ... yes, that we'll have to consider.

@Jean Francois
Cam problems: From my experience, in such cases it is good to shut down the machine. Restart SC/cam with no other SW running. The 12V is only for cooling.

Cheers, Christian
Post Reply