David James created a new topic ' KStars and Ekos on a tablet computer' in the forum. 3 months ago

Does anyone else use a tablet computer for KStars and Ekos, like the Lenovo X230 Tablet?

The touchscreen responses are... weird. I'm using version 3.4.2 from the PPA.

Unlike other KDE apps, using the stylus I can't get drop down menus (File, Time, etc) nor any response fromtapping the icons. I have to use the touchpad or a mouse. In the sky display the sky does pan around with stylus movement when it's directly in contact with the screen. Howevering above the screen moves the cursor, but there are no tooltips. It's also curiously inaccurate: using the right-click function of the stylus when hovering over an object typically brings up the 'Empty Sky' context menu but right-clicking on the touchpad/mouse (without moving the cursor) brings up that object's context menu. This even happens on large objects like the Andromeda Galaxy. After much trial, I've found I have to get the cursor about 3/8" or a little less than a cm above the object to bring up its context menu with the stylus' right click. Needless to say, this is practically impossible to reliably repeat, especially with no tooltips.

In Ekos, I also have to touch the screen with a stylus about a cm or 3/8" above a button or field area to actually hit that button/field/item. For instance, on the Align tab, tapping "Capture & Solve" brings up Load & Slew instead, so to get Capture & Solve I have to tap in the area above where it says "Solver Control".

The INDI control seems to work fine. The Mount control also works fine, thank goodness.


David James replied to the topic 'Remote Astrometry' in the forum. 3 months ago

I eventually got it working... it seems the Remote solve is far more sensitive to insufficient astrometry.net FITS files than a local offline solve on the very same machine...? I'm not joking here: it would regularly solve on the host machine as "offline" but would continue to fail to solve when launched from the laptop in "remote" mode.

So really load up on the astrometry.net FITS on your solving host machine.

The host machine profile needs to have the INDI Astrometry driver loaded and enabled (enable it in the INDI Control Panel).

If the Astrometry driver isn't loaded on the remote host, you get a message on the local machine:

"Cannot set solver to remote. The Ekos equipment profile must include the astrometry Auxiliary driver."

But confusingly, that's not referring to the Ekos equipment profile on the local machine, but rather on the solving host machine. Moreover, you'll get that message if the Solver isn't enabled on the remote host machine, even if the Astrometry driver is loaded. I haven't been able to consistently bring it online from the outset.

Overall this all seems a little bit less useful than I first imagined. Let's suppose you've got a limited-capacity device like an Astroberry at your mount doing direct mount and camera control which you access over VNC/browser, but you've also got a powerful server machine elsewhere on the network. It would seem to make sense to install astrometry.net and its FITS files on the server machine while letting Ekos on the Pi do lookups to that machine, but you can't: the Astrometry driver is tied to the rest of the INDI controllers on the host machine, meaning it has to be on the Astroberry*. Now if instead you've got the Astroberry just running as a barebones INDI server while running Ekos on your desktop machine, you might as well just run the solver on your desktop in 'Offline' mode. It's only if you have Windows and you can't run astrometry.net locally does 'Remote' make any sense.

*You might be able to do this by changing the API url of the solver in the Astrometry.net options and then using the "Online" solver, but you're going to have to configure yourself an astrometry server, if that's even possible.


David James replied to the topic 'Getting the ASI120MC clone to work as a total linux noob' in the forum. 3 months ago

That is the same FWTool I used on my ASI120MM (with the -compatible firmware). I checked the md5sum against what I already had. When I used that to update my ASI120 it resulted in a device that would get stuck capturing an image but never actually succeed. Not only did I use the -compatible firmware variant, I also tried the one without a hash suffix. No luck on either.

Maybe ZWO's own Linux tool works better on non-ZWO products.


David James replied to the topic 'Remote Astrometry' in the forum. 3 months ago

After an hour or so at this using my desktop machine as the putative astrometry server and a laptop as the client doing astrometry look-ups, all I get are solver failed errors.

I had the indi astrometry driver loaded and enabled on the server profile (with Telescope Simulator and CCD Simulator) and the same on the client, with it connecting to the server's IP address. Everything appears to load up fine on the client machine. From the server machine, I can do a local (i.e. offline) "Resolve and Slew" on an existing FITS but when I try that on the client with "remote" set it just fails.

Is there a guide somewhere detailing exactly what has to be configured for remote astrometry to work, on both the server machine and the client machines?


David James replied to the topic 'Remote Astrometry' in the forum. 3 months ago

I didn't realize you were accessing the RPi via KStars running in Windows; I thought you were running KStars directly on the RPi but via a VNC or browser interface from Windows.

I haven't yet set up a remote astrometry solver. As you're running Windows on your workstation, you don't have much choice in the matter, but I wouldn't normally set it up with the remote astrometry server running on the Pi as its processing power is limited compared to workstations. I mean I have it running locally on the Pi, but that's to ensure I have it when I'm in the middle of nowhere.

I'll have to look into how to set this up myself.


David James replied to the topic 'Remote Astrometry' in the forum. 3 months ago

You must have Kstars from the OS's repository installed? It's possible that version isn't recent enough to support offline astrometry plate solving.

So yes, best get the Kstars from the ppa in the links previously.

To help in daylight and without need of attaching mounts and such, you can create an additional Ekos profile. I call mine "Simulators" and I add a bunch of things like
Telescope Simulator for the mount
CCD Simulator for the imaging camera
Guide Simulator for the guide camera
That allows you to do a certain amount of "playing around".


David James replied to the topic 'Remote Astrometry' in the forum. 3 months ago

Let's also take a look at the permissions of the astrometry files themselves:

astroberry@astroberry:~ $ ls -lh /usr/share/astrometry/
total 9.7G
-rw-r--r-- 1 nobody nogroup 101M Dec 7 2014 index-4202-00.fits
-rw-r--r-- 1 nobody nogroup 104M Dec 7 2014 index-4202-01.fits
... etc ...


David James replied to the topic 'Remote Astrometry' in the forum. 3 months ago

astroberry@astroberry:~ $ apt-cache policy astrometry.net
  Installed: 0.76+dfsg-3+b1
  Candidate: 0.76+dfsg-3+b1
  Version table:
 *** 0.76+dfsg-3+b1 500
        500 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages
        100 /var/lib/dpkg/status


David James replied to the topic 'Getting the ASI120MC clone to work as a total linux noob' in the forum. 3 months ago

If you're trying to run the basic USB2.0 ASI120M* or its clones on a Raspberry Pi device, I've got bad news for you:

ASI120 Flakiness on Astroberry

There's some indication from another user that they work better with RPi4 devices than RPi3 devices such as mine, but I've also corresponded with someone who owns a T7 and both Pi4 and Pi3 devices who experiences much the same issues on both. A powered hub seems to help a bit, but the ASI120 is not always detected in all hubs, either.

With respect to updating firmware, it's not your Pi that's getting a firmware update: it's the T7 itself. The architecture-specific "drivers" to which you refer are actually compiled programs for that architecture to enable you to update it from that architecture. Unfortunately the non-Windows versions don't seem to work properly (yes, I tried already). To actually update the T7's firmware, the recommended course of action is to do it from a Windows machine. So from the ZWO Software & Drivers page, you'll need the following:

Windows tab: Native Drivers
FW Update tab: USB 2.0 Camera Firmware (there's two things to grab here)

First install the Native Drivers on a Windows machine, then plug in your T7, then install the VS2008 pkg and then the firmware. The firmware file itself for the T7 is ASI120MC-compatible.iic and is found in the FWTool zip.

This should get your T7 to a nominally operational state for most but not necessarily all Linux workstations. I have been able to use it successfully from KStars/Ekos on Linux laptops. If you are doing actual photography with it on a Pi (say of the planets), it will probably work, but if your intent is to use it for guiding... expect flakiness of the sort I posted earlier.


David James replied to the topic 'Remote Astrometry' in the forum. 3 months ago

Have you got the program 'astrometry.net' installed, as per below? Your initial post says you installed the driver but I don't know if by that you mean what is below or something else.



David James replied to the topic 'Remote Astrometry' in the forum. 3 months ago

"Remote" I believe is if you set up an Astrometry server on, say, a computer elsewhere on your home network with more space and/or processing power than what you're using at the mount and point your controlling Ekos installation to that server.

As you've got an RPi and have downloaded the index FITS to it, you just need to select "Offline" on the Align tab. You don't need the Astrometry Aux device at all; that would be for the case above.


David James created a new topic ' ASI120 flakiness on Astroberry' in the forum. 3 months ago

This post is more of a "heads up" for anyone contemplating buying/using an ASI120MM/MC (the puck-shaped versions, not the "mini" 1¼" version) with an Astroberry for guiding than anything else. As far as I'm aware, there is no fix for the issue described below.

In short, just look at the following gif of my ASI120MM operating in PHD2 on an Astroberry RPi3B+:

It does the same thing with the internal Ekos guider.

That jumping around isn't just a visual artifact, either: the guiding software thinks it's real and tries to compensate.

I have found that extending the exposure length to 2.0, 2.5 or 3.0 seconds tends to diminish the issue. PHD2 seems to be slightly better at handling this phenomenon than the internal Ekos guider, but there's not a lot in it. When using the internal guider, it frequently stops and restarts guiding due to RMS being exceeded.

My ASI120MM has been updated with the ZWO firmware (yes, using the -compatible firmware file, and yes, run from a Windows box with the Windows firmware updater from ASI), so that's not the cause or a solution.

Additionally, in conversation with another astrophotographer, I've been able to confirm that the generic T7 / T7C astrocameras (pinkish with a slim 1¼" profile, pictured below - they outwardly looked to be well designed) available on eBay, Aliexpress and Amazon etc. also suffer from the issue when used on an RPi. However, I haven't experienced the same issue when using it directly from a Linux laptop running Ekos, though I believe others have.


David James replied to the topic 'Astroberry + QHYCCD users' in the forum. 3 months ago

colgs3b wrote: I have been using Ekos/Indi for a few years now, starting with the AstroPi script. I have a QHY5L-II-M and 163M. I frequently had "stability" issues, but it is hard to say whether this was from indi/ekos or the QHY drivers themselves (after all, QHY's EZCAP_QT will still crash on my on my PC and Mac).

Oh good, I'm not the only one who can't get EZCAP_QT running. I tried running it directly (the thing that shows up in your start menu is a script) and it failed. I even tried compliling it according to instructions on QHY's site, but the downloaded source code is missing what appears to be a fairly critical file, so it won't actually compile.

Or was it my hardware, since I was using SBCs? I used a Rock64 setup until recently, and on that Ekos/Kstars would certainly crash now-and-then. I just got a Raspberry Pi 4 and installed Astroberry, but the weather has only been decent once. Everything seemed to go smoothly until .... Best I can tell, the vnc server died or wireless networking died while I wasn't monitoring the session, according to the logs. My sequence completed though, and I got an image of the Atlas comet before it broke apart.

I've had that too with the VNC cutting out. But Ekos over the network seems to work fine.


I just bought an older but still relatively recent tablet computer (a Lenovo X230T) to use as part of my astrophotography setup. I installed Kubuntu 20.04 LTS on it, and after that, KStars from the PPA (i.e. kstars-bleeding, never once touched the Ubuntu repository version).

So we have:

kstars-bleeding 6:3.4.2+202004251749~ubuntu20.04.1
indi-qhy 2.6~202004201858~ubuntu20.04.1
libqhy 3.31+stable~202004192223~ubuntu20.04.1

And... it doesn't work.

However, if I go off to QHYCCD and, after navigating about blindly for awhile, get V2020.02.19.0 from

and install it ... it all works.

The message in the Indi panel is now:
[INFO] Using QHY SDK version 20.2.19

So there's definitely something lacking in the INDI QHY drivers as I'm getting the exact same thing issues in two separate computers.