mosaic's

[hdman1]

Hey again,
I think this is a simulator problem phd won't lock because the star field is weak I have no gain setting, only exposure. I will give us both a break after this. The sequence runs the first set of exposures and ask for file name, goes back to the top slews after which phd cannot find a star low snrs!
Again log attached.

Thanks again, BR

[admin]

Hi,

there isn't much you can do from the SharpCap side if PHD fails to find a suitable guide star in the field of view when asked to start guiding. The only real idea I can suggest is to put the 'Start Guiding' step in a retry step, so that SharpCap will try 3 or 4 times to get PHD running in case the initial failure is just a random thing.

cheers,

Robin

[hdman1]

Greetings Robin, Happy New Year!
I ran my mosaic sequence tonight and it performed as expected. Now I simply use CdC to setup number of frames export the coordinates to SC rename to: sequence_coords.txt and I'm in business.
Can't thank you enough for you help. Long live Sharp Cap and it's author!

Bm

[ChrisM5527]

Hi Robin - just a quick question. I've created a mosaic script and tested it. I seemed to work ok (just went through the steps as we have perpetual clouds these days). I did not include a plate solve and resync. When I looked at the camera file, the coords were off from the telescopium CSV file by about 1 degree. Any idea as to why that might be the case? I would have thought the plate solve would be irrelevant since the mount was going to the coordinates per the file - even if the scope was slightly off in reality, the mount should have thought it was at the CSV coords???? Any idea what may have happened or is the plate solve a critically missed step?

Thanks,

Chris

[admin]

Hi Chris,

I would have expected the mount to report the correct co-ordinates after the GOTO, even if in reality it wasn't pointing to quite that position in the sky. You might get a small offset as SharpCap will interpret the co-ordinates it is given as J2000, but the mount will probably use JNOW (SharpCap converts between the two as required), but that will be a small number of arc minutes, not a degree.

One possibility that comes to mind is that the co-ordinates from Telescopius are not being interpreted correctly by SharpCap. You can check this by putting the text of the co-ordinate into the target box for a 'Move the mount to RA/Dec Co-ordinates' step. When you do that, SharpCap shows a little popup explaining how it is interpreting the co-ordinate text, like this

Screenshot 2025-12-23 114706.png (15.13 KiB) Viewed 1005 times

So, that's definitely worth checking out. I suppose if your mount is set up with a pointing model then maybe that could cause the co-ordinates to be reported differently, but I wouldn't expect that (or that it would be so large).

Please feel free to share your sequence file if you want - I will happily look at it and see if I can spot anything.

cheers,

Robin

[ChrisM5527]

Hi Robin, thanks for the earlier reply. I tried another experiment but got clouded out before I could try the target box suggestion. What I do have is a screenshot of 3 panes that were shot by SharpCap, showing the mount location and the result of the initial plate solve. They were not consistent with the CSV file which I will include as well. I will also include the sequence file. So, it was a simple test file, just to prove out the walk through.
I was able to do some stacking of the data but it is very blah and I dont want to include as it is not good (clouds again). What it suggested was a bit more then 10% overlap and a vertical step offset from pane 1 to pane 2 (should have been parallel I think).
Any insight would be appreciated.

Best regards,

Chris

[admin]

Hi Chris,

thanks for sharing the sequence code and the list of targets. I quickly ran through the sequence using the 'ASCOM Sky Simulator' camera and the ASCOM Platform simulator mount (I removed the filter wheel stuff and setting the long exposures). As far as I can tell, everything went as planned with the GOTO movements in that experiment. If I check the SharpCap log after running I can see things like...

Code: Select all

Debug   14:04:47.408974 #1  Sequencer : Info      : 'Next target : RA=06:37:51.0,Dec=+05:33:06, Pane 1' 
...
Debug   14:04:47.412344 #1  Sequencer : Starting  : Move the mount to (RA,Dec) RA=06:37:51.0,Dec=+05:33:06 (RA=06:37:51.0,Dec=+05:33:06)            in void SharpCap.Sequencer.SequencerContext.OnProgress(string e)
Debug   14:04:47.636311 #1  Sequencer : Info      : 'Converting RA=06:37:51.0,Dec=+05:33:06 (J2000) position to RA=06:39:16.1,Dec=+05:31:44 (JNOW)' while running step Move the mount to (RA,Dec) RA=06:37:51.0,Dec=+05:33:06 (RA=06:37:51.0,Dec=+05:33:06)                 in void SharpCap.Sequencer.SequencerContext.OnProgress(string e)

Here you can see that the sequencer has correctly interpreted the co-ordinates from the CSV file and has then converted them from J2000 to JNOW as expected before sending the command to the mount.

What is interesting is that there is no plate solving step in the sequence that you have uploaded, so as it is it runs by just performing the GOTO movements to the best of the mounts ability. If you want the position to be adjusted by using plate solving then you would need to add a plate solve and resync step as the first step in the loop over the mosaic frames. Maybe you were expecting the loop to do that for you?

cheers,

Robin

[ChrisM5527]

Hi Robin - thanks again for your time. So just a bit of clarity. When I sent my mount to the rosette, I did a plate solve via SharpCap at that time, manually (before running the sequence). The result is at the bottom of the three pane snips that I included. So before I started the sequence I'm pretty sure the mount knew where it was, hence I felt fine leaving the plate solve out of the sequence steps. In the past, I've noted that after a plate solve and then a slew, followed by another verification plate solve, my mount has little error in the resync (AP mount).
I will dig a little further as I'm sure that I'm doing something fundamentally wrong. But now that I've got the mosaic process kinda ok, I'm feeling good about eventually doing some mosaics (if the clouds ever give us a break here).

Regards,

Chris

[admin]

Hi Chris,

yes, agreed - if you have recently done a plate solve in the same area then the errors in subsequent GOTO movements nearby should be pretty small (presuming nothing bad is happening mechanically - for instance a slipping RA clutch could ruin your entire day...).

From your screenshot, we can see that the mount co-ordinates that are in the capture settings files seem to match the ones that SharpCap calculated in my test - RA=06:39:16.1,Dec=+05:31:44 (JNOW). That's the JNOW conversion of the RA=06:37:51.0,Dec=+05:33:06 (J2000) co-ordinates of the first frame, which is expected.

Is this what you were noting? In that case all is working as planned (as long as your co-ordinates in the CSV were J2000 co-ordinates in the first place). The drift between J2000 and JNOW is about 1.25 minutes of RA and there is also a small offest in DEC due to the shift of the earth's axis.

cheers,

Robin

[ChrisM5527]

Hi Robin, I guess I didn't parse your response back well enough (the conversion explanation). Some of the snip was cut off but I see that maybe there was no issue!

But a funny thing happened to really mess up my thinking - I looked at three sources for RA/DEC coordinates for the rosette nebula and all three were different (same J2000 basis). I then got to thinking that the plate solve, when it happens, it becomes the master in that regardless of what Telescopius sends to my mount in a CSV file, a plate solve would adjust it to the plate solver coordinate system.

Am I off here in this thinking? I know that this isn't really a SharpCap issue anymore but I'm trying to understand the background stuff....

Regards,

Chris

PS - I missed the J2000 to JNOW conversion going on