QHY 174 GPS Calibration LED issue // USB Traffic weirdness

[procyon12]

Hi Robin,

inside the range of my test parameters I get good linear and consistent dependencies, see the attached picture.

Dogleg: For me there is only one at 20ms with usb-traffic > 25. As I wrote yesterday, then the reachable framerate drops, that means, with 20ms I cannot use usb-traffics > 25. But why should I? So far I didn't observe other reasons for a dogleg.
But you have other hardware, can it be that the doglegs you observed are not only related to the usb-traffic/reachable fps but to other parameters?

For me, this is looking promising too , however what I actually didn't test are possible effects of fieldsize, binning, bit-depths ...

Christian

picture editet due to a wrong formatting within EXCEL.

Christian

[admin]

Okay,

that kind of makes sense that we get different results once the USB traffic controllers limiting the frame rate rather than the exposure limiting the frame rate. That will probably link into the ROI having an impact on the calibration – as a smaller ROI the point where the USB traffic becomes the limiter changes compared to a full frame imaging session.

I still think we need to cover both use cases – although some people will optimise their USB traffic to ensure that they get the best frame rate, others will prefer to keep a high value to get the best stability out of the camera.

Cheers, Robin

[admin]

Hi,

Right, I think I now have a good understanding of how the calibration values need to be calculated.

I believe that the values used for the calibration are based on cycles of a 75 MHz clock. I think that the zero point is likely to be the ending point of the previous frame (or some point
in time close to that).

The start calibration value should be set to the maximum of two calculated values, which I will call the interframe delay (IFD) and frame wait (FW).

The IFD corresponds to the value for low USB traffic settings where the frame rate is not being limited by the USB traffic value. This then represents some small delay between the previous frame ending and the next frame starting.

The FW corresponds to the value for hi USB traffic settings where the transfer of the frame to the computer is taking longer than the exposure time. In those cases it seems that the next frame cannot begin until a point in time such that the previous frames transfer will complete before the next frame exposure completes. I expect this is required to free up an internal buffer to hold the data from the upcoming frame.

The value of the IFD is given by a simple formula:

IFD = 1120 * USB Traffic + 6301 (gradient and offset are approximate)

The IFD does not seem to depend on exposure length, ROI size or bit depth.

The FW is more complex:

FW = C + A * USB Traffic - 75000 * Exposure (ms)

The factors C and A both depend on the ROI size (to be more precise, the height of the ROI). C also depends on the bit depth.

A = 79.7 * height + 4470
C = 445.2 * height + 27478 (8 bit)
C = 776.5 * height + 46266 (16 bit)

Again the coefficients and offsets are approximate, but the variation of the parameters is linear in the height with very little deviation.


Once the start position has been calculated, the end position can be calculated by

End Pos = Start Pos + 75000 * Exposure (ms) - 1903 - 277 * USB Traffic

The biggest factor here is the exposure time measured in cycles of the 75 MHz clock. The final terms are perhaps related to inaccuracies in the exposure time (i.e. that the exposure length is not quite the value that is requested by the camera software). These last two terms are more approximate, perhaps with more measurements we can get a better estimate of these.

I think that using these calculations will mean that SharpCap can estimate the correct start and ending calibration positions for any set of camera parameters and then provide sliders to allow fine adjustments over a range of values to home in on the exact calibration parameters required.

Any confirmation of these calculations or updates with more accurate coefficients would be welcome.

Cheers, Robin

[procyon12]

Hi Robin,

I think that using these calculations will mean that SharpCap can estimate the correct start and ending calibration positions for any set of camera parameters and then provide sliders to allow fine adjustments over a range of values to home in on the exact calibration parameters required.

That sounds very promising , good work!

I will test this as soon as possible, but this may take a few days due to other tasks.

Christian

[procyon12]

Hi Robin,

only a few values I could calculate so far. Can they be correct with regard to your formulas?

Christian

[admin]

Hi,

All are pretty close except for the bottom right one, where I get a start value predicted of about 62,000 and the actual start value is about 67,000.

Cheers, Robin

[procyon12]

Hi Robin,

I will check the values.

For the formulas above
download/file.php?id=2551
I have made a correction, there was a wrong EXCEL-formatting. Maybe this has relevance for your formulas?

Christian

[procyon12]

my calculation for start pos was wrong, see pic, added also the data from my trend-formulas.

Christian

[procyon12]

Hi Robin,

I made an additional test with: 8bit, H1000, 20ms and 200ms, traffic 1 - 50; calculated with your formulas and measured (except End Pos >10,000,000). I found good matches, see pic. I also attach the EXCEL worksheet.

Christian

edited, the lower right diagram was wrong.
Christian

[admin]

Hi,

Thanks for taking some more measurements which seem to confirm the patterns. I will try to release an update with the auto calibration code in over the next few days (although I'd like to make the adjustment range that you get around the auto calibration point wider if possible first).

Cheers, Robin