November 24, 2018 - Reading time: ~1 minute

All my images below are free to use for anything covered by a Creative Commons CC-BY license, which is pretty much everything, commercial or non-commercial.

If you're looking for my old Astro Journal with my Equipment and Astro Automation pages:


Connecting your astro devices without cables

December 5, 2021 - Reading time: 9 minutes

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.

Testing out the Newt - leaking light

December 4, 2021 - Reading time: 2 minutes

I was out for a few hours last night with the 800mm Newtonian, mostly to test out the focuser setup and get autofocus working with the AF3. I got about halfway through that--I think I have backlash accounted for, but still had some weirdness with the AF routing, and thinking that was the tension screw on the GSO focuser being too loose. In the middle of testing I kept running into wide bands of reflected light that changed from target to target--I jumped around to NGC 1499, Witches Head in Orion, and last, M45, the Pleiades. There were bands of light of various directions for all but the Witches Head, which is the only one in the southern sky. 

Spent the day shooting dark frames and covering up various parts of the scope to track down the source of unwanted light. (I remember Cuiv had a video on this a while back, with a similar issue with his Vixen 800mm Newt). I now have a black cloth sleeve that rolls up from the focuser base to the camera. It works, and it doesn't even look that weird. Really.

Here's an example of 30 stacked subs of M45, no cal frames, with the band of bad light diagonally across the center--sort of reddish with RGB lined up. I didn't even try to stretch the image, just wanted to see how much showed up after stacking. And the real issue here is that this changed with targets, so no extracting it with flats.

Update: I'm now wondering if my Wyze cam with the IR lights was part or all of the problem. It's one of the Wyze Cam 3s with pretty good low-light video. I usually don't run it with in night vision mode with the IR lights, but I was this time.

The Underutilized Ferromagnetism Advantage

December 1, 2021 - Reading time: 3 minutes

When you see reviews of Newtonian astrographs, you sometimes hear—if the option is available—that you should get the carbon fiber version—for a variety of good reasons, including reduced weight, less susceptible to temperature fluctuations like steel tubes, and that cool carbon fiber look. Steel OTAs (Optical Tube Assemblies) are cheaper, but they also have an underutilized ferromagnetic advantage—meaning magnets love to stick to them. I bought a ZWO EAF (auto focuser) for my Apertura 8" (203mm) newtonian with an 800mm focal length at f/4, but I ended up removing it and using it with the William Optics SpaceCat 51. I have a couple Deep Sky Dad autofocusers, including a new-ish AF3 I had bought for a scope I sold. 

I was tinkering with options for using the AF3 for focusing the Newt. The obvious approach would be to use something like the ZWO EAF bracket and couplers. Or... I could take a completely different path, using strong magnets to hold down the focus motor, with a timing belt to turn the 10:1 reduction focus knob. 

This idea wasn't completely out of the blue. I've been using these neodymium bar magnets for a while to hold down Raspberry Pi devices and my Pegasus Pocket Powerbox. I bought a pack of adhesive-backed metal plates (link below) to hold down these devices. But I don't need them for newtonian scope because the whole thing is steel.

First off, these magnets are crazy strong, and you have to be careful with them. Get them around your tools or a box of hex bolts and it's like angry Magneto tussling with the X-Men. But if you glue two of these to a spare guide cam dovetail bracket, you have the perfect base for your autofocus motor on a steel OTA. I always tape over the magnets with gaffers tape (cloth tape) so I don't scratch my scope. I then glued a small 32mm dovetail to the AF3 motor housing and that's it. I let the E6000 glue dry for 24 hours, and tested out the setup up in N.I.N.A. The belt tension was easy to dial in by carefully sliding the dovetail base and testing the belt. I'm happy to report that everything seems to work well. The motor isn't going to budge with two of these magnets holding it down.  

E6000 industrial-strength glue
Neodymium Bar Magnets
Adhesive metal plates for magnets

Nothing from the Milky Way

November 30, 2021 - Reading time: ~1 minute

Here’s M31, the Andromeda Galaxy without any stars from our galaxy, the Milky Way. The two bright objects orbiting Andromeda are captured galaxies, M101 (bottom right) and M32 above Andromeda. Almost everything in this frame that generates light is a star in another galaxy.

The Baader Mark III Coma Corrector

November 30, 2021 - Reading time: ~1 minute

I just ordered the Baader coma corrector for my 800mm f/4 Newt, and spent a few minutes getting the 55mm distance to sensor spacing right for the ZWO ASI071 camera.

Rosette Nebula - without stars

November 28, 2021 - Reading time: ~1 minute

The large HII region, the Rosette Nebula (Caldwell 49) in the Constellation Monoceros, with the stars removed from the image. This just shows the roughly 500 trillion miles of hydrogen clouds with the surrounding empty space.

NGC 281, IC11, the Pacman Nebula in Ha

November 25, 2021 - Reading time: 2 minutes

A wide-field narrowband (hydrogen-alpha) image of the Pacman Nebula in Cassiopeia. This emission nebula is a little under 10,000 lightyears away in the Perseus Spiral Arm of our galaxy, and it doesn't seem quite large enough for this view--except to show that Pacman is alone out there in this region of space (from our perspective). And that's one of the many cool aspects that makes NGC 281 fascinating to capture--there are so many others, an intense star-forming region, it's a great Hubble palette target, large examples of bok globules, X-ray imaging reveals a dense molecular clouds of hydrogen and carbon, feeding the process of star-creation, to name a few. 

The double star eta Cassiopeiae (η Cassiopeiae) is the bright point of light above Pacman/IC 11 (brightest in the frame). Eta Cass. is made up of eta Cassiopeiae A, a sun-like G-type main-sequence star, and its smaller K-type orbiting companion, eta Cassiopeiae B. With a little research, this might be a cool SF world to tell a story around--the main star is like ours, but with an additional sun orbiting. And it's only 19.5 lightyears away.

Imaging notes: 57 x 300-second subs in 3 nanometer hydrogen-alpha. No calibration frames. Guiding was better than expected, with total RMS hovering between .7 and .9 arcseconds. Seeing was below average--astronomical seeing, which is impacted by turbulence and temperature differences in the atmosphere. It's pretty common to have a clear night with terrible seeing. There's a time and place for twinkling stars--like writing a song, but they're the bane of astrophotographers. Gear notes: ZWO ASI1600MM-Pro monochrome camera, Antlia 3nm Ha Pro narrowband filter, William Optics SpaceCat 51 apochromatic refractor, Sky-Watcher EQ6-R Pro mount.

Orion Nebula, M42 and surrounding region

November 21, 2021 - Reading time: ~1 minute

One more of the Orion Nebula, Running Man, De Mairan's Nebula (M43).