Initial GOTO positioning of telescope sometimes hangs at start of observation.

[Short-bus]

Recent new problem has appeared. Occasionally the initial GOTO instructions at the start of an observation seem to hang. It appears that the motor being moved receives configuration, but then stops reporting any status back. This suggests something corrupted or lost, but the problem is random and uncommon. Adding more tracing into microcontroller side to see if more clues available. No crash or error seems to be reported, but motor being moved simply goes silent. The other motor continues reporting status unaffected.

[Short-bus]

The problem may be related to the microcontroller having a USB connection and/or Thonny active at the same time. It looks like the microcontroller clock gets set from the desktop computer via these connections. During a restart of the microcontroller there may be some confusion with the RPi if the clocks change. It looks like sometimes the 'timer' which triggers motor status messages may get confused if the underlying microcontroller clock changes. 'restart' behaves differently when a USB connection is active because the microcontroller isn't power cycled, this may leave the timer objects in an unexpected state. Have added protection into the timer class to check and correct if the timer delay suddenly exceeds the timer's limit because the underlying clock has changed. Experiments continue to see if this is the real cause.

[Short-bus]

Found that Thonny can automatically synchronise the microcontroller clock. (Thonny parameter sync_time = True ) This would explain some of the problems observed if it's the same for CircuitPython. The microcontroller may have already set a TimeOffset via the GPIO/UART communication. If the microcontroller is then connected via USB and Thonny, or if Thonny connection is restarted then it will synchronise the underlying clock, but the TimeOffset is still applied by the program, resulting in the clock leaping forward in time by a huge amount (years). Possible solutions are to change the sync_time parameter to False for Thonny in its configuration file. But if that's forgotten the behaviour will return. Another solution is to monitor the time returned by time.time() - if that changes massively, then the underlying clock has been synchronised. In which case reset TimeOffset and ClockSynchronised attributes of the clock class. This will then resynchronise with pi-lomar automatically.

[Short-bus]

Summer2023 update includes improvements to this matter. Will continue to monitor during winter observing sessions, but considering this closed until the issue appears again.