×

INDI Library v1.9.7 Released (29 Jul 2022)

Bi-monthly INDI Library released with new drivers and bug fixes.

10Micron Mount Modelling

  • Posts: 73
  • Thank you received: 8
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 :)

Sounds like its a maybe!
The following user(s) said Thank You: Jasem Mutlaq, Craig
Last edit: 5 years 1 month ago by Micheal Fields.
5 years 1 month ago #18778

Please Log in or Create an account to join the conversation.

Ekos already has a similar tool, the Mount Modelling 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?
Jasem Mutlaq
Support INDI & Ekos; Get StellarMate Astrophotography Gadget.
How to Submit Logs when you have problems?
Add your observatory info
The following user(s) said Thank You: Craig
5 years 1 month ago #18780

Please Log in or Create an account to join the conversation.

  • Posts: 73
  • Thank you received: 8
Sounds really exciting. I look forward to the future.
5 years 1 month ago #18791

Please Log in or Create an account to join the conversation.

  • Posts: 77
  • Thank you received: 32

Replied by Hans on topic 10Micron Mount Modelling

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.

-- Hans
The following user(s) said Thank You: Craig
5 years 1 month ago #18802

Please Log in or Create an account to join the conversation.

  • Posts: 116
  • Thank you received: 28

Replied by Michael on topic 10Micron Mount Modelling

Hi Hans and others,

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.

Thanks

Michel
The following user(s) said Thank You: Craig
5 years 1 month ago #18856

Please Log in or Create an account to join the conversation.

You can use Ekos DBus interface to communicate with alignment module: api.kde.org/4.x-api/kdeedu-apidocs/kstars/html/index.html
If there is something missing you might need, let me know.
Jasem Mutlaq
Support INDI & Ekos; Get StellarMate Astrophotography Gadget.
How to Submit Logs when you have problems?
Add your observatory info
5 years 1 month ago #18857

Please Log in or Create an account to join the conversation.

  • Posts: 116
  • Thank you received: 28

Replied by Michael on topic 10Micron Mount Modelling

Jasem,

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 ?

Michel
5 years 4 weeks ago #18865

Please Log in or Create an account to join the conversation.

Michael,

From Python, you can communicate communicate with the DBus interface. Here is a tutorial 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.
Jasem Mutlaq
Support INDI & Ekos; Get StellarMate Astrophotography Gadget.
How to Submit Logs when you have problems?
Add your observatory info
The following user(s) said Thank You: dolguldur
5 years 4 weeks ago #18866

Please Log in or Create an account to join the conversation.

  • Posts: 116
  • Thank you received: 28

Replied by Michael on topic 10Micron Mount Modelling

Jasem,

that's right if you stay on pure linux (or BSD) based systems. But MW support windows as well and I would stay with an OS independent solution if I am leaving the windows environment. So accessing Dbus from python is still a learning curve for me, but having a native python implementation for a remote Dbus client is really tricky. All other imaging suites offering a REST API for remote control, which makes thing much more easy. Is there anything like that in EKOS ?

Michel
5 years 4 weeks ago #18867

Please Log in or Create an account to join the conversation.

Currently there is no such system. I suppose one could wrap the DBus calls in REST API with a micro framework like Bottle py
Jasem Mutlaq
Support INDI & Ekos; Get StellarMate Astrophotography Gadget.
How to Submit Logs when you have problems?
Add your observatory info
5 years 4 weeks ago #18868

Please Log in or Create an account to join the conversation.

  • Posts: 77
  • Thank you received: 32

Replied by Hans on topic 10Micron Mount Modelling

Hi Michel,

I propose to use ERFA instead : github.com/liberfa/erfa "ERFA is a C library containing key algorithms for astronomy, and is based on the SOFA library published by the International Astronomical Union (IAU).
ERFA is intended to replicate the functionality of SOFA (aside from possible bugfixes in ERFA that have not yet been included in SOFA), but is licensed under a three-clause BSD license to enable its compatibility with a wide range of open source licenses. Permission for this release has been obtained from the SOFA board, and is avilable in the LICENSE file included in this source distribution."

I've tested ERFA myself and it gives the same results as SOFA github.com/d33psky/J2000-JNow

-- Hans
5 years 4 weeks ago #18871

Please Log in or Create an account to join the conversation.

  • Posts: 77
  • Thank you received: 32

Replied by Hans on topic 10Micron Mount Modelling

HI all,

For 10Micron mount modelling we need to add the following functionality to the driver :

First store the temperature and pressure. This will get used by :newalpt and/or :endalig# lateron.
  • :SRTMPsTTT.T# Sets the tempreature at the location of the telescope used in the refraction model to sTTT.T degrees Celsius. Returns 1# if OK, 0# on error.
  • :SRPRSPPPP.P# Sets the atmospheric pressure at the location of the telescope used in the refraction model to PPPP.P hPa. Returns 1# if OK, 0# on error.
Begin a new alignment specification. (This will not clear the active alignment model the mount is using.)
  • :newalig# returns V#
Next loop over up to 100 alignment points, per point get mount RA/DEC, pier side, local sidereal time, plate-solved RA/DEC (*) and store :newalpt
  • :GR# get mount right ascension. Returns HH:MM:SS.SS# (hours, minutes, seconds and hundredths of seconds)
  • :GD# get mount declination. Returns sDD:MM:SS.S# (degrees, arcminutes, arcseconds and tenths of arcsecond)
  • :pS# Pier side. Returns string "East#" or "West#"
  • :GS# Get local sidereal time
  • :newalptMRA,MDEC,MSIDE,PRA,PDEC,SIDTIME# Returns nnn# if OK with nnn the number of active points, E# if not
With
  1. MRA - the mount-reported right ascension, expressed as HH:MM:SS.S
  2. MDEC - the mount-reported declination, expressed as sDD:MM:SS
  3. MSIDE - the mount-reported pier side (the letter 'E' or 'W', as reported by the :pS# command)
  4. PRA - the plate-solved right ascension (i.e. the right ascension the telescope was effectively pointing to), expressed as HH:MM:SS.S
  5. PDEC - the plate-solved declination (i.e. the declination the telescope was effectively pointing to), expressed as sDD:MM:SS
  6. SIDTIME - the local sidereal time at the time of the measurement of the point, expressed as HH:MM:SS.S
End the new alignment model and compute a new alignment from the given alignment points.
  • :endalig# returns V# if new alignment model has been computed OK
Save the model.
  • :modeldel0NAME# DELete a model with name NAME (up to 15 case sensitive characters, spaces allowed). Returns 1# if OK, 0# on error
  • :modelsv0NAME# SaVe the model with name NAME. Returns 1# if OK, 0# on error
(*) We need to transform plate-solved J2000.0 coordinates to JNow as input for the :newalpt PRA ad PDEC parameters and JNow as SIDERES, however in this transformation we need to deliberately ignore everything that is related to refraction (like temperature, pressure, humidity, wavelength) and only correct for precession, nutation and light aberration. This can be done with SOFA/ERFA Atci13, or with Atco13 when all its refratcion parameters are set to 0.
The 10Micron mount then receives these 'half transformed' coordinates and corrects for refraction with the temperature and pressure it was given earlier with :SRTMP and :SRPRS (ignoring things like humidity and wavelength).

Lateron we can add functionality to manage the models with these
  • :getalst# Gets the number of alignment stars used in the current alignment model. Returns n#
  • :delalig# Deletes the current alignment model and stars. Returns #
  • :getalpN# Gets alignment information for star number N. Returns: E# on error or "HH:MM:SS.SS,+dd*mm:ss.s,eeee.e,ppp#" where HH:MM:SS.SS is the hour angle of the alignment star in hours, minutes, seconds and hundredths of second (from 0h to 23h59m59.99s), +dd*mm:ss.s is the declination of the alignment star in degrees, arcminutes, arcseconds and tenths of arcsecond, eeee.e is the error between the star and the alignment model in arcseconds, ppp is the polar angle of the measured star with respect to the modeled star in the equatorial system in degrees from 0 to 359 (0 towards the north pole, 90 towards east).
  • :delalstN# Delete alignment star N and recalculate the model. Returns 1# if OK, 0# on error
  • :modelcnt# Gets the number of alignment models. Returns: n#
  • :modelnamN# Returns the name of model number N or just # on error.
  • :modelld0NAME# Loads the model with the given NAME. Returns 1# if OK, 0# on error

I intend to add all this to the INDI driver. Does this line up with the EKOS Mount Modelling tool ?

-- Hans
The following user(s) said Thank You: dolguldur
5 years 3 weeks ago #19017

Please Log in or Create an account to join the conversation.

Time to create page: 0.522 seconds