Jean-Luc replied to the topic 'Configuring EQMOD for EQ6 Custom Ratio Belt Mod' in the forum. 2 weeks ago

You don't miss anything. If you can modify the code, you may fork and ask for a pull request. I don't have time to make the mod myself.
You may create a new driver inheriting from indi-eqmod, indi-eqmod-custom for instance, where you could add some properties to override the ones sent by the mount and overload the functions you need. I think it would be safer if those figures may not be changed using the default driver. Put the code directly in the indi-eqmod directory and add an option to build/install your driver in the CMakeList.


Jean-Luc replied to the topic 'v4l2 CCD & guiding issue' in the forum. 4 weeks ago

Yes, the order is normally 0=1.0x, 1=0.75x, 2=0.5x, 3=0.25x (and 4 =0.125x for firmwares/mounts supporting it).
Have you checked if the Dec motor is effectively running when calibration reverses Dec ? How does move the dec encoder value during these 3-4 seconds ?


Jasem Mutlaq thanked Jean-Luc in topic v4l2 CCD & guiding issue 4 weeks ago
Jean-Luc replied to the topic 'v4l2 CCD & guiding issue' in the forum. 4 weeks ago

I've checked the pulse guide code and it seems it is ok up to the level of serial commands.
Now the big difference between RA axis and Dec axis is that the Dec axis should be started when guiding. The RA axis just sees its internal speed register changed. Concerning the Dec axis it should explicitly be started with a :J2 command. I wonder if the motor startup time is not too long in that case especially if the mount uses some kind of energy savings. A good test would be to use a very low custom track rate in Dec (the min is 0.8 arcsec./s) to keep the Dec motor running and to check if Dec guiding works as wanted in that case.
Otherwise how did you proceed to change the magnitude of the Dec guiding ? Simply changing the speed, the time or both ?


Jean-Luc replied to the topic 'Eqmod alignment cleared when a new client is connected' in the forum. 2 months ago

Yes, same error here. Fixed in PR 354 . ~/.indi/horizonData.txt file is also loaded on first connection now, if it exists.


Jean-Luc replied to the topic 'Eqmod alignment cleared when a new client is connected' in the forum. 2 months ago

Thanks Patrick for pointing out those issues and fixing the file loading problem.
On my side I think I've fixed the issue concerning the initialization of the pointset. Made pull request 347 .
Actually this error may also concern horizon limits, I'll have to check.


Jean-Luc replied to the topic 'StellarMate' in the forum. 2 months ago

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.



Jean-Luc replied to the topic 'eqmod pierside management' in the forum. 2 months ago


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.


Jean-Luc replied to the topic 'eqmod pierside management' in the forum. 3 months ago


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 ?


Jean-Luc replied to the topic 'Meade LPI-G (monochrome) support?' in the forum. 3 months ago

You may try to declare these new ids to the uvcvideo kernel module using

modprobe uvcvideo # load the kernel module if it is not yet there
echo  0549 e004> /sys/bus/usb/drivers/usb/uvcvideo/new_id
# plug the camera
That works for me with a em28xx video grabber.
Maybe this is not an uvc camera so try other modules (gspca maybe).
Look in /lib/modules/VERSION/kernel/drivers/media/usb/ with VERSION being your running kernel version, you 'll find the list of your usb modules.


Jean-Luc replied to the topic 'EQMOD remote connection issue' in the forum. 3 months ago

Looking at the log, it seems you have a bugged version of the indi eqmod driver which appears some time ago.

DEBUG	139.213261 sec	: Trying connection to /dev/ttyUSB1 @ 9600 ...
DEBUG	139.213430 sec	: Connecting to /dev/ttyUSB1
DEBUG	139.227043 sec	: Port FD 8
DEBUG	139.227580 sec	: Connection successful, attempting handshake...
COMM	139.228293 sec	: dispatch_command: ":", 2 bytes written
The mount seems to be on ttyUSB1 but the sent command is wrong anyway: it should be ":e1" and not ":" only.
Try to update your indi version on your orange pi with a newer version.



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!