I use the gpsd.socket, you can disable it but then you must enable and start the gpsd.service to be launched all the time. The use of a .socket in systemd allows for the creation of the socket so other services or processes see that it's up but the process itself isn't running.
I did have fun trying to get gpsd to work though. This page helped: gpsd.gitlab.io/gpsd/troubleshooting.html (Check the Troubleshooting Start at Boot).
I've had issues before similar to this, but it's been so long ago that I can't remember how I solved it.
Given the ISO 3200 and exposure time of 60 seconds, but the image doesn't show stars it could be: a) camera is not focused, b) mirror lockup might be an issue. Are you able to see stars/sources when you take an image in the Capture module, rather than the Align module? If you're not getting stars there, then it is to do with the camera settings.
Kevin you made me think of something.
Phil, you say gphoto is working for you. What is the actual commands that you're running? INDI may not be running the same command, which could lead to it not taking the image. So providing the command that is working we can check the INDI code and see if if they match.
I have similar gear as you (have a ASI1600MM-Pro not a GT and have a different focuser), I might see if I can try this. I also run Manjaro ARM rather than Astroberry/StellerMate or Ubuntu based, though I could try to burn an image something default. I can also try to run a test from my x86_64 server. I'll let you know how this goes.
I don't own any of those cameras but I did use my DSLR with Ekos before. So somethings you might want to check on each of the camera that aren't working.
* Are you in BULB mode on the camera?
* Do you have Mirror Lock on or off?
These values need to match with what you have in Ekos, otherwise its just going to be a nightmare. Ekos and Gphoto can't control these, so you need to make sure the values match manually.
I can't remember what happens if the camera isn't in BULB mode but Ekos is, but I do know what happens if you have a mismatch in mirror lock up as the camera will thinks it should put the mirror up waiting for another command but it doesn't receive it, then the camera's mirror lock up will time out.
Basically if you can get gphoto2 to work, you should be able to get Ekos to use the indi_gphoto driver to work, there are aliases for this different type of cameras and since you're getting camera details while it connects that says the driver is working.
I'm not sure if this is the correct setting but do the following:
In the 'Options' button in the bottom right, click on that, and go to the FITS section. In there untick 'Use FITS Viewer'. The help text of this says to 'Automatically display received images in FITS Viewer'.
Also if you're using a RPi, you might want to select 'Limited Resource Mode', though this will mean your DSLR images will come as grayscale and not be debayered (and I found that was the best anyway as you will want to do image calibration in gray scale before debayering).
You have done a lot of investigation including using the cables on a NINA Astro, which I'm assuming was on a x86_64 device running Windows. The fact you're saying even INDI drivers from 18 months ago aren't working but you had this working 6 month sounds like a RPi hardware issue. Just because Linux can see the cable, doesn't mean it can talk to it. If you can afford it, get another RPi and try your SD card in that, even if this doesn't solve your issue you will have a backup RPi in case the other dies when you least expect it; I lost a few nights of observing as I had a RPi die on me and I didn't have a backup. I know I had issues with my EQ6 connecting when I put the cable into a USB3 port, and I was tearing my hair out trying to work it out.
Here are some other things I would try to rule out:
* use different USB ports and see if they give different results (if the EQ8 is like the EQ6 then you should be using USB2).
* if you're using a USB hub, even a Pegasus Astro, ditch the hub and plug directly into the RPi and only in the USB2 ports
Plugging a USB2 device into a USB3 bus will still have Linux show that the device is on the USB2 bus, this is how you can plug a USB3 hub in with USB2 ports and the devices show up in lsusb has being on the USB2 bus.
Do you have any other USB2 only devices you could test? For me my only other one is my GPS dongle, all the reset use USB3.
Do you know if you're using a 32bit or 64 bit Linux? I've not kept up to date with Astroberry but I know that I had issues with Astroberry and using a 32 bit o/s. I've got a lot better stability of the system using a 64 bit Linux but I use a my own setup using ArchLinux and not the Astroberry or StellarMate that most people use. However, you can find that most people tend to get better stability if it's a 64bit OS.
As the RPi doesn't have a system clock you will need to make sure you update the time when you start up (i.e. it doesn't have a clock powered by a small battery when there is no power at all to the RPi). While I don't run StellarMate I do run my KStars on a RPi and even at home I have issues with WiFi and the RPi has issues getting a GPS fix until I get its time synced. I just use my mobile phone, set up a WiFi hotspot, and have the RPi connect to it. Once the RPi has connected I get a GPS fix within seconds with my GPS dongle. The reason for all that, having the RPi connect to the phone allows for the time to be synced.
You may not need the GPS fix to get the right location if you're just setting up a location in KStars but you will need the date and time up to date so you can point your OTA in the right direction. As Jasem says, you don't need the tethering once it has got the GPS fix similarly it doesn't need the the tethering once it has the correct date and time.
Evans told me he way too busy to help. If they provide the script then great, but like Astronerd I'm not going to hold my breath.
They use avrdude to flash the UBPv2, so if they were able to tell us what parameters to use and provide the firmware hex file then the open source community could pitch in to create the automation script.
I set my system up my X11 with a dummy monitor. I needed xf86-video-dummy installed (that's the ARM/Manjaro package, I think the Ubuntu package is xserver-xorg-video-dummy).
If you have a RPI4 you can run a 64bit OS as the processors are the arm64/AArch64. However, you can't upgrade your current install from 32bit to 64bit but need to start anew (get a new SD card and install the 64bit OS). A 64-bit OS can run 32-bit programs (Windows does it, MacOS used to, Linux does by having the 32bit libraries installed in a separate area).