I too have about a 2m cable. I got a couple of RJ11 breakout boards so I can just use whatever telephone cable is handy.


And by "much faster" I mean "a qualitatively difference computing experience". I still have the occasional lag or wait, but it's night and day vis-a-vis the microSD days.



I don't have the reference at my fingertips but it's pretty easy to set up the Pi to boot StellarMate from an external USB. This has several advantages. A USB 3.0 SSD is much faster than a microSD card, you can have all the space you want to store images (which also happens pretty fast), and you can remove it and plug it straight into your processing computer instead of having to drag files across the network.

In fact I often just leave the files in place and process them right there on the SSD -- it's that fast. The only challenge is finding a way to mount the ext4 file system. On my Mac it was pretty easy, I'm still struggling to do it for Windows. It's also a pretty inexpensive way to go, you can get a terabyte drive for around a hundred bucks.

OK, one other challenge: Sometimes I disconnect the SSD and then forget where I put it. Or forget to plug it into the Pi and wonder why I can't connect to it (answer: its boot drive is missing, you numbskull Rick!). My SSD is maybe half a centimeter thick and considerably smaller than the Pi -- a little tab of Velcro holds it nicely to the case. I got one with a USB-C connector so it would plug right into the MacBook Pro where I do all my processing, so I have a USB-C --> USB-A adapter on the Pi.

As for connection method reliability, I guess I have to agree that I have seen both Wifi and cabled connections to a laptop die more often than sequencing does on the Pi, and the latter is most often a guiding or focusing fail which is independent of how you connect. Usually if a cabled connection fails it's because the astronomer is clumsy, but "I resolve to be more careful around wires in the dark at 2 AM" is not exactly a robustly-engineered solution. Aviation taught me that human factors should be accommodated where possible, not treated as character flaws to be overcome.


I use Method 1, but it's largely because I have worked a lot at sites without electricity. I've never had a laptop with enough battery capacity to stay live throughout an imaging session, but the Pi consumes so much less power that it's easy to piggyback off the battery for the rest of the rig. Now that I've found a home with concrete pads and electrical outlets in a Bortle 5 location...huh, I hadn't really thought about it, but maybe it's time to switch.

Although frankly KStars seems to be flakier on my Mac and Windows laptops than it is on the Pi. I haven't been motivated to fix that because, meh, I just use the Pi. I do really enjoy the faster download times when I have connected directly to the gear with the (much) faster machines, wonder if it would be the same remoting to INDI.


Rick Wayne created a new topic ' FireCapture INDI connection' in the forum. 2 months ago

Wandering about in the settings for FireCapture on Windows, I noticed an option for connecting to an INDI server. Has anyone tried this? Normally I just unplug the camera from my Pi and into the Windows computer to capture planetary video, but it might be nice to leave everything plugged in so that I can go back and forth from DSO to planetary, and leverage plate solving and such from my comfortable StellarMate OS environment.

I could just install and run FireCapture on the Pi, but I'm not sure how it would perform. I connect to the Pi with an Ethernet cable, so there's at least a chance of pretty good throughput if I don't bog the Pi down with the overhead of running the software locally. I've seen some complaints about poor performance but don't know if that's still the case with a Pi 4 and more up-to-date software. I'm running an ASI183MM over USB 3, and of course I'm capturing a small ROI when doing planets.


Thanks Jasem!

That cable appears to be functionally identical to the Starizona adapter, though I don't know if the Starizona one uses the FTDI chipset. The one you linked is out of stock so I'm motivated to at least give this one a shot.

Assuming I can plug the Starizona directly into the mount (they do include a cable for that), which INDI driver should I use?


Hey all,

Our local astro club has a rather nice RC on the aforementioned Orion HDX110-EQ-G mount. Currently all it has is a hand controller. I'd like to control this mount from Ekos via INDI.

I ordered a USB-to-Synscan module from Starizona, which apparently can plug either into the HC with the included RJ-11 cable, or replace the hand controller using the RJ-45 cable. Documentation is minimal.

The Synscan driver appears to be pretty limited. In particular, it doesn't do pulse guiding. That's not necessarily a deal-breaker -- the scope has a LaCerta MGEN II with an ST-4 connection to the mount -- but I'm a lot more comfortable using PHD than I am trying to figure out the MGEN's quirks. I suppose I could pull the MGEN off the guidescope and replace it with my ASI120MC and use PHD via ST-4, but I'd rather not disturb the setup unless I have to -- the scope does not belong to me, after all.

What are my options here? I'm running StellarMate OS on a Pi 4. Is there an advantage to replacing the HC, or should I just connect through it? Will one of the other drivers work? I've never played in the Sky-Watcher/Synscan universe before, all my experience has been with iOptron mounts. Is the USB-to-Synscan the correct hardware?

Ideally I'd like to get, in order of priority:

  1. Automated pointing via Capture and solve/Slew to target in the Alignment module*
  2. Dithering
  3. Guiding via PHD

*Currently I can't get it to plate-solve any of the 12.8' images off my imaging camera. I downloaded all the index files down to 4200, still no joy. Fortunately ASTAP works fine, so I can do it sort-of manually. And of course PHD guiding would be nice.



Your suggestions?


Kevin has the source on Git (I will let him provide you the URL). The HAT plugs into the Pi using the many-pin header connector. You will need to remote into the Pi or connect a display, keyboard, and mouse to it so you can compile the driver there (the README for the driver has the details for that). There are some settings that you need in the INDI control panel for the motor control to work properly, most notably the delay -- my motor did not work at all without that. I used a somewhat earlier version of the driver which needed some constants changed in the source code, or at least I thought so :-). Pretty sure it's more of a turnkey thing now. The Waveshare board has several options for connecting the motor wires, including pin headers and screw terminal blocks. I bought a little RJ-11 breakout board, connected wires to that, and then just epoxied that to the top of the case. That way I can use phone cables to connect to the motor (which also has an RJ-11 breakout attached). But you could just wire it directly to the stepper motor if you prefer.


Thanks. I'm downloading the files over my university Ethernet, then will copy to the Pi in the future. Man. A 12.8' FOV needs a LOT of files! Well, I'm a silly person who hangs an ASI183 on the end of an AT12RC, after all.


Hey all,

Pardon if this question has been asked too many times, but searches did not turn up anything on point. I recently started working at a much finer image scale and am pretty sure I need the lower-level astrometry index files. Is there any way to do this from KStars or Ekos without having the equipment connected? There's basically no internet at the observatory. Normally I'd just run the simulators and check off whatever files I needed regardless of whether the program thought they were "Required" or "Recommended" or whatever, but the cam sim is dead on this laptop for some unknown reason.

When I did manage to get things connected with Internet available, all the choices besides the index files which I already had on disk were grayed out. I did not see any affordance to change that. I'm running 1.7.2.

Of course, there's always doing it via data.astrometry.net, but the 4200 series has 47 files. Oh well, Ruby to the rescue, I guess. :-)


Previous iterations of the Ekos PAA would warn if you started within 60 degrees of the meridian, headed that way. E.g. if you were pointed at azimuth 160 and had "West" and "30 degrees" selected, a dialog would pop up, warning that the alignment might not be valid.

I happened to violate this "rule" last night by a few degrees, and no complaint. And a really good alignment, too!

So can I rely on this now? The field of view from my yard is quite restricted, which is why I'm aligning pointed south in the first place. If I can count on straddling the meridian with the three exposures, I'll be able to routinely use 30 degrees and so can count on more precise initial alignments.

If so...thanks folks! I just updated last night and the PAA worked like a dream, just chugging through with nary a hiccup. Well, OK, when I tried to wedge a 60-degree arc from just west of the meridian, it wasn't wild about plate solving the image of my neighbor's garage. I can be patient about including their garage in the catalogs, I guess.

The first time I got a successful run I did not see the updated polar alignment figures during the "refresh" cycle; the second time, the figures appeared, which was helpful.


Sadly, this did not work for me. Thanks though!


Thanks Fred, I'll dig the CEM70 out of the garage and give it a look tomorrow!