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 www.raspberrypi.org/documentation/config.../external-storage.md 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!


Huh! Wonder why it's whacked for me, then. Something about the CEM70? Well, it's not really an issue. I use the PAA as a backup and quantitative assessment of my iPolar solution now anyway.

However, I was just reading up on the no-polaris alignment and was gobsmacked. That is quite the feature, my friend. Can't wait to try it out -- it literally opens new horizons for me, i.e. in my tree-cave back yard I may be able to move around until I have a patch of sky that includes a target, rather than just using the tiny slice from which I can see Polaris.


A  quick question, apologies if it has been covered earlier in this long thread:

My CEM70 is often persnickety about doing the rotations in the polar alignment assistant, so I usually check "Manual rotation". When I get the nice triangle in the PAA, the alt-az adjustments don't move it the star WRT the triangle. Is it expecting that the mount has returned to the zero position before clicking "Refresh"? That would be a bit odd, since it's plotting the triangle on the third image, which is at 60° RA from zero, and I'm prompted to select a star there. (I don't know if clicking on a new star even works once you've clicked "Refresh".)

My CEM70 has also  been rather persnickety about parking and returning to home position in the past, I know that Jasem looked into this for iOptron mounts at least once but I'm rather chary about letting it smack into the tripod again to discover if the problem still exists so I have the "park afterwards" checkbox off too.


Restart KStars? That's about all I can think of, if the file is there, perms are OK, and it has Kevin's content, it ought to work. It's unlikely that the XML files live in a different folder, but you could try picking one of the other drivers that's in the Ekos distribution and searching for it everywhere in the file system with:

sudo find / -name name-of-file.xml

where "name-of-file" is the other driver filename, like indi_wmh_focuser.xml.

If you find the file in another place besides /usr/share/indi, you could copy indi_wmh_focuser.xml there too and see what you get. Beyond those two ideas...I got nothin', I'm afraid.


Check the permissions on the file.

Re why it isn't in the library, I have no idea. It's a terrific DIY solution, the driver Just Works and so does the Waveshare board. Heck, the board is cheaper than buying the parts to solder together a myFocuserPro, and you can be running 15 seconds after you open the package.