I don't think you are at the stage where you need anymore equipment other than cables and perhaps a USB hub.
I had something similar with the SestoSenso2 driver from latest git. I reverted to Stable and now it works.
When you connect via Ethernet you will get an IP address in the subnet of your home network, this is typically an address beginning with 192.168.x.y.
In order to connect via the Ethernet you need to find out what IP address it was given, you should check your Internet router, which also usually hosts your DHCP server which hands out IP addresses to clients on your network. It might have a configuration page which allows you to see the current DHCP leases that are active on your network.
I'm pretty sure that this is an issue with interaction with the latest Kstars / SestoSenso2 INDI drivers from nightly / git.
I was finding that during the Autofocus routing was moving the focuser, but didn't appear to be updating the absolute position of the focuser, so the Autofocus routing reports that it is moving the focuser by 250 steps... and then it just hangs, never getting to the point where it starts to attempt an image capture.
Manually moving the focuser 250 steps and manually taking a capture was working.
I've just properly re-applied the Astroberry stable image and everything is working again (with the same INDI config files).
I'm not so sure, the issue was that when I went "AutoFocus" the only output I got was "Focusing Outward by 250 steps", it didn't even try to capture an image after that.
However, if I manually moved the focuser and manually captured an image then I could try and focus.
Seeing was terrible by the way, low cloud / light fog, so it wasn't an opportunity to capture any quality subs anyway.
I also tried unchecking Focus from the scheduler, but it still appears to try to focus.
All this with stable and also (in the video) checkout from git and compile.
I have had various issues, with various devices scanning serial ports. My advice is to ensure that you hard code all serial devices via their appropriate /dev/serial/by-id/ symbolic link and disable the serial port scanning.
Also if you have a GPS - configure GPSD to the appropriate serial port and disable automatic serial scanning there as well.
I use this one:
I use it as it accepts a M.2 SATA SSD, which were particularly cheap at the time, and it improves performance quite a bit over a normal SD card. I also like it as all ports now go to one side, which helps with cable management.
Yes, I would like this functionality.
The nightly repo is for ubuntu. Astroberry is based on raspbian.
If it works on raspbian it is by coincidence only and will break before long.
If using Astroberry, backup your system (I rsync'd my drive to a second SSD), and checkout the git version and follow the compile instructions finishing with "sudo make install".
My workaround for this on my CGX is to use a ST4 cable.
sudo systemctl stop virtualgps <--- This stops a running virtualgps service
sudo systemctl disable virtualgps <--- This prevents the virtualgps service from starting at boot time, but it doesn't stop an already running virtualgps service.
In case you have problems getting a fix from your GPS, then it's a good idea to put your usual home location into /etc/location.conf
That way, if you can't get a fix, then you can start the virtualgps service and use it with GPSD as normal.
sudo systemctl start virtualgps
You don't need to enable virtualgps in order to start it, that just makes it start automatically at boot time.
edh wrote: Using a VK-162 GPS. Often the gps alternately reports 2 different positions - 1 is the correct current position and the other is lat 52:xx:xx North and long 21:xx:xx East. Viewing the gps data with xgps shows it switching between 2 sources - 1 is /dev/tty/ACM0 (correct) and the other /tmp/vgps which is a softlink to /dev/pts/0. What is this source and how can it be removed?
This happens with multiple VK-162 devices and happens on both Astroberry and Stellarmate.
I have manually changed all my serial devices to the symlinks that you find on /dev/serial/by-id/ folder.
Additionally I have reconfigured GPSD to a manual serial device as I found that by default it seemed to open any serial device to see if it was a GPS device.
Since doing the above all my devices consistently open correctly.