Sequencer moves FOV away from centered target

[iKon308]

Hi Robin -- thanks for investigating.
SC log is attached (zipped, just over 1MB).

All the Best!
Dave Stokes
https://flic.kr/ps/3Qc1Ud

[CarCarlo147]

Ok, so I have had as much of a test as I can during daylight (I have a slightly tweaked setup here where I can test that sort of thing using ASCOM SkySimulator), and it seems to work in simulation. I recreated your orientation and field of view of the Monkey Head nebula and it ended up in the middle of view. Interestingly, the offset is exactly in the RA direction - about 2 to 3 minutes of RA (30 to 45 minutes of arc) out.

What option do you have set for the 'After solving...' action in the SharpCap plate solving settings? The default is to sync and recenter, but the alternative of an offset GOTO should work, but is known to be limited to one use after moving to a target - a second use will repeat the offset and move the target out of center.

cheers,

Robin

Immagine 2024-02-15 161622.png (65.56 KiB) Viewed 318 times

[CarCarlo147]

I'm saying something stupid, but that's the only thing I changed when I went back to the previous version.
When I start the camera, the capture profile is set to BIN 2 for polar alignment convenience. This was changed to 1x when I went back version and before starting the camera.

[iKon308]

Robin -- last night issue seemed resolved although I did not do an exhaustive test (greedily imaging while the clouds were away). The root cause of problem might have been operator error. Please close issue at this point. Sorry about wasting your time.

All the Best!
Dave Stokes

[admin]

Hi Dave,

good to hear it is working again - I will leave your log for now unless something new turns up. It would still be good to see the logs from @CarCarlo147's issues to see if I can spot any obvious differences between the working log and the one that had a problem.

cheers,

Robin

[CarCarlo147]

Hi, Robin
the bad weather didn't allow me to do any more tests.
I'll send the logs as soon as I can.

Thank you

[admin]

Hi,

no problem - I am waiting for clear skies here to run my own tests...

cheers,

Robin

[CarCarlo147]

Hi Robin,
this evening I did the tests which confirmed the operation by returning to the old version.
These are the log files of the version: 4.1.11799 (I tried twice)

Log_2024-02-17T18_27_58-15000.rar

(653.99 KiB) Downloaded 16 times

Log_2024-02-17T18_34_59-3864.rar

(882.43 KiB) Downloaded 13 times

this version: 4.1.11757 it works correctly

Log_2024-02-17T18_44_28-10112.rar

(277.5 KiB) Downloaded 14 times

First screenshot with 4.1.11799 and off-center target at the top

Immagine 2024-02-17 183318.jpg (198.45 KiB) Viewed 225 times

Second screenshot with 4.1.11799 by clicking center in view

Immagine 2024-02-17 183758.jpg (230.21 KiB) Viewed 225 times

third screeshot with 4.1.11757 and target perfectly centered

Immagine 2024-02-17 184654.jpg (218.81 KiB) Viewed 225 times

[admin]

Hi Carlo,

thanks for the logs and screenshots - based on those I am fairly sure I understand most of what is going on. Interestingly I tested last night using my mount which runs GreenSwampServer and it worked fine, but I found two differences between what I was doing and your testing

1) I was just using plate solve + resync, not the annotation + recenter target. Sorry if I missed noticing further up that you were using that approach
2) From the logs I can see that your GSS is set to report J2000 as the epoch to applications

It turns out that this looks very much like the same underlying issue as this thread : viewtopic.php?t=7407&start=10 - the problem occurs with mounts that report J2000 pointing only. Fortunately I have a fix for that already in my code here and will be releasing an update with the fix in either today or tomorrow.

The annoying thing is that I still can't see why it became broken between 757 and 799... The underlying bug causing the issue (incorrectly offsetting the co-ordinates from plate solving from J2000 to JNOW on the assumption that was necessary to match the mount co-ordinates) has been there since long before build 757. I can only assume that there was another issue in the same part of the code that made the same conversion mistake and the result was that the two mistakes cancelled each other out. Presumably I fixed the other issue when tidying up the co-ordinate conversion code between 757 and 799, leaving behind the first issue which was now revealed when the mount reports J2000 co-ordinates.

So, today or tomorrow I should have a fix, but the workaround for now is to change the 'Equatorial System' in the GS Server settings from J2000 to Local Topocentric (this is 2nd item from right on the top row of the main settings). That should work around the bug in the current version of SharpCap.

As far as I can tell, GS Server actually does not perform correction for co-ordinates based on the 'Equatorial System' setting - that setting just changes the information about the mount returned to applications like SharpCap. 'As far as I can tell' is based on a quick look at the GS Server source code on Github and failing to find any J2000/JNOW conversion code except for a polar alignment module. That would mirror the situation with EQMOD where the same setting exists, but doesn't actually have any effect in the ASCOM driver's handling of co-ordinates. The correct setting for both of these ASCOM drivers is 'Local Topocentric' and setting anything else is incorrect. To be honest, I don't think the option to adjust this should appear in the settings of either ASCOM driver, but that's another matter.

cheers,

Robin

[admin]

Correction to the above...

At a further check of the Green Swamp Server code, I found where it converts co-ordinate systems internally based on the 'Equatorial System' setting, so it actually does implement that setting correctly - unlike EQASCOM.

I have now uploaded a new version of SharpCap that should fix the recentering issue with mounts set to J2000.

cheers,

Robin