Feature Tracking Calibration "Failed due to inconsistent scales from Axis X"

[Borodog]

So, just to clarify, would you suggest using the full sensor during calibration and choosing a very large "Required Movement", like 500 pixels? Would that maximize the chance that SharpCap will (a) actually take up the dec backlash, and (b) return values that will not result in failure?

By the way, when SharpCap is attempting to calibrate, is it *assuming* there is no backlash? I.e., is it attempting to determine the two rates (x & y) and hence the angle by dividing the resulting movement (along an axis) by the total commanded movement neglecting the possibility of backlash? If you do that you will always get bad rates, and the worse the backlash, the worse the rates.

If instead, you allow the mount sufficient time to take up the backlash and then calculate the rate from only the most recent few samples, you will not only get accurate rates (and hence an accurate angle), you can also calculate the X intercept from the same most recent samples, i.e. the backlash.

backlash.png (30.15 KiB) Viewed 676 times

[admin]

Hi,

so yes, I think the bigger minimum movement may help.

The calibration code does take account of the sort of 'dog leg' graph that you have shown - it basically looks for the point where cutting the graph in two at that point gives the best straight line correlations in the two separate sections. There are also requirements that the second section has to have a gradient and that the correlation has to explain at least a certain fraction of the variance in the second section too.

cheers,

Robin

[Borodog]

Thanks, Robin.

Can you elaborate on what this means:

" . . . and that the correlation has to explain at least a certain fraction of the variance in the second section too."

Are you saying that you have to have something like a minimum R value for the fit in the second section? If so, what is that R value?

By the way; is the data in the guiding log sufficient to reconstruct a graph like the one I posted above?

Mike

[admin]

Hi Mike,

yes, you should be able to reconstruct the graph from the guiding log data - look for lines that contain MountOffset= and ImageOffset= - those values are the total mount movement requested since the start of that calibration stage and the total image offset recorded since then, respectively.

Looking at the code for the regression check, there are comments that indicate that the r^2 limit was once 0.9, but the code for that check seems to have gone, meaning that almost any r^2 would pass that point (although if it was a random correlation it would fail later at the point where it is compared to the opposite direction).

The way that the backlash is handled is that to furthest movement of the image during calibration is calculated and the points are used where the total movement exceeds 25% of the furthest movement. So, to look back at your graph as an example, the points where the measured movement is >2.5 would be used for the regression measurement, which would give the correct rate.


cheers,

Robin

[Borodog]

Thanks. Should be clear but poor seeing tonight, so I will have plenty of time to do nothing but try to figure out the magic settings to get this to work. Hopefully a very large required movement will do the trick.

[Borodog]

The "required movement" field only goes up to 100. Maybe it helped? Sometimes calibrated, sometimes failed. It still appears to me that SharpCap is simply not allowing the dec backlash to be taken up and then enough time for a clean measurement.

GuidingLog_2022-11-18T18_17_03-6648.log

(278.5 KiB) Downloaded 56 times

[Borodog]

By the way, I added a guide scope to the rig tonight so I could polar align accurately instead of roughly. I put it to within an arc-minute, still offset east to only drift one way in dec.

Thinking about this, it seems like the extremely short time SharpCap allows to try to calibrate guiding is bound to be a problem. PHD2 takes MUCH longer to calibrate (minutes) and produces clean graphs in doing it and guides well. The few points that show up in the graph in SharpCap over the few seconds it allows for calibration in dec appear almost random, clearly dominated by the motion of the target due to the scope bouncing around a bit in the slight breeze.

[admin]

Hi,

if you are seeing a maximum value of 100 for 'Required movement' then I think your SharpCap is out-of-date. I changed that on the 3rd November to have a maximum of 250 not 100. With version 4.0.9455 or later you should see a maximum of 250 (and the maximum value is obeyed rather than ignored). If you have been using 4.1 for this testing then I think the problem is that I have not had a chance to update 4.1 for a couple of weeks, so the latest 4.1 may not have this change yet.

Certainly any bouncing of the image that exceeds the required movement threshold could lead to a premature end to calibration and bogus results. The bigger threshold should definitely help if this is part of the cause.

cheers,

Robin

[Borodog]

I was using 4.1.

[Borodog]

Ok, update on this. I installed the updated 4.1 beta (not today's) that included the larger allowable required movement, up to 250 pixels. I polar aligned with a guide scope to less than an arc-minute. I made the mount east heavy to keep the RA gear engaged. Other than the significant DEC backlash, the mount responded well to the hand controller, there was not a significant amount of drift. There was quite a bit of bounce from ground level wind at 2800mm.

I used the entire ROI for feature tracking. First, I got complaints about low contrast unless I set the minimum contrast to 0%. Don't know what the implication of that is. Second, setting the minimum movement to 250 pixels didn't really help at all. In fact, it made it worse. What would happen is that the planet would start moving and then it would eventually stop, short of the 250 pixel requirement. It was apparently still sending commands, but the planet was no longer moving, so it never reached 250 pixels, and would stay in this state indefinitely if I didn't cancel it. So I cut it in half to 125 pixels, which it seemed to be able to reach. But then of course it failed because of "inconsistent scales from axis X".

I did realize that changing the motor speed on the hand controller also changed the way feature tracking worked, which I never quite realized before. I eventually changed settings randomly until I finally got a successful calibration and after that feature tracking worked just fine, but I have no idea why the settings I ended up at worked when other settings didn't.

GuidingLog_2022-11-27T19_00_20-9992.log

(92.37 KiB) Downloaded 57 times