"Telescope Not Connected"

[Mark de Regt]

This is a very, very common problem I have--probably three times a week.

The system will be going along just fine (for minutes or hours, or sometimes even throw the error on startup at dusk; last night it was after four hours of perfect imaging), then throw an error message saying the telescope isn't connected. If one is awake and monitoring the system, it's an easy fix--just re-connect and home the scope, and start again.

Apparently, this is a very common problem at my site, with everyone who uses a Bisque mount (mine's a Paramount ME).

But that's not the point of automating software, is it?

What causes this, and how can I prevent it?

Thanks.

Mark

[Eric Dose]

Two main causes that I've heard of:
(1) The user has allowed Windows to suspend USB (most common), or
(2) An electromagnetic pulse (from header thermostat, magnetic relay, etc) confuses Bisque's overly sensitive control board. This might explain why multiple Bisque mounts at your site suffer the same problem.

[Bob Denny]

In general what Eric says are the most common reasons for spontaneous USB disconnect. With that said --

What I see in the log you posted is:

2019-10-08 05:58:58.6: ++ Auto Focus ++
2019-10-08 06:00:12.4: ** ACP script "AutoFocusScheduler" failed:
2019-10-08 06:00:12.4: **Script Error**
Source: ACP
Message: The script was aborted.

The first scheduled autofocus appears to have failed within the ACP support library, probably on a call to FocusMax. For more detail on this (and the failures below as well) we need to look at the actual AutoFocus process logs. They are in My Documents\ACP Astronomy\Logs\ and the one for the above failure will be AutoFocus-10-Oct-2019@055858.txt (or thereabouts). We may learn more from that.

2019-10-08 06:00:12.4: ** Autofocus failed (n=1), will retry ASAP after 0 min.

It's going to try focusing again immediately (0 min above)

2019-10-08 06:00:12.6: Dispatcher cycle time: 0.1 sec.
2019-10-08 06:00:12.6: Acquire data for Observation NGC7380...
2019-10-08 06:00:12.6: (belongs to Project NGC7380, Plan NGC7380-H 1800s (15-16))
2019-10-08 06:00:12.8: ++ Auto Focus ++
2019-10-08 06:00:28.7: ** ACP script "AutoFocusScheduler" failed:
2019-10-08 06:00:28.7: **Script Error**
Source: ACP
Message: The telescope is not connected.

It tried to do another AutoFocus and the telescope was not connected again. In both cases these problems weren't fatai to the run because it was FocusMax that had the problem talking to the mount, and ACP Expert just saw these two as "focus failures" for whatever reason...

Then the Scheduler gave up trying to focus for the moment

2019-10-08 06:00:28.7: ** Autofocus failed (n=2), will retry ASAP after 5 min.

and tried to acquire some data. As soon as it tried to get some info from the mount it saw it was disconnected. End of story.

2019-10-08 06:00:28.8: **EXCEPTION IN SCHEDULER:
2019-10-08 06:00:28.8: The telescope is not connected.

If you want I will analyze the AutoFocus logs, but I doubt we'll learn anything useful. The issue of spontaneous USB disconnects is something we see in astronomy fairly commonly. Adding a bit to Eric's info, I would have a look at the power all the way from the AC line plug through to the DC outputs used to drive the instruments like the mount, focuser, camera, etc. A look with an oscilloscope would be best, to see if there are spikes or brief dips in the voltage under load that wouldn't show on a simple multimeter. The oscilloscope can be used to measure the DC voltages too. Having a big UPS between the wall and the power bricks would be a great idea, along with beefy power bricks/packs. Also look for sources of electromagnetic interference (anything that might arc etc.).

I know you're remote, but if you let the facility people know everything, including the times(!) you'll be helping them zero in on the cause. THe logs will provide you with times. In the case of the log you posted, the first time it saw the problem was at 06:00:12.4 UTC. It is likely that FocusMax had just tried to slew the telescope. Could the Slew have caused a dip in the voltage or a surge? That's the sort of thing I mean.

[Mark de Regt]

Thanks, Bob.

FWIW, here's the autofocus log you requested.

Mark

[William Bristow]

Two main causes that I've heard of:
(1) The user has allowed Windows to suspend USB (most common), or
(2) An electromagnetic pulse (from header thermostat, magnetic relay, etc) confuses Bisque's overly sensitive control board. This might explain why multiple Bisque mounts at your site suffer the same problem.

Yes, item (2) had been a common finding with my own Paramount MX and our five Paramounts of various models and vintages at our remote site.

It is really important when using a Paramount and having high-current devices plugged into the Versa Plate USB sockets and using a common power supply to power those devices, that at least a single USB 2 opto-isolator is installed on the USB 2 cable between the Paramount and the computer otherwise all sorts of nasty leakage currents, noise and spikes from those devices will try to route-to-ground via the Paramount-Versa-Plate USB sockets-MKS Control Board-USB 2 cable to computer connection and the result is repeated random mount disconnects.

We use inexpensive self-powered OLIMEX USB 2 opto-isolators on almost everything at our remote site, I think they cost around $30 each and you have to seal them up with silicone rubber, or put them in a small enclosure as they are supplied only protected by heat-shrink sleeving, plus the OLIMEX brand only supply them with standard sized USB-B-in - USB-A-out sockets so for a Paramount you need USB converter plugs or short patch cables, but the extra effort is worth it in improving the resilience of USB comms between the Paramount and computer as well as providing a measure of protection against lightning damage for the vulnerable USB UART chip on the mount control board.

If you search your local electronics suppliers for USB-2 full-speed, self powered galvanic Opto-Isolators you should be able to find an equivalent to the OLIMEX brand, if you have a Farnell / Element 14 distributor local they usually carry them in stock.

Besides an opto-isolator, all the USB cables will benefit from having snap-on ferrite clamps placed both ends, approx 1” (2.5cm) from the plugs, to help suppress transient interference.

Got to be worth a try if nothing else works......

[Bob Denny]

06:00:06 [**HARDWARE OR DRIVER ERROR**]
06:00:06 [Source: System.Dynamic]
06:00:06 [Object reference not set to an instance of an object.]
06:00:06 [This is not an ACP problem]

This is actually somewhat interesting. It is 100% certain coming from TheSky (the "System.Dynamic" is a signature of an error coming from TheSky). Not very descriptive, but it indicates that there was an internal error of some sort in TheSky. It could be how TheSky responds to a lost USB connection, but could is the key word. I have no info on which to base any sort of conclusion. In any case the Scheduler sees it as some sort of focus failure.

[Bob Denny]

William, we are on the same wavelength. Thank you very very much for relaying your experiences!! Mark, you might want to capture the info in this thread and pass it along to Lloyd.

I talked with Mark at length this morning, stressing how important the power is, and if you'll look at the second to last paragraph in this message I'm repeating the same things only you provided more detail. Thank you again!!

[Bob Denny]

Besides an opto-isolator, all the USB cables will benefit from having snap-on ferrite clamps placed both ends, approx 1” (2.5cm) from the plugs, to help suppress transient interference.

And I learned the same thing relating to Ethernet cables this morning as well, while talking with Eric Dose. Ferrites to suppress the common mode spikes which most often come from nearby lightning hits.

[Mark de Regt]

It is a remarkably cryptic error code, but it always ends up meaning that the mount no longer is connected. The status is changed by (i) re-connecting the mount; (ii) homing the mount, and (iii) re-starting Scheduler.

I'll pass all this on to Lloyd.

Thanks.

Mark

[Bob Denny]

Yes, a glitch. THe System.Dynamic is an internal error-source code of TheSky, I am guessing part of the QT library on which it is based.