Jean-Luc replied to the topic 'Meade LPI-G (monochrome) support?' in the forum. 3 days 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. 3 days 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 days 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 days 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. 5 days 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. 5 days 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. 5 days 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 week 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 week 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 week 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 week 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. 3 weeks 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...

Jean-Luc replied to the topic 'Meridian flip still working for people?' in the forum. 4 months ago

Hi,

mlarsson wrote: Hi!

I'm not sure whether I am connecting to the topic or not - I have a Losmandy G-11, so no EQMOD here. But I have problems with meridian flip.

My situation: I've set the safety limit to 5 degrees past the meridian. According to the people who know more about this mount than me, issuing a Goto within 2.5 degrees of the safety limit should cause the mount to flip. According to my manual tests - using the handcontrol, not Ekos - this seems to be correct.

Now I tested this by tracking a star across the meridian, with 60 sec exposures. I've set the HA to 0.2, so as to make it happen within the zone of between 2.5 and 5 degrees past the meridian. It tracks, approaches the limits, and then, at 185 degrees, it seems to issue a meridian flip command - according to the capture model. However, I cannot see anything in the Indi panel for the mount. Issuing a manual Goto (with the Handcontrol, not Ekos) to the star it is already pointing to, initiates a Meridian flip.

It seems to me that no Goto command was issued - or what is happening here? Log files attached - Kstars log, mount log, and CCD log.

Magnus

Looking at the log, it seems the goto command is performed as expected.
Now reading a document I've found here on pages 33 and 69, it seems the default goto limit is 122 degrees from east, and that you have to set it manually for goto commands perform a meridian flip. If I've understood there are some extensions to perform meridian flip in the gemini protocol, that the hand controller should use. For programs using only lx200 command set, you have to change this goto limit to 95 degrees if you want any goto commands perform a flip if target is 5 degrees past the meridian. I don't have such a mount so I can't help more, but you may start to look in that direction.

@Jasem
I wonder if you may not simply disable alignment during imaging in Ekos, so you would get the true coordinates. After all alignment is mainly used for goto accuracy.

Read More...

Jean-Luc replied to the topic 'Meridian flip still working for people?' in the forum. 4 months ago

knro wrote: I just finished the live testing for merdian flip and it worked fine using the Nearest Point align mode. WIth N-Star there were a few issues, not with the flip itself, but with post-flip realignment process.

I think that meridian flip should be initiated using true telescope coordinates, or alignment could be disabled when performing the flip.
In any case I would suggest you use more alignment points, the nearest model is quite simplistic.


How would clients know about true telescope coordinates? From Ekos, I just monitor HA and issue GOTO to the same place once HA threshold is exceeded.

indi-eqmod exposes true telescope coordinates in the align tab, and maybe every mount should expose them. Ekos monitors HA using aligned coordinates, and as said above, initiates the flip when HA is 0.06 above meridian. In the log the alignment process (be it Nearest or Nstar) reports a 0.08 difference in RA, thus the goto won't perform a flip. This is a feature, not a bug. Actually you may now use the Pier Side property as defined by Patrick (which uses true coordinates in the driver directly) to initiate the flip: there you will be sure the mount would perform a flip.
The other point was tthe number of sync points: using only one sync point is not very useful. And if you make your sync near the pole, a small error here is multipled by the inverse of the sinus of the declination. I wonder if this is not why some people get scope outside limts error sometimes.

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!