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.
CREATE DISK IMAGE
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.. 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.