Verdict: loose/flaky cable.

I tried a test this morning, and the camera did not even show up in lsusb.

Mattia; did not try unplugging and plugging back in, will do that today. As for the lsusb output suffice it to say that the output included an entry for the camera. I will also try removing the dongle for GPS to see if that changes anything.

Read More...

It's always SOMETHING. Spent most of the weekend fighting WiFi issues (and solving them, yay!!!) but now I have camera issues!

[2024-04-21T19:27:50.224 MST INFO ][ org.kde.kstars.ekos] - "Failed to connect to ZWO CCD ASI533MC Pro. Please ensure device is connected and powered on."

Well, my camera is connected and powered on. The light is on, so that's the power. As for connection lsusb shows me the camera.

and nothing in dmesg.

So what to check next?

Read More...

>> If you were unable to reproduce the problem, it is probably because the configuration files are correct. Tried changing your gpsd file with the previous values, and you should end up with the mount problem again.

I don't think that's right. I experienced failure after changing the gspd file and rebooting. See this post and this post .

Thanks for the explanations of how this all works but I'm still not seeing anything that would explain the intermittent failure. It would be nice to create a rule that would get the dongle onto a completely different /dev entry.

Read More...

After mulling my last post over, several questions come to mind. I am referring to this:

Sorry, that was a nice feature. Can it be added?

Read More...

I spent a frustrating morning playing with my rig in three different setups.
1. No Dongle
2. Dongle connected after Pi booted
3. Dongle connected before Pi boot (the situation last night).
In no case could I reproduce the problem I saw last night. I made the mount go to various objects which were all invisible (due to my doing this in daylight hours) but in all cases the scope was pointed in the right general direction according to the map in KStars. If the problem had recurred, i would have seen error messages like these I saw last night

[2024-04-17T20:32:32.364 MST DEBG ][           org.kde.kstars.indi] - Celestron Advanced VX HC : "[DEBUG] CMD <e> "
[2024-04-17T20:32:32.364 MST INFO ][           org.kde.kstars.indi] - Celestron Advanced VX HC :  "[ERROR] Serial write error: Write Error: Input/output error "
[2024-04-17T20:32:32.365 MST INFO ][           org.kde.kstars.indi] - Celestron Advanced VX HC :  "[ERROR] Failed to read RA/DEC

In Astriarch 1.7, the noVNC clipboard used to allow me to copy something from the host PC into the window, then copy it again and paste it into a window on the Pi where Astroarch is running. This would enable cut-from-host-paste-to-Pi. In Astroarch 1.8 this doesn't work. I can copy from the host-pc into the clipboard window, but when I paste in a Pi window, some other clipboard is the source of what gets pasted. It seems that there are two different clipboards in play. As I said, this was not the case in 1.7 or with Astroberry before that. Is this a bug, or is there some setting I need to set?

Read More...

After sleeping on the matter, I decided to say, to hell with the GPS. Since I have to enter the time and location every time I start the mount, I could just go with that, and use the "Mount updates KStars" for time and date setting. That would cover most of it. The only thing missing would be updating the system clock. I could live with that.

In any case that would fulfill your first test item. I will send you logs and screenshots. Then I would go back to trying the GPS, both after startup and before, and send those logs and screenshots and the other information you request.

But I am still wondering, what is going on on the system level here? Why doies tthe system decide that /dev/ttyUSB0 is no good, and set up /dev/ttyUSB1 instead? KStars and INDI logs provide no information on that, even at the most verbose level. Something is causing that to happen and I wonder if system logs would record some useful information about this.

Read More...

Nope. I spoke too soon. Somehow, in spite of all the changes, /dev/ttyUSB0 still goes away (only /dev/ttyUSB1 remains). Enough. Not going to fight this tonight. Willing to try anything else you might want to recommend another night.

Read More...

Actually START_DAEMON must be set false from my experiments.

With that, and the chrony stuff, it's all good now.

Read More...