AstroGoBox – A Compact Control Box for Mobile Astrophotography

AstroGoBox featured image.

AstroGoBox is a compact, telescope-mounted control box designed to simplify and harden mobile astrophotography setups. It reduces cable chaos, increases USB reliability, and allows comfortable wireless control. This is especially convenient on cold nights.

The AstroGoBox is based on a Raspberry PI 4B which runs the standard Raspberry Pi OS Linux and uses the INDI protocol to control astronomical devices.

This article gives an overview about the AstroGoBox, the idea behind, its features and its tech stack.

Motivation: Improve the reliability of mobile astrophotography setups

Let me tell you a quick story. If you can find yourself in a similar situation this article is for you:

Once upon a time, there was a gnome who wanted to take pictures of the night sky.

At last—after weeks, or perhaps even months—there came a clear, almost moonless night. By a rare alignment of fate, the gnome also found the time to go outside and do some imaging. It was cold. The tripod felt like an ice cube. The gnome wired his notebook to his telescope equipment using several rather long USB cables that twisted across the ground like sleeping snakes.

Eventually, everything was connected: cameras, focuser, mount—every last device. Polar alignment was completed. The object of desire was located in the sky. The camera cooler was running, perfect focus was found, guiding was calibrated, and at last the machinery began to collect photons. The seeing was extraordinary, and the gnome was certain this session would produce glorious results.

While waiting, however, the gnome slowly began to resemble an ice cube himself. He thought longingly of a cup of hot tea in the tent. But would it be wise to leave the notebook unattended? Would the setup truly do its job? Shouldn’t the guiding be monitored? What if one of the cameras lost its connection to the computer? What if focus drifted? What if the mount limits failed and the telescope collided with the tripod in a terrible mechanical tragedy?

And so the engineer gnome decided to stay and watch. The only sounds were a distant barking dog and the gentle whirring of the mount.

About thirty minutes later, the gnome was no longer resembling an ice cube—he had become one. His fingers were stiff, and the cold began to crawl under his winter jacket. At last, he decided it was truly time for a cup of hot tea. The setup was running well, after all… so why shouldn’t it?

Inside the tent, it was cozy. The gnome enjoyed his steaming cup of tea, and for a few precious minutes, all was well. But then an uncomfortable feeling crept in. Was the setup still fine? Shouldn’t he go back and check? Just in case?

After a few minutes, he could bear it no longer. He put down his cup and went outside—just for a quick look.

When the gnome returned to the telescope, he became furious. The guiding had stopped. But why? After some investigation, he discovered that the USB connection to the guide camera had failed. Deprived of its electronic lifeline, PHD had stopped guiding in silent protest. The gnome restarted the software, hoping that only the last frame had been lost. But then he noticed something worse. The mount had lost track of the object entirely. It, too, had disconnected.

With a heavy sigh, the gnome began the alignment procedure once more. He relocated the target and tried to match the previous framing as closely as possible. By now, working at the computer had become nearly impossible—his hands were completely frozen. In the end, he lost at least one full hour of priceless imaging time to a single technical failure.

And as the mount finally resumed its slow, faithful tracking, the gnome once again asked himself the ancient and eternal question of astrophotographers everywhere:

“What in the world am I doing out here?”

And the moral of the story was this: Longer is not always better 😉

If you find yourself in the shoes of our little engineer, you are not alone. Me (and potentially a few others) had (and probably still have) this type of issues with their setup. It was one of those nights when the idea of the AstroGoBox was born.

My initial mobile astro-setup looked roughly like this:

  • A notebook connected to the telescope
  • A lot of cables running back and forth
  • Long USB cables to all devices (mount, camera, focuser, etc.)

This setup has two major disadvantages:

  • Unreliable USB connections: Long USB cables tend to lose connection from time to time. One dropped connection can easily ruin an entire recording session.
  • Comfort vs. cold: Either you stay outside in the cold to see what’s going on, or you go somewhere warm and lose direct feedback.

The Idea: A “Go Box” for Astrophotography

The initial inspiration came from the concept of a Ham Radio Go Box:

  • Ready to go
  • Simple
  • Robust

Why not apply the same idea (at least partially) to a mobile astrophotography setup? That question led to the AstroGoBox project — a solution that is not only practical, but also a lot of fun to design and build.

Creator: Logan Rickert | Credit: Logan Rickert Copyright: © Logan Rickert 2023. Attribution 4.0 International (CC BY 4.0).

Design Goals and Requirements

  • Increase USB reliability: very short USB cables by mounting the box directly on the telescope
  • Immediate status feedback: LEDs for each connected device
  • No more freezing: full wireless control
  • Future-proof: USB-only connections (no device specific ports – e.g. serial / mount / direct connection to focus motor…)
  • Compact and robust: small enclosure, LC display, 12V supply
  • Standalone operation: control without a notebook using display and rotary encoder
  • Low power consumption: based on a Raspberry Pi 4
  • Easy and cheap to build and reproduce: Using standard components (Raspberry PI 4, standard enclosure, display, rotary encoder, …)
  • Based on free & open source software: Use Linux as a basis, INDI stack, all additional software to drive the box is / will be open source

How AstroGoBox Works

AstroGoBox connects devices via various USB ports. It is mounted on the telescope right beside the cameras. Thus, the length of the USB cables is reduced to a minimum. This tremendously increases reliability of the USB connections.

Short USB cable length

The length of the most relevant USB cables – especially the cameras – are now reduced to 30-50cm.

The picture above illustrates how the AstroGoBox connects the different devices. Since it is mounted on top of the telescope (right beside the cameras), the USB cable length can be reduced significantly. This is actually simple but also effective. On my setup I was able to reduce the most relevant USB cables to ~30cm – 50cm. The cables are long enough so that movement of the focus is not disturbed.

The less error prone cables like the serial cable to the mount or to the focus motor still have their original length. At the moment the small device specific adapters for the mount and for the focus are mounted outside the AstroGoBox with Velcro. This way the AstroGoBox remains device unspecific and supports all devices which can be connected via USB and which have a corresponding INDI driver.

Wireless connection to the PC

Before, the notebook was directly wired to the astronomical equipment. The AstroGoBox has a Wifi hotspot inside which allows wireless connections from a notebook (or a mobile phone or tablet – if this makes sense to anyone). There is no additional WLAN router required. That means, one can carry it around – sit in the car, lie in the tent or just be inside. It is also very helpful to put the notebook right beside for polar alignment, without being limited by attached cables or potentially interrupting their connection.

Menu and Local Control

The menu is controlled by a rotary encoder. Turning the encoder moves the selection up or down. Pushing the encoder selects the highlighted row.

The built-in menu is operated using a single KY-040 rotary encoder:

  • Rotate to navigate up and down
  • Press to activate a menu entry
  • A dedicated “Back” menu item for navigation

This allows basic operation and status checks even without any notebook or tablet connected. For example, you can shutdown or restart the AstroGoBox but you can also start, stop or restart individual INDI drivers or – if necessary – the entire INDI server.

But there is more: Sometimes you may want to change the focus for manual observations. If your notebook is not yet setup, or it is just out of reach, you can control the focuser via the menu while standing near the telescope. The same is true for other devices. For example, you can set tracking mode or park / unpark the mount.

LED Status Indicators

The two red LEDs indicate that mount and seeker camera are not ready.

Each connected device has its own red LED:

  • LED off: Device is ready and connected (e.g. via INDI)
  • LED on (red): Device is not ready or not connected

An additional green LED can indicate that all devices are connected properly, allowing you to identify problems at a glance. This is not really necessary, but especially during setup it gives a direct feedback about potential connection issues. The LEDs are controlled on the software layer – i.e. they represent the real connection state of the INDI driver to the device. If either the Linux device is not present or the device is not connected on the INDI level, the LED can be configured to indicate this as a problem by glowing red. It saves you some time fiddling around with the notebook to check connection states. This is especially helpful when your hands are already frozen 😉

Modes of operation

The potentially preferred mode of operation is connecting from your notebook to the INDI server which is running on the AstroGoBox (via the wireless connection). If you run for example KStars (with Ekos) or XEphem as your main astronomical software on your notebook, you can easily connect and thus you get full control over your astronomical equipment remotely from your laptop.

In addition, the AstroGoBox runs a VNC server. That means one can connect to it and theoretically the entire application stack (including KStars or XEphem) could run on this box. I do not recommend this due to lack of performance of the Raspberry PI machine for such purpose, but in general it is possible.

Mounting the AstroGoBox

To keep the USB cables as short as possible, the AstroGoBox is supposed to be mounted directly onto the telescope. Depending on your setup this will of course vary. On my setup the box is mounted with a photo screw (diameter 1/4-20 UNC). This diameter matches some screw holes on my mounting rings. It was a bit hard to find the correct screw but finally Ebay did the trick (this is not an affiliate link). In order to mount the box I decided to drew a hole right through it instead of gluing or using Velcro fastener. This gives better stability since about 10 cables will be connected to this box. Furthermore, controlling the menu with the rotary encoder is much more fun when the box is stable.

Engineering thoughts

Main Components

Essentially, the AstroGoBox consists of the following components:

Of course everything is somehow connected. The following diagram provides an overview:

Wiring status LEDs, display and rotary encoder

The status LEDs, the display and the rotary encoder are connected to the Raspberry PI 4. Overall, wiring the display, the rotary encoder and the LEDs is no rocket science at all. Still, overall there are quite some wires. Especially with the selected enclosure (see below), the available space for additional cables is quite limited. Therefore, I decided to create a small two-sided circuit board which plugs right into the 40 port GPIO in a 90° angle. This way I save a lot of space and also to me this solution seems to be much cleaner. I was using free tool KiCad to create the schema and the circuit board.

You can find the project files on github here.

I sent the circuit board to aisler.net for manufacturing. The minimum quantity at that time (March 2024) was 3 PCB boards and the overall price I paid was roughly 25€.

The front panel PCB plugs right into the Raspberry PI 4 via a 90° 40 pin plug. Please be aware of the small distance of about 1mm between the plug and the front panel circuit board. Without that gap the front panel would have collided with the Raspberry PI.

Enclosure

The enclosure is a standard Bopla U-135 with replaceable front- and back plates.

The electronics are housed in a standard plastic enclosure (Bopla U135) with replaceable front- and back plates. These plates can be redesigned and 3D-printed to accommodate USB ports, displays, or future extensions. For the moment my initial solution is very cheap since I did not spend the time to design a nice looking front-plate.

Overall, the box is pretty packed with the required components. If you just look at the main component, the Raspberry PI 4, you will easily jump to the conclusion that this enclosure fits easily. However, if you look closer you may discover that the cables, 12V power converter, USB hub and display require quite some additional space. During planning there was a moment when I thought all the stuff will not fit in there… but finally it worked out. The following picture shows how in the end everything fits.

Ventilation

12V Power Suppy for Raspberry PI

12V-to-5V DC-DC converter working with Raspberry PI 4.

Usually the Raspberry PI 4 is powered by a 5V power supply. However, since my entire astronomy equipment is powered by 12V, I needed a power converter. I a 12V to 5V converter from Greluma one at Amazon for about 9€. The device plugs right into the USB-C connector of the Raspberry PI 4. The first time I plugged in this device I was a bit nervous to mess up my Raspberry PI, because I have read some horror stories about cheap converters before. However, luckily it worked and so far I did not have any issues with this converter.

Exposing the Raspberry PI 4 USB ports to the “outside world”

The final clue were the very short USB cables available with connectors into different directions. The Raspberry PI 4 has 4 USB ports which are all quite close to reach other. Since I needed at least one of them to be wired to the USB Hub, I could not expose then 1:1 to the the “outside”.

By using USB connectors which go into different directions, I was able to access all the Raspberry PI 4 USB ports which I needed under the given space constraints. The image on the left shows three USB connectors. One of them goes to the USB HUB. The other two are exposed as female USB-A ports. Their intended use it for example for cameras.

USB Hub

The enclosure of an old USB 2.0 hub has been removed and it was mounted right inside the AstroGoBox.

As USB hub I am using an old USB 2.0 device which still was lying around somewhere. If you are interested in building your own AstroGoBox, you most likely will not have the same USB hub available. Finding a good alternative may require some creativity. Below are some proposals as alternative USB hubs which might or might not work (I have not tried them). At least the proposed devices have a short cable of max. 20cm. It might be an option to remove the enclosure of the hub and put it right into the AstroGoBox. As an alternative an integration without removing the enclosure might be possible.

Here is the list of potential candidates:

Furthermore, the USB A connector which is connected to the Raspberry PI might be too long to fit into the box. One idea to overcome this issue might be a 90° angled connector like this one.

Software

This section provides an overview about the software stack used by the AstroGoBox.

AstroGoBox Operating System

The AstroGoBox runs a standard Raspberry Pi OS. In my case I was downloading the image for the Raspberyy PI 4B. If you run a Linux you may use rpi-imager to create new 64bit OS installation. On Debian based Linux systems you can easily install rpi-imager by typing the following command:

sudo apt-get install rpi-imager
Controlling Astronomical Devices with INDI

To control the connected astronomical equipment it uses INDI plus the corresponding device INDI drivers (3rd party). In my experience it was a good idea to not rely on the package maintainer version. Instead I suggest to checkout one of the latest release tags of the INDI git repository and compile it yourself. Then you can also checkout the INDI 3rd party git and compile the INDI device drivers you need for your equipment. The INDI server automatically starts when the AstroGoBox boots up. I registered it as a service to easly monitor, start, stop and restart it.

Wireless control

In order to allow wireless access the AstroGoBox makes use of hostapd and iptables.

  • hostapd creates the Wi-Fi network to which Wi-Fi clients can connect.
  • iptables ensures that the Wi-Fi clients obtain an IP connection to the next network via NAT (routing/firewalling).
Raspberry PI menu control

Another component is the AstroGoBox Raspberry PI menu control. The menu software handles the input from the rotary encoder and updates the content on the OLED display. It also handled the execution of commands depending on the user input. It is a small project created by myself for this purpose. It is freely available on github. The menu control also starts automatically and runs as a service.

LED status control

The next software component is the status LED control. Those LEDs shall indicate if a device is ready. Ready in this context means that it is physically connected (e.g. via USB) and that the corresponding INDI driver is running and is also connected. Only if both conditions are true, the device is ready to operate.

Initially I solved this with a bash script which was making use of indi_getprop to read the connection state of a device and the gpio command to enable or disable the LEDs. In addition I had to check if a device was even physically connected because some INDI 3rd party drivers did no handle a physical connection loss correctly.

However, this script became unmanageable and was not really flexible. For this reason I created the small software project indi2gpio also freely available on github. This service as well runs as a service.

INDI Device Auto-Connector

The last piece I decided to add is an INDI device auto connector. INDI already comes with a similar functionality but I found it unreliable at the time. The main issue I faced were certain INDI drivers which were not handling a physical connection loss correctly. Some INDI drivers were indicating that a device was still connected even if it was unplugged – forever.

For this reason I created a small project which monitors the device on both levels: The Linux “device” level (/dev) and on the INDI level. If on either level a connection loss is indicated, the INDI auto connector automatically restarts the corresponding INDI device driver. The project is freely available on github. It also runs as a service on the AstroGoBox.

And then, finally, after all the work has been done…

While enjoying a warm and tasty cup of tea in the cozy tent, the gnome calmly monitored the guiding process on his laptop. Thanks to the live stacking feature of Siril, he could watch how each new frame steadily improved the image, photon by photon.

Every now and then, the gnome paused the automatic recording and carefully refocused the camera to compensate for the slow drift caused by falling temperatures. Small guiding corrections he applied directly in PHD, pressing a few buttons while observing the never-ending ups and downs of the guiding star’s deviation.

All the while, he sipped his deliciously warm tea. And once again, a thought crossed his mind:

What an awesome hobby this was, wasn’t it?

And if the gnome has not yet built an observatory, then he is still using the AstroGoBox for his mobile setup to this very day.

Leave a Reply

Your email address will not be published. Required fields are marked *