SharpCap 4.1 Beta Update - 16th January 2023

[admin]

Hi folks,

big changes this week to ASCOM device handling - please read on...

Download Link : https://d.sharpcap.co.uk/download.html? ... 0&arch=x64

ASCOM Device Retry/Reconnect Support

One of the things I notice in lots of uploaded bug reports is a common pattern. Something fails with an ASCOM device - for examply moving an 'XYZ' focuser fails or changing filters on a 'PQR' wheel. When I dig into what has happened in the run up to the failure by looking at the associated SharpCap log, I frequently find a USB disconnect event logged not long before the failure which looks like it is the failing device disconnecting from USB. Maybe the cable has been pulled slightly by a mount movement? Maybe the device has glitched and disconnected? Maybe the user pulled the plug deliberately? Anyway, whatever the cause, the error is being caused by trying to send a command to a device that isn't connected any more.

Previous versions of SharpCap would have just popped up a message to tell you that there was a problem with your XYZ focuser. This new version takes a different approach...

In the case of a failure of a significant action (ie move a focuser or filter wheel, slew, sync or move a mount, etc), SharpCap will run through a retry sequence automatically:

* First retry - just send the command again - if it was just a temporary glitch this may well succeed.

* Second retry - try to disconnect and then reconnect the device. If the reconnect succeeds, send the command again.

Possible outcomes :

* First retry or second retry works and command is sent successfully - all is well - SharpCap will continue with whatever it is doing.
* Second retry reconnects but the command fails again - show failure message very much like the old SharpCap used to.
* Second retry fails to reconnect the device - show a message explaining that the device is probably no longer connected and prompt the user to check the connection - for instance

Capture.JPG (45.39 KiB) Viewed 777 times

The user can try the 'Reconnect Hardware' button - possibly after checking the connection or even unplugging then reconnecting the device to reset it.

Hopefully this will provide a much more user-friendly way to deal with issues related to devices disconnecting.

Note that if you are using SharpCap automation (ie the Sequencer or similar), you will just get the two retries happening, not the 'Reconnect Device' window shown above - instead the sequencer will log the error and stop if both retries fail.

Python Scripting update to Python 3.4

The Python scripting in SharpCap has been running Python 2.7 up to now, but finally there is a version of IronPython available that supports Python 3.4 - I have now incorporated this into SharpCap.

Python scripts may need updating to reflect the change from Python 2.7 to Python 3.4 (in particular, 'print x' becomes 'print(x)' ).

I have added the same site-packages to the standard python library packages as before - that is 'six' and 'pyro4'. If any scripting users have ideas for useful additional default packages (must be small, and pure python rather than using native libraries), please let me know.

Code cleanup

I have done a big code cleanup and modernization in this release. The changes are done by automated tools, so in general what the code does should be exactly the same after the changes as before. However, there are hundreds or even thousands of small changes being made, so it is possible that some could have side effects. Do report any new bugs!

Code: Select all

Other Features

ADC alignment now has an option to calculate the channel misalignment from image features rather than from the center of brightness. This should allow the ADC to be aligned on a lunar image where the moon fills the whole (or most of) the screen. However, there seems to be more noise in the alignment figures calculated this way, so be sure to turn up the 'averaging' setting to average over 5, 10 or even more frames.

As usual, various bug fixes have been made, and this SharpCap 4.1 beta includes the new ZWO SDK and other bug fixes included in SharpCap 4.0.9529

cheers,

Robin

[jolo]

Hm, I am not able to download from this link

Sorry! The address you followed (or typed into your address bar) doesn't match up with any pages on this website.
https://d.sharpcap.co.uk/file/4a2b94df- ... 23df72_x64

[admin]

Argh, the download page only worked for version numbers up to 9999 - now we are at 4.1.10024 it fails.

I have fixed the issue now, but the bad result may be cached in your browser. If it still fails, please copy the link above into a different web browser (ie MS Edge) and it should work.

cheers,

Robin

[Borodog]

blah blah blah lunar ADC blah blah blah

Yay!

[admin]

Ah, but I would be interested to hear how well it works

In testing it could clearly pick up deliberate misalignment of the channels in a static image, but testing on live, noisy, images revealed a lot of variation from frame to frame... Hopefully with enough averaging it will settle down to a usable figure, but I don't think it will be as accurate as the center of brightness measurement.

cheers,

Robin

[Borodog]

My hope is that like planetary, any approximation to the right amount of correction will be close enough.

[celkins]

Robin,
I couldn't call this a bug, but maybe sub-optimal behaviour?
I started a live stack on M42 with an H-Alpha filter, looking for max dynamic range, and thus BRAIN recommend 5 minute exposures... I usually use sigma-clip stacking, but on this occasion thought I might as well go with averaging, since M42 is likely to pass into my "zone of avoidance" before I've got enough to matter, but after the first sub arrived, I changed my mind, and switched to sigma-clip, causing SC to throw out my sub. Now with only 1 frame collected, why is this necessary? The only thing I can think of is if you only accumulate stats for the sigma-clip as each sub comes in: would it be difficult to deal with the case of changing to sigma-clip with only the first sub collected by just running the stats, rather than ditching the frame?

Cheers,
Carl

[admin]

Hi Carl,

it's to do with the way that the different stacking modes are implemented - there is a calculation engine that processes the frames and keeps track of the results so far for each mode (default, sigma clip, maximum value). When you change the stacking mode the existing engine is discarded and a new one (of the correct type) is created.

I guess, in theory, I can feed the single (most recent) previous frame to the new engine, since I hang on to a copy of that in memory in case you switch from 'view stack' to 'view frames'. I will have to look to see if that will work or not.

cheers,

Robin

[Xio1996]

Hi Robin,

I was observing last night (EAA) and came across a possible bug (it could just be me). I was observing using 15 seconds subs but the Camera Settings text file reported I was using 2s exposures. The final image name was Stack110frames_1650s... which I think means SharpCap knew I was using 15s subs.

I have copied the Camera Settings file below.

As an aside, I'm really loving the 4.1 betas. I really like the new functionality of keyboard shortcut's to zoom (100%/Auto) and the ability to flip the image. Thank you for adding the ability to find out the Live Stack saved images pathnames in the scripting object model, very useful.

Many thanks

Pete

[AA294CPRO]
FrameType=Light
Debayer Preview=On
Output Format=PNG files (*.png)
Capture Area=3744x2808
Binning=1x1
Pan=192
Tilt=0
Colour Space=RAW14
Fan=On
Temperature=5.1000000000000005
Black Level=20
USB Speed=2
Auto Gain with Auto Exposure=Off
Auto Exp Target=120
Frame Rate Limit=4 fps
Analogue Gain=900
Exposure=2.000s
Timestamp Frames=Off
Trail Width=6
Minimum Trail Length=100
Trail Detection Sensitivity=11
Mask over exposed pixels=Off
Flip (after dark/flat)=Horiz
Remove Satellite Trails=Remove
Background Subtraction=Blended Offset
Planet/Disk Stabilization=Off
Banding Threshold=40
Banding Suppression=40
Apply Flat=C:\SharpCap Captures\2023-01-19\Test\flats\MasterFlat_18_10_23_offset=0.093%.png
Hot Pixel Sensitivity=9
Subtract Dark=C:\SharpCap Captures\darks\AA294CPRO\RAW14@3744x2808\15.0s\gain_900\MasterDark_20_frames_5.5C_2023-01-19T18_49_01.png
NegativeDisplay=0
Display Black Point=0
Display MidTone Point=0.5
Display White Point=1
Notes=
TimeStamp=2023-01-21T19:07:19.8162120Z
SharpCapVersion=4.1.10024.0

[admin]

Hi Pete,

were you using PHD2 and dithering? When you have those enabled, SharpCap will change the exposure time to 2s during the dither operation (to avoid wasting whole long exposures because part of them happened during the dither). After the dither is complete, the exposure should change back, but I found a bug in that code in 4.1 last week (fix will be in today's update), so maybe you hit that bug and the exposure was not changing back?

Glad to hear that you are enjoying the other features in the beta - I have quite a few new ones to introduce this week

cheers,

Robin