Option to suppress sync mount time via ASCOM on connect

[Ruediger]

Hello,

at the moment, NINA overwrites the mount time when the mount gets connected. This causes serious trouble when the mount is synchronized via GPS or another stratum 0 time sources. This is usually the case for 10 Micron mounts, which need that high precision and have direct attached GPS receivers.

Reasons:
1. The PC clock is very inaccurate. There is a deviation from more than 500ms by standard design. Additionally there is an penalty coming on top from the code execution time.
2, If working offline, the PC clock is not properly synchronized since no timeserver is available at all. So the offset is even much bigger, especially when there is a poor real time clock built in. Therefore the 10M mount has a high precision clock built in, which has always a minor drift to any PC clock.
3. The mount is getting at the same time different, competing synchronizations: GPS hardware and ASCOM.
4. The Model was created with precise stratum 0 time, but then it is running with a different offset coming from the very imprecise Windows time. This causes degration of the pointing model precision.
5. Once connected to NINA you need to reboot the mount, to regain the required times precision from Stratum 0 to have the precision required for satellite tracking.
6. It is an function which is not obvious and also not expected. It leads to problems and you do not now where it comes from. You only notice a sudden time offset you do not know where it comes from.
7. Standard Windows configuration out of the box is set low time precision. In order to get the required time precision, changes have to be made to registry: https://learn.microsoft.com/de-de/windows-server/networking/windows-time-service/configuring-systems-for-high-accuracy

Suggestion:
Please provide an option in mount's configuration to switch off this automatic synchronization via ASCOM.

Thank you in advance!
Rüdiger

‌

[Stefan B]

Hi,

Ideally the 10 Micron driver should reject time syncs when it is being synced via GPS. N.I.N.A: will respect the driver’s rejection when not being available. If it accepts the time set, we do it to synchronize it with the system time, as we assume the mount time is inaccurate due to not being synced by anything. This is done due to users not being aware that the mount time is out of sync - e.g. after daylight savings changes or handcontroller not having an internal clock.
https://ascom-standards.org/Help/Developer/html/P_ASCOM_DeviceInterface_ITelescopeV3_UTCDate.htm

‌

[Ruediger]

Hi Stefan,

I understand this argument, which might be valid in some cases. But on the other hand 10M is of the opinion, why should we handle a use case, where the software is doing something, which it is not expected to do.

This is a kind of deadlock.

Rüdiger

‌

[Stefan B]

I'll add a flag in options to turn off this feature for the next beta.

[Ruediger]

Many thanks for your great support. Much appreciated!

Rüdiger

[Stefan B]

Fix Issue #1281 - Option to suppress sync mount time via ASCOM on connect

→ <<cset 368f60ef5401>>

[Dale Ghent]

For the record, I’m going to absolutely lay into 10micron on this. Their argument of the app setting the time is “unexpected” is completely and utterly invalid and speaks to their unfamiliarity with the ASCOM Telescope driver specification.

The ASCOM Telescope class specifies the UTCDate property, used for getting the mount’s time as well as OPTIONALLY setting it. This means that it is completely possible for this property to be implemented in a read-only manner. In fact, it is the first exception that is explained in the UTCDate documentation that explains this. Any driver author should be able to understand this.

If 10micron feels that a client app such as NINA should not set the mount time, then they should reflect that in their ASCOM driver’s UTCDate implementation by making it unsettable, thus making it read-only. In such a case, when NINA (or any other app) attempts to set the mount time via UTCDate, then NINA will receive the expected PropertyNotImplementedException and move on.

There is no need for a “deadlock” on this as the ASCOM specification is clear: 10micron should implement the UTCDate property in their driver so that it reflects their preference of no app-settable mount time. Them saying that we should remove the action or do additional work shows that they have not done basic research of their own and are unfamiliar with the very specification that their products depend on when it comes to being controlled by higher-level applications such as NINA.

Please link this them this. @Stefan B this is really a driver conformance issue in that 10micron has improperly implemented UTCDate. I say we remove this option pending 10micron’s adjustment of their driver to suit their own stance.

[Ruediger]

Hi Dale,

I also read the specification, which Stefan has linked and I come to a different conclusion. Only because it is optional, it does not mean you can modify it as you want. It gives the programmer the opportunity to implement such a feature, but it does not mean you can modify it unasked, simply because it is there.

By giving the option, the driver vendor stays fully compliant to the specifications. Setting parameters unasked is a complete different topic and I do not understand the argument “if it is available I can do what I want”.

Therefore I do not share your point of view.

[Dale Ghent]

That is a completely wrong interpretation, Ruediger. The ASCOM developer guidance clearly states that anything that is implemented in the driver is expected to work and work correctly. Applying this to optional setters for a property, it is thus expected that the driver author not implement the property as settable if it will lead to unwanted or undesired results. That’s why it is optional. Client app authors should not expect a set to succeed in such a case and should properly handle the defined exception, as we do.

This is not a question of setting mount time being “normal” or “expected” or “unexpected” - this is purely a question of the driver author implementing a specific property in a way that reflects their stance on it regarding their own products and hardware. 10micron responsibility is to provide an ASCOM driver that reflects this. They have not. Are they now going to chase down any client app that attempts to set mount time? No, that would be a huge waste of their time and aggravate their users and customers. The solution is for them to adjust their driver so that it throws PropertyNotImplementedException for the UTCDate setter. This makes it so that their mount’s own time isn’t upset by any ASCOM client, not just NINA, and client apps do not need to implement a needless option that must then be maintained and documented.

[Ruediger]

I do not understand, why the driver developer has to take care, that someone is not abusing a function, which is correctly implemented according to standards. Why has the driver developer to protect the data from unwanted changes?

My expectation from any software is, it does not make any modifications or sets parameters which I have not explicitly asked for.

For me the logic is reversed and I do not follow this reversed logic. For me it is given, that no changes are done, without explicit user request.

The requested NINA option would not be needed, if the time would not be set unasked. It is done just to avoid glitches or problems due to incorrect mount time. You have cured one problem, but caused another one. Both have their justifications.

But where this approach also fails, if you work offline and the PC’s clock is not properly synced at all. It is not only a questionable function in 10M use case, but in general. I would prefer a a warning, as we had in location sync, where the user can decide. This is the same issue.

Anyway, I do not want to extend this topic to a bigger discussion.

I just created this issue because we discussed this point in 10M forum where users suffered from this issue and we were all of the opinion that it is a bad idea to overwrite the time unasked when connecting a mount.

I volunteered to create the Bitbucket issue to articulate the problems occurring from that, since the others had no account.

Rüdiger

‌

[Stefan B]

I completely disagree on Dale here. The property write is optional as said. 10Micron driver also accepts it properly - but this leads to an overwriting of a different - more accurate - time source. Nothing unexpected happens in the driver really. Just an unexpected user experience.

Most likely the intention in ASCOM was for it to be synced by GPS time from the start. N.I.N.A. slapping the system time on it is a good idea most of the time - for mounts that have no internal state etc., but not always - Thus a toggle is warranted.

[Dale Ghent]

An ASCOM client such as NINA is not aware of the “unseen functions” that a given mount may have. Indeed, the user of the mount may not be entirely aware of such unseen functions as well. Remember, we have to look at mount drivers (or any ASCOM driver type, for that matter) through the view of a generic ASCOM interface. Because of this, the ASCOM driver specification provides several ways for a driver to describe its capabilities to a client application. It is the responsibility of the client application to observe these capabilities and properly deal with any capability that is not present or is not permitted by the driver. Again, I reference the ASCOM Guiding Principles regarding this.

In this case of NINA attempting to set the mount time via the ASCOM UTCDate property, it is understood that the driver may optionally implement a setter for it. By implementing a setter, and thus allowing NINA to set the driver’s time, 10micron’s driver is saying “Ok, we will accept any time you give to us.” In effect, the 10micron driver is permitting an unwanted action to occur. It is unwanted because the 10micron mount/software has an alternative means of keeping time. NINA does not know that there is a GPS involved or the mount has its own way of keeping its clock accurate. NINA sets the time, no exception is thrown by the 10micron driver as a result, and NINA is led to believe all is well.

In the ASCOM world and, indeed in the wider world of programming in general, a program that takes any form of input is responsible for validating that input - not only to ensure that the input conforms to expected parameters, but also to react appropriately if the input is not allowed, undesired, or not permitted. That is why the ASCOM documentation for the UTCDate property specifies that, if the time should not be writable for any reason, that any attempt to set it will result in the driver handing the client an exception. NINA’s code understands this is a possibility and such a condition is not treated as an error. NINA just records this in its log and moves on. No user intervention is required.

In 10micron’s case, all they need to do is adjust their driver to throw PropertyNotImplementedException when a client application attempts to set the time. Doing so will prevent any application, not just NINA, from setting the time when the 10micron is being synced with a GPS anyway. This removes the need for a configuration option the user has to manipulate. The driver and client work together to do the right thing.

If it would suit both you and 10micron, I have opened a thread on the ASCOM Developer’s forum to gather the opinion of Bob Denny and Peter Simpson themselves, who are the two people who have the final say in these matters as they maintain ASCOM itself. I expect that they will agree with me on this, and I hope that 10micron follows their advice if so. I think adding the option in NINA was rash and ought to be removed if Bob or Peter agree that it is the driver’s responsibility block unwanted sets of UTCDate.

‌

[Stefan B]

Dale, the property to disallow writes is only specified when the Driver uses the system time as reference.

It is perfectly fine for the driver to accept time setters. This is useful for GPS sources to sync via ASCOM. The ASCOM definition lacks a capability flag to determine if the mount time is GPS synced or not. We just assume it is not and compare it with the system time.
Again - The 10 micron driver accepts it and works perfectly fine with it. We just overwrite a more accurate source, and that is the problem.

[Dale Ghent]

We are talking about the 10micron implementation here, not a theoretical one. If the 10micron driver knows that the mount is receiving time via other means (external application, built-in GPS, etc.) and it considers that time source to be authoritative and desired above any other time input, then the driver should certainly throw on a set of UTCDate. I don’t know how else to explain this other than it is basic input validation. It does not need to be the user’s responsibility to determine this via a setting in NINA. Am I the only person who is reading the UTCDate documentation? There is one, possible two, different kinds of exceptions that the driver can throw if the set is unwanted.

[Stefan B]

I did not implement this based on the 10 Micron driver. Forget about 10 Micron for a moment and just think about the property and how it could be used.
If I have a third party tool that also talks via ASCOM and sets GPS time to the mount, I don’t want N.I.N.A. to send the system time. Simple as that.

[Dale Ghent]

Then don’t run the tool and instead run a tool that sync the PC’s clock to the GPS. If you have a GPS, then it is far better, and far more useful, to sync both the PC and mount’s clock to it. Remember, NINA’s astrometric calculations are done using the PC’s clock, not the mount’s. The PC clock not being synced to a GPS but the mount’s clock is, is not an optimal situation to be in.

GPS (or other time source) → PC clock → Mount (via NINA UTCDate setter)

It is the user’s responsibility to ensure their PC’s clock is accurate because it ought to be for the purposes of astrometric calculations. How they do that - GPS, NTP, PTP, whatever - is up to them. NINA will help them in any case by copying that time to the mount if the mount driver permits that. If the mount and its driver has its own way to get time, then the setter should throw.

‌

[InFINNity-Deck]

Dear Dale and Stefan (and all others),

I understand that in the meanwhile a switch is implemented in NINA where the user can turn this feature off, thanks for that. I prefer to have it like this as I want to be in control of the commands that NINA sends to my equipment and perhaps one day this feature will be useful. I prefer to have a fixed time-offset (preferably very small) due to whatever method I use rather then multiple solutions with their own offsets and not knowing which one was used last.

Once again thanks and thanks for building such an outstanding package!

Nicolàs

[Dale Ghent]

Nicolàs, how are you setting the mount’s time outside of the driver? Timekeeping on computing systems in general is very much a solved problem. In fact, timekeeping in the context of astronomy setups is a topic I have written about. The problem many people encounter on the consumer-grade side of things is that most systems utilize timekeeping methods that are certainly sufficient for consumer-level tasks, but not sufficient when applications require that their notion of time be as accurate as possible. Windows, by default, is not configured to satisfy any requirements of highly accurate time. In fact, Windows' built-in NTP client syncs the system clock once per week by default. That leaves a lot of time for the undisciplined PC clock to drift before it is snapped back to reality each week.

For the purposes of controlling a mount, both NINA and the mount should have clocks that are as close as possible. A basic example is when NINA precesses a J2000 coordinate to local-apparent (aka JNOW) before telling the mount to slew to those precessed coordinates. NINA uses the PC clock to do the precession via the standard SOFA precession library routine that everyone uses. When told to slew to those coordinates, the mount probably uses its internal clock to determine its movements not only on RA, but also on declination if things such as models are involved. If NINA precesses the coordinate with bogus time, a bad coordinate will be given to the mount. If the mount has bogus time, then the mount will not point accurately. Both systems' clocks should be as close as possible to each other.

This is why the mount having a GPS, while nice, is insufficient for the entire system if the PC clock is not also disciplined with a reliable time source. With applications such as NMEATime2 and the NTP.org reference implementation for Windows such as the one available from Meinberg, it is possible to make the PC’s clock constantly accurate, and then provide that time to the mount by setting its clock through its driver’s UTCDate property.

However if the mount has its own source of time that it would rather rely on, that is fine. The driver for that mount can throw an exception if a time set is attempted via UTCDate. This still means the PC’s clock should be maintained, even if it is via a separate (but still authoritative and correct) time source than the mount’s own time source.

But nowhere in this is a situation where one can desire that the mount and PC be operating on wildly different clocks. When you get down to it, the two must be the as in sync as possible. This is why we copy the PC’s time to the mount via UTCDate. Thus there is no need to actively manage this communication between NINA and the mount as long as the mount’s driver reacts accordingly with attempts by NINA to set its time. And that is why I strongly contend that the ASCOM documentation is correct and that any driver that does not want the time set by the app throws one of the two defined exceptions for such a case. Having option an option to disable this is not only distracting and invites problems should a user disable it without being aware of the ramifications of doing so, but it’s completely unnecessary if the ASCOM driver is acting in what it knows to be its best interest.

[Stefan B]

Dale - if the system clock and mount clock is synced already perfectly and N.I.N.A. is sending the UTC date over like it currently does it will already introduce drift.
DateTime.UtcNow can be inaccurate to up to 15 milliseconds! Add to that the code path and device overhead to send this property over. This is the only reason why I added this toggle.

When the clock is wildly off we still show the warning.

[Ruediger]

On 10M mounts the GPS receivers are hardwired to the mount’s computer in order to keep latency as low as possible. There is no tool running, nor a driver in play, nor does the ASCOM driver knows about that.

Additionally a high precision clock is built in.

To set the time via ASCOM is only a fall back in case you have obstructed view and no GPS signal, or you do not own the hardware.

‌

[InFINNity-Deck]

Hi Dale, my mount sits in a an observatory. Time is controlled by a NUC that polls a time server every 256s using w32tm. Setting the mount’s time is done during start-up using 10Micron’s Clock Synch (is does not synch during tracking).

The GM3000HPS clock is very accurate and the drift between PC and Mount marginal, Below is a half-hour graph created by my MountMonitor. The black line shows the drift between mount and pc as 0ms/hour.

The program queries time every 1s for monitoring purposes only. The difference with NIST time server is 13 ms/hour, but that could be noise.

Nicolàs

‌

[Dale Ghent]

@Stefan With our use of .NET8, I believe that value you quote to no longer be the case and is why I felt comfortable implementing the time setting in NINA using DateTime.UtcNow. Reference this GH issue, dotnet#5883 from 2016, where there is a discussion about changing Datetime.UtcNow to use a new precise time function introduced in Windows 8, GetSystemTimePreciseAsFileTime() which has a reported resolution of 1us. There was some debate and some reservations over it being a way to get more precise time but at a cost of being much slower to return it.

That ticket spawns dotnet PR 9736, which explored this more and ultimately implemented this change in February 2017. Some concerns were raised out of research that the altered DateTime.UtcNow would still have some limits to its precision due to clock drift between time sets of the system clock, as in the case of SNTP clients being used. But this was later clarified that the new way is and remains precise if the system clock is slewed/skewed between time reference points, such as what NMEATime2 and the NTP.org Windows service from Meinberg do.

So, on a modern .NET stack as the one we use, I believe that DateTime.UtcNow is as accurate as any time function on Windows can be expected to act. I can’t immediately trace this merged PR to a .NET release but, considering this happened in early 2017 and we are on the bleeding edge with NINA 3.0, I’m confident we are using the high-accuracy version of DateTime.UtcNow and not some creeky older version from Framework.

@Ruediger If the 10u ASCOM driver is aware that the mount is syncing via is own GPS, it can turn off the UTCDate setter. It can dynamically decide if throwing or not is appropriate based on what it knows about any GPS that is present and its disposition.

[Dale Ghent]

@Stefan @Ruediger

Both Bob and Peter have weighed in on the topic I started on the ASCOM Developers' forum. Both agree that the 10micron driver should throw an exception if it decides that setting UTCDate is a undesired thing. So, this really isn’t a matter of opinion that is up for interpretation anymore. Can you please direct 10micron’s staff to the thread?

[Stefan B]

The official MSDN is still stating a latency from 0.5ms up to 15ms. https://learn.microsoft.com/en-us/dotnet/api/system.datetime.utcnow?view=net-8.0
Add to that device latency.

I want to emphasize again, that this decision is not driven by the described driver issue, but by the latency problem - This was a concern of mine from the get go of this feature. If you have a better app/device to do it, N.I.N.A. should have an option to disable this behavior and I don’t see anything bad in this.

[Dale Ghent]

@Stefan there is the possibility that the documentation is out of date. We can see the .NET runtime code explains the use of the high-precision time function:

https://github.com/dotnet/runtime/blob/16cb41496d595e2568574cfe11c763d5e05136c9/src/libraries/System.Private.CoreLib/src/System/DateTime.Windows.cs#L152

[Dale Ghent]

I will also add that there are 40 uses of DateTime.UtcNow throughout NINA, many of which are used in our astrometric calculations. If you are concerned about latency, that worry should extend to more than just this one aspect of mount time.

[Former user]

@Dale Ghent So if the option to disable this behaviour in NINA is implemented, how is this going to affect things? What is the downside?

[Dale Ghent]

Good question, Dan.

First, it would exist to suit, and I would say encourage, a driver design that is not in line with the ASCOM specification and the ethos of interaction it sets forth. The driver is the referee regarding whether time sets are accepted or not by it, as it is with any input. If a such sets are undesired, then it is the driver’s responsibility to signal that by making the UTCDate setter unavailable. Bob and Peter have made this clear in the aforementioned ASCOM Developers thread.

Second, it invites people to unknowingly deactivate a mechanism that was put in place to address a common problem across many makes and models of mounts and their associated ASCOM drivers, where time is not being actively managed by either entity.

We have seen similar problems play out with the “Automatic sync on/off” option in the Options → Equipment → Telescope section. That option was implemented to placate a TheSkyX + T-Point user who complained that NINA sending syncs of plate solve results was messing up their T-Point model, and that NINA absolutely needed an option to turn that off. Well, the ASCOM spec provides for a property (CanSync) that could have been used by the TheSkyX ASCOM driver to tell NINA that it was not capable of receiving syncs. NINA would respect that. Instead of TheSkyX improving their software to appropriately set that driver property when their T-Point product is active, we relented and added the mentioned option. Years later and to my best knowledge, the TSX ASCOM driver still advertises that syncs are accepted even though it may be running a T-Point model that can be corrupted by them, and we’re stuck with an unnecessary option that we cannot remove, and people often mistakenly turn off.

Third, it’s just unnecessary UI and documentation clutter and is a concept that raises a concern to the user experience level that should have been easily taken care of backstage, between the ASCOM driver and the mount.

[Former user]

@Dale Ghent I understand now, basically the 10M driver doesn’t conform to the ASCOM standard for handling such matters. I am not a NINA user, but I came along to better understand what is going on. I don’t have this issue, and as good practice I use a GPS time server on my LAN so that both PC clock and 10M mount clock are accurate and in sync.

Is it safe to assume that most observatory control software use PC clock when doing the plate solve? In this case, if the mount is updated and synced to a GPS time server directly, like some (most?) users do with 10M mounts, but the astro-software looks at PC clock that is less accurate when plate solving, I can see how errors in pointing and model making can appear.

I don’t know how much error this introduces in the model and unguided tracking.

‌

[InFINNity-Deck]

Dear Dale,

I noticed your posts on the ASCOMTalk/Developer newsgroup (https://ascomtalk.groups.io/g/Developer/message/7454). For the members in this current NINA Bitbucket thread that are not members of ASCOMTalk/Developer newsgroup I repeat my post here:

Dear Dale,

I take it that your story of the past few posts in large part relates to the current issue discussed on the 10Micron and NINA fora:

Clock Offset Bump When Connecting Mount To NINA: https://www.10micron.com/forum/viewtopic.php?f=2&t=2052
Option to suppress sync mount time via ASCOM on connect: https://bitbucket.org/Isbeorn/nina/issues/1281/option-to-suppress-sync-mount-time-via

I think the point that 10Micron user (and possibly other mount users as well) have, is that the user wants to stay in control of what is being done with their equipment by whatever software is being used in the process. As an example if I do spectroscopy I do not want to dither as that will move the star from the slit, so I turn of dithering in that case. Had dithering been a default uncontrollable feature of NINA, I would have stopped using NINA and moved to another package. The same happened when I was using SGP and found out that dome control was done without correction for the lateral offset in a side-by-side set-up and at random moments, so also in the middle of long exposures. The SGP-developers did not want to take action on both of them, so I moved to NINA as the former was already implemented while the latter was a quick fix. Both options can be disabled at will, so I was a happy user again (and still am).

The recent issue with NINA setting the mount clock was that initially there was no way the user could control this feature, so no way to enable or disable it. Again in spectroscopy where we want to have the slit landing on the target, we want to be sure that modelling and acquisition is done using the same time-offset to UTC (no matter how large/small). As NINA is not involved (in my case) in modelling, I would certainly not want it to adjust the clock while controlling the acquisition.

So quick-fixes are much appreciated, even if they fix a driver related issue, but need to have the option to be dis/enabled by the user.

with kind regards,
Nicolàs
a.k.a. InFINNity Deck on above mentioned fora

with kind regards,

Nicolàs

‌

[Ruediger]

I want to add a general point:

I want to trust a software. It should not tamper any data, if I have not explicitly asked for. There are many more ASCOM drivers with optional Inputs and I do not want to be afraid, that they also get changed. Suddenly things do not work as expected and I do not know why. This is a decision only the user has to make.

Second: no one has considered in the discussion when you are offline when mobile and the PC clock is not able to sync via time server. Then you overwrite the precise GPS time with something very far off. A couple of seconds are not unusual. I consider this approach in general questionable.

[Former user]

Dear @Dale Ghent , reading closely this paragraph

In 10micron’s case, all they need to do is adjust their driver to throw PropertyNotImplementedException when a client application attempts to set the time. Doing so will prevent any application, not just NINA, from setting the time when the 10micron is being synced with a GPS anyway.

I don’t think this could work. 10M mounts have 2 ways of keeping time. For mobile users, a gps dongle is attached directly to the controller for feeding geolocation, altitude and time.

For fixed observatories, the geolocation and altitude can be set manually in the controller, and for time keeping, there is a separate application, a clock sync utility that reads the PC clock and updates the mount clock accordingly. This implies the PC clock then needs to be kept accurate, usually by GPS dongle connected to the computer or LAN.

Off course even a fixed observatory can use the direct link between a gps dongle and the controller for setting these parameters, but some users don’t have accurate GPS signal in the observatory and fall back on the clock sync utility 10M provides.

So, if I understand your statement correctly, by asking 10M to disable, in the driver, any client application from updating the time, it will render the 10M clock sync utility app useless and the user will have no option to sync the mount clock anymore.

Perhaps this situation can also be avoided in the driver, by checking if the mount has a direct GPS feed or not. If not, the driver should accept only connections from the 10M clock sync utility?

In the end I would point out, that other software packages (Prism v.11 in my case) , lets the user decide how geolocation and time are handled as to not create confusion. For example I disabled any geolocation and time updates to be sent from Prism to the mount.

‌

[Stefan B]

I maintain my decision to keep the toggle option.

It's not advisable to force synchronization of the mount time without considering the existing offset.

Why should N.I.N.A. initiate a time sync if the system is already in close alignment? This rationale underlies my decision to introduce this control feature. Consider the analogy of forcing a location sync based on coarse coordinates without an option to disable it. It's a comparable situation, as it might provide a rough location but override a more precise setting unnecessarily. Indeed, syncing is beneficial if your mount is significantly misaligned, but a minor deviation of a few meters, similar to a discrepancy of a few microseconds, doesn't justify a sync. Thus it can be turned off.

The purpose of the toggle is not to address scenarios where the time sync is clearly beneficial, such as when there's a substantial time offset between the system and the mount, which could lead to unforeseen issues. It's designed to avoid unnecessary syncing when the existing alignment is already sufficient.

[Former user]

Thank you Stefan

[Dale Ghent]

Stefan, is this you also going on record as allowing 10micron’s ASCOM driver to be non-compliant, or are you going to also urge 10micron to sort out their driver in the terms the ASCOM specification and its maintainers lay out?

[Stefan B]

As I mentioned now a couple of times, this toggle has nothing to do with any driver compliance.

[Dale Ghent]

It is still an open question, and the driver’s functioning in this regard was the original reason why this issue was create. I believe it deserves a clear answer.

[Ruediger]

Reuslts ASCOM Conformity Checker

[Ruediger]

I just ran the 10M ASCOM driver against latest "ASCOM Conformance Checker" and it states fully compliant. No error, no issues. It has passed all checks successfully. Therefore I don't see, why the driver should be "non-compliant"

Result above.

[Dale Ghent]

Ruediger, the ASCOM Conformance tester is for validating the technical operation of the driver. While it does a lot, it is not the last word when it comes to whether a driver is truly compliant with the intent of the ASCOM specification, purely from the perspective of an ASCOM client. It can only test the technical aspects and function of the driver. The UTCDate property must be implemented so that the app can read the time, but the ability to set time through it is optional for the driver author to implement. The Conformance tool cannot infer whether setting a mount’s time via the driver is desired or not, for example when the mount is managing time itself via GPS. An ASCOM client, and thus the Conformance tool, is not expected to have this special knowledge about the mount. It can only test that the optional setter for UTCDate throws the expected exceptions if it does throw one because time setting is disallowed or not implemented, or that it accepts the provided time input if it does not throw an exception.

The guidance from the ASCOM authors, Bob and Peter, is clear: If the mount is managing time itself, the driver should throw an exception and reject any external attempt to set the time. This is the change that 10micron must implement. By doing so they protect the mount time no matter which application is using the driver - NINA, SGPro, Voyager, etc. This would make it such that no app would need to implement an option and the issue is taken care of automatically.

[Ruediger]

Sorry, but I have a different opinion. I share the opinion from Stefan and others.

Why should the vendor implement a protection against the abuse of a correctly implemented function? Moreover the term “non-compliant” is not correct. It works exactly as requested by the ASCOM specifications. Your argumentation extend the term “compliance” to some additional use cases to justify an unwanted modification of mount time. I see nowhere a justification to overwrite the mount time unwanted by the users.

Following your argumentation, it would be the same, if I connect an ASCOM switch like the UPB an you set all switches to 0 because it is optional and just for safety reason.

For me it is an unwanted and unexpected misuse of an optional function which purely belongs in the responsibility of the user.

‌

[Dale Ghent]

Ruediger, you can have all the differing opinion you want about it, but what the ASCOM authors say about this topic is what driver authors ultimately must adopt.

There is a reason why the ASCOM specification has defined UTCDate being writable/settable as optional behavior. It is not mandatory that the driver allow it. Why do you think the reason is for that? Think about it for a moment. Why does the ASCOM specification not mandate a settable UTCDate? The ASCOM authors are clear on the reason why it is optional: it is to permit the driver author, or user, to make the decision of whether accepting external time through that interface is desired or not.

You have made it perfectly clear that setting the mount time through any means other than the mount’s internal GPS is unwanted and that is perfectly fine. Because the settable interface for UTCDate is optional, the 10micron can adjust their driver so that it blocks such action no matter which application it comes from. There is absolutely no need to chase down every ASCOM client in the world and beg them to implement an option to stop doing that.

‌

[Dale Ghent]

If you want to use analogies, here is one that is relevant: In our houses, if we do not want someone on the street looking in through our windows at night, what do we do?

Do we go outside ask anyone who walks down the street to kindly not look inside the windows of our house as they pass by?

Or do we just close the blinds or curtains on our windows so that no one can see in?

I will go out on a limb and presume that you would rather close your blinds or curtains. That is what the 10micron driver should be doing with their UTCDate property. If sets through it are undesired, then the driver may block them, and no one has to go around to every app and beg them to implement a special option to not do that.

‌

[Stefan B]

This discussion addresses two distinct problems.

Problem 1: A driver accepting a sync, even when it should recognize that it is already GPS synced:
While the ASCOM specification permits the driver to accept a time sync, it would be advantageous for the 10Micron driver to reject an incoming sync if it is already GPS synced. This improvement in the 10Micron driver would enhance its functionality.

‌

Problem 2: N.I.N.A. syncing Time without even considering if there is an offset
The issue here is that N.I.N.A. indiscriminately performs a sync in all situations, disregarding whether the system time and the mount time are already synchronized. According to the ASCOM documentation, this setter is intended to enhance accuracy (“This allows clients to adjust the telescope's UTC clock as needed for accuracy”).
However, this automatic behavior can, in fact, slightly diminish accuracy. Hence, it is reasonable to provide an option to disable this feature, which is independent of the driver’s behavior.

‌

The toggle addresses Problem 2.
Further discussion on Problem 1 is not necessary here. The preferable approach for 10Micron is clear: to disallow a sync when a GPS source is already present.

[Ruediger]

To point 1: I will drop a mail to 10M and ask for an option in the ASCOM driver to reject the a time sync - though I probably know the answer.

Update: Mail sent to 10M support.

Update 2: request declined

[Chris Woodhouse]

Just a few points of clarification as an owner of 10 Micron and Paramount mounts.
(to Dale’s point earlier) the ASCOM x2 adaptor for TSX has had a sync disable option (to protect TPoint) in its ASCOM properties for many years and there was no need for additional toggle in NINA. It is likely the reason for the disable sync in NINA may well have been for EQMOD users.
Timing accuracy is relative. GPS accuracy is highly dependent upon relative timing accuracy of receivers, measured in nS. The recommended NMEA GPS receiver on my 10U, however, which is a common interface, has substantial absolute timing inaccuracy (and additionally, consider the latency of an NMEA string at 4800 baud). An NTP server is likely more accurate in absolute terms. 10u tracking models benefit from a stable and permanent setup and, it is less common that they will not have access to the Internet. For a tracking model, however, if the absolute timing error is consistent, the model terms can accommodate for that.
So - an NTP source (like those that Dimension 4 uses) is not necessarily inferior to a GPS one. The most important thing is consistency. If you use an NTP server for developing the tracking model (and there are several 10u utilities specifically for doing regular timing syncing to an NTP server), you should operate the acquisition program with the same conditions.
Apart from the less common situation of a 10micron mount in a field with no cellular or internet access, using NTP throughout may be the way forward, with no need for any additional UI complexity

[Dale Ghent]

I’m not aware of how the 10u hardware integrates and uses its GPS. Perhaps they do use the GPS' PPS output to discipline the time that it gives, but I don’t know. Use of the PPS output is how one gets the most accuracy out of a GPS-based time source. Dedicated GPS-based time servers typically also include a rubidium or cesium oscillator to compare the PPS against, or to use in the event that the PPS becomes unreliable due to the effects of things such as GPS jamming. But such attention to detail is likely not present in the mount and is well-beyond necessary for any amateur mount’s own needs.

In the end, the ASCOM driver maintainer's stance is that it is the driver that is responsible for protecting the mount from input that may degrade or damage the mount’s intended operation. This aspect is now being explicitly spelled out in the ASCOM documentation itself. This is why I was adamant that the 10u ASCOM driver permitting time sets when the mount is already using its own GPS for time is an oversight that 10u has the power - and now the clarified responsibility - to address themselves.

‌

[Chris Woodhouse]

I agree. Only they know how the model was made and the best way to set the time, going forward, during imaging. I am flabbergasted by 10 micron’s (and Baader’s) intransigence over matters of basic functionality and electrical safety… so don’t hold your breath.

‌

[Filippo Riccio]

Hi, 10Micron developer here.

Actually, I disagree with the notion that the “correct” action for an ASCOM driver, when requested to set the mount clock to a time specified by the user (in the sense of the client software), is to evaluate whether the user action makes sense or not and succeed or fail accordingly.

There are plenty of situations where setting an “imperfect” time is correct. For example:

• Some other equipment is using a time with an offset, and I want the mount to synchronize with THAT time. Or, I made a pointing model with a clock with some offset, and I want to keep that offset.
• I am making a simulation of some observation run at a different date/time.

The fact that the GPS time is “better” is something that only the user may know. Besides that, there are configurations where the GPS is not involved at all, but the issue remains. An user could use a PC with a time synchronization software to keep the mount clock synchronized to an NTP server, and another PC to run NINA. The mount has absolutely no way of detecting whether a time command comes from NINA (and the ASCOM driver) or from the time synchronization PC. I can think very easily about a situation where the PC running NINA is switched on only when needed, and something like a Raspberry Pi, synchronized to a NTP server, is used to keep the mount clock in sync. We are not here to fight about what we suppose an user is better with.

Besides that, the whole idea that the mount should refuse commands that “degrade” the performance of the system is dangerous. The mount has no idea about what the user wants in terms of performance. Should we reject autoguide commands just because there is a model loaded with 2 arcseconds RMS error? Maybe the user is not guiding, but dithering.

As asked by Ruediger, we may consider a flag to reject the time synchronization commands in the ASCOM driver, but IMHO it would be just another source of potential errors for the user, who could easily forget that the setting exists at all.

A setting in the mount where the user may choose the time source, whether GPS (and in this case, no time command would be accepted) or user specified, could be a better idea - we were actually already thinking about this. But this would not address the issue of a different time synchronization source on the network, so I think the ability for the NINA user to choose whether to perform the time sync or not should be available to the user anyway.

With best regards,

Filippo

[Chris Woodhouse]

If NINA tries to sync location with the mount, and it conflicts, it does ask the user what it wants to do. Location, however, unlike time sources, is going to be (or assumed) constant during the imaging period.

The dilemma is always about how much NINA should add to its UI to accommodate unique hardware needs. There is a NINA plugin for the 10 micron mount. Maybe that, or the 10 micron driver (after all it has a complete Linux machine of its own) is the place to offer the user that level of control.

[Dale Ghent]

Thanks for providing input, Filippo.

The provenance of the mount’s sense of time can be completely controlled by the driver because of two key aspects:

1. Regarding PC time, the ASCOM driver has access to the same local time facilities and information that the ASCOM client does. To me, It has always seemed a little pointless for the driver to accept time input from the client (via settable UTCDate), when the client is very likely getting the time from the same system that the driver is running on. So, why permit UTCDate to be set if the driver can just get and use time from the local system itself, if it has to. It would be making the same assumptions and guesses about the accuracy of the PC’s clock that any ASCOM client would. To that end, the actual UTCDate interface itself is not really designed for applying high-precision time adjustments. It is fine for the vast majority of needs, but obviously it can introduce some measured amount of delay in the time that is sent to the driver through it. So, it would be better if the driver handled time management itself, as many drivers do (Astro-Physics and PlaneWave are 2 examples I am aware of.)
2. The ASCOM driver has the ability to know something more than any ASCOM client can about the mount: It can know that the mount is equipped with a GPS and possibly even the state of that GPS. Ergo, if the GPS has a fix and is maintaining time on the mount. If the ASCOM driver can know that is the case due to its ability to know the status and capabilities of the mount, then why would time sets from external apps ever be desired? A working GPS that is disciplining the clock of the mount can be considered to be a reasonably superior source of time. Therefore, the driver should block any UTCDate set attempts by an ASCOM client to protect that clock.

The reason why NINA attempts to set the mount’s time using the PC’s clock is because many ASCOM drivers sadly neglect to do any proactive time management of the mount. This means we get a bunch of support interactions twice a year when daylight savings time changes occur around the world. People use their mount for the first time after the DST change and wonder why it is pointing 1 hour off in RA, as these mounts unfortunately use local time internally.

So, we take a policy of assuming the PC’s clock is sufficiently accurate, via NTP or GPS, and apply that time to the mount via the ASCOM driver’s UTCDate setter. We make this assumption because not having an accurate PC clock will lead to other problems and it is (or, at least should be) generally understood by everyone involved in astronomy that accurate timekeeping is not optional.

Additionally, setting the mount time via UTCDate saves the user some manual steps, as the only other way to update the mount’s time would be to physically be at the mount to manually type the new time on the mount’s hand controller or keypad. In remote setups or where doing this is inconvenient, automatically setting the time through the driver’s UTCDate can be a much better - and faster - user experience.

But if the mount has its own time source that it trusts and the ASCOM driver is aware of this fact? Then the ASCOM driver can make UTCDate read-only. An ASCOM client that attempts to set the time will receive a PropertyNotImplemented exception instead and, knowing that the ability to set is optional, should quietly move on.

Honestly, I wish there was never a need for a settable UTCDate and every ASCOM driver directly managed time for the mount, and appropriately based on the mount’s own features. If the mount has a GPS or it its own NTP client, then those sources should be preferred above using PC time. If the mount has no GPS or NTP client, it is reasonable to assume the PC’s clock is accurate enough to apply it to the mount - but by the ASCOM driver; not the client. There are some basic expectations that the user has their system environment configured appropriately for their needs. If the user is involved in an astronomy task that requires precision time, it is expected that they have configured their PC as required to meet those requirements. We (the ASCOM client and driver) can only assume that it is.

That is why I view this is a configuration domain for the ASCOM driver, and the ASCOM driver should block UTCDate sets if it knows that the mount already has a better source of time. In an optimal design, the question of a mount’s time management should never be the concern of the ASCOM client. A mount’s time should be taken care of before an ASCOM client even connects to the driver, or before the Connected=true property set returns. Time should "just work" as far as the client is concerned.

[Filippo Riccio]

Chris: I don’t think this is a case of “unique hardware needs”. It is not only 10Micron that can have a mount clock that is more accurate than the PC clock - it depends clearly on the situation. Even a “lesser performing” mount whose alignment procedure has been done beforehand could benefit by not resetting the clock to the PC system clock, even if its clock is inaccurate.

Dale: I would agree with you if the ASCOM specification provided a method such as “synchronize your time with the world clock in the best way you can”. And I see your point in wishing the UTCDate property weren’t settable - forcing the driver, the controller or the end user to manage time in some other, more “correct” way. But, this is not the way it is, and as such the UTCDate is allowed as a way to set the time to the value specified by the user.

Thus, it is an assumption (that is not made by the specification) that this method should be used exclusively to set the time to the “current” time. An assumption that could also be wrong in practice, since the user could legitimately use a different time (some cases above - other accurate time sources who are not a GPS and whose accuracy is unknown to the mount controller; simulating an observation session at a different time; using a clock with an offset due to observational constraints; …).

The ASCOM specification itself states that a reason to throw a “not implemented” exception is that the mount controller could lack an internal clock and use the system time instead. This means it is clearly understood in the specification that the UTCDate property can be set to a different value than the system time - as specified by the user.

Now, the “philosophical” stance. A driver implementation is correct if it follows the specification, not if it makes assumptions about what the user wants. I suppose the consensus that seems prevalent now on the ASCOM-Talk group - that a driver should “protect” the equipment against requests by the user that could “degrade” performance - will open many cans of worms, since one thing is a protection against physical damage (i.e. if a mount controller has knowledge about mechanical limits, it should refuse to perform actions that could cause damage), another thing is to refuse the user requests assuming the driver, or the controller, knows better. The entire reason a standardized specification exists is to provide a consistent interface, not to second guess user choices. For example: it is perfectly reasonable that a printer driver refuses to print when an ink cartridge is empty, to avoid damaging the printing head; but would you accept a printer driver refusing to print images with unbalanced colors?

As a side point, it is not always true that the 10Micron ASCOM driver knows the status of the GPS. This is true if you connect a GPS as the one provided by 10Micron. But even with an external device such as the MGBox (quite common among 10Micron users), which has a GPS, can connect to the mount using the serial command protocol to provide time synchronization. So the time source will be the GPS, but the mount will see it like an external PC sending time synchronization commands through the serial port of the mount.

In the end, I think that managing this issue in the client software is the correct choice, just as it is done for the location. It is the client software that can make assumptions such as “I am starting a photographic session”, or ask the end user, who has the complete knowledge of the system, what to do.

[Chris Woodhouse]

So - there needs to be an explicit decision, made by the user, on the source of the clock, based on their understanding of the relative merit of the stability and absolute accuracy of various time sources. That sounds like the 10Micron ASCOM driver properties need some additional options for the user to explicitly set, and additional API calls to the mount hardware to ensure those assumptions make sense (like local GPS connection).
This has the added benefit that there are a consistent set of controls, irrespective of the choice of capture application… very much aligned with the ethos of ASCOM.

[Dale Ghent]

There was an exhaustive discussion about managing mount time on the ASCOM Developers' forum. The results of this discussion have been reflected in the new draft documentation for the ASCOM/Alpaca interfaces. In short, the mount ASCOM driver must properly manage the time inputs in accordance with the mount’s capabilities and the status of those capabilities. You can read the full article here: https://ascom-standards.org/newdocs/mount-time-place-faq.html

[Filippo Riccio]

I’m going to post my considerations in the ASCOM-talk group as well. In the end, I will follow the consensus, of course, even if I think it is wrong! We don’t want a war about this!