SharpCap Forums

Posted: **Mon Apr 29, 2024 10:49 pm**

So for as long as I can remember my Sync and Recenter command has been off by about 10 minutes and I just live with it but I am now wondering if there is something I can do to get it right. I am inserting the PNG's so you can see for yourself how far off they are. I am also attaching the settings sidecars. The settings sidecar's both properly identify my Celestron CGEMDX as JNOW. I made the mistake of updating SC this afternoon but if you tell me the logs are still good I will retrieve them if I am told where to look. Is my camera upside down is my camera sideways is is is...

Stack_5frames_75s_WithDisplayStretch.CameraSettings.txt: (1.39 KiB) Downloaded 97 times

: SC Stack_5frames_75s_WithDisplayStretch.jpg (926.46 KiB) Viewed 2818 times

Stack_57frames_3420s.CameraSettings.txt: (3.16 KiB) Downloaded 93 times

: SC Stack_57frames_3420s.jpg (921.16 KiB) Viewed 2818 times

Posted: **Tue Apr 30, 2024 7:57 pm**

Hi,

the amount of the error sounds consistent with J2000 co-ordinates being sent to the mount when actually it works in JNOW co-ordinates.

SharpCap asks the mount which co-ordinate system it uses, but some ASCOM drivers report the wrong setting. This can lead to SharpCap not applying the required correction and the positions being in error by about 8 minutes of arc.

Posting the log should reveal whether SharpCap thinks the mount is JNOW or J2000, which is the first step.

cheers,

Robin

Posted: **Wed May 01, 2024 12:12 am**

Here you go with the log

Log_2024-04-25T19_49_31-14624.log: (668.64 KiB) Downloaded 98 times

The Camera settings .txt and log shows Mount reporting JNOW, converting to JNOW

Could this be associated with the time sync situation I posted about elsewhere or or or way beyond my wheelhouse

Posted: **Wed May 01, 2024 4:58 pm**

Hi,

Ok, that's good to know - the mount is reporting JNOW and SharpCap is converting to JNOW. The only reason that you would be out in that situation would be if the mount reports JNOW but is really J2000, but I think that's unlikely.

The time on the mount seems OK - from the log

Code: Select all

Info   	20:56:52.518777	#26	Mount reports UTC date of 2024-04-26T03:56:43.0000000

Earlier in the log, your time zone is recoreded as UTC-7, so that ties in nicely - the time difference between PC and mount is only about 9 seconds, which wouldn't cause a big error. Anyway, a plate solve/resync should correct for time error - really it should correct anything except initial co-ordinates being wrong or hardware backlash in the mount movement.

I would suggest that when you get a chance, you do a GOTO without the plate solve/resync option turned on and check that the final mount co-ordinates match those listed in the log for JNOW of the target. You can also check those against Stellarium JNOW for the same target. Then do a plate solve/resync manually and see what happens. You can send me the log after that test so I can check what happened.

cheers,

Robin

Posted: **Fri May 03, 2024 5:43 am**

Check out the RA & DEC Celestron Driver does not match either JNOW or J2000 on Stellarium after a SC GOTO Sync ReSync:

: Screenshot 2024-05-02 212352.jpg (188.21 KiB) Viewed 2630 times

When I center M87 with the arrow buttons in SC the JNOW's in Stellarium and SharpCap agree

: Screenshot 2024-05-02 223402.jpg (146.87 KiB) Viewed 2630 times

When I do a Plate solve and ReSync I get a less then .001 error no need to sync

When I do a SC GOTO Catalog & Sync & Recenter off it goes to the crazy original location...

Log_2024-05-02T22_17_07-8688.log: (286.45 KiB) Downloaded 92 times

Posted: **Fri May 03, 2024 8:17 am**

Hi,

thanks for the log - a first run through it seems to indicate that the mount isn't moving to the position that it's being asked to goto after the sync

Code: Select all

Info   	22:19:00.560001	#1 	Field solved to RA=12:33:56.3,Dec=+12:05:53, field Size {Width=0.47526357, Height=0.4753004}							
Info   	22:19:01.561852	#1 	Before Sync mount is at RA=12:32:00.5,Dec=+12:15:22																		
Info   	22:19:03.472274	#1 	After Sync mount is at RA=12:33:56.4,Dec=+12:05:53																		
Info   	22:19:03.474467	#1 	Frame center calculated at RA=12:32:41.6,Dec=+12:13:59 (J2000)															
Info   	22:19:03.475072	#1 	Frame center converted to JNOW : RA=12:33:56.3,Dec=+12:05:53															
Info   	22:19:03.481586	#1 	Plate solve info with center at RA=12:33:56.3,Dec=+12:05:53 recorded against mount position RA=12:33:56.4,Dec=+12:05:53, mapping data is 1.2586186E-05,-0.0001574585,0.00015744509,1.2571821E-05,188.17332,12.233015; {X=1504.5, Y=1504.5}; 3009; False, orientation is 94.57051490678998					
Debug  	22:19:03.481934	#1 	Notification (Status=OK): Mount synced to RA=12:33:56.3,Dec=+12:05:53, re-centering on target at RA=12:32:00.5,Dec=+12:15:22 (offset of 0.50 degrees)			
Info   	22:19:04.482610	#1 	Before Slew mount is at RA=12:33:56.4,Dec=+12:05:53																		
Info   	22:19:18.718184	#1 	After Slew mount is at RA=12:31:55.9,Dec=+12:14:54

Reading down, we can see in line 2 that the mount has done the initial GOTO the right location, then in line 3 the sync to the plate solve has worked correctly and updated the mounts co-ordinates.

Three lines from the end, you can see that SharpCap knows it needs to go back to the correct target co-ordinates of RA=12:32:00.5,Dec=+12:15:22 (which we saw in line 2), but in the last two lines you can see that the mount doesn't end up at those co-ordinates after the slew operation.

Now, I don't *think* anything in SharpCap is going to change those co-ordinates for the slew before they get to the ASCOM driver, but you could do a log with additional logging for 'Mount hardware communication' turned on to be sure, so I think the ASCOM driver is 'doing something weird'.

I wonder if it is trying to correct for backlash or similar, and therefore making adjustments to small GOTO movements... If it has logging that can be enabled in the ASCOM driver setup then we could check what commands it receives from SharpCap to confirm if it is causing the miss all on its own.

Interestingly, you have a different (non-CPWI) Celestron driver to the one I have - I am using a Celestron created one (v 6.1.7350) from here : https://github.com/ascomghostdrivers/le ... opeDrivers

cheers,

Robin

Posted: **Fri May 03, 2024 3:55 pm**

First - Thank you for you for the latest driver update! I noticed the driver menu for this one allows a checkmark for logging.

One thing I forgot to mention was I tried CPWI driver and got the same errors.

I noticed the driver allows for the addition of some time to let the scope settle so I added time to ensure the scope is done before the next request is started... The more I think about this the more I think that it cannot be related as plate solving would fail if that was the problem.

What I will do:

Update NonCPWI driver to the one you listed - Done

Turn on ASCOM driver logging - Done

Tighten up backlash on the mount - Done

Turn on the 'Mount hardware communication' logging in SC - Done

Turn on plate solving logging in SC - Done

Ensure nothing on the Mount Menu has anything related to backlash turned on - Done

Or would you suggest I enter the appropriate settings into the mount hardware menu?

Run the same procedures as last night - However I did remove all of CPWI including the driver - Tonight

Posted: **Sat May 04, 2024 1:29 pm**

Last night I tried to remove the error:

What I did:

Update NonCPWI driver to the one you listed

Turn on ASCOM driver logging

Tighten up backlash on the mount

Turn on the 'Mount hardware communication' logging in SC

Turn on plate solving logging in SC

Ensure my Mount Menu backlash was set Zero

Ran a couple of runs and still no joy

I then changed backlash from 0 to 50 and then to 60.

Ran a couple of runs and still no joy

SC log zipped:

Log_2024-05-03T17_13_56-17964.zip

(62.32 KiB) Downloaded 83 times

ASCOM Celestron Telescope Driver log zipped:

ASCOM.Celestron.1947.570640.zip

(640.61 KiB) Downloaded 92 times

Posted: **Sat May 04, 2024 4:07 pm**

Thanks for posting both logs - very useful, but not necessarily good news...

Taking the example of the goto to M87 starting at 19:58:29, the following information comes out

Code: Select all

19:58:29.285501 SharpCap catalog co-ordinates : RA=12:30:48.0,Dec=+12:24:00 (J2000) position to RA=12:32:02.7,Dec=+12:15:54 (JNOW)

Mount log records :

Code: Select all

19:58:29.364 SlewAsync                 Ra 12.5340925860724, Dec 12.2651160371104  (12:32:02.7, 12:15:54)

SharpCap log records slew complete:

Code: Select all

19:58:49.400764	#1 	Sequencer : Info      : 'Mount slew complete

At which point, mount log records

Code: Select all

19:58:49.797 GetRaDec                  Ra 12.5329399108887, Dec 12.2742819786072  (12:31:58.6, 12:16:27)

Ouch, we've drifted over half a minute of arc in declination and about 4 seconds of RA (which is actually a minute of arc due to 15* multiplier). I can't see a good reason for this, the mount just doesn't go where it's being asked to go!

So, now we move on to the plate solve/sync bit...

From SharpCap log

Code: Select all

Info   	19:59:06.048409	#1 	Before Sync mount is at RA=12:31:58.6,Dec=+12:16:27		
Info   	19:59:07.473829	#1 	After Sync mount is at RA=12:32:07.0,Dec=+12:25:52				
Info   	19:59:07.475835	#1 	Frame center calculated at RA=12:30:52.1,Dec=+12:33:58 (J2000)	
Info   	19:59:07.476464	#1 	Frame center converted to JNOW : RA=12:32:06.9,Dec=+12:25:52

So, the sync seems to proceed correctly with the mount reporting back the correct co-ordinates after sync

Next, the re-goto, from the SharpCap log

Code: Select all

Debug  	19:59:07.480307	#1 	Notification (Status=OK): Mount synced to RA=12:32:06.9,Dec=+12:25:52, re-centering on target at RA=12:31:58.6,Dec=+12:16:27 (offset of 0.16 degrees)

Note that SharpCap is using the co-ordinates that the mount ended up at to here for the re-goto co-ordinates, not the initial target - this is because the 'plage solve + resync' is designed to be able to operate independently of the 'Goto Target' tool - it assumes that it needs to center the current mount co-ordinates, so will read those then re-GOTO them.

From the mount log

Code: Select all

19:59:08.568 SlewAsync                 Ra 12.5329399108887, Dec 12.2742605209351 (12:31:58.6, 12:16:27)

Excellent, the mount has received the (slightly wrong) co-ordinates correctly...

But, if we follow through to the end of the goto movement, SharpCap log

Code: Select all

Info   	19:59:38.295336	#1 	After Slew mount is at RA=12:31:54.3,Dec=+12:17:03

Mount log

Code: Select all

19:59:38.290 GetRaDec                  Ra 12.5317511558533, Dec 12.2843027114868 (12:31:54.3, 12:17:03)

Yep, the mount has done it again - out by about 30 seconds of arc in dec and 4 minutes of RA (roughly the same as last time).

So, because SharpCap is trusting the mount to go to the right place on the first GOTO, the error accumulates twice during the process, putting things off center... I could change the code to solve the double error issue, but I honestly have no idea why the mount is seemingly ending every GOTO movement slightly in error.

Hmm - any way that you can kick off a GOTO movement from another application and see if the mount ends up at exactly the target co-ordinates or a little bit off?

cheers,

Robin

Posted: **Sat May 04, 2024 4:15 pm**

I did a Cartes du Ciel last night and it worked almost perfectly I wish I could remember the time so you could look at the Mount log but I think it was about 2/3rds through the night can you see a non-SC requested movement in there?

SharpCap Forums

Sync & ReCenter

Sync & ReCenter

Re: Sync & ReCenter

Re: Sync & ReCenter

Re: Sync & ReCenter

Re: Sync & ReCenter

Re: Sync & ReCenter

Re: Sync & ReCenter

Re: Sync & ReCenter

Re: Sync & ReCenter

Re: Sync & ReCenter