GoTo : wrong coordinates for targets

[Cepadues]

Hi everyone,

I've encountered a problem with Sharpcap's Goto catalog function, it's been sending me almost a decimal degree away from the target that I've requested,

Here's an exemple for M51, here are Sharpcap's logs :

Code: Select all

18:28:28 Starting  : 
18:28:28 Starting  : Move the mount to (RA,Dec) RA=13:29:54,0,Dec=+47:12:00 (RA=13:37:60,0,Dec=+47:12:00)
18:28:28 Info      : 'Converting RA=13:37:60,0,Dec=+47:12:00 (J2000) position to RA=13:39:02,3,Dec=+47:04:34 (JNOW)' while running step Move the mount to (RA,Dec) RA=13:29:54,0,Dec=+47:12:00 (RA=13:37:60,0,Dec=+47:12:00)
18:28:44 Info      : 'Mount slew complete, waiting for mount to settle.' while running step Move the mount to (RA,Dec) RA=13:29:54,0,Dec=+47:12:00 (RA=13:37:60,0,Dec=+47:12:00)

And the result slewing as seen on stellarium (which is very close to real life) :

stellarium-004.png (297.03 KiB) Viewed 401 times

GSS reports that the mount was sent to RA=13:39:02, DEC=47:04:34 which can be confirmed by Stellarium. The problem arises both with GSS set to J2000 and "Local Topocentrique" which is JNOW). Futhermore, if coordinates are entered manually, the target is often right in the middle of the view which tells me that it is not an issue with GSS.

I had the same problem with EQMOD (which used J2000) so I'm guessing that the issue lies between the coordinate conversion or the standard between Sharpcap and driver (J2000 vs JNOW ?)

Could someone please point from the log which set of coordinates GSS should report because it's not very clear to me ?

[admin]

Hi,

the difference between J2000 and JNOW should not put you off target by more than about 8 minutes of arc, so if you are ending up a degree or more off then J2000/JNOW is not the whole of the problem.

Some things that occur to me are

1) Do you have the option to solve/sync turned on in SharpCap? If so, turn off to test if the initial GOTO movement goes to the correct co-ordinates as recorded (JNOW) in the log for the target.

2) Once the plate solving is disabled, check that the GOTO co-ordinates shown in GSS/SharpCap mount panel are correct after the GOTO movement.

3) If you have a sky pointing model set up in GSS (multiple sync points recorded), then try turning it off temporarily to see if that has an effect. In particular if you have a sky pointing model you need to change the plate solving option from 'sync and recenter' to 'offset goto'

cheers,

Robin

[soundfan]

Hello Robin,

I dare to enter this thread as I think I have the same (or very similar) problem.

I use Sharpcap (4.1) with a Touptek 2600C on a RC10C (250/2000), mounted on a iOptron CEM70. Since a few weeks (can't exactly remember the date) the Goto function of Sharpcap acts strange. I select a target, move to target, plate solve and recenter. Everything works fine except the target is not in FOV. If I open Skysafari and check location of the telescope it is always 1-2° east of the target. If I select same target in Skysafari now and send the goto from there, the mount finds the target dead center.
Two months ago I'm sure Sharpcap always centered the target after platesolve and recenter perfectly.

I can't remember having changed anything except updating Sharpcap regularly.

Any hint would be appreciated. If you need more data or log files, let me know. But please be patient with me, I'm not that deep into logs and that stuff. So far Sharcap just worked...

Many thanks in avance

CS Mike

[admin]

Hi Mike,

yes, a full log file of a session where you hit the problem would be great, along with any comments you have on things you noticed happening that might be of interest. As I mentioned above, it might be best to split the action into the initial GOTO (no plate solve selected) and then a plate solve+sync manually - that lets you see the mount co-ordinates and image after the GOTO and before the plate solve, just in case anything odd is going on.

cheers,

Robin

[soundfan]

Thanks for your quick reply, Robin.

Attached two session logs from April 6th and 27th. I hope you can find what's going on in there.

Let me know if you need more / other information.

Many thanks in advance!

CS
Mike

[kaymann]

It looks like we three are all trying solve the same problem (viewtopic.php?t=7670)...

[admin]

Hi,

looks like we have a different issue here - from the logs, it seems that the mount ASCOM driver is sometimes ignoring the sync request without raising an error - for instance

Code: Select all

Debug  	22:42:08.464954	#1 	Notification (Status=OK): Plate solve succeeded, position found to be RA=10:30:04,7,Dec=+22:50:16 (JNOW, offset of 3,10 degrees
Info   	22:42:08.465504	#1 	Field solved to RA=10:30:04,7,Dec=+22:50:16, field Size {Width=0,6711456, Height=0,44944328}							
Info   	22:42:09.466734	#1 	Before Sync mount is at RA=10:29:25,9,Dec=+19:44:29																		
Warning	22:42:10.651938	#22	Obtaining lease on WriteableBitmap took 691ms																			
Info   	22:42:11.653356	#1 	After Sync mount is at RA=10:30:04,7,Dec=+19:44:29																		
Info   	22:42:11.655783	#1 	Frame center calculated at RA=10:28:44,1,Dec=+22:57:40 (J2000)															
Info   	22:42:11.656508	#1 	Frame center converted to JNOW : RA=10:30:04,7,Dec=+22:50:16															
Info   	22:42:11.661050	#1 	Plate solve info with center at RA=10:30:04,7,Dec=+22:50:16 recorded against mount position RA=10:30:04,7,Dec=+19:44:29,

Note that the before and after sync co-ordinates recorded in the log here are the same at 19:44:29, in spite of the plate solve center being near to +23 declination.

This might just be something in the ASCOM driver being weird, or it could be to do with having an advanced pointing model enabled in the ASCOM driver.

Probably the best thing to do here is to work around the problem by changing the Plate Solving 'after solving...' setting from 'Sync mount and recenter target' to 'offset the mount position to center the target' - this avoids using the mount sync command and hopefully bypasses the issue.

cheers,

Robin

[Cepadues]

Hi,
As I was away from home the last few day I couldn't experiment much with real hardware, and I'm sorry for the delay between my replies.
I'll try to answer as many points in this message so it can get a bit long, but first of all thanks @soundfan for joining in as it looks like we're facing the same problem!

Every tests I ran was using Carte du Ciel, the GSS telescope simulator, and ASCOM Sky Simulator (from the same dev as ASTAP) configured to mimic my camera setup (IMX290). This setup being "perfect", only a negligeable offset will be measured with the plate solve and sync function.

the difference between J2000 and JNOW should not put you off target by more than about 8 minutes of arc, so if you are ending up a degree or more off then J2000/JNOW is not the whole of the problem.

I can confirm that after changing this setting in GSS the view in Stellarium/Carte du ciel barely moves. So J2000 vs JNOW is eliminated.

1) Do you have the option to solve/sync turned on in SharpCap? If so, turn off to test if the initial GOTO movement goes to the correct co-ordinates as recorded (JNOW) in the log for the target.

2) Once the plate solving is disabled, check that the GOTO co-ordinates shown in GSS/SharpCap mount panel are correct after the GOTO movement.

3) If you have a sky pointing model set up in GSS (multiple sync points recorded), then try turning it off temporarily to see if that has an effect. In particular if you have a sky pointing model you need to change the plate solving option from 'sync and recenter' to 'offset goto'

1) Tried it with both options, with the sync option turned off and targetting M51 (Theory : AD=13h30m56,16s DE=47°04'12,7"):

Code: Select all

SEQUENCE
    MOUNT GOTO RA=13:29:54,0,Dec=+47:12:00
    TARGETNAME "M51 (NGC 5194,Whirlpool Galaxy)"
END SEQUENCE				in async Task SharpCap.Sequencer.SequencerContext.RunAsync(ScriptBlock script)
Debug  	18:08:26.208597	#1 	Sequencer : Starting  : 																								in void SharpCap.Sequencer.SequencerContext.OnProgress(string e)
Debug  	18:08:26.232783	#1 	Sequencer : Starting  : Move the mount to (RA,Dec) RA=13:29:54,0,Dec=+47:12:00 (RA=13:37:60,0,Dec=+47:12:00)			in void SharpCap.Sequencer.SequencerContext.OnProgress(string e)
Debug  	18:08:26.260812	#1 	Sequencer : Info      : 'Converting RA=13:37:60,0,Dec=+47:12:00 (J2000) position to RA=13:39:02,3,Dec=+47:04:36 (JNOW)' while running step Move the mount to (RA,Dec) RA=13:29:54,0,Dec=+47:12:00 (RA=13:37:60,0,Dec=+47:12:00)					in void SharpCap.Sequencer.SequencerContext.OnProgress(string e)
Debug  	18:08:34.929526	#1 	Sequencer : Info      : 'Mount slew complete, waiting for mount to settle.' while running step Move the mount to (RA,Dec) RA=13:29:54,0,Dec=+47:12:00 (RA=13:37:60,0,Dec=+47:12:00)			in void SharpCap.Sequencer.SequencerContext.OnProgress(string e)
Debug  	18:08:44.938508	#1 	Sequencer : Completed : Move the mount to (RA,Dec) RA=13:29:54,0,Dec=+47:12:00 (RA=13:37:60,0,Dec=+47:12:00)			in void SharpCap.Sequencer.SequencerContext.OnProgress(string e)
Debug  	18:08:44.940796	#1 	Sequencer : Starting  : Set imaging target name to 'M51 (NGC 5194,Whirlpool Galaxy)'									in void SharpCap.Sequencer.SequencerContext.OnProgress(string e)
Info   	18:08:44.942428	#1 	Target name changed to M51 (NGC 5194,Whirlpool Galaxy)																	in void SharpCap.Models.Application.set_TargetName(string value)
Debug  	18:08:44.954730	#1 	Sequencer : Completed : Set imaging target name to 'M51 (NGC 5194,Whirlpool Galaxy)'									in void SharpCap.Sequencer.SequencerContext.OnProgress(string e)
Debug  	18:08:44.961558	#1 	Sequencer : Completed : 																								in void SharpCap.Sequencer.SequencerContext.OnProgress(string e)
Info   	18:08:44.966122	#1 	The sequence is now finished

2) I don't understand which set of coordinates I should look for in the logs as both of them seems wrong, which can be confirmed by Carte du Ciel :

CDC_M51.png (88.58 KiB) Viewed 189 times

3) I don't have any model configured in GSS, and I don't even think it supports poiting model. But Stellarium managed to send the mount to the right coordinates, and so did Sharpcap when using coordinates from stellarium.

It seems more likely that Sharpcap's catalog or Sharcap's conversion results in wrong coordinates being used as GOTO command.

To prove that issue, I've ran multiple go-to with sharcap's catalog and plate solves to confirm that the mount was sent to the expected coordinates :

M33 was almost 2° off :

CDC_M33.png (91.4 KiB) Viewed 189 times

M63 was 1° off :

CDC_M63.png (97.58 KiB) Viewed 189 times

M101 was very close !

CDC_M101.png (91.08 KiB) Viewed 186 times

M42 was 1° off too :

CDC_M42.png (115.16 KiB) Viewed 186 times

And finally just to confirm that it's not only Messier catalog, NGC3626 :

NGC_3626.png (118.21 KiB) Viewed 186 times

It might not be important but the target seems to be always to the right of the sensor.

I hope my logs will bring more information to the table, because it doesn't seem to be a problem of syncing but rather of catalog being off.

Thanks very much for looking into our issue,
Cheers!

[soundfan]

@Cepadues: Thanks for supporting.

I can confirm that it is indeed something with the catalog.
I selected Ascom Telescope Simulator for .Net and run the Ascom remote server at the same time. Connect Skisafari to it and - voila - all Goto coordinates just deviate.

Example: Sending the Mount (Simulator) to Regulus sends it to "Converting RA=10:11:43,0,Dec=+11:58:00 (J2000) position to RA=10:13:01,1,Dec=+11:50:50 (JNOW)" while Regulus position in Skysafari (and in real life) is at RA 10h 09m 40.12s; Dec +11°50' 56.3" (JNOW) (see log file).

While Dec matches pretty much, RA is off by 03m 20s (~0,825°). FOV of my RC10 (250/2000) is 0,67°x 0.45°, so target is not even on the sensor.

Deviation between time of mount and time of PC is also not possible, because simulator obviously runs on PC time.

Is there a way to check if Sharpcap uses the correct time or position or catalog or whatever?

CS Mike

[Cepadues]

Is there a way to check if Sharpcap uses the correct time or position or catalog or whatever?

In the log there's a line for that :

Code: Select all

Calculating Alt/Az for catalog based on lat=47.8929162, long=-1.5064371, UTC=2024-05-05T16:08:19.8565754Z

My UTC time was correct since France is UTC +2 due to daylight saving. As far as I remember the problem was anterior to the last daylight saving change...
But by anychance, would you happen to live in a country that recently changed to summer time ?