the 'sync' function in NINA

[StuartT]

I have been using NINA for a while now and I really love it. But I was watching a video the other day which explained the "noSync" function, but I didn't understand it.

Normally, when I do a plate solve in NINA it computes from the image how far away it actually is from where it thinks it is and adjusts the telescope position to match. I thought that was 'syncing' I assume this then also means that if you slew to another target, the scope is more likely to be in the right place because of this syncing because the mount now has a more accurate knowledge of its position following the plate solve (i.e. the mount has updated its model of the sky).

Am I correct so far?

If so, why would I need to use NoSync? What would be the point of plate solving if NINA doesn't then correct the mount?

Edited February 4, 2022 by StuartT

[teoria_del_big_bang]

15 minutes ago, StuartT said:

Am I correct so far?

That certainly is my understanding (although as I have learnt what I think is correct is not always so 🙂 )

Steve

[teoria_del_big_bang]

35 minutes ago, StuartT said:

I have been using NINA for a while now and I really love it. But I was watching a video the other day which explained the "noSync" function, but I didn't understand it.

Normally, when I do a plate solve in NINA it computes from the image how far away it actually is from where it thinks it is and adjusts the telescope position to match. I thought that was 'syncing' I assume this then also means that if you slew to another target, the scope is more likely to be in the right place because of this syncing because the mount now has a more accurate knowledge of its position following the plate solve (i.e. the mount has updated its model of the sky).

Having seen the video I think all you say is correct for most amateur imagers with affordable gear.
Some permanently mounted advanced telescopes must build their own map of the sky and so that map does not want disturbing by small adjustments the plate solving does to get the exact framing.
It also mentions that sometimes syncing near the Meridian can confuse the telescope, but not sure what issues that can cause. Even if it did screw things up a bit surely when you slew to another target it would just plate solve again and put things right, maybe needing a couple of extra images and syncs to achieve it ?
As it is a pretty recent addition I guess most of us can just leave this off without any issues.

Steve

Edited February 4, 2022 by teoria_del_big_bang

[StuartT]

5 minutes ago, teoria_del_big_bang said:

Having seen the video I think all you say is correct for most amateur imagers with affordable gear.
Some permanently mounted advanced telescopes must build their own map of the sky and so that map does not want disturbing by small adjustments the plate solving does to get the exact framing.
It also mentions that sometimes syncing near the Meridian can confuse the telescope, but not sure what issues that can cause. Even if it did screw things up a bit surely when you slew to another target it would just plate solve again and put things right, maybe needing a couple of extra images and syncs to achieve it ?
As it is a pretty recent addition I guess most of us can just leave this off without any issues.

Steve

Thanks for taking the time to watch. Sounds like I don't need to worry then. My mount isn't a fancy one (EQ6R Pro)

Wonder why syncing near the meridian would be problematic? 🤔

Edited February 4, 2022 by StuartT

[dghent]

Refusal for EQMOD to sync near the meridian is a something that's peculiar to EQMOD. You would need to ask its maintainers as to why it is that way. As far as I'm aware, the GSS driver doesn't have this issue; at least it doesn't complain about it.

Yes, the "No Sync" switch is primarily for people who use the TheSkyX to drive their mount while using T-Point. This mainly pertains to Software Bisque mount users. Syncs can adulterate the T-Point model. There is a switch in the TSX ASCOM driver to blackhole any syncs that come into it, but the user who originally requested that NINA have a way to not send syncs refused to use that for whatever reason.

[StarryEyed]

Look up radians and what happens at the equivalent of 180 degrees. Considering a mount inaccuracy of a degree and the problem with radians at 180 becomes clear. Computers like to calculate angles in radians. So things can get messy when your not sure which side of the line your on. This problem is true for both axis but the meridian is the one that's constantly being crossed.

Its a great problem and the math is quite fun. I first got to grips with radians programming a 3D spinning sphere on an Acorn Electron forty years ago continued to do so for work on and off ever since. I remain a fan of all things spherical. 

Theres a doc on this for EQMOD its a good read and watching the model calc and track the mount is good fun. A bit like lifting the bonnet and watching the wheels turn

EQMOD - 1-Star, 2-Star, 3-STAR, N-Star Alignment Tutorial

eqmod.sourceforge.net/docs/eqmod_alignment_models.pdf

[StuartT]

22 minutes ago, StarryEyed said:

Look up radians and what happens at the equivalent of 180 degrees. Considering a mount inaccuracy of a degree and the problem with radians at 180 becomes clear. Computers like to calculate angles in radians. So things can get messy when your not sure which side of the line your on. This problem is true for both axis but the meridian is the one that's constantly being crossed.

I'm not sure I see your point. 180 degrees is π radians. And...? What is especially difficult about that value? 

[StarryEyed]

+radians become -radians when you pass 180 or 0 degrees. if a mount has +-0.25 degree pointing accuracy and you point it at the meridian you cant know if its + radians or the - radians you just cant because of the mounts physical limitations. I see mechanical and software engineers argue the other is the problem at work (nothing to do with telescopes). The answer is more money or avoiding the problem not syncing near the merdian. 

Edited February 5, 2022 by StarryEyed

[dghent]

Computers don't "like" anything in particular. It won't know a radian from the going price of fish at the market. It's a real number, either way. The problem you speak of is a mechanical issue involving the precision that the hardware is capable of. Other mounts and, indeed, other drivers, have no problems dealing with this.