ASCOM / On Step Bluetooth connection broken as of 4.1.10827

[mfs4n]

I was actually coming here to whine about the AutoFocus runaway problem, only to find it addressed. I downloaded the latest Beta to get the fix, but found that I could no longer connect to my On Step mount via Bluetooth over COM. I could not even bring up the Properties menu in the Hardware configuration tab. I have no problem connecting to the On Step with the ASCOM device hub or older versions of Sharpcap Beta than the one listed in the subject line.

Instead, when the initial automatic connection to the mount fails I see Error Code: 0x80040407. I've also attached an image of the error message that pops up when I try to bring up the Properties for the OnStep in the Sharpcap Configuration Hardware tab... and of course the Sharpcap Log.

I basically reverted Beta versions until things worked again. The problem seems coincident with the comment "Improved handling of situations where an ASCOM mount unexpectedly disconnects". It also happens to be the version where you fixed the focus runaway.

=======

While I have your attention. First, let me thank you for all the effort you've put into autofocus. The FWHM focus is absolutely essential to my observational niche, which is scheduling several occultation observations with the sequencer and then going to bed. Just a few thoughts I've had while trying to wrestle the autofocus into submission.

- A little bit of windshake or glitchy tracking throws a monkey wrench into consistent measurement of the focus from focus setting to focus setting, even with averaging. I would much rather see the *option* to use the "best of" at each focus position. The individual frame focus measurements are quite robust, as you can see from how small the uncertainties are when things are well behaved. "best of" should yield a more consistent set of points for the parabolic fit when the images are jumpy. This leaves you without statistical uncertainties, so maybe a problem for the subsequent fit.

- The fixed SNR threshold for selection of the focus stars becomes a problem for the more extreme points on the focus curve where you would like to start/end nearly at donuts. The result is you get the dreaded "25" at those points and the focus graph rescales to that massive y-axis. I have no idea how the "25's" enter into to the parabola analysis (I'm guessing those points get tossed). I don't know if there's a way to have an adaptive SNR threshold that anticipates that the extreme images will be at lower SNR. The images aren't close to Gaussian at that point. "Too Few Stars" comes back to bite you just when you really want those off-best focus images. One thought for a distant future, if you do a autocorrelation of the image you can get out the FWHM from the width of the autocorrelation peak basically using the information from every star in the image. This will only work well in non-nebular regions, but could be more robust than using individual selected star FWHM measurements.

=======

Finally, another topic unrelated to the subject line, because of the occultation timing requirements, my most useful sequencer command is WAIT UNTIL LOCALTIME xx:xx. The bad news is that if I miss that time by even 1 second because of a long platesolve or focus the sequencer is then sitting there waiting until the next occurrence of that time 24 hours later, so I'm dead for the rest of the night given that the telescope is unsupervised. Usually this is easily scheduled around but sometimes I have to cut it close if two events are occurring within a few minutes of one another. It would really be nice to have "just missed it" logic or a parameter for the command so that if the wait until time is 2 minutes in the past the sequence will just drop through the wait and keep going.

Thanks for everything,
Mike.

[admin]

Hi Mike,

phew... lots of bits in that post!

Firstly on the focuser connection, that's really odd because I didn't make any changes to the hardware connection code between 4.1.10790 and 4.1.10827. Also the error message in the log file looks like one you would expect to see if the ASCOM driver is not properly registered. I'm wondering if you have perhaps switched between the 32 and 64 bit versions of SharpCap 4.1 as you were changing versions. Sometimes you can get ASCOM drivers that only register for 32 bit use (possibly even only 64 bit - not sure I have ever seen that though). Alternatively the registration for one or the other can get damaged in the registry for some reason.

I would suggest the first thing to try would be to uninstall completely and then reinstall the ASCOM driver for the OnStep and see if that resolves the issue.

On to focusing...

I *think* that if you use the adjustments in the 'Averaging' tab on the left hand side, you can set the option to 'Show : Best Score' and 'Average over : 5 frames'. With those options set, 5 frames captured will count as '1 sample' for the autofocus scan, and it should take the best score of the 5 frames as the value for that one sample, which is pretty much what you wanted I think. If you set two samples in the focus scan options then it would take 2 sets of 5 frames, take the best score from each 5 and average those two values. It's certainly worth a try...

As you note, 25 is a 'no stars' value - aimed to be higher than any realistic FWHM measurement that you are likely to have. They should be ignored from the curve fitting point of view. You can re-scale the focus graph (use the mouse wheel) and drag it around to look at different parts when zoomed in if you want to. I think the zooming is uniform mind you.

If you can share a couple of images showing the donut stars that are causing issues then I will gladly analyze how they behave under the star detection to see if there is any easy adjustment to make it more likely to spot the stars correctly (hopefully without breaking anything else!).

I see what you mean about the 'wait until time' step - with the wait steps that wait for dawn/dusk/etc you have the option of either until past that point or until the *next* event... Not so with wait for time. How about a 'wait until later than' step?

cheers,

Robin

[mfs4n]

Thanks, Robin, for all of the suggestions.

Indeed I had accidentally loaded a 64-bit beta version at one point but I'm pretty sure I reverted back to 32 and was still seeing the problem. I'll double-check. You did mention looking at a focuser connection problem in the log, but my problem was with the telescope controller (OnStep) so I just wanted to make sure you were looking at the right spot in the log. In the meantime I might re-install the ASCOM driver for OnStep and see if that cleans things up.

Thanks for pointing out the features of the focuser on the left side that allow you to home in on the best sample. I'm in the process of trying different configurations to see what is optimum. It's probably address in another thread but sometimes I see what looks like a very fitable sequence and the autofocus makes no attempt to display its parabolic fit and fails (by the way, thanks for returning to the original focus start point when you have a failure - which is the reason I started using this Beta). Most of the time, though, the fitting works well.

I narrowed down my autofocus range to stay away from the donuts and am happy with the result. As you noted, it's probably not a good idea to modify the code for that special regime as you risk breaking something else.

"Wait until later than" is exactly it. If i have set WAIT UNTIL LOCALTIME 06:32 and it gets to that step at 06:34 i want it to drop right through and keep going.

Thanks,
Mike.

[admin]

Hi Mike,

good news...

I think I have found the cause of the OnStep issue - a slip up on my part in the code between those two versions. Unfortunately when I first investigated I was concentrating on the focuser code (probably because I was thinking of 'OnStep' as a focuser), even though you had quite specifically shown an error message relating to the mount controls. Anyway, issue now found and fixed and I will release that in an update on Monday.

I also had a look into the problem of focusing on donuts and found that the code I was using to detect bright blobs in the image was testing the central pixel of any possible blob to check it was a bright blob rather than a dark blob. Ooops... That doesn't work for donut stars at all. I have adjusted the code now to search for bright pixels within the potential blob, rather than just test the center and it should improve matters (perhaps even fix the issue entirely).

I will add the 'wait until later than' step - it's a nice easy change.

cheers,

Robin

[mfs4n]

Hi Robin,

Thanks so much. Looks like that's 3 for 3 for fixes and useful mods. I'll try everything out when the new Beta posts.

Mike.