QHY 174 GPS Calibration LED issue // USB Traffic weirdness
Re: QHY 174 GPS Calibration LED issue // USB Traffic weirdness
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
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
- Attachments
-
- vgl2_20ms-left_sgn1_corr.png (123.45 KiB) Viewed 2879 times
Last edited by procyon12 on Fri Feb 07, 2020 5:05 pm, edited 1 time in total.
- admin
- Site Admin
- Posts: 13280
- 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
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
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
- Site Admin
- Posts: 13280
- 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
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
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
Re: QHY 174 GPS Calibration LED issue // USB Traffic weirdness
Hi Robin,
I will test this as soon as possible, but this may take a few days due to other tasks.
Christian
That sounds very promising , good work!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.
I will test this as soon as possible, but this may take a few days due to other tasks.
Christian
Re: QHY 174 GPS Calibration LED issue // USB Traffic weirdness
Hi Robin,
only a few values I could calculate so far. Can they be correct with regard to your formulas?
Christian
only a few values I could calculate so far. Can they be correct with regard to your formulas?
Christian
- Attachments
-
- 16bit_h480_exp20+100_trfc5+50.png (6.84 KiB) Viewed 2895 times
- admin
- Site Admin
- Posts: 13280
- 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
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
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
Re: QHY 174 GPS Calibration LED issue // USB Traffic weirdness
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
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
Re: QHY 174 GPS Calibration LED issue // USB Traffic weirdness
my calculation for start pos was wrong, see pic, added also the data from my trend-formulas.
Christian
Christian
- Attachments
-
- ClpBrd2.png (10.86 KiB) Viewed 2872 times
Re: QHY 174 GPS Calibration LED issue // USB Traffic weirdness
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
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
- Attachments
-
- 8bit_1200xH1000_exp20+200_trfc1-50_calc+measr_cr.7z
- (20.02 KiB) Downloaded 108 times
-
- 8bit_1200xH1000_exp20+200_trfc1-50_calc+measr_cr.png (51.25 KiB) Viewed 2842 times
Last edited by procyon12 on Sun Feb 09, 2020 11:00 am, edited 1 time in total.
- admin
- Site Admin
- Posts: 13280
- 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
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
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