This was tested with Ekos Windows and Linux (in VM) connected to a wINDI server connected to an EQMod-managed mount. Ekos versions tested were Bleeding and Nightly #171 and later. When trying to plate solve a position with sync and slew, the position gets further and further from the target after each solve (I used astrometry) . Essentially if you have a maximum distance from target set, you'll never get there because your solution will be further and further out. 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)
Complementary information from the forum thread indicates that you (not sure I can match usernames, sorry if it's not you!) used the Windows port of astrometry.net "ansvr", and that this plate-solver provides an additional field named "epoch". In any case, is this description correct? In your situation, "epoch" has value "JNow", which indeed is causing an issue in the solver analyzer in ekos/align/onlineastrometry.cpp, which doesn't check that json field and bluntly considers all result coordinates to be J2000. We could either stick to the original astrometry.net API, which doesn't include that field, or honor that field when it is present. First solution is the simplest for us :) Second solution can be done too relatievly easy.
Hi TallFurryMan, Yes I tried to use ansvr, but had problems with Ekos plate solving: ansvr would most of the time just hang or crash (I don't have issues using it from other applications). So for plate solving I used astrometry.net. BUT, Ekos had originally issues connecting to the mount via wINDI + EQMod because my system is entirely J2000 and Ekos assumed JNow. Could it be that it's in fact the opposite that's happening? Ekos assumes JNow coordinates in its orders to the mount and the mount moves in J2000, taking it further and further from the target?
There was an issue I just resolved and merged to master as mount module was reporting ERROR since it wasn't processing EQUATORIAL_COORD So hopefully this is resolved after our rework on scheduler module it's done. If you try it now it's probably going to be broken since work is not yet complete.
Thanks Jasem! Cedric, getting this to work under a short amount of time would require you to extract the code tree in the pre-merge state and cherry-pick Jasem's change. So it depends whether you are willing to wait 2-3 weeks for the dust to settle on kstars-bleeding...
Thanks both. I'll wait. I'm not setup to build kstars and it would probably take too long for me to do it.
This should be resolved with 3.5.0