Interaction between Flip and Feature Tracking

[Borodog]

Not really a bug, but unwanted behavior. Turning on image flip after Feature Tracking calibration causes correction to be sent with the wrong sign.

Cheers,

[admin]

Hi Mike,

how about using the 'Flip (after dark/flat)' option in the preprocessing controls? That's now the preferred way to flip/rotate the image, as it happens later in the processing inside SharpCap code rather than inside the camera SDK code. I *think* that will avoid the problem because the feature tracking hooks in and looks at the image before the processing happens.

cheers,

Robin

[Borodog]

Ah yes; the flip I was using is a camera control as I recall, so happens upstream of SharpCap. Thanks.

A couple of other small issues I noticed last night:

As of this last or a recent update I can no longer connect two instances of SharpCap to the mount via ASCOM/the Celestron Telescope Driver at the same time. I used to be able to do this, using one instance with my guide scope and camera for GoTo and the other with the main scope and camera for feature tracking. As of last night, connecting the second instance throws an error and requires me to disconnect the first instance; after that the second instance connects properly.

This one is really bizarre. There appears to be an error in the calculations for the channel offsets in the ADC tool. I have never seen this before, but it was clear that the calculated channel offsets were dependent on the location of the planet's disk in the FOV; the farther the planet was from the center of the FOV, the larger the calculated offsets became. When the planet was near the edge of the FOV, the calculated offset were absolutely huge (dozens of pixels). I was able to get around it by using feature tracking to drive the planet to the center of the FOV, but there seems to be an error in the calculations. I don't know when this was introduced, as I have been using the planetary live stacker for setting my ADC for a long time, ever since I realized that the ADC tool had excess precision that I was chasing. I decided to given the ADC tool another go and immediately noticed the issue.

Cheers.

[admin]

Hi,

I did update the ASCOM libraries I use in Monday's version of SharpCap, but the changes in those looked innocuous (mostly handling existing errors more nicely). What error do you get from the Celestron driver? I had the impression that the older Celestron driver ran as part of the SharpCap process, so it opens the serial port to talk to the hardware and that means another process can't use the serial port. CPWI on the other hand does the communication in a separate process, so multiple apps can connect. If it is a serial port cannot be opened error then the fix is usually to use the ASCOM Device Hub (and puzzle would be how it ever worked...)

I will have to look at the ADC alignment stuff - did you have the black level threshold set accurately so that only the planet and a few pixels around it were above the shaded black area? All bets are off if that is not set correctly...

cheers,

Robin

[Borodog]

Robin,

Regarding the error thrown when connecting the second instance of SharpCap to the mount, It was a VERY large error box full of text. I'll try to reproduce it the next time I image.

Regarding the ADC tool, yes, the black level was properly set. Only the planet and a very small region around it were not masked out.

[admin]

Hi,

OK, will have a look at the message for interpretation when you have the text of it.

I just tested the ADC alignment on an artificial source with the camera ROI moving around to place it in different parts (center, corner, edge, etc) of the FOV, and the readout is pretty much constant regardless of where the light is in the FOV, so I think it is not the software miscalculating the offsets. At least that's the case with a simple setup - maybe other camera options like flat correction could have some impact on this.

cheers,

Robin

[Borodog]

Hmm. I'll try to reproduce it next time and screen record it. The effect seemed pretty clear at the time, but maybe there was something else going on. For example, if I adjusted the ADC, which caused the image to jump off-center, while simultaneously causing a blur that was interpreted by the algorithm as a large offset.

[Borodog]

Robin,

Finally had a chance to image again. Here's the error that pops when I attempt to connect a second instance of SharpCap to the mount like I used to:

SharpCap_error.jpg (778.71 KiB) Viewed 28 times

Once again disconnecting the first instance allows the second instance to connect just fine now, but it used to work fine having both connected.

The ADC problem did not come up, but I was too busy to test for it specifically; I just kept the planet close to the center of the ROI while adjusting the ADC with small movements, and letting Feature Tracking guide the planet back to the center. If I have time while imaging to reproduce it (and can) I'll let you know.

Cheers,

Mike

[admin]

Hi Mike,

since it used to work, I can only think that something has changed in ASCOM - either the platform itself or the libraries that SharpCap uses to talk to the platform. I checked the Celestron ASCOM driver you are using and it is an .exe driver, so it runs in its own process. That means that (in theory) multiple clients should be able to talk to the same driver without issues (DLL based drivers that run in SharpCap's process will always hit this sort of 'cannot open COM port' error if you try to access the hardware from two versions of SharpCap). I suspect that if you went and looked in the process list in task manager at the point of the error you would find two ASCOM.Celestron.exe processes - one which is actually in control of the mount and one that is failing to connect and therefore giving the error.

Your best bet is to just sidestep the issue entirely and use the 'ASCOM Device Hub' telescope driver - the whole purpose of that driver is to deal with this problem and let multiple applications access a single piece of hardware. You set SharpCap up to talk to the device hub telescope driver, and set the device hub up to talk to the Celestron driver. All commands go via the device hub, which makes sure they are all routed to a single version of the Celestron driver and the sharing plays nicely.

cheers,

Robin

[Borodog]

Thanks Robin. I'll try that.