Hi Steve
The INDI Control Panel is a low level interface to the device driver and much of what is on it reflects the coding interface to the device. The layout is largely auto-generated and terminology is almost entirely up to the developer of the driver. Every driver is different so documenting them would be very difficult. There is good documentation aimed at the developers of device drivers.
Some parts of the interface are standardised so that applications like EKOS can wotk with devices from multiple suppliers.
If you are using EKOS (or indeed any other application) you normally would not need to use the INDI control panel much, if at all, as EKOS would send the required settings to the driver and these would show up in the control panel.
As to the specifics of the SVBONY control panel I would interpret it as follows:
Stream On/Off means the video is displayed on screen but is not saved to a file.
Record saves the video to a file.
Record On starts recording until Record Off is used.
Record (Duration) records for the specified number of seconds or until record Off is used.
Record (Frames) records the specified number of frames or until Record Off is used.
Whether FPS is controllable or not depends on the device capabilities. In this case it looks like you set the exposure time and the device decides the frame rate.
WCS is World Coordinate System. As I recall it is used to save RA and Dec in the FITS header when you are imaging. The WCS tab lets you enable or disable this standrad feature.
Read More...
ST4 is even more ancient than that. It has its roots in the old hand controllers used for manually guiding. In those days you would watch a guide star against the cross hair reticle and push the N/S/E/W buttons on the hand control to correct. ST4 autoguiding replaces the manual button pressing which is why it has 4 wires plus a ground - one wire for each of the N/S/E/W buttons on a hand controller. So a 100ms pulse is the same as holding down a button for 100ms. You could still guide manually via the ST4 port with a set of 4 push buttons if you wanted to. Each button grounds the relevant wire which causes the mount to move in the appropriate direction while the wire is grounded.
Pulse guiding uses two way communication between the mount and the autoguider. That way if something fails in the mount is is usually detected pretty quickly. With ST4 there is no feedback from the mount. Also, the ST4 cables are notoriously unreliable. If one wire fails, especially if intermittently, it is difficult to detect what is going wrong.
Read More...
Having Ekos crash after connecting to the driver generally means the driver itself has crashed. It would be useful to see the logfile but you may need to also enable debugging in Ekos and try again to get more information. Click the Logs button on the Ekos setup page and select Verbose, Output to File, tick Mount under the Ekos section and tick Mount under the driver section. Then click Ok and you will get the maximum log messages.
Even though it may be gibberish to you the log file is a great help for support as we cannot see what is happening at your end.
Read More...
Yes my rig sounds complicated but it really isn't too bad. There was a lot of trial and error to work around shortcomings with the Pi and the mount wifi. But this setup is close to the philosophy of INDI and IoT where the idea is lots of low power computers embedded in devices and networked together. The nice thing about this is that if you need to reboot one computer the rest keep running.
The Aaeon is a x64 board. At the time I got it the best Pi option was the Pi3. Some drivers would not run on ARM devices, the Pi OS was a bit flakey and it did not have a USB3. The Aaeon has USB3 and runs 64bit Ubuntu (up to 20.04 now). Unlike the Pi it does not mind being powered down unexpectedly and does not stop responding randomly after an hour or two of operation. Never had any problem getting drivers for it. Plus it has 64Gb eMMC storage so I save images to that and it is basically instantaneous vs several seconds download over wifi. Also, it has a wifi antenna port so I can connect an external antenna. The Pi wifi is rubbish due to the internl antenna. The only reason I use a Pi instead of the Avalon mount's internal wifi is that the Avalon wifi is even worse! I'm considering changing the Pi for a low powered Aaeon due to the hangups. But in the meantime I've installed the hardware watchdog on it and so far it has not hung up since then, touch wood.
BTW I am thinking of also installing a Pi for relay control. One issue I get sometimes with the Aaeon is the ASI1600MM not being found. It seems to be a timing issue and I've found a time delay relay delaying power up to the Aaeon solves it. Having a bit more control would be nice. Unfortunately the Pi Zero W is currently unavailable here. Also note that you need the Pi Zero v2 (the one with an ARMv7 CPU) to install Ubunt. I think I'll go with a Pi 3 Model A+ which is a stripped down Pi and has the same form factor as the Aaeon and only draws about 4W under load, a bit over 1W idle. There is a 3 relay hat with the same form factor.
I used to have KStars crashes quite often but the latest release seems to be more stable. It will still crash if one of the INDI drivers crashes. One solution I found is to run KStars from within WSL (Windows Subsystem for Linux). This works well if you have Windows 11, not so well with Windows 10 or lower. It seems more stable and you can also run Ekosdebugger within the Linux environment for better debugging.
Read More...
Hi David,
The way to run multiple Indi servers is to chain them together which is exactly what I do. I have my x64 device (an Aaeon UP Core) on the dovetail to control EFW, Cameras and focuser. A RPi2 is on the RA axis and controls the mount. Both run INDI with drivers relevant to their tasks. Note: The RPi2 runs without a GUI so it doesn't have much to do except run INDI server. The primary INDI server is on the Aaeon and I chain the RPi2 INDI server using INDI web manager remote driver option which in my case is "Avalon StarGo"@10.42.0.1 (the Pi2 runs a wifi hotspot so my Aaeon has 2 wifi devices: one to connect to the RPi2 and one for the main connection to the rest of the world)
I run Ekos on a third Windows machine and simply connect to the primary INDI server on the x64. It forwards all comms to/from the RPi2 so it looks like the RPi2 drivers are on the Aaeon. So from the main computer everything is in one place.
The only "downside" is that all work on the RPi2 is through the command line via SSH from the Aaeon.
Read More...
You need to use the INDI control panel as there is no relevant EKOS module.
If you use the home automation switches be sure to check they can work with DC. I was looking into a DIY solution for my observatory and the solid state relays I could find dont switch DC, only AC. These devices have a built-in web server which is easy to interface to but may use different command sets which means different drivers. You could instead use something like a eddicated Pi Zero to control all the relays you need. That could run the relevant INDI drivers and nothing else. There may even be a pre-built setup of this type somewhere on the webs. I could certainly find Arduino style solutions quite readily and regular Raspberry Pi relay hats.
Read More...
There are currently two drivers in the 3rd Party drivers repo: indi-asi-power and indi-rpi-gpio which would both do the job. The first one is specifically set up for the ASIAir Pro whilst the second one is more generalised for any RPi so the GPIO pinds are configurable.
There is currently an issue with the builds on these as they are dependent on the build of the libpigpiod library but I'm not able to get that library to build automatically. I'm sure it is not complicated but I've never done it so don't know specifically what is needed. If any other dev knows how, we can probably sort out the issues pretty quickly and make those drivers available in the nightly builds.
github.com/indilib/indi-3rdparty/tree/master/indi-asi-power
indilib.org/raspberry-pi/raspberry-pi-gpio-control.html
Read More...
One way is to use Astroberry on a RPi as it has a relay driver the uses the GPIO pins. There is also the indi-rpi-gpio driver which is similar and also allow PWM on the GPIO pins and can be installed on other RPI systems like StellarMate. The RPi can be controlled via Wifi.
I'm sure there are a multitude of "standards" for wifi enabled devices. As we used to say "the great thing about standards is there are so many to choose from!". As long as there is an API for the device then a driver could be written but the RPi approach can drive conventional relays and the drivers are already there.
Read More...
PHD2 only gets the camera data from INDI and that does not include the focal length of the guide scope. Could be worth an enhancement request in PHD2 to allow the server interface to receive focal length from the client but that would also require a change in EKOS to send it.
Read More...
