Sharpcap Sequence Platesolve Step Coordinates Creep

[rac19]

I have mentioned this problem before but now I have some numbers to illustrate it.

I have a sequence that stops every 10 minutes to plate solve and recenter with the aim of keeping the target galaxy in the centre of frame.

The problem seems to be that with each iteration there is a small amount of creep in coordinates displayed on Sharpcap, in mount information/control panel. I assume that these are the coordinates that are used in plate solve and recenter step.

My target was the Sculptor Galaxy, RA 00 47 33.14 Dec -25 17 19.7 according to Stellarium. The first issue is that after performing a GoTo in Stellarium, Sharpcap displays the coordinates as 00 48 39 and -25 09 57 respectively after a manual plate solve and recenter with the galaxy dead centre in the frame. I assume that could by a J2000, JNOW conversation or some such.

Below is a list of coordinates displayed after successive plate solve and recenter steps about 10 minutes apart. Some creep in the coordinates is evident and the image was quite bit off centre at the completion of those steps. A GoTo from Stellarium resulted in the original coordinates being displayed in Sharpcap with the Galaxy again dead centre after a manual initiated plate solve and recenter.

RA 00 48 41 Dec -25 09 58
RA 00 48 42 Dec -25 09 58
RA 00 48 45 Dec -25 09 58
RA 00 48 50 Dec -25 09 58
RA 00 48 51 Dec -25 09 58

After Stellarium GoTo
RA 00 48 40 Dec -25 09 58

[rac19]

I tested the MoveTo sequence step.

If I provide the coordinates displayed in Sharpcap (RA 00 48 39 Dec,-25 09 57) to the MoveTo sequence, step the target galaxy is considerably off centre, half out of frame. If I provide the Stellarium coordinates (RA 00 47 33.14, Dec -25 17 19.7), the target galaxy is much closer to centre though not as close as when I issue a GoTo from Stellarium and a manual plate solve and re-centre from Sharpcap. I am not sure if i did a plate solve and re-centre from the Sequence, so I will make sure to do so next time.

[admin]

Hi,

do you have the SharpCap log from this session? It will contain info of all the plate solving results and also the mount co-ordinates before and after the various sync and GOTO movements - inspecting that might well help reveal what is going on.

The GOTO sequence step expects that the co-ordinates that are entered are J2000 values (on the assumption that you will get them from a star chart or similar). For the sculptor galaxy those are the 00 47 33 and -25 17 19 set. I expect that the 00 48 39/-25 09 57 co-ordinates are JNOW, so if you use them in a GOTO step then there will be an incorrect J2000->JNOW conversion carried out on them.

Internally, SharpCap tracks co-ordinates as being either J2000 and JNOW and converts where necessary. All user supplied co-ordinates are assumed to be J2000.

cheers,

Robin

[rac19]

Thanks Robin.

If the plate solve and re-centre step get's the target coordinates from the the values displayed in Sharpcap, is it possible that an error could creep in with repeated use of this step in a loop? For example if the process was to read the coordinates as displayed, possibly convert from JNow to J2000, plate solve and re-centre, convert from J2000 to JNow then update the displayed coordinates. The displayed coordinates seemed to change only after each plate solve and re-centre step.

It might help if it there was a new step to capture the target coordinates, in the correct epoch, before starting a loop and have an optional parameter in the plate solve and re-centre step to use the captured coordinates. Alternatively there could be an optional input parameter to supply the J2000 coordinates directly, as per the GoTo step.

I will look at the Sharpcap log when I have time.

[rac19]

A footnote to my previous post. There is a slight loss of precision in the displayed coordinates in that Stellarium supplies values to 1 or 2 decimal places of a second and the displayed value is to the nearest second. That's probably not significant and f/5 but could be significant at higher focal ratios. There is no doubt a limit as the focal ratio increase, beyond which plate solving ceases to be a practical proposition of course.

[admin]

Hi,

actually I have just added sequencer steps that allow you to store a set of co-ordinates and then go back to them later in the sequence. You can either store the co-ordinates as read from the mount, or as calculated via plate solving. These new steps will be in next week's update.

It's possible that there is some creep due to rounding, but I would have thought that would be in fractions of an arc-second, not several arc seconds.

cheers,

Robin

[rac19]

Thanks Robin, I agree that you would think that any rounding error would be small, but it does seem to happen.

I look forward to testing the new feature. I was going to suggest storing the values as read from the mount but, not being familiar with the internal workings of Sharpcap, I wasn't sure if that was possible.

I wonder if this could be a concept that could grow, internal variables within a sequence .

[rac19]

Here are the log files from the other night. I wasn't only looking for the Sculptor Galaxy which makes it more difficult to analyse. It might be better to record a log while I am only focused on a single task. I am interested to see how the new feature that you mentioned works. I will try it on the next clears night.

[admin]

Hi,

thanks for the log, I will have a dig through it and see what I find.

I have been reluctant to put general purpose variables into the sequencer, as it would significantly increase the complexity and also make it impossible to estimate the time that the sequence will take to run in many cases (already there are some cases that are impossible, but currently most sequences get a time estimate). Fortunately simpler special purpose data storage doesn't induce the same problem

cheers,

Robin

[admin]

Hi,

OK, here is a section of the smaller log, which shows how a single plate solve/recenter worked and what the result what

Code: Select all

Info   	21:19:24.957279	#1 	Before plate solving mount points to RA=00:48:40,Dec=-25:09:42															in async Task<bool> SharpCap.ViewModels.PlateSolveAndResync.SolveImpl(bool gotFrame, string tmpFile, CancellationTokenSource tokenSource, IMount model, SizeF? imageSize)
Info   	21:19:38.800377	#1 	Mount reports JNOW, converting results position from RA=00:47:33,Dec=-25:21:39 (J2000)									in async Task<bool> SharpCap.ViewModels.PlateSolveAndResync.SolveImpl(bool gotFrame, string tmpFile, CancellationTokenSource tokenSource, IMount model, SizeF? imageSize)
Info   	21:19:38.883156	#1 	Conversion result is RA=00:48:41,Dec=-25:14:06 (JNOW)																	in async Task<bool> SharpCap.ViewModels.PlateSolveAndResync.SolveImpl(bool gotFrame, string tmpFile, CancellationTokenSource tokenSource, IMount model, SizeF? imageSize)
Debug  	21:19:38.884154	#1 	Notification (Status=OK): Plate solve succeeded, position found to be RA=00:48:41,Dec=-25:14:06 (JNOW, offset of 0.07 degrees), field of view is 0.5153x0.3895 degrees, pixel size 0.8 arcsec/pixel, up is 4.5 degrees E of N.					in void SharpCap.UI.NotificationViewModel.DisplayMessage(NotificationMessage message)
Info   	21:19:38.884154	#1 	Field solved to RA=00:48:41,Dec=-25:14:06, field Size {Width=0.5153334, Height=0.3895167}								in async Task<bool> SharpCap.ViewModels.PlateSolveAndResync.SolveImpl(bool gotFrame, string tmpFile, CancellationTokenSource tokenSource, IMount model, SizeF? imageSize)
Info   	21:19:39.898159	#1 	Before Sync mount is at RA=00:48:40,Dec=-25:09:42																		in async Task<bool> SharpCap.ViewModels.PlateSolveAndResync.SolveImpl(bool gotFrame, string tmpFile, CancellationTokenSource tokenSource, IMount model, SizeF? imageSize)
Info   	21:19:41.169405	#1 	After Sync mount is at RA=00:48:41,Dec=-25:14:06																		in async Task<bool> SharpCap.ViewModels.PlateSolveAndResync.SolveImpl(bool gotFrame, string tmpFile, CancellationTokenSource tokenSource, IMount model, SizeF? imageSize)
Info   	21:19:41.170401	#1 	Frame center calculated at RA=00:47:33,Dec=-25:21:38 (J2000)															in void SharpCap.Models.PixelPositionProvider.SaveDataImpl(RADecPosition frameCenter, MappingData mappingData)
Info   	21:19:41.251188	#1 	Frame center converted to JNOW : RA=00:48:41,Dec=-25:14:06																in void SharpCap.Models.PixelPositionProvider.SaveDataImpl(RADecPosition frameCenter, MappingData mappingData)
Info   	21:19:41.251188	#1 	Plate solve info with center at RA=00:48:41,Dec=-25:14:06 recorded against mount position RA=00:48:41,Dec=-25:14:06, mapping data is 0.0002206936,1.725054E-05,1.715973E-05,-0.0002206618,11.90606,-25.36031; {X=1224.918, Y=882.4698}; 0; False, orientation is 4.4580470777401					in void SharpCap.Models.PixelPositionProvider.LogMapping()
Debug  	21:19:41.252185	#1 	Notification (Status=OK): Mount synced to RA=00:48:41,Dec=-25:14:06, re-centering on target at RA=00:48:40,Dec=-25:09:42 (offset of 0.07 degrees)				in void SharpCap.UI.NotificationViewModel.DisplayMessage(NotificationMessage message)
Info   	21:19:42.262982	#1 	Before Slew mount is at RA=00:48:41,Dec=-25:14:06																		in async Task<bool> SharpCap.ViewModels.PlateSolveAndResync.SolveImpl(bool gotFrame, string tmpFile, CancellationTokenSource tokenSource, IMount model, SizeF? imageSize)
Info   	21:19:43.522813	#1 	After Slew mount is at RA=00:50:20,Dec=-25:39:01																		in async Task<bool> SharpCap.ViewModels.PlateSolveAndResync.SolveImpl(bool gotFrame, string tmpFile, CancellationTokenSource tokenSource, IMount model, SizeF? imageSize)
Info   	21:36:11.944709	#1 	Before plate solving mount points to RA=00:48:39,Dec=-25:09:57															in async Task<bool> SharpCap.ViewModels.PlateSolveAndResync.SolveImpl(bool gotFrame, string tmpFile, CancellationTokenSource tokenSource, IMount model, SizeF? imageSize)

The interesting thing here is that we start off with the mount pointing to RA=00:48:40,Dec=-25:09:42. Plate solving results seem reasonable, and the sync works. SharpCap asks the mount to go back to the initial co-ordinates, but firstly the position immediately after slewing is RA=00:50:20,Dec=-25:39:01 and that just before the next plate solve is RA=00:48:39,Dec=-25:09:57.

Now, I don't think the position immediately after slewing matters - I expect that the mount reports the slew as complete before it has fully homed in on the target so that SharpCap just reads the values earlier than it really should. It's the drift of 15 seconds before the next plate solve that is adding to your overall drift.

How could that drift come about? SharpCap has not sent commands to the mount in that period, but perhaps you have guiding active, which might do that. Alternatively, perhaps when the mount finally does settle after the first sync/goto, it is a little off, and that incorrect value gets read back the next time around.

cheers,

Robin