Plate Solve in Sequence Loop

[rac19]

More...

Because the plate solve and re-centre occurs at 10 minute intervals, the first image of each image set (except in fact the first set) is probably over corrected, for the initial fast drift + the slower 10 minute drift. I will look at the last sub in each set to see if they are properly centred. If they look interesting, I will post them.

[rac19]

Yet more...

I used Blink to view the 60th subs in sequence for each set and, subjectively, the variation looks about the same as the 1st subs. I can post the images if required.

[rac19]

I am running the sequence tonight and copied line below from log just now.

21:03:22 Starting : Plate solve a single frame, sync the mount and re-goto the target co-ordinates

There seems to little doubt that the current Plate Solve setting is used.

The re-centering accuracy seems to be about the same as before so I may need to adjust my expectations. I will initiate a plate solve and sync manually from the telescope control panel later to see if it centres more accurately.

[admin]

Hi,

all good investigation, since it could have been some backlash due to the movement that would be taken up by further tracking, but apparently not the case.

If you could post the entire log from a session then I will check that the plate solving info looks correct throughout.

cheers,

Robin

[rac19]

I didn't see this until I had packed up for the night so I will send the full log next time. Is there a log that is more detailed than the one in the progress window? It might be useful to have a log of telescope coordinates read from the mount and written to the mount (if that ever happens).

I did notice tonight that the telescope coordinates displayed in SharpCap differ slightly from "everything else". I am running CPWI with both Stellarium and Sharpcap connected to the mount through CPWI.

CPWI 12:40:05 RA, -11:36:59 Dec
Stellarium. 12:40:06 RA, -11:37:05 Dec
SharpCap. 12:41:14 RA, -11:44:23 Dec

I am am pretty sure that all three applications are using J2000 coordinates so there shouldn't be any errors due to epoch conversion.

[admin]

Hi,

the log you want is the main SharpCap log - Help menu, select 'Show Log', then you can either copy the text for the current session or use the 'Locate on Disk' button to go straight to the folder containing the current logfile and previous ones too.

My experience is that almost all mounts run in JNOW co-ordinates (even some that claim they are running J2000). SharpCap will respect the co-ordinate system that the mount claims to run, meaning that if the mount claims JNOW then it will do conversions to/from J2000 when working with plate solve results. If your mount claims to be J2000 and is not then that could be an issue, but I think it would lead to a constant offset, not a random drift.

cheers,

Robin

[rac19]

There is something going on with J2000/JNow conversation as per the snippet from tonight's log.

Info 21:36:46.709206 #1 Plate solving : in Task<bool> SharpCap.ViewModels.PlateSolveAndResync.SolveImpl(bool gotFrame, string tmpFile, CancellationTokenSource tokenSource, IMount model, SizeF? imageSize)+(object s, SolveProgressEventArgs a) => { }
Debug 21:36:46.710204 #1 Notification (Status=Warning): Solving: in void SharpCap.UI.NotificationViewModel.DisplayMessage(NotificationMessage message)
Info 21:36:46.711201 #1 Frame Orientation : Up is 12.1 degree E of N in double? SharpCap.ImageProcessing.ExternalPlateSolverBase.ParseOrientationFromWCSData(Dictionary<string, string> fields)
Info 21:36:46.715191 #1 Mount reports JNOW, converting results position from RA=12:22:46,Dec=+15:47:20 (J2000) in async Task<bool> SharpCap.ViewModels.PlateSolveAndResync.SolveImpl(bool gotFrame, string tmpFile, CancellationTokenSource tokenSource, IMount model, SizeF? imageSize)
Info 21:36:46.798969 #1 Conversion result is RA=12:23:54,Dec=+15:40:02 (JNOW) in async Task<bool> SharpCap.ViewModels.PlateSolveAndResync.SolveImpl(bool gotFrame, string tmpFile, CancellationTokenSource tokenSource, IMount model, SizeF? imageSize)
Debug 21:36:46.799966 #1 Notification (Status=OK): Plate solve succeeded, position found to be RA=12:23:54,Dec=+15:40:02 (JNOW, offset of 0.05 degrees), field of view is 0.4212x0.2631 degrees, pixel size 0.8 arcsec/pixel, up is 12.1 degrees E of N. in void SharpCap.UI.NotificationViewModel.DisplayMessage(NotificationMessage message)
Info 21:36:46.799966 #1 Field solved to RA=12:23:54,Dec=+15:40:02, field Size {Width=0.4212, Height=0.2630817} in async Task<bool> SharpCap.ViewModels.PlateSolveAndResync.SolveImpl(bool gotFrame, string tmpFile, CancellationTokenSource tokenSource, IMount model, SizeF? imageSize)
Info 21:36:47.799912 #1 Before Sync mount is at RA=12:24:05,Dec=+15:41:41 in async Task<bool> SharpCap.ViewModels.PlateSolveAndResync.SolveImpl(bool gotFrame, string tmpFile, CancellationTokenSource tokenSource, IMount model, SizeF? imageSize)
Info 21:36:49.003542 #1 After Sync mount is at RA=12:23:54,Dec=+15:40:02 in async Task<bool> SharpCap.ViewModels.PlateSolveAndResync.SolveImpl(bool gotFrame, string tmpFile, CancellationTokenSource tokenSource, IMount model, SizeF? imageSize)
Info 21:36:49.004540 #1 Frame center calculated at RA=12:22:46,Dec=+15:47:21 (J2000) in void SharpCap.Models.PixelPositionProvider.SaveDataImpl(RADecPosition frameCenter, MappingData mappingData)
Info 21:36:49.085324 #1 Frame center converted to JNOW : RA=12:23:54,Dec=+15:40:02 in void SharpCap.Models.PixelPositionProvider.SaveDataImpl(RADecPosition frameCenter, MappingData mappingData)
Info 21:36:49.086321 #1 Plate solve info with center at RA=12:23:54,Dec=+15:40:02 recorded against mount position RA=12:23:54,Dec=+15:40:02, mapping data is -0.0002144469,-4.618732E-05,4.607786E-05,-0.0002144418,185.6998,15.81302; {X=916.0175, Y=498.3444}; 0; False, orientation is 12.1407904830824 in void SharpCap.Models.PixelPositionProvider.LogMapping()
Debug 21:36:49.087320 #1 Notification (Status=OK): Mount synced to RA=12:23:54,Dec=+15:40:02, re-centering on target at RA=12:24:05,Dec=+15:41:41 (offset of 0.05 degrees) in void SharpCap.UI.NotificationViewModel.DisplayMessage(NotificationMessage message)
Info 21:36:50.099372 #1 Before Slew mount is at RA=12:23:54,Dec=+15:40:02 in async Task<bool> SharpCap.ViewModels.PlateSolveAndResync.SolveImpl(bool gotFrame, string tmpFile, CancellationTokenSource tokenSource, IMount model, SizeF? imageSize)
Info 21:36:51.340755 #1 After Slew mount is at RA=12:22:12,Dec=+16:05:33

[rac19]

Tonight I am manually pausing image capture to initiate a plate solve and re-centre when appears necessary. The behaviour may be more to do with the 10 to 15 delay between the GoTo and plate solve and re-centre, which includes the fast initial drift (due to gear play) and the slower, long term drift.

Looking at CPWI, the UI clearly states J2000 and I can only find J2000 in the CPWI log, JNow is not to be found.

[admin]

Hi,

well, that's odd, because from the log it can be seen that the ASCOM driver for CPWI is reporting it is JNOW to SharpCap

Code: Select all

Info 21:36:46.715191 #1 Mount reports JNOW, converting results position from RA=12:22:46,Dec=+15:47:20 (J2000)

That means that SharpCap will internally convert the J2000 co-ordinates that come from plate solving to JNOW before sending them to the mount.

There is an interesting bit right at the end too

Code: Select all

Debug 21:36:49.087320 #1 Notification (Status=OK): Mount synced to RA=12:23:54,Dec=+15:40:02, re-centering on target at RA=12:24:05,Dec=+15:41:41 (offset of 0.05 degrees)
Info 21:36:50.099372 #1 Before Slew mount is at RA=12:23:54,Dec=+15:40:02
Info 21:36:51.340755 #1 After Slew mount is at RA=12:22:12,Dec=+16:05:33

The actual distance to be moved by the slew is very small - just a copyle of arc minutes, but you can see from the last line that the mount has actually moved quite a distance (about 1/3 degree in dec). I suspect that the mount is doing the small slew by moving away and then moving back to the target location (seen this on some other Celestron mounts) and SharpCap is catching the co-ordinate readout for 'after' when it is still part way through the move away/move back routine.

cheers,

Robin

[rac19]

Yes, Celestron mounts tend to move away then move back with a final up/right movement, if a "re-GoTo" is initiated. The Evolution mount can drift for nearly a minute after a GoTo.

GoTo Approach can be set to minimise (even eliminate) the drift but I think that it changes for different areas of the sky. The Evolution mount on a wedge is quite unbalanced and I think that the load shifts between gear faces depending or whether the OTA is pointed east or west. I will pay more attention to that next time.