ASA DDM ASCOM Issues

[Gerald Hitz]

Users of ASA DDM legacy mounts (60, 60PRO, 85) are facing issues with N.I.N.A.

The offical ASCOM driver from ASA is not supported any more, so we can’t fix the issue from this side.

‌

This driver does not implement the following properties:

• UTCDate
• TrackingRates

When connecting the Telescope we get an exception regarding UTCDate. This could be avoided by using ASCOM Remote and Alpaca but is an addiotional complexity.

N.I.N.A should not rely on this method to be implemented.

I propose to catch the exception in AscomTelescope.cs and to calculate the response from current time.

        public DateTime UTCDate {
            get {
                try
                {
                    return GetProperty(nameof(Telescope.UTCDate), DateTime.MinValue);
                }
                catch (System.Exception)
                {
                    return DateTime.UtcNow;
                }
            }
            set {
                try
                {
                    SetProperty(nameof(Telescope.UTCDate), value);
                }
                catch (System.Exception)
                {  }
            }
        }

A better aproach would even be to use the usually implemented property LocalTime and convert it to the according time zone.

‌

The bigger problem is the missing property TrackingRate.

In N.I.N.A, when enabling/disable the Tracking - for example when using the Polar Alignment Plugin - it will raise an error and stop. The reason is that after setting the (working) ASCOM property Telescope.Tracking also the (not implemented) TrackingRate is called.

Not sure if simply ignoring the TrackingRate PropertChange will fix this, but his would be my proposal.

‌

        public bool TrackingEnabled {
            get {
                return GetProperty(nameof(Telescope.Tracking), false);
            }
            set {
                if (CanSetTrackingEnabled) {
                    if (SetProperty(nameof(Telescope.Tracking), value)) {
                        try
                        {
                            RaisePropertyChanged(nameof(TrackingMode));
                            RaisePropertyChanged(nameof(TrackingRate));
                        }
                        catch (System.Exception)
                        {  }                                               
                    }
                }
            }
        }

‌

Hope my explanation was understandable. Changing N.I.N.A’s behaviour regarding UTCDate and TrackingRate would help many ASA users

Best regards,

Gerald

‌

[Stefan B]

Hi - a log file to show exactly what the driver is throwing as an error would be helpful.

N.I.N.A. reads the UTCDate property as per spec it has to be implemented: https://ascom-standards.org/Help/Developer/html/P_ASCOM_DeviceInterface_ITelescopeV3_UTCDate.htm UTCDate Read must be implemented and must not throw a PropertyNotImplementedException.

When writing to it (in 3.x nightlies) a potential exception is caught, as it may not be implemented which is fine.

For the TrackingRate a fix is in the nightlies when this throws a property not implemented exception to ignore it. Fix is planned to be backported for 2.3 HF2

[Dale Ghent]

The last time I checked, ASA is still an operating company. Tell them to take responsibility for the issues in their software. We will not put vendor-specific work-arounds in our code. The best way to “help ASA users” is for ASA to help their users.

[Gerald Hitz]

Hi Stefan, thanks for the fast response. Will create a log file when I’m out next time.

The ASA ASCOM driver implements the Version 2 of the Telescope Interface. Not sure if UTCDate was mandatory also at this stage and can’t find a documentation online.

Great to hear that TrackingRate exception is now handled, will give it a try.

[Stefan B]

It would also be great if you could run the driver through this tool and attach its output: https://github.com/ASCOMInitiative/ConformU/releases

[Gerald Hitz]

ASCOM Conform report

[Dale Ghent]

That’s quite a list of problems. ASA can run the same test themselves and it will provide a convenient roadmap on what they must fix.

[Gerald Hitz]

They won’t do this.

ASA changed their business model from hobbyist to professional telescopes and marked the smaller mounts as “legacy”. We cannot expect any new driver from them. Many ASA users already tried to convince them to release new updates, but unfortunately without success.

Since the legacy mounts are not covered in any guarantee anymore they also do not need to fix it…

[Dale Ghent]

Well that’s unfortunate for their users to be abandoned by the company. I guess it is too late for the EU’s new “Right To Repair” law to affect this. I also suppose they also do not see fit to open source their driver so that someone else can do the work they should be doing to fix it, or at least release the communications protocol so that someone has the basic information required to make a new, independent, and conformant driver.

Our stance on non-conformant ASCOM drivers is something we’re strict about, especially since tools such as ConformU are available so that driver vendors can validate their own drivers before releasing them to customers or the public. We do not exist or have the resources to effectively pick up support whenever a company decides it has had enough with a product and abandons it. Implementing workarounds is a technical minefield and makes gross assumptions about how something is really broken, not just how it appears to be broken. So, the cleanliness and reliable operation of our own code cannot be beholden to their bad software design and product lifecycle decisions.

‌

[Martin Junius]

Hi all, normally a DDM would be controlled by Autoslew and N.I.N.A (or CdC and others) interfaces via ASCOM to Autoslew, which works well. If you have problems here, you might want to contact the Autoslew author, Philipp Keller, directly.

[Gerald Hitz]

As already said, the vendor won’t fix it. And we also don’t have the source code to maintain the code.

Nevertheless, I wrote an ASCOM Telescope driver this evening which just proxies the request to another ASCOM Telescope driver. The new driver implements the Telescope V3 standard and fakes some properties which are missing in the original driver.

NINA works like a charm now!

Unfortunately I could not test 3PPA due to clouds.

https://github.com/photon1503/ASCOMProxyHub

[Stefan B]

Cool - nice to see that you could work around the problem!

[Stefan B]

I've added an exception handler to UTCDate property in Nightly 63, as the documentation is not entirely clear on this. In case of a general error we skip this check mount time logic.

[Gerald Hitz]

Thank you very much, Stefan!