Welcome, Guest
Username: Password: Remember me
20 Aug 2017
INDI development team is happy to announce the release of INDI Library v1.5.0. This new exciting release builds on the maturity of INDI Library and comes with many new supported devices and fixes for existing drivers.
Read More...
  • Page:
  • 1

TOPIC: eqmod pierside management

eqmod pierside management 2 weeks 4 days ago #18273

  • fm
  • fm's Avatar Topic Author
  • Offline
  • Junior Boarder
  • Junior Boarder
  • Posts: 28
  • 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_telescope_094446.log
File Size: 194 KB
Attachments:

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

eqmod pierside management 2 weeks 4 days ago #18279

Hi,

fm wrote: I have a custom MC (aiming at being) eqmod-compatible.

Me too, welcome to the firmware/hardware debugging world.

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 ?

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.

2. my gotos do not complete : scope moves to the right coordinates, tracking resumes, but the driver does not get out of slew mode.

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.

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.

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 ?

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

eqmod pierside management 1 week 3 days ago #18430

  • fm
  • fm's Avatar Topic Author
  • Offline
  • Junior Boarder
  • Junior Boarder
  • Posts: 28
  • 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_telescope_165500.log
File Size: 11 KB
Attachments:

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

Last Edit: by fm. Reason: adding a log file

eqmod pierside management 1 week 3 days ago #18432

Hi,

fm wrote: 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).

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.

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.

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.

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.

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.

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

eqmod pierside management 1 week 3 days ago #18433

  • fm
  • fm's Avatar Topic Author
  • Offline
  • Junior Boarder
  • Junior Boarder
  • Posts: 28
  • 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

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

Last Edit: by fm.
  • Page:
  • 1
Time to create page: 0.309 seconds

Login

3rd Party

Choose from the numerous 3rd party INDI drivers to suit your needs!

Got Problem?

Check out the FAQ, the forum, and the bug tracking system to resolve any issues you might have!
You can also subscribe to INDI newsletter and development mailing lists to get the latest updates on INDI!

Gallery

Replica

Why INDI

Replica