Sorry I didn't see your question before. More often than anything else, I change the folder the subs are saved to. And I seem to frequently find myself messing with the exact mix of exposure time and # of subs, though the latter is easy to control per rbarberac's suggestion. So if I created a sheaf of sequences for single filter-exposure-gain combos, I guess I could combine 'em in the scheduler. Interleaving filters would make it more complicated, of course.


Rick Wayne created a new topic ' Combining autofocus and offsets' in the forum. 3 weeks ago

Just double-checking that I've got this right. I'd like to expedite my LRGB acquisition, interleaving the subs for each channel more to ensure that, on a given night, I wind up with roughly equivalent integration time on each. So the strategy is:

  1. Autofocus Luminance. Note the position. Repeat for R,  G, and B.
  2. From the Filter drop-down, check "autofocus" for Luminance.  For the other three channels, uncheck "autofocus" enter the difference between L and each other channel as "offset".
  3. Start my acquisition session with Luminance, and thus autofocus.
  4. When the filter switches, the offset should be applied to get it pretty close to perfect focus.
I figure that if the L is spot-on, I don't have to be OCD about RGB, since the eye picks up detail mostly in luminance. Without pausing to autofocus R, G, and B, it costs me very little imaging time to switch filters, and so I can afford to do so much more often. If I run, say, 25 L and 5 each RGB, I'm autofocusing every 20 minutes with my customary 30-second exposures for star color, so when the clouds roll in I'll have a balanced set of data. (Or is it better to set them all to "offset" with L=0, focus initially with L, and just tell Ekos to refocus every N minutes?)

This would be especially helpful for mosaics; since slewing and solving is so quick on the Pi 4, I might even extend the technique to cycle repeatedly around the whole mosaic FOV instead of doing one bit at a time and dealing with the subsequent background normalization and other problems between panels.


I know that others have had success running the Ekos focus module with other Canons (e.g. the 650D). There is apparently a camera-menu setting to select the button on the rear of the camera to do AF instead of the shutter button, it won't work without that. Other than that, sorry, can't be much help.

The way this works is to give INDI control of the focus in/out, and then the Ekos focus module runs it. That module is of course purpose-built to focus stars on a dark background via the half-flux radius (HFR) metric; the camera's built-in focus software isn't intended for astro and is hopelessly incapable.

Sorry that I don't know much more about it than that.

As for platforms, I have run on Mac OS a bit and extensively on a Pi 3B and 4B with StellarMate OS; offhand I don't recall what distro Jasem bases SM on, it used to be Ubuntu but it's one of the Debian ones now (much better overall). StellarMate OS will cost you $50 but is usually quite stable and well-maintained, along with direct support from the vendor. It also offers a mobile-device app in the same vein as ASIAir's. I have had the occasional hang or crash on all platforms, as with just about any software that talks to hardware. But on the Pi 4B running StellarMate OS, that happens only occasionally, and usually when I'm doing something like repeatedly pausing, stopping, and restarting a running sequence.

I really like running it on the Pi because:
* There isn't a cable from my computer to the scope
* The Pi sips power, so can easily run all night off the same battery powering my mount and camera
* I can mount the Pi on either the scope or the tripod
* I can use a laptop, tablet, or phone to run the interface, and if one runs out of battery I can just pick up the next one without interrupting the session
* Connecting is very flexible -- the Pi will connect to my home wifi, an Ethernet cable, or put up a hotspot when I'm in the field

This pretty much ticks all the boxes for me. I found StellarMate OS to be much simpler to set up and get running right out of the box, so the $50 was well worth it to me, especially given the regular updates and new features that appear on the platform promptly when they're put into Ekos.

Setting up to boot the Pi off a USB 3.0 SSD drive (StellarMate has a utility for this) significantly improved performance, well worth doing IMO.


What I do is create the sequence on the simulator, then open the .esq file in a text editor. Pretty simple XML format, so it ain't hard to change things without mucking anything up too badly. I know that's perhaps not as smooth a user interface as one might like, but it gets me moving forward. I've even done the same with .esl schedule files.


Yah, I should just delete this. I almost never look at that screen, hence my idiocy. Would you post that as a separate topic? I'm embarrassed to leave this up but your alternative is valuable information. We know that at least one person really needed to see it. :-)


I just leave it off all the time. Pretty sure it was still off when I brought up the window.


So I wanted my Pi to boot and run off a nice big SSD. Here's the simplest way I know to make that happen. If you want to clone your existing StellarMate system with all your tweaks and files, you'll need access to the "dd" command, available on Linux, Macs, and Windows machines with a Bash shell or similar installed (e.g., Cygwin). If you just want to install the StellarMate image you bought from Jasem, jump past these first instructions to BURN DISK IMAGE.


  1. Sadly, you can't use the Linux command line to clone your MicroSD card while you're running from it on the Pi. So power down the Pi, pull the card, and put it into a USB reader attached to another machine. (Although if you've got a spare MicroSD that your Pi can boot from, boot from that, and insert the to-be-cloned card into a USB reader on your Pi!)
  2. From the command line, determine the device name of your card. On my Mac, Balena Etcher reports it as "/dev/disk2", and the "mount" command reports that "/dev/disk2s1" is mounted. "/dev/disk2" is what we want.
  3. Run the dd command. Check at least twice that you have not confused the "if" (input file) and "of" (output file) arguments. Yes, it's possible to toast your computer's file system if you do. "if" should be the device name you figured out in Step 2, and "of" should be a regular file name -- that file will be as big as your card's capacity. You want a 4-megabyte block size. On my Mac, the whole command is:
    sudo dd bs=4194304 if=/dev/disk2 of=/Volumes/home/Downloads/RickStellarMate-1.5.8.img
  4. Now, RickStellarMate-1.5.8.img in my Downloads folder is an image like the one you got from Jasem,  but with all my stuff. Eject the MicroSD card.

It's good to use a program like Balena Etcher for this, since it will do some error-checking for you. With Balena, it's just:
  1. Plug your SSD into a convenient USB port
  2. Run Balena, selecting "Flash from file"
  3. Choose the image file you created above as the source
  4. Choose your SSD as the destination. CAREFUL: It is possible to nuke your system if you pick its hard disk instead of the external. Check that.
  5. Flash!
If you don't have Etcher, you can use the good ol' dd command again. This time, "if" is your image file, and  "of" is your SSD, whose device name you investigate as you did under CREATE DISK IMAGE.  For my Mac:sudo dd bs=4194304 if=/Volumes/home/Downloads/RickStellarMate-1.5.8.img of=/dev/disk2

(Note that I'm using "disk2" again, the system assigned the same device name to the SSD after I unplugged the MicroSD card and plugged in the SSD.)

Note too that this will not only wipe any data on your SSD, it will wipe the file system too, so you can no longer plug it into any computer that doesn't recognize the ext4 Linux file system.

  1. Plug SSD into your Pi, ensuring that you have no MicroSD card
  2. Power up. Zingo bingo!

Ah. Yes. That. Well, "dd" created a partition the size of your MicroSD card on the SSD, but if you have a big SSD, a lot of it is going to waste. We need to make a file system "partition" for it, format  the file system with the ext4 filesystem, and graft it onto the tree of folders and files so that you can make use of it. This is a bit more abstruse, but bear with me, it's perfectly straighforward.
  1. If your Pi doesn't already have the Gnome Partition Editor  "gparted" installed, install it: sudo apt install gparted
  2. Run it: sudo gparted
  3. You will see a disk with a bunch of unallocated space. In the case of my 500GB SSD, rather a lot of unallocated space. Right-click that and create a partition, accepting all the default choices, ensuring that it's formatted as "ext4"
  4. Save and exit gparted
Now you've got a partition ready for Linux to use. To make it part of the file hierarchy:

  1. Make a backup of the system file table: sudo cp /etc/fstab /etc/fstab.bak
  2. Create a folder under which your new storage will live. I made a folder /home/stellarmate/images.
  3. Find the partition-table UUID of the new partition: lsblk -o NAME,SIZE,PARTUUID
  4. Using whatever text editor you like via "sudo", open the file system table: sudo vi /etc/fstab
  5. Duplicate the line with an "ext4" filesystem type named "/".
  6. Edit the new line's PARTUUID portion to be the value you got in step 3.
  7. Edit the "/" portion of the new line to be the folder you created in step 2 (in my case, /home/stellarmate/images).
  8. Change the options portion of the new line (it was "defaults,noatime" for mine)  to "defaults,auto,users,rw,nofail".
  9. Change the 1 at the end of the line to a 0.
So my fstab, when I'm done, looks like:
proc            /proc           proc    defaults          0       0
PARTUUID=d9b3f436-01  /boot           vfat    defaults          0       2
PARTUUID=d9b3f436-02  /               ext4    defaults,noatime  0       1
PARTUUID=d9b3f436-03  /home/stellarmate/images  ext4    defaults,auto,users,rw,nofail    0    0
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that

(I mostly used the directions in for this)

Next time you  boot, you'll have oodles of space  on your SSD, and it will appear to be just part of the system.


Just wanted to finish this off with a couple of quick notes. As Jasem said in another thread, Ekos uses the system time when a profile is started, not the KStars simulation time.

I got a fast USB SSD and set up to boot off that. No difference to my issue.

However, ensuring that the color overlays were off in KStars, selecting the "independent window" open for Ekos, and minimizing the KStars window seems to work around it.

Even with the color overlays turned off, if I do a "find" in KStars, though, the whole system slows to a crawl. What's weird is that using the "find" option in the mount control dialog, which brings up the same search box, apparently works just fine.

So I've got a functional workaround.


Updated to add: Well, as you might have imagined, Ekos's clock does seem to run independently. Pausing the KStars sim on my Mac does not prevent the hour angle from updating, at least.


I believe it's at the default of once per second -- I'll have to try that. Pretty sure it's not running running out of memory, as "top"reports a significant fraction of it free.

I was going to say "but I'm already running 'top' on the Pi", when I realized that the import of your ssh suggestion was to do so in a manner independent of VNC. Which is also worth trying.


Recently I've noticed some rather annoying behavior with my setup (4GB Pi 4, StellarMate OS 1.5.8). The system will appear to freeze, but not quite. It just gets really, really, really super-slow to respond. For example, I might hover my cursor over the application icons in  the menu bar to switch to the system file manager, but the highlight doesn't appear. But if I leave it there for 30-40 seconds, the UI responds. Likewise I can click, and half a  minute later the selected application minimizes or comes to the foreground as appropriate.

I am running VNC over the built-in WiFi hotspot. The program "top" in a terminal window shows load averages around 0.6, nothing maxing out the CPU, though KStars frequently jumps to the top.

The weird thing is that I can often provoke this behavior at will -- all I have to do is bring up the KStars window. If I leave it minimized, the system just hums along. I noticed it particularly after I turned on the HiPS All Sky Overlay once, but it still seems to occur once I eventually managed to turn it off (at 40 seconds per click!). I have had slowdown problems previously but I only saw this start to happen after I turned on the "independent window" setting for Ekos, so that I could, in fact, minimize the KStars window and just use Ekos.

Is this a known issue? Are there other workarounds besides "minimize KStars the moment you bring up Ekos and don't touch it again?" I haven't tried resizing the KStars window, nor stopping the KStars clock (I'm not sure how that interacts with Ekos's notion of what time it is, which is kinda important for telescope control!)

I'm running profiles with PHD guiding almost exclusively. 




I tried aligning from way back under the trees, no northern visibility at all. Lined up the tripod by aligning the center post with a leg on a heading of 000° using my trusty 50-year-old Boy Scout compass (magnetic declination is negligible here). Slewed to visible sky at about 130° az and 35° altitude. Ran the PAA, the azimuth was so far off the triangle didn't even fit in the camera frame. Wound up running it for three or four cycles overall, PAA said 40", PHD Guiding Assistant said 2'. I'll take that!

Star still wasn't tracking the triangle, however. No matter, since the helpful circle guided me to the correct adjustments quite easily, so long as I didn't go too fast. Racking the azimuth more or less followed the hypotenuse, but not quite. Altitude was of course about perpendicular to that. Mount was pretty close to level by the bubble in the base. Does sensor orientation matter? My camera was at some completely random rotation since I was mostly just playing around.

Chris and Hy, this is the nuts. Terrific work, and it will make a big difference to my imaging. Even when I don't have good targets in my available slice of sky in the back yard, I can use that time to debug hardware and workflow instead of infringing on valuable remote-site dark-sky time. Bravo!