Jean-Luc replied to the topic 'StellarMate' in the forum. 5 days ago

Hi,
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.

Read More...

Jean-Luc replied to the topic 'eqmod pierside management' in the forum. 1 week ago

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.

Read More...

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

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 ?

Read More...

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

Hi,
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.

Read More...

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

Hi,
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.
Regards.

Read More...

Jean-Luc replied to the topic 'Missing C++ compiler error during Pyindi-client installation' in the forum. 4 weeks ago

Ok, there lacks the symbolic links from lib*.so to their current versions:

ln -s /lib/arm-linux-gnueabihf/libz.so.1 /lib/arm-linux-gnueabihf/libz.so
ln -s /usr/lib/arm-linux-gnueabihf/libcfitsio.so.2 /usr/lib/arm-linux-gnueabihf/libcfitsio.so
I think that may be a distribution issue.

Read More...

Jean-Luc replied to the topic 'Missing C++ compiler error during Pyindi-client installation' in the forum. 4 weeks ago

Try to locate those libraries:

locate libz.so
locate cifitsio
Remove the (now unuseful) nova in libraries and add the paths found above to library_dirs in the setup.cfg file.
You could try by hand if the compilation has a chance to achieve from the directory where you run the setup script:
arm-linux-gnueabihf-g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-Bsymbolic-functions -Wl,-z,relro -g -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 build/temp.linux-armv7l-3.5/indiclientpython_wrap.o /usr/lib/arm-linux-gnueabihf/libindiclient.a -L /usr/lib -L /usr/lib/arm-linux-gnueabihf -lz -lcfitsio  -o build/lib.linux-armv7l-3.5/_PyIndi.cpython-35m-arm-linux-gnueabihf.so
Eventually replace /usr/lib and /usr/lib/arm-linux-gnueabihf with the ones you found previously. And there may still miss the -lpython3 flag.
What is strange is that they have made a new version of Ubuntu mate (02/2017) but the tutorial has been made using their previous version and that was working well.

Read More...

Jean-Luc replied to the topic 'Missing C++ compiler error during Pyindi-client installation' in the forum. 4 weeks ago

I tested on my desktop fedora 24 and that works.

gcc -pthread -Wno-unused-result -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -I/usr/include -I/usr/include/libindi -I/usr/include/python3.5m -c indiclientpython_wrap.cpp -o build/temp.linux-x86_64-3.5/indiclientpython_wrap.o
creating build/lib.linux-x86_64-3.5
g++ -pthread -shared -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld build/temp.linux-x86_64-3.5/indiclientpython_wrap.o /usr/lib64/libindiclient.a -L/usr/lib64 -lpython3.5m -lz -lcfitsio -lnova -o build/lib.linux-x86_64-3.5/_PyIndi.cpython-35m-x86_64-linux-gnu.so
running bdist_egg
.....
It seems your compiler does not understand the link command from swig, but the _PyIndi module should be linked against libz, libcfitsio and libnova.
Maybe you could try to force the library search path (the -L option above) in the setup.cfg file:
[build_ext]
swig_opts = -v -Wall -c++ -threads -I/usr/include -I/usr/include/libindi
include_dirs = /usr/include:/usr/include/libindi
libraries = z cfitsio nova
library_dirs = /usr/lib:/usr/lib/arm-linux/gnueabihf
These library_dirs paths depend on your distribution and platform so I let you put the correct values.
Normally the compiler does not need this -L option as it uses defaul value. I tested manually here and in my case - L /usr/lib64 is not needed.
I also notice that there also lacks in your case the -lpython3.5 linker option in the g++ command, so you also may have to add it in the libraries list.
Maybe the swig version you use has some bugs (I use 3.0.8,. I see you have 3.0 in ubuntu mate).

Read More...

Jean-Luc replied to the topic 'Missing C++ compiler error during Pyindi-client installation' in the forum. 1 month ago

No it did not work. Actually this extra arg is a Python list (and I also forgot a comma). Try with

pyindi_module = Extension('_PyIndi',
                          sources=['indiclientpython.i'],
                          language='c++',
                          extra_compile_args=[ '-std=c++11'],
                          extra_objects = [join(libindipath, 'libindiclient.a')]
)


Read More...

Jean-Luc replied to the topic 'Missing C++ compiler error during Pyindi-client installation' in the forum. 1 month ago

Hi,
You may try to add an extra_compile_args in the definition of the Extension in the setup.py file

pyindi_module = Extension('_PyIndi',
                          sources=['indiclientpython.i'],
                          language='c++',
                          extra_compile_args='-std=c++11'
                          extra_objects = [join(libindipath, 'libindiclient.a')]
)
and then run directly python3 setup.py install --user.
Maybe language='c++11' does also the trick.
I don't remember if the c++11 porting has been made in indi before or after I made the last update to pyindi-client.
Anyway I will update that when all those big changes will be finished.

Read More...

Jean-Luc replied to the topic 'Issues with indi_eqmod and custom MC' in the forum. 1 month ago

I don't know where the indi driver runs but I don"t think another thread for reading from the MC would help.
Maybe you could first try to check if there is an answer directly with picocom or microcom (or putty...).
Another solution is to debug the firmware, I use gpsim but your processor is not supported so that would need some tweakings to run it. I think you use xc microchip compiler (#include <xc.h>), I know the microchip IDE has a debugger but it does not support RS232 on Linux. Maybe on Windows but I've never tried that.

Read More...

Jean-Luc replied to the topic 'Issues with indi_eqmod and custom MC' in the forum. 1 month ago

I didn't see your max(30, stepperiod...) on first reading.
Now I wonder why there is no answer from your firmware. Moreover it is ok when you start tracking:

2016-07-26T09:29:29: StartMotor() : Axis = 1 
2016-07-26T09:29:29: read_eqmod: "=", 2 bytes read 
2016-07-26T09:29:29: dispatch_command: ":I1560200", 10 bytes written 
2016-07-26T09:29:29: read_eqmod: "=101", 5 bytes read 
2016-07-26T09:29:29: dispatch_command: ":f1", 4 bytes written 
2016-07-26T09:29:29: SetSpeed() : Axis = 1 -- period=598 
Another point is the behavior of the hand controller: do you think there are no readings of the motor firmware answers ?

Read More...

Jean-Luc replied to the topic 'Mount (EQMod - AstroEQ) crashes during parking' in the forum. 1 month ago

Hi,
Looking to your log:

2017-07-17T14:04:08: Parking mount: RA increment = -7939585, DE increment = -8762072 
2017-07-17T14:04:08: GetDEEncoder() = 8762072 
2017-07-17T14:04:08: read_eqmod: "=D8B285", 8 bytes read 
2017-07-17T14:04:08: dispatch_command: ":j2", 4 bytes written 
2017-07-17T14:04:08: GetRAEncoder() = 7939585 
it seems your park position is 0x000000 encoder position in both RA and DEC.
Knowing that encoder positions are centered in 0x800000, this is not usual.
Could you check the contents of your ParkData file ?
Or maybe reset your park position using the driver.

Read More...

Jean-Luc replied to the topic 'Issues with indi_eqmod and custom MC' in the forum. 1 month ago

Hi Ilia,
I think that the '=' answer is not sent because the StepPeriod is too short (000006) for your firmware.
The pic processor may be almost always in the timer interrupt routine, hence no time for send_string().
I would suggest to apply a min when setting stepperiod[axis] in the SetStepPeriod case, as the indi driver has no way to know this minimum.

Jean-Luc.

Read More...

Jean-Luc replied to the topic 'Trying to debug a PyIndi-client script' in the forum. 2 months ago

Hi,
The code in this tutorial is for Python2 (and it works, I just tested), I got the following error using Python3:

Traceback (most recent call last):
  File "timelapse.py", line 48, in newText
    self.logger.info("new Text "+ tvp.name.decode() + " for device "+ tvp.device.decode())
AttributeError: 'str' object has no attribute 'decode'
Which is not the same error as yours...
So I wonder how did you install the Pyindi client wrapper: you have to use pip now, the repo given in the tutorial is no longer maintained.
pip install pyindi-client
or pip3 if you use python3.
See here for more info.
Now I've got no newMessage from the driver when running the script in Python2, so not sure what's going on in your case...

Read More...

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!