Auto-tune QHY GPS Calibration End Pos

Got an idea for something that SharpCap should do? Share it here.
Forum rules
'+1' posts are welcome in this area of the forums to indicate your support for a particular feature suggestion. Suggestions that get the most +1's will be seriously considered for inclusion in future versions of SharpCap.
Post Reply
Kai Getrost
Posts: 21
Joined: Sun Jun 07, 2020 2:36 pm
Location: US

Auto-tune QHY GPS Calibration End Pos

#1

Post by Kai Getrost »

With SharpCap 3.2.6248 and a QHY174M-GPS camera, the computed GPS Controls -> Calibration Start and End Pos values are close -- but often slightly incorrect -- for my setup. The net effect is that I often get BadCalibrationReduceEndPos in GPS Status -- and no valid GPS timing, which is critical for me for occultations. I work around this by manually calibrating of course, but then have to do that for nearly every Exposure/Binning/Capture Area/USB Traffic/etc. setting change (because auto-computed End Pos is so often just a bit too large), so I end up creating and calibrating a lot of profiles.

In my experience/setup, the point where BadCal... starts to occur is always within 0-2 End Pos counter values (single, least-significant digits) of when I'd stop anyway per the documented procedure. I.e. 0 to 2 clicks up (in the off-LED-direction) from where the LED just goes completely out, gives me BadCal..., as will any value larger than that. And it occurs the very next frame after that (too-large) End Pos is set. This behavior is consistent across every Exposure/Binning/Capture Area/etc. change for me.

Given this strong correlation between the desired End Pos and the BadCal... message, and how quickly it appears (next frame after the bad End Pos is set), I'm wondering if an "Auto-tune End Pos" setting can be implemented. This would binary-search for the correct End Pos, based on when it just barely (1 counter value change) triggers BadCal... (and then maybe adds 1 or 2 for safety?). The currently computed value is pretty close for me; only a few tens of thousands off typically, which a binary search should be able to reduce in 10-15 frames. Even if End Pos is way off -- or we ignore the pre-computed End Pos and start from some huge max like 100 000 000 -- binary search would get there in 27 frames. (Yes this gets worse for longer exposures, both because they take longer to expose and because the correct End Pos is larger. But realistically, the starting point -- currently-computed End Pos -- is much closer, so long waits shouldn't happen much I think.)

Since there's no error for a bad Start Pos that I see, I don't see a way to auto-tune Start Pos (at least not without significant frame analysis to look for the LED). But a bad Start Pos doesn't cause full GPS timing failure the way a bad End Pos does, so that's less critical for me.

In my mind, enabling this Auto-tune End Pos would cause it to do the binary search for End Pos whenever SharpCap changes End Pos. I.e. whether it sets End Pos via computation (because Exposure etc. was changed), or from a preset (because a profile was loaded). And the on/off setting value would be saved in profiles as well. This way, one could preset End Pos for a profile -- and on loading have SharpCap leave it alone (Auto-tune Off) or try to automagically adjust (Auto-tune On), in case the preset is no longer valid, or the user adjusts Exposure etc. after loading the profile (triggering Auto-tune). A popup of "Auto-tuning End Pos..." could appear (same style/location as the one-line "Capture complete" popups) while auto-tune is in progress, letting the user know that End Pos is in flux. Since BadCal... seems to occur even with the LED off, turning on the LED during the auto-tune wouldn't even be necessary I think.

Some sanity checking would need to be in the search procedure, because I have had setups where a BadCal... status caused by an End Pos change is then not undone (back to Locked) by undoing that End Pos change. (This occurs on USB2 ports for me, for example. But I no longer use them.) Such a scenario would make binary search fail of course, because the search space isn't "sorted" reliably. Bailing on the auto-tune if it fails to converge in 35 frames -- and restoring the starting (formula-computed?) value -- would be sufficient I think.

It might be a bit annoying waiting for this Auto-tune to trigger and settle on every Exposure/Binning/etc. change, so most folks would leave it Off. But if those settings changes often cause the BadCal... message (i.e. for me), waiting a few seconds for Auto-tune would be much faster than manually tuning.

I'd be happy to alpha-test any sort of implementation of this feature, to see if it helps with my setup. Thanks.
Kai Getrost
Posts: 21
Joined: Sun Jun 07, 2020 2:36 pm
Location: US

Re: Auto-tune QHY GPS Calibration End Pos

#2

Post by Kai Getrost »

and then maybe adds 1 or 2 for safety?
Correction: subtracts 1 or 2.
User avatar
admin
Site Admin
Posts: 13173
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Auto-tune QHY GPS Calibration End Pos

#3

Post by admin »

Hi,

I did actually wonder about something like this at the time – reducing the end position by one every time a bad calibration frame comes in would be the simplest approach. Unfortunately I just ran out of time available to work on that particular feature any further. It will certainly be something to consider when I have a few more time to dedicate to the GPS camera.



Cheers, Robin
Kai Getrost
Posts: 21
Joined: Sun Jun 07, 2020 2:36 pm
Location: US

Re: Auto-tune QHY GPS Calibration End Pos

#4

Post by Kai Getrost »

admin wrote: Wed Jun 10, 2020 8:09 pm I did actually wonder about something like this at the time – reducing the end position by one every time a bad calibration frame comes in would be the simplest approach.
...
Yep. But for me, the computed End Pos is often too large by well over 1000, so such a linear decrement could take 8 minutes or more on my 500ms default profile. I'd plead for a binary search. :)
Post Reply