I bought Stellarmate OS in October and installed it on a Raspberry Pi3b+ (The latest Pi with a 1.4GHz 64-bit quad-core processor, dual-band wireless, and Bluetooth 4.2/BLE). This system is now running the INDI server core of my astro setup, and I replaced the second Pi in my "distributed INDI-based astro-imaging setup" post with an iOptron StarFi. I need to write an update post for my setup. For the Orion Atlas EQ-G mount I'm using the Shoestring bluetooth-to-serial adapter (BT2EQ6 Bluetooth Module with DB-9 connector). I bought an inexpensive GPS dongle to get position and system time for Ekos and KStars. So far, Stellarmate is working out well. The only downside I have experienced is common on any remote astro system, that's the delays in the capture and focus workflows for large FITS files. My Atik 414EX had larger pixels and lower resolution, and ended up with 16-bit FITS files around 3 or 4 MB, while my higher resolution ZWOs (ASI071MC and ASI1600MM-P) are ten times that size.
August 19, 2018
Running a distributed INDI-based astro-imaging setup
This sounds grander than it is, but it’s not incorrect. And INDI makes it easy, with distributed processing built into the protocol, so that once you have your devices plugged into some number of machines (e.g., Raspberry Pi's) and you establish a chain of priority--who's calling who, there's no difference in the way any app (like Ekos) interacts with the INDI-based system, whether it's a single computer or a group of computers.
My main reason for dividing instances of the INDI server across two Raspberry Pi's is to separate my iOptron CEM25P mount from the rest of the hardware (CCD, filter wheel, focuser, guide camera). I want to run the telescope-based components over wifi, with a dedicated battery pack, so there are no cables running from the mount to...anything. Everything is attached to the scope, including the rechargeable battery. And everything is controlled from my Macbook Pro over wifi. The problem to solve, which started me down the chained INDI server path, was to exclude the Go2Nova 8408 hand-controller from the mix. The iOptron mount passes all slewing and guiding commands (and everything else) through the controller over serial. I don't know if this is unique to iOptron mounts, but I don't have to do this with my Orion Atlas EQ-G; the serial cable from the computer plugs directly into the mount, without having the SynScan controller in the middle. Here’s the general idea with the CEM25P: in order to control the mount from any command software using INDI or ASCOM you connect the Go2Nova controller to the mount as usual, and then run a serial cable (RS232 -> RJ9) cable from the controller to your computer, in this case, a Raspberry Pi3B+ mounted on the telescope. This is fine if you don’t mind running cables to and from your scope, cameras, focuser, filter wheel--for power and data. This is how I’ve run things on this mount for the last year or so.
What changed? I’ve been looking at the StellarMate gadget for a while now, and Jasem’s presentation on the Astro Imaging Channel (https://youtu.be/XkgwY_KsBjc) tipped me toward checking it out. He did a great overview of single-board computers in astro automation, with particular focus on Raspberry Pi's and the Atom-based Windows machines that have become popular. My goals with astrophotography have also changed over the last couple years; I've been moving more toward portability and automation, minimizing setup time, and using smaller refractors and lightweight but accurate EQ mounts. (Another general reason to go with StellarMate OS is it works great with the faster Rasp Pi 3B+. Just purchase the OS on stellarmate.com, download, flash an SD card, and you’re good to go).
Here's a diagram that shows one of my astro device setups. I spent the day getting this going, but haven't been able to get out under the stars with this yet. So far I've tested out the startup process several times, and successfully used all the connected equipment--slewing in KStars, taking a dozen exposures with the main CCD and guide camera, testing the focusing system. Everything worked well, but I think the final test will be guiding. I don't expect any problems, but that's the one connection that relies on one INDI server talking to another without any complications.
Any downsides to this setup? I don’t see any with the system distribution side of things. The only critique of chaining INDI servers I’ve read is about potential inefficiency and network latency, but I don’t see a problem here. Correct me if I’m wrong, but network speeds, even over a slow-ish wifi connection, are still going to be astronomically faster than the serial communication rates we use--9600 bits/sec to control a telescope mount, for instance. Even for guiding, where you need response times in seconds, latency shouldn't be a problem. With these inexpensive Raspberry Pi’s that can support 5.0 GHz wifi with speeds in the hundreds of millions of bits/sec, one second is still a long time.
I have only done some preliminary testing on the power side of this setup, with a boost converter (DC step-up) to maintain a fairly constant 12vdc output for the devices, and with a load the battery and converter can handle. I'm also looking at mounting a separate battery dedicated to dew control, and again it's about maintaining voltage and current.
Some helpful links, including Jasem’s distributed INDI tutorial:
Here’s an overview of the settings I'm using:
All three systems--primary pi, secondary pi, Macbook Pro--are running over the Stellarmate Wifi hotspot. The secondary Pi (astro-ieq) has a static IP of 10.250.250.105
Secondary Pi: astro-ieq
Connect through USB to Serial to the iOptron Go2Nova 8404 controller and CEM25P
Run this command:
sudo indiserver -m 100 -v indi_ieq_telescope
Primary Pi: stellarmate
Connect USB to: Atik CCD, ZWO guide camera, ZWO Filter Wheel, Moonlite-protocol focuser, and the remote connection you just started on the Secondary Pi: iOptron CEM25 on astro-ieq
Add a hostname to /etc/hosts that identifies the Secondary Pi
Run this command:
sudo indiserver -m 100 -v indi_atik_ccd indi_moonlite_focus indi_asi_ccd indi_asi_wheel "iEQ"@astro-ieq:7624
I don't think you need to sudo these commands, but I did in my tests. The "iEQ" designates the device ID for the iOptron CEM25 series of mounts. This parameter "iEQ"@astro-ieq:7624 tells the INDI server to connect to the "iEQ" device (iOptron mount) on astro-ieq (the secondary pi) through port 7624 (default INDI port). The tip from Jasem's tutorial (link above) on chaining multiple Raspberry Pi's together is to run indiserver -m 100 -vv indi_ieq_telescope first to get the verbose output and grab the device IDs. That's how I found the ID "iEQ", which works for several iOptron mounts, including the CEM25P and iEQ30.
I have a Macbook Pro running Ubuntu Mate 16.04 in a Parallels VM. From here I setup a remote mode profile for the Stellarmate Primary Pi, which is running on 10.250.250.1. From the main computer's point of view--my point of view--there's nothing different about any of the operations in Ekos. That is the advantage of using the underlying INDI protocol, which supports distributed components at a deep level. After startup, you just do your imaging runs like you always do: polar alignment, create or manage your sequence queue, schedule new sequences. Everything just works!
Here are three shots of my working multi-node setup, showing the primary Pi (running StellarMate OS). The aluminum box on the top is a Raspberry Pi 3B+, with all four telescope-mounted components plugged in: Atik 414EX mono CCD, ZWO filter wheel, ZWO ASI120MM mini guide camera, and Moonlite-protocol focuser (not in view, other side of the scope. This is a new DIY focuser and controller I'm also testing out, which uses an Arduino Nano, 28BYJ-48 stepper motor, and ULN2003 motor driver board). The black box beneath the Raspberry Pi is a 6000mAh Li-ion battery with 12vdc out (https://www.amazon.com/dp/B00ME3ZH7C), along with a 5vdc USB power port. I run the Pi off the USB port, and the Atik camera off the 12v line, with a step up (boost) converter between to make sure we keep a steady 12v. You see that cable hanging down by the camera? That's the power line. I disconnected it before I took the pics because I'm measuring the boost converter for a 3d-printed case. For the system test I just velcro'd the PC board to the battery pack.
Close-up of the boost converter I used my testing so far, the XL6009 DC-DC step-up power converter https://www.amazon.com/dp/B06XWSV89D. I put this inline between the battery and the camera's 12v connector. The problem I'm solving is the battery pack will drop voltage over time as the batteries discharge, and I'm willing to trade-off amperage in order to keep the voltage stable at 12v along that curve. Again, this is a test, so we'll see how this works out. My concern with real-world use is how much the camera draws for TEC (thermoelectric cooling) when I'm maintaining a sensor temperature at -20C? I still have to figure this out and see what I need to do for power to support this.
This next pic shows the secondary Pi, the black box velcro'd to the back of the iOptron CEM25P hand controller. The RJ-11 line from the conroller plugs into the mount, the RJ-9 (4-pin serial -> USB) cable plugs into the secondary Pi. For now I'm testing this off AC power, but for portability I will also run this side off of a battery pack.
Another shot (from the top) showing the Pi running Stellarmate, with the four telescope-mounted devices using all the USB ports.
Here's a tip for you: if you're not actually doing any debugging, turn off debug on the Options tab in the INDI control panel for all your devices or you’re going to see a bunch of dialogues with commands sent to devices, status codes, and other fun stuff.
February 4, 2018
Astro Automation for Wide Field Setups with DSLR Lenses
The goal of automation is to be able to perform all your astro-imaging functions (slewing, target acquisition, plate solving, focusing, filter changing, and image capture) without going anywhere near your telescope, mount, or camera. That’s pretty much everything except polar alignment, and every time I see those Avalon mounts with the motorized altitude and azimuth positioning I'm thinking that has to be next.
It took me a little while to work out a few complexities, but I have been running an automated astro setup for almost a year. I have every device connected and operating on the pier or tripod--on the deck or out in the backyard, controlled over wifi from inside the house on very cold nights, or when mosquitos the size of velociraptors are out hunting. On cool or bug-free nights, I’ll be outside, but well away from the gear, just to stare at the stars and look for satellites during long exposures.
The heart of any astro automation setup is going to be a computer of some kind, usually running Windows or Linux, that you, the astronomer, will remote into using a service like TeamViewer or VNC. This remote computer will sit outside, connected to your mount, scope, and camera, and will probably be running the software and drivers you enjoy using to control your devices—applications like SGP, MaxIm DL, APT, Ekos/KStars. Simply put, a basic system will allow you to sit inside the house and control a remote computer, which in turn, has all the software running to control your telescope mount, cameras, and other peripherals. There are variations on this, but you typically start with a computer and a USB hub, with everything you want to automate plugged in.
By automating “everything” I mean all the equipment supported by ASCOM or INDI, which is a lot. These are the two main protocols that underlie almost all the devices we use to manage and schedule our astro imaging equipment. (I should also include the OS and device-specific drivers and apps many manufacturers also provide—e.g., see the Moonlite Focuser app below). I have an Orion Atlas EQ-G and an iOptron CEM25P, Atik, ZWO, and QHY cameras, motorized filter wheels and focusers, all the typical stuff that can be controlled through software, running on a machine that you control from a distance (usually over wifi, but a wired network is also common). After polar alignment, I operate my setup remotely. I don't go near the mount again until I'm ready to tear down and bring it all inside.
Here's the typical arrangement of the devices necessary for automated astro imaging, depending of course on the targets you're shooting, type of composition, field of view, the kind of astro-imaging that interests you. If you are an astrophotographer taking long exposure frames of deep sky objects--nebulae, galaxies, then you probably have these five controllable astronomical components: mount, primary camera, filter wheel, focuser, and guide camera. You may not have filters if you're shooting in color. Or you may have more, such as an observatory with a motorized roll-off roof or dome rotation, field rotators, motorized caps or flats, sky cams, weather monitors, multiple OTAs with cameras.
Okay, back to the project.
After having all my stuff running for a while, I wanted to bring the final piece of the automation puzzle to my wide-field setup. I have a Geoptik Nikon lens to CCD adapter, which sits in the middle of everything. I'm typically going to use the Atik 414EX mono CCD or the QHY5III178 color CMOS with the Nikon lens. For guiding I'm going to use a William Optics 50mm scope with a ZWO ASI120MM-S camera, which mounts to that angled piece of aluminum you see in the video and pics below. Notice that everything about this wide-field system can be remotely controlled except the focusing of the Nikon lens.
Before we get to focusing automation, let's look at what I'm focusing, because after some tinkering and prototyping, I selected this lens specifically for this purpose. I have several Nikon lenses that could work, but I went with my old Nikon 18-200mm f/3.5-5.6 lens, mostly because the focus ring rotates in-position--not helical, moving forward and back with the glass. (This is how my Nikon 180mm f/2.8 works--it's fast, heavy, and very solid, but it has manual focus with a capital M, and it will take more than one of the little 28BYJ Steppers to move it). Another advantage of the the 18-200 focus ring is that it's rotationally infinite--is that what it's called? The ring doesn't have a stop, or end point, but continues to spin without affecting focus beyond the minimum focus range and after reaching infinity. This allowed me to use the Moonlite Focuser protocol with a stepper motor to rotate the focus ring without having to worry about limits.
On top of these advantages, the Nikon 18-200mm is a nice all-purpose lens, ED glass, with aspherical lens elements, sharp to the edge at 18mm and at 200mm. Obviously, this is a huge range for a field of view--going from wide angle to telephoto. At 18mm with the QHY camera it's something like 23° x 16° (1406' x 938'). That’s most of the constellation Orion! The main optical downside is that it's a DX lens, suitable for sensors up to APS-C, but it vignettes like a bad photographic cliché with larger sensors. (I haven't used this lens since I moved to the full-frame D750 a couple years ago).
So, back to the real problem: the lack of focus automation when this 18-200mm lens is not attached to a Nikon camera. I did some research on DIY motorized focusers, and there's a lot of cool stuff out there. My requirements were fairly simple: it had to work under Linux on the Raspberry Pi, which is what I use to run Ekos/KStars/INDI, but it would be nice if it ran under SGP with ASCOM. This led right to a thread on the forums at indilib.org (links to all this stuff below) that started with a discussion on using the Moonlite Focuser protocol and commands. From there I ordered and started prototyping with 28BYJ-48 stepper motors and the ULN2003 driver board connected to an Arduino (tested out both the Uno and Nano). See links below for purchasing details--they’re inexpensive. I bought a pack of five stepper motors and driver boards for under $13 USD.
I used pretty standard parts--standard, because I ordered most of it from Amazon. (See the parts list below). There are a couple pieces I scrounged from other projects and components, like the L-bracket that just worked perfectly for adjusting the belt tension, which I took from a cheap follow focus device (about $35 at Amazon), but any L bracket with a slot for sliding will work.
Here’s the wiring diagram for an Arduino Uno, 28BYJ-48 stepper motor, and ULN2003 motor driver board.
And here’s the system running:
Here's my working stup with the Atik 414EX mono CCD and Pentax 200mm f/4, with WO50/ZWO Guide cam:
I have been using João Brázio's Ardufocus code on GitHub: https://github.com/jbrazio/ardufocus with the following changes to the config.h
// Driver pin-out definition
// Define bellow the pin-out for your specific driver.
// IN1, IN2, IN3, IN4
#define MOTOR1_PINOUT 7, 6, 5, 4
I defined the stepper pinouts in reverse, but you can also use:
Here's the OLD Moonlite Focuser protocol code I originall used, lifted from the following INDI forum discussion, along with a few mods to support an Arduino Nano:
Main thread on the INDI forums that started me down the path of making my own focuser for DSLR lenses:
Here's the latest version, but continue on to see where I started with my Astro-controller experiments.
I just finished setting up version 2 of my astro-controller, with both a Raspberry Pi 3 running Ubuntu MATE and a mini Intel-based machine running Windows 10 64-bit--and USB 3.0 and an SD Card slot! I've been running Ekos/KStars/INDI on Ubuntu MATE for a while now, and I don't see going back to ASCOM + SGP as my main astro workflow anytime soon. (And I don't say that lightly. Sequence Generator Pro is one of the most complete, powerful, and easy to use observatory control applications on Windows).
I do have one other option: I haven't tried running the Ekos/KStars/INDI set in the VM under Windows. I suppose it's possible to run everything on this 4.72"/120mm square Windows machine. Okay, I admit a single aggregated system is an interesting idea, but it's tough to beat the Raspberry Pi for a tiny yet powerful, inexpensive, ARM-based system with four USB ports--and everything booting off a micro-SD that can be backed up at regular intervals, and restored in minutes. (And at $35 a board, I have a couple, ready to swap in if something catastrophic happens). The complexity of a Windows10/UbuntuVM all sharing processing power and one set of USB ports tipped me in favor of two separate lightweight systems, both bundled together and easily moved between my two astro setups, William Optics GT-81 and Astro-Tech RC. (The whole bundle is easy to move, mounted on its own dovetail clamp. See the pics for details).
My overall purpose here is to get the best of all astro worlds in one bundle--everything I love about Ekos/KStars/INDI under Ubuntu, and everything I love about the apps that use ASCOM under the hood--or that simply have better drivers or options under Windows because the engineers for some manufacturers favor the OS, such as QHY. (I have used my QHY5III178 CMOS camera with both the INDI drivers and native Windows drivers, and it's just a fact: there's more there under Windows. Same goes for the QHY Polemaster). I continue to use digiCamControl under Windows when I use my Nikon D750 for color subs. This is a full-frame sensor, so the raw files are large, and I haven't been impressed with the D750 on the Raspberry Pi 3 in terms of the transfer time for each image. INDI/Ekos fully supports most Nikon DSLRs, but in this case with digiCmControl, I'm just used to the app--been using it for years. In fact, I started out in astrophotography shooting the moon and a few larger DSOs (M31, M42) using digiCamControl to capture images and control the camera. (I can hear you ask, "why not BackyardNikon?", and I agree that it's powerful and full of features, but digiCamControl is free and has a fairly complete feature set--certainly enough to continue using it). I also have the Atik drivers and Artemis app installed, as well as Nebulosity 4 for managing FITS files and for doing other image-related stuff. Finally, I have installed the closest thing to Ekos that I have used under Windows, Sequence Generator Pro (SGP) by Main Sequence Software. SGPro is amazing--it combines all the loosely scattered ASCOM processes, apps, and control functions under one application, and I would recommend it to anyone using Windows for astrophotography.
So, there you go. I put this new astro-controller setup together in order to have everything INDI and ASCOM offer, and everything that Linux and Windows can offer--and all for around $200 USD. It allows me to control the mount, plate-solve, and guide with one, while taking subs with the other. I remote into Windows from my Macbook Pro using TeamViewer, and I use VNC when I need to remote control the Raspberry Pi. Ekos and INDI have complete remote control operations built-in at a deep level, allowing me (if I ever needed it!) to control multiple observatories, each with multiple astro setups. A couple more details: everything, from the mount up, runs off 12vdc, split between one 12v 7amp line. The Raspberry Pi runs off 5vdc, and I'm powering it off the GPIO pins with 12v stepped down to 5v using a voltage converter (5v 3A Switch-mode UBEC). I only use the GL.iNet GL-AR150 wifi router when I'm using my astro set up away from the house. To mount these boxes on the dovetail clamp I use 3M Extreme Mounting Tape, which becomes terrifyingly sticky and extremely useful when bonding things together, like small astro devices to dovetail clamps, or jet engines to commercial airplane wings.
Here's the new controller setup fully connected and running on my William Optics GT-81, testing out some of the functions, and downloading the astrometry data on the Windows system before I make the cabling nice and neat.