Using a powered hub may not always be the answer. I was having a lot of problems running the Moonlite focuser and Celestron GPS drivers through a powered hub. When I switched to runing them connected directly to the Pi they were fine.
The only benefit of a powered hub is more power and a device that has an external power supply, so is not powered through the USB port, should take very little from the USB.
Thanks for the suggestions stash, connecting the telescope and focuser directly to the Pi and running remotely through VNC and using KStars remotely seems to give reliable communication.
I need to experiment to see how to get everything else connected. I can't avoid a hub entirely because I have 5 USB devices (scope, focuser, filter wheel, guide camera and main camera). At least I can move on now.
From what I hear a Pi should be able to cope with two USB serial devices. I think I'll try writing a TTY exerciser and see if that gives any clues about what is going on.
But not today, I'm going flying.
I've been spending a lot of time tinkering with the drivers to see if I can fix it, both use a basic tty_write - tty_read based send_command function. The timeouts are long, 5 seconds for the Celestron and 3 for the Moonlite. I'm familiar with the protocols, I write and maintain the ASCOM drivers for both of them.
I'd post logs but the critical DEBUG_ERROR messages only show on the display, not the log.
I haven't tried connecting both directly to the Raspi, only throuh a powered hub but that's a good idea. At present I have a keyboard and mouse connected directly but they are pretty passive while this is all going on.
My day job for many years was sorting out this sort of thing, only with electron microscopes, and using a variety of platforms but in more recent years Windows. I used to have a system that had a special RS232 connector that allowed snooping on both sides of the RS232 signals. It would only work on early Windows, Windows 98 was probably the last, and I don't think I've needed it for 20 years. Now I can see a need again.
I really like the idea of a RasPi communiting wirelessly rather than an active USB extension under the back door to a laptop on the washer but I'm getting a bit tired of the struggle.
I am using a powered hub. I'm aware of the power issues with the RasPi.
I'm also aware of the problems with Prolific adaptors and am using a FTDI one.
The cables seem good to me and I've found a short one for the Moonlite. The FTDI serial adaptor has the cable built in, about 200mm long.
Each driver is fine individually but not when they are both running. With both drivers running I see several timeout errors a minute on both but with only one no errors. I haven't changed the cabling, just starting and stopping drivers.
I've tried two Moonlite boxes and it's the same on both. They use their own power supply so overloading the USB power is unlikely to be an issue.
Just tried it again, I only get timeout errors when both drivers are running. No change to connections.
I'm seeing some unreliability with serial communication on a RasPi 3 if more than one serial device is running.
The devices I'm connecting is the Celestron GPS and the MoonLite focuser.
If either is connected on it's own everything works reliably but if both are connected I see occasional serial read timeout errors.
The FTDI USB to serial converter I'm using with the Celestron shows that something is being send but there is no reply. I guess that means that whatever was sent wasn't recognised by the mount.
Does anyone have any ideas? Am I driving the RasPi too hard? I'm reasonably confident that the hardware - cables etc. - is OK, it hasn't changed between running a single driver and running two.
The only solution I can see is to implement retries for critical code, or for polling state ignore the failures.
The dome azimuth can be different to the mount azimuth because the mount may be offset from the centre of the dome and in the case of a German Equatorial mount (The one with the telescope and a counterweight on opposite sides) will vary depending on the pier side.
What happens is that the dome azimuth is calculated from the mount ra and Dec, pier side, time, location and mount position in the dome. This is all dome in the base dome implementation, which all dome drivers are based on, so you won't see it in the individual dome drivers.
Thank you for the reply Jasem. It looks as if I was using some old and unknown version of the driver.
As I said in my second message I got it fixed by recompiling but it also survived an install/update following the instructions in the Atik driver details on the web site.
I have no idea what versions I was using so reverting to them will be tricky.
Incidentally would it be worth having a way to identify components accurately such as by adding a day number to the version data?
Sorry to put you to this work.
Got it going. I noticed that the cooler information wasn't present so I compiled and installed from the sources so I could debug. And all it needed was compiling and installing.
I'm not sure exactly what version I had installed, are the 3rdparty drivers installed as part of the 1.7.6 install or could it have been even earlier?
I tried my Atik 383L+ on my raspi and I get a crash when I try to set the bin size or start an exposure.
This is what happens setting the bin values:
And this is what happens starting an exposure:
[2019-04-15T13:44:47.923 BST DEBG ][ org.kde.kstars.indi] - Atik 383L : "[DEBUG] ArtemisBin 101 2 2 "
[2019-04-15T13:44:47.924 BST DEBG ][ org.kde.kstars.indi] - Atik 383L : "[DEBUG] ArtemisBin Done "
[2019-04-15T13:44:47.927 BST DEBG ][ org.kde.kstars.indi] - INDI Server: "2019-04-15T12:44:47: Driver indi_atik_ccd: stderr EOF"
[2019-04-15T13:44:47.928 BST DEBG ][ org.kde.kstars.indi] - INDI Server: "Child process 5047 died"
[2019-04-15T13:44:47.928 BST DEBG ][ org.kde.kstars.indi] - INDI Server: "2019-04-15T12:44:47: Driver indi_atik_ccd: restart #1"
I suspect this has failed inside the binary library.
[2019-04-15T13:49:41.412 BST DEBG ][ org.kde.kstars.indi] - Atik 383L : "[DEBUG] ArtemisStartExposure 101 1.000000 "
[2019-04-15T13:49:41.413 BST DEBG ][ org.kde.kstars.indi] - Atik 383L : "[DEBUG] Start Exposure: 1 1.00ms (0) "
[2019-04-15T13:49:41.414 BST DEBG ][ org.kde.kstars.indi] - Atik 383L : "[DEBUG] ArtemisStartExposure Done: 0 "
[2019-04-15T13:49:41.961 BST DEBG ][ org.kde.kstars.indi] - Atik 383L : "[DEBUG] ArtemisImageReady 101 "
[2019-04-15T13:49:41.961 BST DEBG ][ org.kde.kstars.indi] - Atik 383L : "[DEBUG] ArtemisImageReady Done: False "
[2019-04-15T13:49:41.961 BST DEBG ][ org.kde.kstars.indi] - Atik 383L : "[DEBUG] ArtemisCameraState 101 "
[2019-04-15T13:49:41.962 BST DEBG ][ org.kde.kstars.indi] - Atik 383L : "[DEBUG] ArtemisCameraState Done: 1 "
[2019-04-15T13:49:41.962 BST DEBG ][ org.kde.kstars.indi] - Atik 383L : "[DEBUG] ArtemisExposureTimeRemaining 101 "
[2019-04-15T13:49:41.962 BST DEBG ][ org.kde.kstars.indi] - Atik 383L : "[DEBUG] ArtemisExposureTimeRemaining Done: 0.999000 "
[2019-04-15T13:49:41.967 BST DEBG ][ org.kde.kstars.indi] - Atik 383L : "[DEBUG] Toggle Debug Level -- Driver Debug "
[2019-04-15T13:49:41.967 BST DEBG ][ org.kde.kstars.indi] - Atik 383L : "[DEBUG] Toggle Logging Level -- Driver Debug "
[2019-04-15T13:49:41.970 BST DEBG ][ org.kde.kstars.indi] - INDI Server: "Child process 8960 died"
[2019-04-15T13:49:41.970 BST DEBG ][ org.kde.kstars.indi] - INDI Server: "2019-04-15T12:49:41: Driver indi_atik_ccd: stderr EOF"
[2019-04-15T13:49:41.971 BST DEBG ][ org.kde.kstars.indi] - INDI Server: "2019-04-15T12:49:41: Driver indi_atik_ccd: restart #1"
[2019-04-15T13:49:41.971 BST DEBG ][ org.kde.kstars.indi] - INDI Server: "2019-04-15T12:49:41: Driver indi_atik_ccd: pid=10067 rfd=5 wfd=19 efd=20"
Some other things, there is no indication of the CCD temperature, even though this is available from the camera and there is a message saying that Abort Exposure isn't supported, even though it is in the camera and driver.
I may have a go at looking at this, I wrote the original Atik ASCOM driver many years ago. They took it in house subsequently but some of this is still vaguely familiar.
I've attached the full log file.
File Attachment:File Name: log_13-43-00.txt
File Size: 143 KB
It's the sofa mount I like Guide corrections by moving a small weight across the cushions.
Perhaps Ron has his house on an equatorial mount. Hope it's a fork mount, a pier flip doesn't bear thinking of.
I think you may need autoguiding becuse the requirements for guiding seem to be much more stringent than for imaging because you need to be pixel accurate over the whole run.
I tried exoplanet imaging a few years ago and when using a separate guide scope there was enough flexure over the 5 hours of images at 30 second intervals that the noise in the processed brightness was enough to swamp the planet brightness dip. This was with a CPC1100 with a ST80 mounted with ADM mounting rail and rings.
I changed to an OAG and the results were considerably different. The stars stayed put and I could detect the exoplanet.
Come to think of it you may be able to use the science image to guide between frames but that could need different software or scripting.
Like it, quite inspiring.
I was saying that my Altair GPCAM MT9M034M doesn't work with INDI on a RasbPi. It behaves as if there is no camera connected, showing a couple of message boxes saying this.
One possibility is that the USB ID is not one that's supported, lsusb shows Device 008: ID:16d0:0b2a MCS.
The 99-altaircam.rules file has this vendor id but someone on the Altair forum says that the id isn't implemented in the binary file.
The 99-toupcam.rules file does not have this id. Apparently some of the same cameras have the USB ID 0547:b121 and these work.
There's been no meaningful response from Altair, this is what makes me cautious about getting anything that relies on their support.