ASIAIR is based on indilib, indi drivers and it is running the indiserver. The standard indiserver from indilib can connect to other remote indiservers and use remote drivers installed on that other remote computer, raspberry pi, etc.

Assuming that the ASIAIR is using the same standard indiserver, connecting to remote telescope/mount drivers should technically be feasible with the ASIAIR. This would be useful for mounts/telescopes that are not available in the ASIAIR drop-down list for mounts.

Actually, this remote access to indi drivers works very well with Sky Safari 7 Pro, PHD2, KStar/EKOS, StellarMate etc… AFAIK, not in the ASIAIR… which surprises me, because it is one of the basic features of the INID framework.

Did anyone here figure out how this would work on the ASIAIR? So far ZWO does not seem to support this handy feature officially.

    Obs30 The standard indiserver from indilib can connect to other remote indiservers and use remote drivers installed on that other remote computer, raspberry pi, etc.

    @Obs30, although it does not work with ASIAIR, you could also try INDIGO as a distributed telescope controller, where devices connected to multiple servers on a network are considered to be on a single INDIGO system bus. For exmple, you basically see a camera as "cameraA@serverB." It is backwards compatible with all the INDI device drivers, too. INDIGO uses Bonjour (née Rendezvous, now also called ZeroConf), so you don't even have to deal with IP addresses -- an INDIGO client will find all INDIGO servers (and thus, all devices, like mounts, filter wheels and cameras) on the local network by itself. It is easy to link a guide camera that is running on one server to a mount that is running on another server, while a couple of cameras that are choreographing the dither are running on other servers :-).

    INDIGO publishes an image of their server called "INDIGO Sky" that runs on a Raspberry Pi, and a client can be any computer that runs INDIGO.

    Good news for Mac users is that Peter (the brains of INDIGO is Rumen, and the brawns is Peter :-) is himself a Mac user, and the INDIGO dylib works seamlessly in Xcode (not my experience with the dylibs from ZWO, where you often had to revert to linking to the .a modules because their dylibs are so broken).

    I have been using INDIGO Sky, but recently converted my Mac Mini M1 (unused after I replaced the Mini with a Mac Studio) to run on 12V DC, so I will be using a Mac in the future as my INDIGO server. The Apple Silicon hardly uses more power than a Raspberry Pi :-).

    Chen

        Obs30 Did anyone here figure out how this would work on the ASIAIR? So far ZWO does not seem to support this handy feature officially.

        The main problem with a remote mount is the need for a local USB serial connection to keep the ZWO code happy, not sure it does anything more with it than just check it's there. I suppose you could use something like USBIP but you begin to wonder if it's worth the effort. Besides, if you are confident enough to hack the ASIAir you are better off just adding the missing mount driver to the local INDI installation - providing you can find a binary built for the version of indilib that's in the ASIAir.

        You can connect anything that talks INDI to the ASIAir, like Ekos or the desktop version of Stellarium. Ekos lets you examine all the mount parameters that the ASIAir app hides, you can also use it to connect a joystick if you start the joystick driver. You could in theory connect an unsupported camera and view the pictures in Ekos.

            w7ay Yes, I would love to use INDIGO :-). Peter and I are in constant contact to get it to work with my mount. We could not get it running yet. There are always some conflicts with the indiservert on my mount.

            My mount is the Avalon M-Uno with the new StarGO2 Pro Raspberry-Pi4B-based controller. It has its own indiserver running with its native/local indi drivers. I bought different INDIGO products, tried the betas/latest builds and Peter supported me all the way. There was always some type of issue.

            Peter says, we need an INDIGO server running locally on the StarGO2 RPi4 to get this to work. Avalon is not supporting this and ignoring all emails on this subject from both Peter and me, while being very responsive on other topics...

              franco Thank you! Yes, I am using EKOS on my MacBook Pro to set up the mount. Their PAA (polar alignment) works great, because I do not see Polaris from my observing site at home. After finishing the PAA routine, I switch to the ASIAIR. Since EKOS works well, I tried StellarMate ... I prefer the ASIAIR!

              As in the previous post explained, I do have a native driver compiled on the StarGO2 Pi, and already copied it to the ASIAIR Pi following a CN tutorial. It does not seem to accept it (I checked rights and ownership of the driver and the xml files), it could not connect... Maybe the issue is the different version of indi between the StarGO2 and the ASIAIR?!

              Therefore, I want to use the so-called chained indiserver on there ASIAIR if possible. This is very straight forward on EKOS and StellarMate... I don't understand, while ZWO is not supporting this.

              I use PHD2 for guiding and it fully accepts the remote driver. I get the "StarGO2 Telescope"@IPaddress:port connection with EKOS, PHD2 and SkySafari 7. This should work equally well with the ASIAIR, IMHO.

              As for the USB connection... I use the ASIAIR also with a small iOptron mount with a serial cable. This works absolutely flawlessly. The StarGO2 on the other hand does not accept any wired connection to drive the mount. Only way is via the network setup by the RPi4.

                  Obs30 Did you check that your driver runs on the ASIAir? Ie run it from the command line.

                  indiserver -v indi_eqmod_telescope
                  2022-07-22T14:09:20: startup: indiserver -v indi_eqmod_telescope
                  2022-07-22T14:09:20: Driver indi_eqmod_telescope: pid=2381529 rfd=3 wfd=6 efd=7
                  2022-07-22T14:09:20: listening to port 7624 on fd 4
                  2022-07-22T14:09:20: Driver indi_eqmod_telescope: snooping on GPS Simulator.GEOGRAPHIC_COORD
                  2022-07-22T14:09:20: Driver indi_eqmod_telescope: snooping on GPS Simulator.TIME_UTC
                  2022-07-22T14:09:20: Driver indi_eqmod_telescope: snooping on Dome Simulator.DOME_PARK
                  2022-07-22T14:09:20: Driver indi_eqmod_telescope: snooping on Dome Simulator.DOME_SHUTTER
                  2022-07-22T14:09:20: Driver indi_eqmod_telescope: Using prefix /usr/share/indi//indi_eqmod_sk.xml
                  2022-07-22T14:09:20: Driver indi_eqmod_telescope: Using prefix /usr/share/indi//indi_align_sk.xml
                  2022-07-22T14:09:20: Driver indi_eqmod_telescope: Using prefix /usr/share/indi//indi_eqmod_simulator_sk.xml
                  2022-07-22T14:09:20: Driver indi_eqmod_telescope: Using prefix /usr/share/indi//indi_eqmod_scope_limits_sk.xml
                  2022-07-22T14:09:20: Driver indi_eqmod_telescope: EnumeratePlugins - found plugin Nearest Math Plugin
                  2022-07-22T14:09:20: Driver indi_eqmod_telescope: EnumeratePlugins - found plugin SVD Math Plugin
                  ctrl_c

                  If you have the source code in git I could build a native version of the driver for you if you find the binary you have doesn't run.

                      franco excellent point. I have not tried this yet. I can try this out this weekend!

                      Thank you for the offer for compiling the driver! Highly appreciated. It is not a public driver, though. I will let you know after those tests.

                        Is there a possibilty to run the Avalon in LX200 simulator mode with INDIGO?

                        Or is the LX200 simulator (together with a real USB virtual serial port) only available in the orginal StarGO and no longer present in the StarGO2?

                        The "Basic LX200" implementation in ASIAIR is too basic (ZWO's implementation has barely enough of the protocol implemented to let SkySafari control the mount, i.e., move and read back coordinates). But could the LX200 simulator, if it still exists in StarGO2, in the mount itself be sufficiently complete to be able to use INDIGO's LX200 mode (if extra "stuff" is needed in the LX-200 protocol on the INDIGO end, Peter can always add them, eh?)

                        Chen

                          w7ay

                          This is exactly what we tried ... or better what Peter advised, using the lx200 protocol. It kind of worked but it got stuck... I would have to look at the exact error messages again. Peter knows the problem in much more detail... I was a bit lost to be honest.

                          Interestingly, the LX200 classic works from other clients but not with the ASIAIR. With the latter only the LX200 Basic works, which is pretty limited. The LX200 Basic works with the new Sky Atlas, plate solving and re-centering. But not for guiding. When I say "does not work" it means that the ASIAIR says "Connection failed". So there is not even a connection building up.

                          • w7ay replied to this.

                              Obs30 When I say "does not work" it means that the ASIAIR says "Connection failed". So there is not even a connection building up.

                              By watching how the ASIAIR communicates with my mount simulator, I could see that what it does is to initially send some innocuous command to the mount, which often is a "get mount firmware version number" command, and wait for a response, to validate that a correct mount is connected.

                              If ASIAIR does not get a response, or the response is some gibberish, it then goes into the catch all "Connection Failed" message.

                              You can also use a (USB) serial protocol analyzer to watch the messages; I had written one a long time ago:

                              https://www.w7ay.net/site/Applications/Serial%20Tools/

                              (Some idiot actually pirated it, and placed the app (using the same name and app icon, no less) on the Mac App Store without my permission and with zero attribution to me, so I took revenge by adding newer features to Serial Tools -- like the NMEA parser :-) ).

                              You can also monitor the exchanges with a more recent WireShark, which will also watch USB traffic, and not just Ethernet traffic. Just a pain to filter away the zillion of messages.

                              Once you find the Avalon response to that handshake, you might be able to ask ZWO to accept that initial handshake from the Avalon's LX200 simulator as valid.

                              The ultimate solution for you might be to implement an "Avalon Proxy" (using an ARM chip, and even just using CircuitPython from Adafruit) that can translate a protocol the Avalon understands, into say the iOptron protocol. You can then use anything, including ASIAIR, that groks the iOptron protocol.

                              Heck, if you are really, really lazy, just pass all the LX-200 commands between ASIAIR and the Avalon's LX-200 simulator, except for that initial handshake that ASIAIR does not recognize.

                              For what its worth, the iOptron protocol is also a bloody mess too --tiny changes here and there for each of their new mounts. But at least it has a two-argument command to "slew mount at Nx sidereal rate for M millisecond"that gives very precise guide pulse instead of software timing it in a client like the ASIAIR. (Not that ASAIIR will implement that more precise command -- ZWO caters to the least common denomintor, including mount protocols.)

                              Chen

                                  Had a go at chaining the indiserver on the ASIAir but although I saw the connection on the remote server, the ASIAir just kept saying the mount wasn't connected.

                                  So I changed tack. I started an SSH tunnel to the Air for port 7624 and now it's using my remote indiserver.

                                  On my desktop machine I started the tunnel like so, you can add -N so ssh doesn't log in

                                  franco@opti:~$ ssh root@asiair -R7624:opti:7624
                                  Linux asiair 4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7l

                                  I started the indisever on the desktop running the simulator

                                  franco@opti:~$ indiserver -v indi_simulator_telescope
                                  2022-07-23T05:22:37: startup: indiserver -v indi_simulator_telescope
                                  2022-07-23T05:22:37: Driver indi_simulator_telescope: pid=3233791 rfd=3 wfd=6 efd=7
                                  2022-07-23T05:22:37: listening to port 7624 on fd 4
                                  2022-07-23T05:22:37: Driver indi_simulator_telescope: HaAxis: TrackRate 1, trackingRateDegSec 15.041067 arcsec
                                  2022-07-23T05:22:37: Driver indi_simulator_telescope: snooping on GPS Simulator.GEOGRAPHIC_COORD
                                  2022-07-23T05:22:37: Driver indi_simulator_telescope: snooping on GPS Simulator.TIME_UTC
                                  2022-07-23T05:22:37: Driver indi_simulator_telescope: snooping on Dome Simulator.DOME_PARK
                                  2022-07-23T05:22:37: Driver indi_simulator_telescope: snooping on Dome Simulator.DOME_SHUTTER

                                  I then selected the Demo Interface as the mount on the ASIAir app

                                  2022-07-23T05:22:52: Client 0: new arrival from 10.7.114.21:56946 - welcome!

                                  And that was it, all working.

                                  Here is port 7624 on t he ASIAir connected to the ssh tunnel

                                  root@asiair:~# netstat -p | grep 7624
                                  tcp 0 0 localhost:7624 localhost:51528 ESTABLISHED 6014/sshd: root@pts
                                  tcp 0 0 localhost:51528 localhost:7624 ESTABLISHED 766/zwoair_guider

                                  This is to prove there's no indiserver running on the Pi.

                                  root@asiair:~# ps -def | grep indi

                                    gutaker lots of guides out there on the internet but it goes without saying that it's entirely at your own risk.

                                      4 days later

                                      franco Thank you for testing all of this! This is great progress! I had no time yet to continue testing on my side. I hope I get around to it this weekend.

                                        franco So cool :-)

                                        I could kind of get it to work with the ssh port tunnelling 😄

                                        I had to first kill the indiserver on the Air, otherwise I keep getting "Warning: remote port forwarding failed for listen port 7624". After I killed the indiserver, this warning disappeared.

                                        In my case I am working on a MacBook Pro. I am using KStars/EKOS to start the local indiserver with the mount/telescope simulators (i.e. remote demo telescope for the Air). Then using the Demo Interface on the Air, any change in the Asiair App is popping up in the log console in EKOS 😃.

                                        I said "kind of", because "indiserver -v indi_simulator_telescope" from the command line does not work with the KStars/EKOS drivers on macOS... but using the KStars/EKOS GUI works. I guess this is specific to how the drivers/executables are setup in KStars under macOS.

                                        Will try this later on the actual mount Pi later this week.

                                            franco Even the ASIAIR SkyAtlas works with the Demo Mount :-) Slewing to a target changes the coordinates and crosshair in EKOS and KStars, respectively.

                                              w7ay Thank you for the extensive explanations! I have to check out this handshake protocol. This might be the actual problem, why the mount is not "recognised". Great hint!

                                                Obs30 I had to first kill the indiserver on the Air, otherwise I keep getting "Warning: remote port forwarding failed for listen port 7624".

                                                The mount toggle in the app starts and stops the indiserver on the Air so it just depends on the order you do things. I believe if you start the tunnel before you toggle on the mount, the ZWO script that starts the indiserver will silently fail but things will still work.

                                                  Hi... tunnelling worked, but the mount coordinates did not synchronise nor did the mount move when I used the SkyAtlas function. IP and port address were correct. Very weird. I used the Demo Interface on the ASIair.

                                                  Above I stated that the mount accepts the LX200 Basic driver... this is actually only partially true. The indiserver of the mount also launches the indi SkySafari client/driver ("tommyGoodBoy") upon startup. I just realised that the Asiair actually connects to this driver via port 9624 and not the actual mount driver (port 7624). I confirmed this with the INDIGO Control Panel.

                                                  So back to square one... or maybe two ;-).

                                                  Could I extend the SkySafari driver to support all the commands of the mount?

                                                    Obs30 this is my very basic understanding of how the indiserver works. I have written a client for the ccd_simulator but not for a mount but I would assume they work the same way.

                                                    Each driver has a baked in set of properties or capabilities. When the client connects to the server, it can read these properties to determine how to talk to the driver. The driver properties should conform to a standard so the client (in this case the ASIAir) doesn't really need to know any specifics except for how to make the initial connection, ie serial or ethernet so that it can prompt the user.

                                                    You said you used the Demo interface on the Air, this will not work if the driver name doesn't match the driver attached to the remote indiserver. You can see the actual driver names listed in the drivers.xml file ( I think that's the correct file name) included in the libindi package. You can change this file on the Air to add a new driver.

                                                    I tested the tunnelling with the EQMod driver on the Air and it worked fine. The EQMod driver has a built in simulator. It also has an option to use ethernet which you can set from the indi control panel in Ekos. I haven't tried this but it might give you a clue as to how the app behaves when setting an IP address for the mount rather than the default serial connection.

                                                        Write a Reply...