×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

eqmod pierside management

  • Posts: 32
  • Thank you received: 0
I have a custom MC (aiming at being) eqmod-compatible.
I am -mostly- completely lost in the tabs of the driver, confused with 2 align tabs, unable to understand the logic of parking,
nor the management of pierside and so on :)
Lets start slowly:

1. how does parking work (I am confused with this so probably I am misunderstanding something) ?
I see parking data as a couple of encoder values, a couple of alt/az values (plus maybe a pierside) and that
completely defines parking position. Due to my obs configuration, I need to park in the meridian and 0 alt, west of pier ; how do I tell that to the driver ?

2. my gotos do not complete : scope moves to the right coordinates, tracking resumes, but the driver does not get out of slew mode.
Here is a test drive :
sync is set to standard sync, align is set to no alignment (there are 2 tabs, 1 called "align", the other called "alignment"... what is the link ?), horizon is disabled,
scope is unparked, tracking, synced, horiz coordinates are correctly updated, eq coords dont move.
From kstars I goto (more or less 2 deg each dir) ; attached is a log, and 2 screen shots before/after goto.
the mount pointer has disappeared, because coordinates have gone wild after the driver decided that the scope has jumped
on the other side of the pier, while the mount correctly performed the desired goto, without flipping whatsoever ;
but the main question is why the goto is not complete according to the driver.

any help will be highly appreciated :)
ty in advance.

File Attachment:

File Name: indi_eqmod...4446.log
File Size:194 KB
6 years 7 months ago #18273
Attachments:

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

  • Posts: 226
  • Thank you received: 88

Replied by Jean-Luc on topic eqmod pierside management

Hi,Me too, welcome to the firmware/hardware debugging world.
Park is now at telescope class level, so it should manage any kind of mounts, and there are different schemes for saving park positions.
If you want to set your own park position, goto that position and stop tracking (use slew not track actually), use motion to adjust the postion eventually and then hit the "current" switch of Park Options in the site management tab. The current encoder position should appear above. You then have to save it explicitely with the "write data" switch.
Looking at the log, it seems the goto was ok: the mount starts slewing, the driver waits that both motors stop, your firmware performs the move and stop both motors as wanted, and then the driver engages tracking.
I wonder how you start and sync the mount; it seems there has been a huge standard sync before you start the log. Try starting at home position, with a firmware reset just before, and leave default alignment options. There are two alignment tabs as there are currently two implementations: you may go from one to the other as desired, the sync points are sent to both implementations and they usually do not widely diverge. Standard sync is the usual sync mechanism: it is a constant displacement which is kept even when you use either alignment implementations, or none.
Concerning pierside, could you give some more precision ?
6 years 7 months ago #18279

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

  • Posts: 32
  • Thank you received: 0
Hi, thanks for the insights. Ive been out for a while, sorry for the late answer :

Concerning parking : I think the problem is in my management of encoders value ; my mount "encoders" value are just microstep counts from
the origin ; at power on, these encoders are (currently) initialized to a hardcoded value ; I set that value at half its (24 bit) range (0x800000) which
is enough to encode 360° each direction without overflow (I have 0x753000 usteps per rev).
From what you wrote, I think that at power on, I have to initialize them at the same value that is stored in park data ? Or does the indi driver
tell the mount the initial value of its encoder when it is parked ? I am still a bit lost, I must admit.
Concerning pier side, I think its closely related to the problem above, so I need to first settle concerning the first point and then
rethink the pier side problem accordingly.
Concerning goto not terminating, I think there is a problem in my firmware ; I am investigating. and I cannot follow the procedure you suggested me
unless I first solve point 1.
So I really need to understand how encoders value are initialized/set/exchanged between the mount firmware and the driver.

Thank you again.

(edit: attached is a log of a power on sequence ; the first line that I suspect might reveal a problem is
WARNING 59.566900 sec : Init() : Motors already initialized.
is this related to the fact that at power on I return 101 as the state of my motors ? is this a problem ?
then
INFO 59.569662 sec : Mount is unparked.
Does this info come from the mount or from the driver initially ?)

Otherwise, the figures are ok (freq, gridperrev, and so on...)
)

File Attachment:

File Name: indi_eqmod...5500.log
File Size:11 KB
Last edit: 6 years 7 months ago by François Meyer. Reason: adding a log file
6 years 7 months ago #18430
Attachments:

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

  • Posts: 226
  • Thank you received: 88

Replied by Jean-Luc on topic eqmod pierside management

Hi,That's correct. The skywatcher firmware sets both axis encoder values to 0x800000. As that does not say anything on the real position of the scope. we have to decide of a convention to go from encoder values to the telescope reference frame. The telescope frame is the Hour angle,Declination frame. Thus 0x800000 for RA axis corresponds to Hour angle 0.00 and 0x800000 for Dec axis corresponds to 0.00 declination. That corresponds to a mount with its counterweight bar vertical and parallel to to north leg (RA axis on meridian) and its Dec axis horizontal and pointing to east. Now it is more conventionnal to use the home position where the Dec axis has been turned 90.0 to point to the pole. The indi driver supposes that your mount is initially in this home position and will set the Dec encoder value accordingly if the motors are not initialized. If the motors are already initialized, it does not alter any encoder values and will report a position using the telescope frame. Looking at your log, if your firmware reports initialized motors, then encoder values should correspond to the real scope position, and 800A8A in RA means you're not exactly on the meridian, and 9D4C00 in Dec means you're at 90.0 declination.
The firmware does not have to initialize encoder values to park data, this is the indi driver that will do that. But it should find uninitialized motors. So I would suggest that your firmware does not initialize motors at startup and returns 0x800000,0x800000 as initial encoder values.
I really think your gotos are correct, in your second image above, the Eq coordinates status is Ok and the mount is tracking. I don't see the end of the goto in the displayed log but a whole goto looks like this
2017-08-12T07:11:57: Telescope slew is complete. Tracking TRACK_SIDEREAL... 
2017-08-12T07:11:57: Iterative Goto (2): RA diff = 1.01 arcsecs DE diff = 0.09 arcsecs 
2017-08-12T07:11:56: Iterative goto (1): slew mount to RA increment = 608, DE increment = 0 
2017-08-12T07:11:56: Iterative Goto (1): RA diff = 5.83 arcsecs DE diff = 0.09 arcsecs 
2017-08-12T07:11:50: Slewing to RA:  7:35:42 - DEC: 31:50:50 
2017-08-12T07:11:50: Slewing mount: RA increment = 1197304, DE increment = -1457700 
2017-08-12T07:11:50: Starting Goto RA=7.59501 DE=31.8471 (current RA=10.7793 DE=90) 
The problem may be that there is a standard sync of ~6h00 in RA and ~30° in Dec, and that's why the scope is considered to be outside limits. For a first try I would not put a scope on the mount, and won't use any sync/alignment stuff. Just check that encoder values and scope position are correct in respect with each other.
Hope this helps.
6 years 7 months ago #18432

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

  • Posts: 32
  • Thank you received: 0
> Hope this helps.
It certainly does ; I can see the light at the end of the tunnel :)
Stay tuned.
edit :
Ok, firmware updated.
Now from the standard home position I want to move to my desired parking position.
First I move the scope WEST. the driver indicates west of pier, fine, I am still pointing
the pole but the mount has moved on the RA axis and is now clearly west of the pier.
Now I want to point south so I need the mount to first go towards zenith and then down to the horizon,
near local plain south.
I order a NORTH motion, kstars pointer goes where I want but the mount is rotating the other direction.
Is "reverse DEC" supposed to solve this ? Because it does not seem to work.
ty
Last edit: 6 years 7 months ago by François Meyer.
6 years 7 months ago #18433

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

  • Posts: 32
  • Thank you received: 0
Ok, just to put a final word to this thread :

I am finally through with all my firmware issues : most were related to uncertainties about
when the eqmod driver does or does not command motor start and stop. In particular, at the end of
a goto, the eqmod driver waits for the motor to stop while my firmware automatically resumed tracking...
And some other issues of the same kind...
It took some time to track down but I'm finally there. Pfew...

Now I need to figure out how sync/align/horizon tabs should be used : are there any docs/links
describing their proper use ?
(an example of question : how do I tell the driver that my mount can track ~ 2 hours around meridian without flipping ?)

thanks.

BTW, should anyone be interested, this is an eqmod-compatible firmware for the MCMT32 hardware . Email me if interested.
--
fm
Last edit: 6 years 6 months ago by François Meyer. Reason: adding mcmt32 info
6 years 6 months ago #19292

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

Time to create page: 0.730 seconds