Livestacking: Cloud rushes through image

[SternwarteOrion]

Hi,
thanks that worked fine! But now I have an other problem:

in bool SharpCap.Cameras.ASI.ASICameraProxy.StartExposure()
Info 19:30:13.704195 #22 Recenter action is Enabled with threshold 80.0, current drift is 4185.21, requesting recenter in bool SharpCap.FrameTransforms.LiveStacking.RecenterAdjustmentAction.NeedsToRun(int transformStackedFrames)
Info 19:30:13.704918 #25 =='.NET TP Worker' (New Thread)
Info 19:30:13.705008 #25 Drift now {X=3531,4038, Y=2246,1455}, running recenter action in async Task SharpCap.FrameTransforms.LiveStacking.RecenterAdjustmentAction.DoActionAsync(int stackedFrameCount, CancellationToken token)
Info 19:30:13.706170 #25 Frame center as shown calculated as RA=22:20:06,4,Dec=+56:52:56 in async Task SharpCap.FrameTransforms.LiveStacking.RecenterAdjustmentAction.DoActionAsync(int stackedFrameCount, CancellationToken token)
Info 19:30:13.706413 #25 Frame center current sky pos calculated as RA=22:17:57,3,Dec=+56:31:29 in async Task SharpCap.FrameTransforms.LiveStacking.RecenterAdjustmentAction.DoActionAsync(int stackedFrameCount, CancellationToken token)
Debug 19:30:13.708405 #1 Notification (Status=OK): Live stacking paused to allow recentering to take place in void SharpCap.UI.NotificationViewModel.DisplayMessage(NotificationMessage message)
Debug 19:30:13.709044 #1 Notification (Status=OK): Moving mount from RA=22:15:01,1,Dec=+57:02:48 to RA=22:12:52,0,Dec=+56:41:21 to recenter stack in void SharpCap.UI.NotificationViewModel.DisplayMessage(NotificationMessage message)
Info 19:30:13.709459 #1 Slew target calculated as RA=22:12:52,0,Dec=+56:41:21 in async Task SharpCap.FrameTransforms.LiveStacking.RecenterAdjustmentAction.DoActionAsync(int stackedFrameCount, CancellationToken token)
Info 19:30:14.984278 #1 Waiting for recenter slew to complete, mount currently slewing: True, pointing at RA=22:13:29,5,Dec=+56:45:34 in Task SharpCap.FrameTransforms.LiveStacking.RecenterAdjustmentAction.DoActionAsync(int stackedFrameCount, CancellationToken token)+() => { }
Info 19:30:20.372437 #1 After slew, mount points at RA=22:12:52,7,Dec=+56:41:21 in async Task SharpCap.FrameTransforms.LiveStacking.RecenterAdjustmentAction.DoActionAsync(int stackedFrameCount, CancellationToken token)
Debug 19:30:20.372638 #1 Notification (Status=OK): Mount movement and settling complete - preparing to restart stack. in void SharpCap.UI.NotificationViewModel.DisplayMessage(NotificationMessage message)
Debug 19:30:22.376119 #1 Notification (Status=OK): Recentering complete, Live stacking resuming

So before recentering, it was fine. After recentering the position was wrong. What could the reason be?

Cheers,
Sternwarte Orion

[admin]

Hi,

is this after the flip has occurred? Is the stack being fully reset at the flip (back to zero frames?). Without a full reset, the recentering will work incorrectly after a flip due to the 180 degree rotation not being handled correctly by the current code.

If it's not that, then I would need to see more of the log to understand what lead up to the very large offset being detected.

cheers,

Robin

[SternwarteOrion]

Hi,
so I tried again and it worked well, but tonight at 9:46 pm and later at 2 am, the telescope pointed fine at Perseus A and the galaxy cluster but for some reason it moved the mount. The meridian flip was at 12pm and it worked perfectly. The telscope pointet at the perfect arcsecond of the night sky. I'll send you the log again.

Cheers,
Sternwarte Orion

[admin]

Hi,

thanks for continuing to experiment and for sharing the log once again.

This one is interesting, at 21:36:06, we have a recenter:

Code: Select all

Debug  	21:36:06.456928	#1 	Notification (Status=OK): Moving mount from RA=03:19:40,1,Dec=+41:31:35 to RA=03:19:37,9,Dec=+41:31:14 to recenter stack

About 10 minutes later, we have another

Code: Select all

Debug  	21:45:48.770345	#1 	Notification (Status=OK): Moving mount from RA=03:19:37,7,Dec=+25:02:30 to RA=03:19:35,6,Dec=+25:02:05 to recenter stack

Note that in the first recenter, the mount is initially at about dec=+41.5 degrees and a small adjustment is made near that position. In the second recenter aat 21:45:58, the mount reports an initial position of dec=+25 degrees, so SharpCap thinks it needs to apply a small offset to that position, calculating a target still close to +25 dec. You can then see the mount slew from +41 dec to +25 dec in response to SharpCap's command...

Code: Select all

Info   	21:45:48.770517	#1 	Slew target calculated as RA=03:19:35,6,Dec=+25:02:05														
Info   	21:45:50.135199	#1 	Waiting for recenter slew to complete, mount currently slewing: True, pointing at RA=03:19:35,7,Dec=+41:06:27
Info   	21:45:50.696631	#1 	Waiting for recenter slew to complete, mount currently slewing: True, pointing at RA=03:19:35,7,Dec=+40:13:39
Info   	21:45:51.257961	#1 	Waiting for recenter slew to complete, mount currently slewing: True, pointing at RA=03:19:35,7,Dec=+37:57:17
Info   	21:45:51.786562	#1 	Waiting for recenter slew to complete, mount currently slewing: True, pointing at RA=03:19:35,7,Dec=+36:04:19
Info   	21:45:52.343702	#1 	Waiting for recenter slew to complete, mount currently slewing: True, pointing at RA=03:19:35,7,Dec=+34:12:24
Info   	21:45:52.891105	#1 	Waiting for recenter slew to complete, mount currently slewing: True, pointing at RA=03:19:35,7,Dec=+31:15:46
Info   	21:45:53.466457	#1 	Waiting for recenter slew to complete, mount currently slewing: True, pointing at RA=03:19:35,7,Dec=+29:19:35
Info   	21:45:54.027046	#1 	Waiting for recenter slew to complete, mount currently slewing: True, pointing at RA=03:19:35,7,Dec=+26:45:03
Info   	21:45:54.610217	#1 	Waiting for recenter slew to complete, mount currently slewing: True, pointing at RA=03:19:35,7,Dec=+26:45:03
Info   	21:45:55.150886	#1 	Waiting for recenter slew to complete, mount currently slewing: True, pointing at RA=03:19:35,7,Dec=+25:39:39
Info   	21:45:55.735242	#1 	Waiting for recenter slew to complete, mount currently slewing: True, pointing at RA=03:19:35,7,Dec=+25:05:06

The 'from' position in the log line 'Moving mount from <Co-ords> to <Co-ords> to recenter stack' has just been read from the ASCOM driver, so as far as I can work out, the underlying cause seems to be that the ASCOM driver is intermittently reporting the wrong RA/Dec co-ordinates back to SharpCap when asked for the current position of the mount - this is then treated by SharpCap as correct and leads to the recenter going to the wrong place.

Now, I guess I can code in some safeguards against this - you would expect potentially some change to position due to dithering etc, but that would be small, not 15 degrees, so some sort of limit could be checked, but there is still the question of what to do when a recenter is needed and the co-ordinates from the mount seem to be wrong - I don't think there is a good answer to that...

Interestingly, what happened at 2am is different - here the co-ordinate read from the mount seems to be correct and a reasonable looking target is calculated, but the mount doesn't actually go where it is asked:

Code: Select all

Info   	01:59:38.067869	#21	=='.NET TP Worker' (New Thread)
Info   	01:59:38.067900	#21	Drift now {X=-27,3863, Y=75,73935}, running recenter action																
Info   	01:59:38.068527	#21	Frame center as shown calculated as RA=03:19:13,9,Dec=+41:31:13															
Info   	01:59:38.068649	#21	Frame center current sky pos calculated as RA=03:19:15,2,Dec=+41:30:45													
Debug  	01:59:38.121057	#1 	Notification (Status=OK): Live stacking paused to allow recentering to take place										
Debug  	01:59:38.121358	#1 	Notification (Status=OK): Moving mount from RA=03:21:02,9,Dec=+41:31:37 to RA=03:21:04,2,Dec=+41:31:09 to recenter stack
Info   	01:59:38.121519	#1 	Slew target calculated as RA=03:21:04,2,Dec=+41:31:09																	
Info   	01:59:44.872836	#1 	After slew, mount points at RA=03:21:10,2,Dec=+41:31:09																	

Note that the co-ordinates shown in the last two lines don't match - the mount is not ending up at the slew destination. Mind you the offset is relatively small - only 6 seconds of RA or about 1.5 minutes of arc. I wouldn't have thought that was enough to cause everything not to stack though, unless the mount didn't stop moving at that point but carried on. Unfortunately nothing else in the log records the mount position for the next hour, at which point a new section of the sequence looks like it moves to a new target.

It's probably worth running the next trial with the SharpCap option to log additional info from mount hardware communication turned on - that will produce a huge logfile, but it will record the figures every time SharpCap reads co-ordinates from the mount (and sends commands to the mount), so we can see if we are getting random glitches in the mount position, which is certainly what this is looking like

cheers,

Robin

[SternwarteOrion]

Hi,
so I tried again and it worked quite well, except that the target was not centered correctly. So the sequence was:

Code: Select all

SEQUENCE
    SAVE COORDINATES "3 29 07.52 +31 21 19.9"
    LIVE STACKING START
    WAIT UNTIL LOCALTIME 21:50:00
    LIVE STACKING STOP
    GOTO SAVED COORDINATES
    DELAY 10
    RETRY ERRORS UP TO 1000 TIMES
        MOUNT SOLVEANDSYNC
    END RETRY ERRORS
    DELAY 10
    LIVE STACKING START
    WAIT UNTIL LOCALTIME 01:00:00
    LIVE STACKING STOP
    SAVE COORDINATES "11 32 53.18 +53 03 28.4"
    GOTO SAVED COORDINATES
    DELAY 10
    RETRY ERRORS UP TO 1000 TIMES
        MOUNT SOLVEANDSYNC
    END RETRY ERRORS
    DELAY 10
    LIVE STACKING START
    WAIT UNTIL LOCALTIME 06:30:00
    MOUNT PARK
    CAMERA CLOSE
END SEQUENCE

but at 9:50 pm (the merridian flip), the telescope was a bit off. At 1:00 am, I decided to photograph the galaxy NGC 3718 because the Embryo nebula was too deep at that point and I could take pictures until 6.30 am. Here is the result of the platesolving at 1:00am:

Code: Select all

Before Sync mount is at RA=11:34:16,6,Dec=+52:54:55																		in async Task<PlateSolveResult> SharpCap.ViewModels.PlateSolveAndResync.SolveImplAsync(IFrameToSolve tmpFile, CancellationTokenSource tokenSource, IMount model, SizeF? fieldOfView, PostSolveActions action, RADecPosition theTarget)

[...]

After Sync mount is at RA=11:33:29,5,Dec=+52:50:21																		in async Task<PlateSolveResult> SharpCap.ViewModels.PlateSolveAndResync.SolveImplAsync(IFrameToSolve tmpFile, CancellationTokenSource tokenSource, IMount model, SizeF? fieldOfView, PostSolveActions action, RADecPosition theTarget)
Info   	01:01:13.322424	#1 	Frame center calculated at RA=11:32:06,1,Dec=+52:58:53 (J2000)															in bool SharpCap.Models.PixelPositionProviderBase.IsOkToSaveData(RADecPosition frameCenter, IMappingData mappingData)
Info   	01:01:13.322793	#1 	Frame center converted to JNOW : RA=11:33:29,4,Dec=+52:50:21															in bool SharpCap.Models.PixelPositionProvider.IsOkToSaveData(RADecPosition frameCenter, IMappingData mappingData)
Info   	01:01:13.323273	#1 	Recording Sky Orientation Mapping from Plate solving at RA=11:33:29,5,Dec=+52:50:21										in void SharpCap.Models.SkyMapping.StorePixelsPerDegreeMapping(Matrix mappingMatrix, string source)
Info   	01:01:13.323378	#1 	PixelSize is {Width=1,45, Height=1,45}, Side of Pier is WestSideLookingEast, Mapping is Rotation (xAxis):107,31, Rotation (yAxis): -252,69 Flip: False, Scaling: (9006,789062,9011,829102), Data : -2679,6875,-8603,467,0,-8603,467,-2682,0557,0, FocalLength calculated at 748.69, PixelsPerDegree=9011.829					in void SharpCap.Models.SkyMapping.StorePixelsPerDegreeMapping(Matrix mappingMatrix, string source)
Info   	01:01:13.323532	#1 	Plate solve info with center at RA=11:33:29,4,Dec=+52:50:21 recorded against mount position RA=11:33:29,5,Dec=+52:50:21, mapping data is TileCenter=RA=11:30:00,0,Dec=+54:00:00, ReferencePosition=RA=11:32:06,1,Dec=+52:58:53, GridScaling=4500, PixelToGrid=Rotation (xAxis):-18,01, Rotation (yAxis): -18,02 Flip: False, Scaling: (0,499476,0,499364), Data : 0,47499642,0,15446909,-1,0829332E-11,0,15446909,0,47487202,-2,9442247E-11 0,47499642, -0,1544495, 3828,6995, 0,15446909, 0,47487202, 604,5095, -1,0829332E-11, -2,9442247E-11, 1, orientation is 107.59455561241342				in void SharpCap.Models.PixelPositionProvider.LogMapping()
Debug  	01:01:13.323637	#1 	Notification (Status=OK): Mount synced to RA=11:33:29,4,Dec=+52:50:21 (offset of 0,14 degrees), up is 107,6 degrees E of N.					in void SharpCap.UI.NotificationViewModel.DisplayMessage(NotificationMessage message)
Debug  	01:01:13.324096	#1 	Sequencer : Completed : Plate solve a single frame, sync the mount and re-goto the target co-ordinates					in void SharpCap.Sequencer.SequencerContext.OnProgress(string e)
Debug  	01:01:13.326117	#1 	Sequencer : Completed : Retry up to 1000 times if there are any errors running these steps								in void SharpCap.Sequencer.SequencerContext.OnProgress(string e)
Debug  	01:01:13.334106	#1 	Sequencer : Starting  : Wait for 10 seconds																				in void SharpCap.Sequencer.SequencerContext.OnProgress(string e)

So, Sharpcap tried to sync the mount and calculated the position after the sync but the position wasn't exactly the target. I know, a FOV of 0.4 x 0.2 degrees is a big challenge for the soft- and hardware but it worked in the past and Sharpcap did plate solve correctly. So, is there any way to fix this?

PS: Here is the image of NGC 1333 as it should be (before the meridian flip):


Here is the image of NGC 1333 after the meridian flip:


And here is the image of NGC 3718:

NGC 3718.jpg (547.45 KiB) Viewed 3168 times

Kind regards,
Sternwarte Orion

[admin]

Hi,

from the text of the log, it looks like your 'after solve' action in the SharpCap plate solve settings is set to 'Sync Mount only', which therefore ends up being the action that is taken by the 'MOUNT SOLVEANDSYNC' step in your sequence. I think that's probably a bug really in the sequencer that it should ignore that option being set (but it would still need to respect the 'offset the mount position to recenter' option if that is chosen).

I will update the code for the next release, but in the meantime, changing that option would (I'm fairly sure) resolve this issue.

cheers,

Robin

[SternwarteOrion]

Hi,
I tried again but this time I captured IC 410 until 11:30 pm, did the meridian flip and from 2:00 am I captured M51. I had the same problems again but my plate solve actions were "Do nothing". I can't explain, why Sharpcap knew the mount were off but didn't do anything although my sequence said "Plate solve a single frame, sync the mount and regoto the coordinates.". And another thing is when I tried to sync the mount with the command "Platesolve and resync the mount" at the tools bar, the plate solve works but I get this error:

Screenshot 2024-12-30 173146.jpg (9.42 KiB) Viewed 3160 times

. I hope you can help.

Cheers,
Sternwarte Orion.

[admin]

Hi,

so the sequence following the 'DoNothing' option when it shouldn't is now fixed in the version I uploaded yesterday. It will now perform a 'plate solve, sync and re-goto' unless the option is set to 'offset to center target', in which case it will do that.

The RADecSync rejected issue is trickier, as that comes from the ASCOM driver, and the specifics of when it might happen are down to the ASCOM driver code. I've seen that sort of message for EQMOD in a couple of circumstances

* A very large difference between the current and Sync locations
* The ASCOM driver sees the Sync location as being on the 'wrong' side of the meridian

If it's the latter then waiting might be the answer, or alternatively moving to a target further past the meridian to plate solve/sync before moving back to the true target.

cheers,

Robin

[SternwarteOrion]

Hi,
so I tried again and I didn't even get the plate solving to work (the second time that happened). When the telescope was pointing towards polaris, the platesolving worked. But as I moved the telescope a bit, plate solving failed. I don't know what I did differently as last year where it worked for almost 6 months.

Cheers,
Sternwarte Orion

[admin]

Hi,

oddly, the image that you attached solves cleanly for me without any problems (to a position near the north celestial pole). I can see various attempts to plate solve with different tools in the log and lots of problems with low star counts (both from Astap plate solving and from live stacking).

At about 18:04, you go to a new target 'Quasar' at RA=01:43:02.5,Dec=+13:38:46 - after that move there are a couple of attempts at plate solving that fail and then they start working, but giving results showing co-ordinates of something like RA=03:12:50,1,Dec=+13:45:51 - an hour and a half of RA or so away from where the mount thinks it is. That seems to repeat for a long time - the mount thinking it is at RA=01:42 or so and plate solving giving repeated results of RA=03:15 or so. If you have any frames captured later in the evening (say 8pm to 9pm) then maybe they can be checked to see if they really are from the RA=03:15 area (in which case why was the mount pointing there rather than where it should?) or if they are from about RA=01:43 and the plate solving is getting the position wrong - if it is the latter, please send me a frame or two so I can test and hopefully fix any issue.

thanks,

Robin