Auto recenter in live-stack units (pixels currently)

[admin]

Hi Mike,

yes, a second camera should work a treat - either running alignment in SharpCap or (probably easier) using it with PHD2 for autoguiding.

Good to see that the images are coming out well - the second one is particularly clear and seems to have less field rotation artifacts in it. Did you get any idea from the live stack log of why some images failed to align? It's quite unusual to have that happen unless there is a problem detecting stars in the raw frames.

cheers,

Robin

[MikeHuerto]

Hi Robin

PHD2 would be great if it worked with my Synscan controlled Dob mount - unfortunately, it does not work with the Synscan Az/Alt app - neither does SharpCap Feature tracking or Firecapture Autoguide - it appears that the guide pulses disable tracking - and the image starts to drift. This is one of the reasons I, and other Synscan Alt/Az users cannot calibrate SC feature tracking on Synscan Alt/Az mounts. I did once try calibrating Feature Tracking on a fixed artificial star. This worked fine, because the star was not moving, BUT when I slewed the scope to Jupiter, it could not track it - as soon as a pulse was sent tracking was disabled. FYI, PHD2 works fine with the same Synscan app in EQ mode with my HEQ5-130PDS combo, so it appears to be a problem with the Alt/Az version of the Windows Synscan App. I have requested Skywatcher fix this bug, but so far nada!

Somehow there appears to be a difference between the recentering guide pulses after plate solving and those issued by PHD2 or SC feature tracking (since plate solving and recentering works fine - as does your new autocenter tool. SO could you design a planetary feature tracking tool that used the recentering type of pulses for callibration and tracking?

As regards the failure to align, I did not check the log in detail, but I assumed that it was because of elongated stars or similar problems with the raws - unfortunately, I had it set to save stacked only. I'll see if I can dig out the logs and send them. I have some screenshots of the FWHM and failures I can send you as well.

The other thing I noticed was that it helped if I increased the number of pixels drifted to 100. Originally, I had it set to 20, then 40, and it seemed that it was trying to check to frequently - and perhaps did not have time to settle or clear backlash.

For the photos - the first one is the Display as seen image from SC, the second one is processing of the 988 saved raw files in Pixinsight, between DBE, background normalizations etc, it's pretty good and removing all kinds of gradients and artifacts.

Best

Mike

[MikeHuerto]

Robin

I´ve attached part of the log for the session between 21:00 and 21:20. Also attached are three screenshots showing the FWHM and rejection status for some of the captures during that time frame.

Please let me know what you think

Mike

[admin]

Hi Mike,

thanks for the updates - the dropped frames make more sense now that I am thinking in terms of them being excluded by the FWHM filter deliberately rather than being unintentionally lost by lack of alignment. I suspect that maybe tracking glictches could have led to the higher FWHM of some frames, but you would really have to look at the individual frame images to be sure.

Now... the recentering and feature tracking. Again it's useful to know the why behind the request.

Recentering during live stacking and after plate solving is done by sending GOTO commands to the mount - basically telling it to move to a new set of co-ordinates. That obviously leaves the mount tracking. Feature tracking and some other features in SharpCap are handled a different way - they send direct movement commands to the mount - like 'move the Azimuth axis at 0.05 degrees per seconds for 1.2 seconds'. It sounds like that is leaving the mount in a non-tracking state, but all is not lost because there is nothing to stop me writing code that tries to re-enable tracking after finishing the move. In fact SharpCap already has code that does this, but it is currently limited to EQ mounts only. If you are interested in trying out a test version that tries to reset the tracking for AltAz mounts, please let me know.

cheers,

Robin

[MikeHuerto]

Hi Robin
Yes, I would absolutely like to test Feature Tracking with a new code that would re-enable tracking. This new code would also need to be included in the calibration step.

Can you also write a reenable tracking' for PHD2 after the mount receives a move signal from PHD2? That would be quite amazing since it would allow me to use PHD2-enabled guiding, which might allow me to extend exposures beyond 4 seconds. I would also be very happy to test this. I have guide camera and guide scope from my 130PDS that I can use on the Dob.

I will repeat the autocenter test, and this time will set it to 'save all frames'. The next test will make use of my Pegasus Falcon Rotator. This should help with alignment.

By the way, is there a way to get SC to sort non-stacked images into a separate folder? That would greatly assist in determining why the frames are being rejected.


Best

Mike

[admin]

Hi Mike,

I'll let you know once I have a version with the re-enable the guiding on Alt-Az movements. I can't really do the same when PHD2 commands the movement as my route to doing it at the right time is knowing when SharpCap is finishing a movement command. Trying to reset tracking after PHD turns it off will always introduce some delay when it is not tracking and that will cause further issues. I presume that PHD2 is sending pulse guide commands to the ASCOM driver, so the fact that it stops tracking in response to that is a pretty critical issue in the ASCOM driver.

Right now there isn't a way to separate the stacked/unstacked images, but SharpCap can save a CSV file for each stack that records the name of each image and whether it is stacked or not along with some other key info, so that might help.

cheers,

Robin

[MikeHuerto]

Hi Robin
Ok, I eagerly await the arrival of the version renable tracking on Alt/Az movements!


As for PHD2, I will attempt to pursuade the folks at PHD2, I am in their user group group on Google


I will also try again with Skywatcher. To me it seems strange tha its not a problem with the EQ version of synscan, I use the same app, from the very same PC for my HEQ5 mount. To help me persuade them, can you think of any reason why pulse guides would turn off tracking in the Alt/Az mode, and not in the EQ mode of the synscan app?

Ta

Mike

[admin]

Hi Mike,

I can understand I guess, since for an EQ mount, tracking is just a matter of moving one axis at a constant rate. An AltAz mount has to constantly calculate varying rates and be moving both axes at once - that's done by the microcontroller in the mount or maybe the handset, which is pretty basic and low powered in terms of the calculations it can manage no doubt...

Now, if you want to pulse guide, really you need the mount to move at its normal rate in the RA direction plus or minus some extra amount (depending on direction). Again, not hard for an EQ mount, but extra maths for the AltAz mount to try to add the guiding movement onto the tracking movement - maybe the microprocessor isn't up to it (or isn't programmed to handle it). It's no good if the mount stops tracking during pulse guiding, as the result would come out all wrong.

So, maybe the hardware just doesn't support pulse guiding in AltAz mode, in which case the ASCOM driver should make that clear, rather than pretending to implement it and not doing it right.

For SharpCap feature tracking I have some hope of a workaround, since you might use 16x movement rate for feature tracking - even if normal tracking stops during the 16x move, the amount of movement lost due to tracking being off is small compared to the 16x movement. I'm not hopeful for that working using the pulse guiding speed in SharpCap, or in PHD2 - the amount of movement lost would be similar to the guiding movement, so guiding would not work I think.

cheers,

Robin

[MikeHuerto]

Hi Robin
Thanks - and very well explained. Well even if it just works in Feature Tracking, it would be a huge step forward for many SW Dob users. Please let me know when I can test. Thanks!

Mike