SharpCap Forums

Hello,

I am creating an Alpaca mount.

Sharpcap seens to want to set the UTC time, which my system does not support as I do not have a RTC....

I see the following exchange of data with the http data comming from you and the Json stuff being my answer...

http GET /api/v1/telescope/1093505024/utcdate ClientID=1&ClientTransactionID=57
----------------------------------->
{"ClientTransactionID":57,"ServerTransactionID":61,"ErrorNumber":1036,"ErrorMessage":"ALPACA_ERR_ACTION_NOT_IMPLEMENTED","Value":""}


http PUT /api/v1/telescope/1093505024/utcdate UTCDate=2025-12-02T16%3A13%3A09.0146526Z&ClientID=1&ClientTransactionID=59
----------------------------------->
{"ClientTransactionID":59,"ServerTransactionID":63,"ErrorNumber":1036,"ErrorMessage":"ALPACA_ERR_ACTION_NOT_IMPLEMENTED"}


And then I get the message: "The mount failed to report its current time. SharpCap tried to set the mount time and that failed too......"

What can I do to not get any errors?

Thanks,
Cyille

Hi Cyrille,

what SharpCap is trying to do is to ensure that any mount it connects to has the correct time set - or warn you if it doesn't. For local ASCOM driver the specification requires that the 'get' of the UTCDate property must be implemented (even if it returns the system clock), but that doesn't necessarily transfer to a remote alpaca driver I guess...

The flow here is that SharpCap will ask the mount for its time, and if it fails to produce a time, or produces one that is significantly off from the system clock, it will attempt to set the time on the mount and produce the warning you see if that second stage fails.

You have a few options to deal with this...

1) Just ignore it - the notification shows as an amber 'warning' not a red 'error' because it's impossible to be sure that the issue is serious (even for ASCOM drivers, some ignore the specification).

2) Accept the PUT on the utcDate but ignore it (ie just take no action but return a success error code)

3) If your system can track time while powered on (but no clock to hold the time when powered off), accept the PUT and use it to set the internal time for that session.

cheers,

Robin

Hello,

Thanks,

I ended up replying with a ALPACA_ERR_VALUE_NOT_SET on the get UTCDate from SharpCap.
I then "accepted" the set and returned an ALPACA_OK.

As far as I can tell SharpCap never asks for the date again, so I don't really need to handle it after that (since my mount does not need the time).

No more annoying error!

Cyrille