If I understand correctly, the 10 micron firmware is able to manage a model itself, so IAS would be redundant in some way here. Actually it should be disabled in that case. Or it can be used in place of the 10 micron firmware, if alignment may be disengaged in the firmware, or the model itself simply cleared in the mount.
IAS is only used for computing gotos at the moment and align position, it can also be used for guiding/tracking (it was its original use in Roger James alt-az driver). If you build a model with some significant misalignment, you may see under kstars that the position reported by IAS while tracking afterwards will diverge from the original tracked object. If you want to guide/track you just have to alter tracking speeds in the readscope status function to adjust that position. I believe this is what the 10 micron firmware is doing. That may be applicable to any kind of mounts where you can control tracking speeds in both axis.
Concerning automatic modelling, this is simply a loop slew/capture/solve/sync if I correctly understand, ekos may handle that quite easily (in some future version maybe, taking care for horizon).
I had a look to the mountwizzard python code, it seems that it is using the ASCOM 10 micron driver to get common mount properties (site, RA/DEC, ..) and directly talks to the mount to manage more specific alignment properties (points list,..). I'm not sure that could work with INDI as access to the mount port may be exclusive and the Indi 10 micron driver may receive unattended data here. I found the 10 micron protocol description, will read it to get more info.
just opened an account. I'm Michel, the developer of MountWizzard(MW). The explanations of Jean-Luc are right for the basic process. There is the plan to integrate an INDI client for using EKOS as imaging and plate solving solution as it currently works with MaximDL, TheSkyX and SGPro. I looked for a native python implementation of the necessary parts of the INDI client (not ctype based python wrappers around c implementations), because I would like to get OS indipendent.
If you have any hint to make this happen, please let me know. I'm as well in talks to Hans, which developed the 10micron INDI driver.
Hi Michael and welcome to INDI forum. Currently, the C++ based
INDI Client API
works on Linux, MacOS, and Windows natively. Ekos already have a Mount Modelling tool which enables the user to generate model points distributed across the sky in different configurations, but all of this relies that the mount SYNC modifies the mount modelling internally. I am not about this part since I'm not really familiar with how 10 Micron internally works.
It seems the INDI 10 Micron driver just needs to add functionality related to handling the modeling in similar fashion to IAS (i.e. clear/save/load model) but instead of doing it in the software, it relays these commands to the mount itself. Am I understanding this correctly or is there more to it?
I am going to let Michel answer you in more detail but essentially yes. The 10Micron has two states. Syncs refine a model and syncs update a model.
Starting with 3 base points which 10Micron mounts need as alignment points, much the same way that Celestron has 2 initial alignment points before you can add any more, but every point beyond the initial 3 counts as refine points. You can have up to 100 total where 3 are base points and 97 are refine points. The mount does the math internally where something else like T-Point does it externally in software on your computer. This allows the 10Micron mount to be fully modeled with nothing more than a cross-hair eye piece or DSLR with live view + cross-hairs and the hand controller.
So what these 3rd party modeling programs like Michel's does is automate the process so we can go have coffee. It slews to a base point, takes a image of the sky, plate solves it, and syncs. Since you select Syncs refine in the mount, it adds it as a new point. When you are done with lets say 45 you have chosen, you have a 42 refinement and 3 base point alignment. This is used by the 10Micron to adjust tracking. The 10Micron has absolute encoders and can make changes based on what it detects during the model. Anything that repeats can be modeled.
Sync align mode is for shifting/correcting an existing model. So if you have 40 points from the night before but maybe you rebalanced and moved your OTA in the saddle, you choose sync align and do one single plate solve/sync and it shifts/corrects/updates your existing model.
So what I am missing from the StellarMate and/Ekos etc is this ability to slew/solve/sync on a generated field of points. Where the following is necessary:
1) Software must tell the 10Micron if it is a refine point or a base point.
1b) Software must issue a sync on a plate solved image as accurately as possible.
2) Software must tell the 10Micron if to set syncs refine or syncs align so it knows if it should be refining or updating.
Somewhat related the mount can also adjust its model and tracking based on refraction which can change when temps drop or raise. So some of these automated modeling softwars like Michel's have a way to interface with existing sources of weather information and time/gps updates and put that in the mount too. As having the correct time is important too.
With modeling and the ability to dither without a guiding I would be super excited about using this ekosystem
Ekos already has a similar tool, the
Tool which is part of Ekos Alingment module, and it is quite similar but not as powerful as Mount Wizard. WIth it you can define the desired points and then go have coffee and come back with the model complete, you can try it now with the simulators. As you correctly indicated, the difference is perhaps telling 10Micron whether the points are "base" or "refine" points.
There is static refraction taken into account into KStars, but I believe Hans was working on weather-based refraction model, so maybe he can contribute this model to KStars so we can take it into account when doing refraction-dependent calculations.
So the 10Micron driver has to expose these properties so clients like Ekos can set whether the point is base or refine and whether to update or refine. But I'm not sure if it is as simple as that. When you select "update", and then you can do syncs in any order and 10Micron will take care of comparing it against the existing model, or you have to do the same order as was done before?
Hi all, I'm glad to see 10Micron mount modeling is getting more attention in INDI/EKOS-land.
The 10-Micron mount alignment models are made in the mounts themselves and are based on (currently up to 100) alignment points. The interesting case is where we plate solve these points so that the whole procedure can be automated. The INDI Alignment Subsystem could be used to select those points, have them plate solved and add the results as a new alignment point to the mount. This is what Michel's MountWizzard does too (it does a lot more).
The mount also wants temperature and air pressure information as it uses this to correct for their effects on pointing. A 'fun fact' is that we must not correct for temperature and air pressure ourselves when converting the plate solved J2000 results to JNow (confirmed to me by a 10Micron dev).
We should use the 10-Micron :newalig# , :newalpt , :endalig# commands to build models instead of just :CM# to 'sync' a point. Next step is to let the mount evaluate the model, optimize it and maybe remove certain points that show too large errors. I do not know if IAS has something similar. The mount can save and recall multiple alignment models.
Ideally I would like to see both MountWizzard and EKOS be able to help build 10Micron alignment models from Linux/Mac/Windows. MountWizzard is mostly Python and it would be really nice if it could be fully Python based. There are INDI client implementations in pure Python so that could be used. The J2000-JNow transformation it currently uses via ASCOM is based on SOFA with a mix of NOVAS helper functions ... I know of no Python-only library of it yet.
recently I got a python package for indi client to work. At least I could get an Image from the CCD Simulator. With the SOFA library I would do a C to python translation myself over time if there is no solution available. First I have to ask the guys at SOFA to get the allowance to use it in MountWizzard.
There is one question open for me: mightbe as well asked in this thread already. Actually I using the imaging programs to capturing *and* platesolving. Ideally I get an image as FITS file, where mount coordinates and plate solved coordinates were in.
I didn't find a feature or way to get EKOS platesolve an image from a client side. Does anybody know how this could be done ? This would help a lot.
if I use the Bus interface of EKOS from my understanding there is no need for INDI (because I get all from that one interface). I guess, that I could access all Dbus API's via TCP connection. Is that right ?
From Python, you can communicate communicate with the DBus interface. Here is a
about using the INDI DBus interface in KStars. But you'd want to use the Ekos DBus interface since the INDI interface is considered low level.