Connecting your astro devices without cables

December 5, 2021

If you're like me, you like the idea of running one power cable to the scope and that's it. Everything but the mount is there—your cameras, filter wheel, focuser, rotator, dew control, everything but the mount. But what if you could also eliminate the cable running down to the mount and free up a USB port at the same time?

With my INDI-based setups, using Ekos to control it all, it's easy to have a separate Raspberry Pi running indiserver connected to the mount and then your main controller on the scope can treat all remote devices as if they're connected locally. That's built into the INDI protocol. There's actually nothing to stop you from using a separate controller (e.g., a separate Raspberry Pi) for every single device, with one acting as the controller for all the others—Sauron mode, one ring to rule them all style. I don't know why you would want to do this with INDI (also looking at you, Sauron), but it will work.

If this decentralized approach is built into ASCOM, I've never seen it. To accomplish this with ASCOM-supported mounts I used Shoestring Astronomy's bluetooth adapter with my Orion Atlas EQ-G (also worked for the EQ6), and I have a StarFi Wifi adapter for my iOptron mount. I don't have anything like these devices for the Sky-Watcher EQ6-R, and when I did some research I didn't run into any astro-specific solutions for the newer Sky-Watcher mounts. 

So, I turned to a generic solution, using a virtual USB hub to connect the EQ6-R and then running the virtual USB client on the main Windows controller. Everything functions properly and should work with any astro apps you're currently using in Windows. I've been using NINA for the past couple months—some great stuff in the latest beta releases: advanced sequencer, the new plug-in model with some awesome plugins, polar alignment built in, and more.

Going wireless with the Sky-Watcher:

Let's cut to the chase. I'm using a VirtualHere server  ( running on a Raspberry Pi 4 with my Sky-Watcher EQ6-R Pro connected by USB cable, and then my Windows 10 machine is running the VirtualHere client, which creates a COM port that EQMOD or Green Swamp Server connects to. Seriously, it's as simple as that.

Here's my Windows machine stacked on a Pegasus Pocket Powerbox. This is attached to the telescope, with all USB and dew PWM cables going directly to the devices and dew strips. I run power directly from the Pocket Powerbox to the camera and focuser. The only cable that has to leave the scope is the 12v 10amp line to power the PPB. 

Here's my Sky-Watcher EQ6-R mount with Raspberry Pi 4 attached. Another 12v 10amp line runs from my power supply to these two with a splitter. 

NOTE: you don't need to run the server (where the mount connects) on Windows, even if your astro apps all use ASCOM in Windows. An inexpensive Raspberry PI will work just fine, even one of the $15 Raspberry Pi Zero 2 W boards.

NOTE 2: Network speed should not be a problem. The guiding system is the obvious one to look at—let's say with a guide cam image every second, deviation calculation, and then pushing a signal to the mount. The way I'm thinking about this set up is that if there's going to be latency in the system, it's not going be across the network. The Sky-Watcher EQ6-R mount is expecting data at 115k BAUD. This is the number of signal changes per second (which I think is changes in voltage—someone correct me if I'm wrong), and 115,200 BAUD ends up being about 11,520 bytes per second, or 92,160 bits per second. I don't know what you're using for wifi, but it's going to be measured in Mbps—millions of bits per second. And with processing speeds and USB data rates also high, I don't see a way for latency to play a role in this setup.

Don at Novaspirit Tech has a great video, walking through the complete setup on the Pi, using Linux on both ends, but it works basically the same with Windows on the client side. ( VirtualHere has servers for just about every OS and hardware combination imaginable, and clients for MacOS, Linux, and Windows. Whatever you're running, it's probably supported.  

It's the coolest thing when you open the Windows Device Manager and see the "Prolific USB-to-Serial Comm Port (COM10)" under Ports (COM & LPT). That's the EQ6-R Pro virtually connected. From there, you run everything normally—start up EQMOD or Green Swamp Server, connect your stuff, and start imaging.

The VirtualHere server is tied to a single device and will allow you to share one USB connection without time restrictions—which may be all you need. To purchase and share more devices with VirtualHere, get a license for $49 USD.

Here's what I did to get things going:

Once you have Raspberry Pi OS running on the same network as your astro controller, open a terminal and get the ARM version of the server. (If you're fairly new to Raspberry PI single-board computers and want to get the basics of installing the OS, check out TheMakersWorkbench video here

Find the download links to the VirtualHere server: 

Here are the basic steps. Open a Terminal and get the ARM version of the VH server:


Make it executable:

chmod +x vhusbdarm

Setup the server to start with the Pi's boot, adding it to rc.local, using nano to edit the file:

sudo nano /etc/rc.local

Move the cursor down to the empty line before the exit 0 

Add the following, pointing to where you downloaded the Virtualhere server for ARM processors:

/home/pi/vhusbdarm -b &

Save rc.local using the following commands in nano:

Control-O, <enter>, control-X

At this point you can reboot and plug in your mount.

On your Windows machine (or Mac, Linux), download the VirtualHere client:

Double-click the app. On Windows it's vhui64.exe (Windows 64-bit VirtualHere Client app), and you should see the VH Client open with a dialog that gives some info about the VirtualHere Server it found on the network—the one running on the Raspberry Pi.

The last step, after you have disconnected the Mount in EQMOD, GS Server, NINA, SGP, etc., go back to the VirtualHere client app and select "Stop using this device" to disconnect the link to the Virtual USB server.