Please can you confirm and comment on the following observations below:
These are the result of many hours of patient testing and experimentation with a custom WindowsForm application that I wrote, and NINA, using standard ASCOM methods and properties. They have been confirmed by other users too.
Statement: If I home the mount from a position more than about 85 degrees away, the mount moves towards home but stops suddenly and does not pass and return to find the actual sensor position. The mount is visibly not in its home position, with a small angular error on both axes.
If I turn on tracking for a few seconds and home again, it hovers over the sensors and accurately homes itself. This is 100% repeatable.
If I repeat this, but with a smaller angular distance between the current and home position, it always homes correctly.
There is a workaround, by altering the park position, or by homing twice. It would be good to understand the root cause and if this is intentional. If so, then it would be useful to provide advice for other users.
The evidence suggests it is not a NINA thing, or an ASCOM thing. (The driver passes ASCOM ComformU and these same applications work perfectly with other mounts.)
I’m speculating, but I think it may be a firmware condition, to protect the mount from accidentally colliding with tripod legs by slewing too far to find the home sensors.
Thanks for your testing, could you send your logs of NINA and ASCOM to us, for double check the cause.
Indeed there’s a max allowed slewing time limit in mount as slewing protection. But sometimes this behavior could also been caused by other coordinates etc reasons. ASCOM log will be helpful for further survey.
Many thanks for your reply. I’m away for a few days and I will do a specific test on my return as I need to ensure logging is enabled.
I have written several ASCOM drivers over the years and designed observatory control systems but in this case, the ASCOM driver is not open source, so I cannot look at the code. I have logged onto GitHub and am looking at the OnStep code to become familiar with its design.
Regards
Chris Woodhouse FRAS
As mentioned above, please send the logs of NINA & ASCOM to our support mailbox for further checking, as the limit of slewing - manual guide slewing is a safe protection in case stop command not be sent in time.
We haven’t got reports of meridian flip failed due to this, as this limit designed for guide slewing, not for goto, so failure of meridian flip could caused by others. The logs of ASCOM communication will be helpful for confirming cause of failure.
There is a difference. For a meridian flip, the mount knows where it is before the slew. As far as I can tell, when you turn on the mount, like a Paramount, it doesn’t know where it is before it finds the sensors and so it proceeds with caution. We have to be careful with what we wish for. My Rainbow mount collided a focuser into a metal tripod leg and sheared off a tensioner bolt with its massive torque
Here you go. I used NINA, rather than my application, as it just does simple ASCOM commands and I have already modified my application with workarounds.
I used the HC to set a park position just below the horizon, pointing north. In NINA, I set tracking on and then asked it to Home. It moved towards the home position but it suddenly stopped just past the home position, although it reported its position incorrectly as the home position. Turning tracking on and then homing a second time, it found the true home position, as defined by the sensors, and again, the mount coordinates showed it had homed (accurately this time).
I then had an idea. I disconnected ASCOM connection, and reconnected via the ASCOM device hub, which has its own log files for diagnostic purposes. All the ASCOM log files are included below. The mount behaviour was identical with the direct and indirect ASCOM connection.
I then changed the Park position to just above the horizon and the WD20 successfully found the accurate home position from that position.
These behaviours are 100% repeatable (I hate intermittent issues!)
@Technical
Hello - I supplied the log files - please can you confirm that it is a deliberate slew limit, to avoid accidents with leg clashes. The current workaround is to: home / track-on / home, to ensure it finds the sensors.
I would also like to know is there a difference is between pressing and holding the home button on the mount and double-pressing the home button on the mount. They both appear to do the same.
Is this related to the hand controller Align submenu: Reset Home?
I’m compiling a user manual, to share with other users, and it would be great to be as accurate as possible.
I am also curious about the home behavior. I have noticed that after a session, when I home the scope, the Azimuth returns to its starting point but th Alt stops slightly inclined. If I turn the power off and then back on and home, it goes back to the original home position with the Alt axis pointing slightly below the horizon. I am curious if the Sync process affects where the mount perceives the home position to be?
This is what seems to be the case from observation and experiment.
The mount can report it is homed, even when it is not. Moves are then relative to this incorrect ‘home’ position. If I select a park position pointing due North at the horizon it will not find the home sensors after power up. It will stop short and not hover to find the sensor. Turning tracking on and then homing a second time finds the sensors every time.
If I change my park position to Alt 5, Az 5, it finds home accurately on both axes every time.
In NINA, I can workaround in the advanced sequencer:
home mount
tracking on
home mount
I also wrote a VBS to do the same thing, when I’m not using NINA.
An earlier post from Technical indicated that slews are initially limited in duration to avoid leg clashes. It makes sense; if the mount doesn’t know where it is on power up, this prevents an accidental slew into the legs. Once the mount knows where it is and power is maintained, it is free to point anywhere within the mount limits.
Thanks Chris. That is helpful. Hoping that Technical is working on this. I am Guessing that WA has significantly increased the number of mounts in the wild over the Black friday sale:-) I expect that support is getting many emails. I did my research and understood that the OnStep control system was going to be a bit of a project to learn the quirks. So far things seem to be very consistent, if somewhat different/counter intuitive. Once I turned off all the anti collision stuff, the mount worked very consistently in Alt Az mode. GPS worked reasonably well outside as well. The hand controller is growing on me for the visual use and I can get things up and going pretty quickly now. I think my next step is to put the big 6 inch F9 triplet on and see how that hardware handles it. I know that the mount will move it around fine, just curious what the damping times will be.
JMD
