Plate Solve Error?

[rac19]

Hi Robin,

I can't help thinking that somewhere in the round trip of getting the coordinates from CPWI and sending them back for a GoTo some sort of unintended/undocumented conversion is occurring (quite likely in CPWI).

When next I have a clear night, I will use a Sequence that stores the coordinates and uses them, in a loop, for periodic Plate Solve and Sync and GoTo Stored Coordinates steps (definitely using the same coordinates each time). If there is an offset the first time around the loop but subsequently (as I seem to remember) that will tell us something.

Best regards,
Richard

[rac19]

Hi Robin,

Further to the previous post, I used findstr to remove the clutter from one of the logs from the other night and it looks to me like Sharpcap detects that CPWI provides JNOW coordinates but converts them to J2000 anyway. There is another conversion before re-centering and I am not quite whether or not the target or re-centering is of the correct epoch.

Best regards,
Richard

[admin]

Hi Richard,

I think that is fine - what is being reported there is that the results from the plate solver are J2000, so SharpCap is having to convert those to JNOW before they are sent to the mount. That's all working as expected.

cheers,

Robin

[rac19]

Thanks Robin, I wasn't quite sure what the log was telling me. I suppose that Plate Solve uses J2000 because ir references stored images.

[admin]

Hi,

yes, exactly - the plate solving program works from a set of data files that contain the positions and brightnesses of stars in J2000 co-ordinates, so the results that come out of the procedure are also J2000 based.

cheers,

Robin

[rac19]

Hi Robin,

I have just done dome testing that I am confident captures the issue.

Screenshots 8 to 13 show a star initially centred then progressively off target to the left with each Plate Solve, Sync and Centre Target. A GoTo from CPWI at the completion of this test (using CPWI coordinates) brought the target back to centre (screenshot 13).

Next I modified my usual sequence, to make it run faster and adding a delay between Plate Solve and Synch Only and Slew to Saved Coordinates. It seems that the same offset occurs the first time around the loop but did not increment for each loop because saved coordinates were used. It also seems that the saved coordinates included the offset, which may be a clue. Again CPWI had no problem re-centering the target. See screenshots 15 to 20.

[rac19]

Here are the rest of the files. Apologies for the amount of data but I think that it illustrates the problem,

[rac19]

Just to confirm what I think that I can see in screenshots 9 to 13, RA (as shown in the Sharpcap UI) seems be 26" less each time.

Also, as seen in Screenshots 15 to 20, the Sharcap Slew to Coordinates (GoTo) seems to goto to the coordinates supplied in the function call, it's just that stored coordinates are slight different to the target.

It looks like the stored RA value (at the start of the sequence) was 14:15:55 whereas the target RA was somewhere between 14:16:16 and 14:16:20, again as read from the Sharpcap UI.

I was using a 0.5x reducer by the so the effective focal length was 1,000 mm.

The coordinates from Stellarium don't quite match but they are close, see attached.

[admin]

Hi Richard,

I am away this weekend, so don't have all the tools handy that I would normally use to analyze log files. However, a quick dig into the one you shared reveals something alarming... The CPWI mount seems to be not quite doing what it is asked, and I think that this is the cause of the drifting issue

Code: Select all

Info   	21:03:15.690796	#1 	Before plate solving mount points to RA=14:16:16,Dec=+19:04:01	
Info   	21:03:41.968006	#1 	Mount reports JNOW, converting results position from RA=14:15:39,Dec=+19:10:20 (J2000)									in async Task<bool> SharpCap.ViewModels.PlateSolveAndResync.SolveImplAsync(bool gotFrame, string tmpFile, CancellationTokenSource tokenSource, IMount model, SizeF? imageSize, PostSolveActions action)
Info   	21:03:41.968665	#1 	Conversion result is RA=14:16:46,Dec=+19:03:55 (JNOW)	
Debug  	21:03:41.968934	#1 	Notification (Status=OK): Plate solve succeeded, position found to be RA=14:16:46,Dec=+19:03:55 (JNOW, offset of 0.12 degrees), field of view is 1.0269x0.7772 degrees, pixel size 0.8 arcsec/pixel, up is 8.8 degrees E of N.					in void SharpCap.UI.NotificationViewModel.DisplayMessage(NotificationMessage message)
Info   	21:03:41.969225	#1 	Field solved to RA=14:16:46,Dec=+19:03:55, field Size {Width=1.0268867, Height=0.777175}								in async Task<bool> SharpCap.ViewModels.PlateSolveAndResync.SolveImplAsync(bool gotFrame, string tmpFile, CancellationTokenSource tokenSource, IMount model, SizeF? imageSize, PostSolveActions action)
Info   	21:03:42.969754	#1 	Before Sync mount is at RA=14:16:16,Dec=+19:04:01
Info   	21:03:44.736237	#1 	After Sync mount is at RA=14:16:17,Dec=+19:04:11	
Debug  	21:03:44.741882	#1 	Notification (Status=OK): Mount synced to RA=14:16:46,Dec=+19:03:55, 
re-centering on target at RA=14:16:16,Dec=+19:04:01 (offset of 0.12 degrees)				in void SharpCap.UI.NotificationViewModel.DisplayMessage(NotificationMessage message)
Info   	21:03:45.744252	#1 	Before Slew mount is at RA=14:16:17,Dec=+19:04:11
Info   	21:03:50.926141	#1 	After Slew mount is at RA=14:15:50,Dec=+19:04:16

Info   	21:04:29.902804	#1 	Before plate solving mount points to RA=14:15:49,Dec=+19:04:16	
Info   	21:04:57.038922	#1 	Before Sync mount is at RA=14:15:49,Dec=+19:04:16

I have included some of the relevant lines above, centered around a plate solve and resync at 21:03...

You can see that SharpCap calculates the plate solve position to be RA=14:16:46,Dec=+19:03:55 (JNOW), but after the sync is sent, CPWI reports RA=14:16:17,Dec=+19:04:11 - it has practically ignored the sync (completely ignored the change in RA requested).

Similarly with the GOTO requested, SharpCap asks CPWI to slew to RA=14:16:16,Dec=+19:04:01, but it ends up at RA=14:15:49,Dec=+19:04:16.

This I think explains everything... Multiple uses of the resync work correctly providing that the mount co-ordinates at the end of the process are the same as the ones going into it. When everything works correctly, that's the case - SharpCap reads the initial co-ords as the target, solves, syncs and then moves to the initial co-ordinates again.

If the mount co-ordinates change during the process then the (incorrect) co-ordinates at the end of the process become the input for the next time around, so any error is applied again and again.

The only reason I can think of for this happening that makes sense is if CPWI is trying to apply some sort of advanced pointing model on the sky based on multiple sync points. This maybe something that can be turned off in the CPWI settings (I don't have any CPWI compatible hardware so cannot check).

Very odd...

cheers,

Robin

[rac19]

Hi Robin,

I didn't expect a reply until Monday night at the earliest. I can wait until next week for any further replies.

The snippet from the log below shows that the sequence stored the precise coordinates shown in Screenshot 15 but that every subsequent GoTo in the sequence is offset by the same amount. This assumes that the coordinates shown in Screenshot 15 agree with CPWI. I will try to check that soon.

This is opposite to my earlier conclusion, the problem seems to be in the way Sharpcap and CPWI interact during a GoTo after all, probably with the passing of coordinates.

I will probably take this up with Celestron next week but I will leave it for a few days in case you come up with more info after you get back to the office.

SEQUENCE
SAVE MOUNT COORDINATES
PROMPT FOR TARGET
LOOP 5 TIMES
CAPTURE START
COUNTDOWN FOR 5 SHOWING "Capturing Images for 10 minutes"
CAPTURE STOP
IGNORE ERRORS FROM ONERROR RUN ""
RETRY ERRORS UP TO 1 TIMES
MOUNT SOLVESYNCONLY
END RETRY ERRORS
END IGNORE ERRORS
DELAY 5
GOTO SAVED COORDINATES
COUNTDOWN FOR 10 SHOWING "Wait 60 seconds for 'scope to settle"
END LOOP
END SEQUENCE in async Task SharpCap.Sequencer.SequencerContext.RunAsync(ScriptBlock script)
Debug 21:23:36.848708 #1 Sequencer : Starting : Sequence in void SharpCap.Sequencer.SequencerContext.OnProgress(string e)
Debug 21:23:36.944200 #1 Sequencer : Starting : Save the current mount co-ordinates
Debug 21:23:36.946878 #1 Sequencer : Info : 'Saving mount co-ordinates of RA=14:16:20,Dec=+19:03:59' while running step Save the current mount co-ordinates
Debug 21:23:36.952653 #1 Sequencer : Completed : Save the current mount co-ordinates