Homing Question for WarpAstron

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.

kind regards
Chris Woodhouse FRAS

I can confirm this behaviour on mine as well. Would like to know if WarpAstron is working on this.

Hi Buzz,

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.

Thanks.

WarpAstron Support Team

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

Is that max slew time limit something that could be controlled in firmware / software?

I have to question this setting (max allowed slewing time). How can this be effective? A Meridian Flip is twice as far as slewing home from zenith.

Why have this at all?

Hi,

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.

Thanks.

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 :frowning:

Doesn’t the mount also know where it is if I’m at Zenith?

To be clear, I
turn on NINA,

  1. Connect to the Mount (mount may or may not know where it is)
  2. Use Flats to slew to Zenith (mount should know where it is, right?)
  3. Slew to Home
  4. Miss home
  5. Enable Tracking
  6. Manually Slew a few degrees
  7. Slew to Home
  8. Successfully finds home after searching

Logs sent via email. Thanks!

Will do, I’m away for the weekend and will upon my return

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!)

Logs 2024-11-18.zip (80.9 KB)

Hope this helps.
kind regards
Chris Woodhouse FRAS
www.digitalastrophotography.co.uk

@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.

many thanks
Chris Woodhouse FRAS