I've now entirely wiped KStars' configuration, started from scratch with latest KStars/INDI, and have the exact same issue.

Without any ability to troubleshoot further I'm stuck unable to use KStars and I'm just burning through viable imaging nights this season troubleshooting software. More than happy to provide logs, remote access to systems, try literally anything... any ideas?

Read More...

I've had issues in the past with not managing to improve on final alignment steps, and found that switching to nearest star rather than n-star in the align options helped.

I'm not sure any of the above issues relate to the fault I am seeing in the Ekos/StellarSolver space, though. The behaviour is quite different and given that this occurs *without the EQMOD driver involved* in a simulator I think it unrelated. I've tried both the Stellarsolver internal SEP and internal solver as well as external solvers/SExtractor (my usual setup) and that all has the same issue.

Read More...

OK, I thought about taking the hardware and second PC entirely out of the equation and I can reproduce this in KStars using nothing but the telescope and mount simulator.

I took GPS out of the equation, both by setting it to use system time in the gpsd INDI driver settings, and by turning the gpsd driver off entirely.

NTP sync is essential to keeping everything to UTC since nothing has real-time clocks, and is working correctly. Time really isn't an issue here! Location from GPS was correct and the site management tab of the EQMOD driver had correct information.

Read More...

OK, so I rebuilt everything from scratch on the INDI side. Fresh Raspberry Pi OS install (Lite 64-bit) and Astroberry repositories set up.
I set up chrony for NTP sync with the UK pool and local servers, and set the gpsd plugin to use the system time so there was no confusion from the GPS. All the clocks in KStars, local system time on both machines, etc all synchronised to UTC and using the same timezones (Etc/UTC).

I used default configurations for everything otherwise in INDI etc.

I left the scope in the home position, pointed at Polaris, and powered up. I then solved a few times and got wildly differing answers. I then moved the scope (slewed from software) and tried again, and again had wildly differing answers while the image remained perfectly still (160 degrees error).

So I'm one of those boring system administrator types who insists that all their servers and other headless devices run in UTC; both Pis are set to Etc/UTC as a timezone and were showing good NTP health, and manual checks showed them synchronised to what I expected. There is a GPS/gpsd on the telescope Pi for location data, which is a little redundant given it's a stationary setup, but it isn't used as a source for system time (e.g. by chrony, as PPS/GPS ref, etc). I'm also in the UK, so in GMT anyway. I also had this issue with local time as BST, a month or so ago.

I will double-check, but I am very confident it isn't this. Good thought though!

Read More...

Hi,
Tearing my hair out over this one!
So I have run a rig with Ekos/KStars for a good long while now without issue and know my way around pretty well. My setup is two Pis, one running INDIserver on the telescope and one in the warm running KStars, Ekos, and PHD2. Both are Pi 4s, 8G.
The setup is a 200PDS and a EQ-6R Pro, early version. Two ZWO cams for image and guide, and off-axis guiding. Sesto senso focusmotor. Power is plentiful via a Nevada linear PSU, and slewing is smooth and consistent. There's been no mechanical change to the setup in years, aside from a successful mount rebuild which has been working fine.

I bumped to INDI 1.9.7 and KStars and Ekos seem very confused about what's going on. With the scope booted up from cold, with no alignment/mount config, pointing roughly at polaris in the default park position, plate solving correctly finds the location and KStars shows the mount position as it is on the mount position overlay.

However, Ekos is showing the error in alignment as huge - >200,000 arcseconds - on more or less every solve. I can't discern a pattern. Even when pointing at the same location and platesolving twice I get huge errors. Slewing by right-click on a target in KStars points the mount incorrectly in real terms and Ekos still shows error but in slew to target mode doesn't actually move the mount. The result is that I can't point the scope.

I have wiped all the config, started from scratch twice, checked everything mechanically, and verified the fundamentals (GPS position is right and being used everywhere I can see, time is NTP-synchronised on both devices to a local grandmaster and UK pool, nothing's under huge load). PHD2 polar align reckons about 7 arcminutes of PA error, which isn't great but should be perfectly fine for the basics. I've tried with both the Align and Alignment subsystems, and the closest I can find to an error message anywhere is "[ALIGNMENT] Failed TransformTelescopeToCelestial" a bunch in logs.

At my wits end when it comes to further diagnostics - any suggestions for approaches on how to figure out what might be going on? Debug logs attached.

Read More...

I've been working on a Rust-native client that has no dependency on libindi, specifically because I want something portable; in theory it would be quite easy to provide a Python extension with the Rust backend.

Having said that, a pure Python client would be much easier to write (I'm struggling with INDI because of the poor state of XML parsers in Rust) and in theory to maintain given the wider Python userbase. For client authoring it'd certainly be easier to work with. I'm writing this purely to drive an all-sky camera and that'll be shipping images off to a neural net/CV stuff for image segmentation, and Python's a native of that sort of thing.

Read More...

I'm using Python 3.

I am completely up for pitching in on pyindi if I can figure out how - I just wanted to confirm that the issue seen above was not isolated and was current.

My main gripe with pyindi is the documentation - if there are major changes underway that's okay, I know docs are often the last thing to get updated (being a maintainer for some OSS myself) but it doesn't help newbies (like me!) coming into an ecosystem if the basic examples explode with the "correct" config/setup/etc.

Read More...

Getting similar problems trying to use even basic basic PyIndi stuff - connection works but trying to update parameters I get the same subscriptable error.
None of the example scripts in the docs work except the basic "import, connect, and do nothing" one.

So yeah, PyIndi appears completely broken right now on 1.8.9. I've been trying to write a Rust INDI client which can provide a Python binding because the current state of PyIndi isn't great (and on other platforms like Windows it's a challenge), but it's a lot of effort to get that working.

Read More...

No, neither is selected. As it happens I should have checked one and had a tripod leg crash later that evening!

Read More...

I also had this yesterday, which prompted me to leg it to the scope ready to pull the power (I image on a tripod, and meridian flips require care) only to find it hadn't moved a bit. No clear indication as to to what prompted it in the logs.

Read More...