Here are my findings for tonight with build #174:
- the plate solve tab now has access to mount position.
- when trying to solve a position, the position gets further and further from the target after each solve (I used astrometry, Ekos seems to confuse and crash ansvr) . Essentially if you have a maximum distance from target set, you'll never get there. A single solve and sync works fine. A conflict between the adapting mount model in Eqmod and some internal Ekos model maybe? (I used Eqmod on dialog, so only the last sync values are kept)
- when you change the astrometry server (e.g. In my case from astrometry to ansvr and back), Ekos doesn't try to authenticate after the server change. So if you use ansvr, changing to astrometry fails because Ekos uses the ansvr session id in the API requests. Changing from astrometry to ansvr works because ansvr doesn't actually care about user and session id.
- when slewing from a scheduled plan, the slewing is extremely slow. Looking at the Ascom commands, it appears that Ekos doesn't wait for the goto to finish. It sends the same slew order over and over again every second or so. As a result, the mount slew is interrupted every second and starts again. The one slew I tried took several minutes. A slew from kstars works as expected though.
FYI, I experimented with INDI for Windows used from Ekos in a Linux VM last night (hadn't thought of doing that before) and the slewing problem is there too.
(using ekos nightly since the mount position issue exists in bleeding)
You can report them to bugs.kde.org so we can follow better there. I haven't had the time yet to test the solver on Windows along with INDI Server for Windows. Hopefully I can get sometime to check it out later on.
To me it looks like the Ekos end expects a synchronous call and the wINDI end behaves like an async call or a callback. But I don't know either code so it's jut a guess.