Synscan V3 handset (position of targets different to real position)

[NorthernAstro]

Hello there,
My synscan V3 handset is having issues in the goto settings, for example, it may be over 10 degrees out in azimuth and a few degrees out by altitude. For troubleshooting purposes and to save you from asking unnecessary questions, I have tried different locations and made comparisons, I have also tested multiple different targets. My location, date and time are also correct and to make sure, I have tried different variables to see if there is a difference but there is not, the handset is still out. I should also let you know that the difference between the real value and H.C. Value is not fixed and does vary. Help would be greatly appreciated as this has really puzzled me. I have updated the firmware and went to older versions - same issue. I have searched for this topic on the likes of YouTube and other forums and cannot find some information. Fingers crossed one of you can help me with this. 
Thank you,

Cai

[Dr_Ju_ju]

and the mount is ??...... is the power supply sufficient & accurate ?  and the motors properly engaging with the gears and there is no sloppiness\binding ?? 

 

[NorthernAstro]

There is no problem with the mount, just the handset, the handset’s belief of where the stars are is wrong.

the altitude and azimuth are different to what they should be, it is the handset with a problem as it is giving out wrong coordinates

thank you for trying though,

the mount is an old sky-watcher alt az goto and works perfectly fine. But the problem is the hand controller

[Dr_Ju_ju]

is the hand controller actually in AZ or EQ mode ??

[NorthernAstro]

Hi, the handset displays both AZ and EQ information so I am assuming it is set in both. When I updated the firmware, the firmware was for all goto mounts.

[StevieDvd]

So are you saying that you can have an object centred and the co-ordinates displayed don't match those you have from another source? What are you using to confirm? And how are you sure the mount is OK?

If it's the goto that's not working then the usual suspects are the date/time, location etc (Daylight saving y/n), low power or sticking/loose clutches.

Someone will correct me if I'm wrong but as I understand it the catalog of objects is held in the handset with standard co-ordinates, these are used together with the location, time etc to calculate the current co-ordinates and to instruct the mount how many steps to move to get there. Hence a simple time or date error can result in failed goto's.

More info would be helpful as there are several avenues to check out to get you sorted.

[NorthernAstro]

Hi, thank you for responding

I have checked the date/time/location multiple times and even changed it to different values and then I checked it with Celestron SkyPortal. My assumption is that the Mount works fine but that is not really necessary as even if the handset is disconnected from the Mount, it still displays the same problems. I believe that the coordinates stored within the handset may be wrong and I am unsure on how to update that or potentially there is an error in reading my location. I have also tried with different voltages (the battery pack which is currently outputting a voltage of around 8V as well as the power cable connected to the mains which is around 12.2V). I hope this info helps, I have not yet tried switching the daylight saving option on or off but currently it is not daylight saving times. I will test this out later as I am not currently with my handset. I will post results of this changes anything. Thank you

[NorthernAstro]

Just tried switching on the daylight saving which did nothing to it so I switched it off but when it changed, it was giving me correct readings (they were out by a few hours but that doesn’t matter as I have quite a wide field scope) I am very happy and this is finally sorted! Thank you to all who attempted to help,

Cai Watson

[StevieDvd]

A little tip from an old IT worker. 

Bad code can allow a setting to be mis-intepreted or uninitialised. If it does not handle all the cases it can cause unexpected results. 

In this case it could be the code was checking for a value of Y or N, but having never been set  before it's blank. By setting a value you triggered the correct code, and you won't be able to set it back to blank anymore.

I've rejected far too many code reviews doing this and seen clients report the errors it can cause. To make matters worse some coders set the default in the wrong place so when screenshots are provided the values are set  after the code failed.  That's why 'turning it off & on again' usually works the next time. To be fair once explained the coder seldom repeats the error and newer software languages tend to prevent uninitialised variables.

 

 

 

[NorthernAstro]

Actually that makes a lot of sense as the controller was new, thank you. 

[malc-c]

What scope and what mount are we talking about ?

If you search for similar topics on the forum you'll see that a lot of these errors are caused by  entering the incorrect date / time and location, or more correctly as the late Eric Morecombe would say, "all the right notes, but not necessarily in the right order".  These handsets require information in US date format.  Some users will set GMT time, and than say yes to daylight saving, whilst others set the BST  and say no to daylight saving.

Synta (manufacture of SW and Celestron scopes) handsets don't store mount information.  When the handset is connected it interrogates the mount to obtain details from the mounts firmware which incudes the number of steps (or click on an encoder depending on the mount) it takes to rotate each axis 360 degrees.  It then uses this information to work out the steps per degree for both axis.  Once you have set the alignment up by selecting a target, slewing to it and then having made any corrections using the directional buttons then confirmed its centred in the eyepiece.  When you then select the next target the handset then works out how many pulses it needs to send to the mount to move to the target based on how many degrees of rotation is required between its current target and the new target.  It sends that to the mounts firmware which then drives the motor the number of pulses / ticks.  Once the firmware has completed that movement it sends a command back to the handset to acknowledge the move is complete.  Now if the target is way off, it would suggest that either the clutch is slipping and thus the mount is not moving far enough, or the handset has been programmed with the wrong data initially and thus it's miscalculated the required number of steps which would be too many or too few depending on the location and time it thinks you are in.

 

[NorthernAstro]

Hi, the issue has now been sorted thank you but I did list that information in my opening paragraph so that people would not ask similar questions but i thank you for trying to help. My location and time were fine and I always like to double check these things and in the event of problems I always like to troubleshoot with different information, therefore I can tell you that the location, date, and time were all correct. But I thank you for commenting

[malc-c]

6 hours ago, NorthernAstro said:

Just tried switching on the daylight saving which did nothing to it so I switched it off but when it changed, it was giving me correct readings (they were out by a few hours but that doesn’t matter as I have quite a wide field scope) I am very happy and this is finally sorted! Thank you to all who attempted to help,

Cai Watson

But that's a contradiction of terms.  How can something be correct and be incorrect at the same time ???

I guess what you did was having made the changes and saved them you needed to power cycle the handset in order to register the changes ?