Jarno Paananen replied to the topic 'Problem to connect ASi EAF' in the forum. yesterday

If you have the older 12V model of EAF, it requires 12V power connected to be visible to the computer. The newer 5V USB power only version does not need that.

Read More...

Jarno Paananen replied to the topic 'ScopeDome' in the forum. 2 weeks ago

Good to hear, let's hope everything works that way! I don't have much free time at the moment but I'll try to upgrade my controller to the same firmware version and reproduce the problem at some point if I could fix the problem or at least understand what causes it and maybe work around it in some way. Thanks for your testing, logs and reports!

Read More...

Jarno Paananen replied to the topic 'ScopeDome' in the forum. 2 weeks ago

Actually I just now noticed that you have newer firmware (6.1) in your controller than what I used for testing originally (5.3, 5.4 and 5.7). Checking the Windows driver release notes there seems to be some issues with the connection too and they have increased the status query rate to every second for that reason, but that was the default in INDI driver already. You can try to play with the polling period setting, but I'm not too hopeful. It's currently also limited to once every 1-3s.

There is a hardware watchdog that resets the controller if it doesn't receive commands from ethernet for some time, so if that is on for some reason, that might cause this resetting thing even if the controller receives commands from serial port. The watchdog can be disabled with the Windows driver I think or by connecting to the serial port with some serial communication program like Minicom or Arduino IDE and sending command setEthWatchdog=0

Read More...

Jarno Paananen replied to the topic 'ScopeDome' in the forum. 2 weeks ago

There is definitely something weird in your USB connections as all the USB-serial devices seem to get the same error for some reason. Are they connected to the same hub? Is the hub powered? Does kernel log (run command "sudo dmesg" on command line for example) show anything interesting when the error happens?

For ScopeDome there is also the possibility to use ethernet connection, I'm running out of ideas why the USB serials behave like that for you.

Read More...

Jarno Paananen replied to the topic 'ScopeDome' in the forum. 3 weeks ago

That Input/output error is a generic one that means the serial port has disappeared from under the driver for some reason when it's trying to communicate with the device. Kernel log from that time might show if the device has reset itself for some reason (there is a watchdog in the ScopeDome controller that might be overly eager) or something else. Also having driver debug enabled in Ekos logging configuration before connecting to the device would show all serial port traffic the driver sends and responses it gets from the device.



Read More...

Jarno Paananen replied to the topic 'ScopeDome' in the forum. 3 weeks ago

Sounds like something is disrupting your serial communications somehow. At least ModemManager and GPSD might cause that when they probe for devices causing the device to react in unexpected ways when INDI driver tries to talk to them. Having the full driver debug log might show the issue, but you can also try uninstalling ModemManager especially if you don't need it. For GPSD you might need to somehow force it to ignore the ScopeDome port as from your log in the EQMod thread it seems you have a GPS device using another ttyACM port or you can try to rule that out by uninstalling or stopping GPSD temporarily too. And you should use the /dev/serial/by-id/ names for device ports avoid the ttyACM and ttyUSB names as the the order they are assigned numbers change randomly if there are multiple devices of same type, ie. a device that is ttyACM0 in one boot might be ttyACM1 the next and the device previously ttyACM1 becomes ttyACM0 depending on the order kernel discovers them. But the names in /dev/serial/by-id/ don't change and always point to the correct actual (ttyACM or ttyUSB) device.

Read More...

Jarno Paananen replied to the topic 'ScopeDome' in the forum. 4 weeks ago

It might be that the serial port assignments have changed, Linux seems to assign /dev/ttyUSB devices randomly every reboot so it's better to bind them to unique names either with udev rules or by using the Ekos serial port assistant. In my case my EQDir adapter and ScopeDome controller both use the same FTDI USB-serial chip and have to be identified by their serial numbers. For example I have in /etc/udev/rules.d/99-indi.rules file lines such as this for my EQDir adapter:

SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A700Q6JZ", SYMLINK+="mount"

which creates a symlink /dev/mount which I then use as port in EQMod driver. You can get the correct values for your devices with "lsusb -v" command and create separate rules for your mount, cloudwatcher and scopedome and they don't get mixed up.

Read More...

Jarno Paananen replied to the topic 'ScopeDome' in the forum. 4 weeks ago

If you have compiled INDI yourself and/or have the source, then indidevapi.c is in libs/indicore directory and sstateStr function is part of that file, error print is on line 682 in current head git version. Running indiserver under debugger is a bit complicated due to multiple processes being involved, Ekosdebugger utility helps a bit with that. But I have a first intuition where the problem might be, have to add some more initialization code.

Read More...

Jarno Paananen replied to the topic 'ScopeDome' in the forum. 4 weeks ago

Thanks, that shows the issue, the driver crashes for an error in the base library:

[2022-12-31T22:24:21.884 CET DEBG ][ org.kde.kstars.indi] - INDI Server: "2022-12-31T21:24:21: Driver indi_scopedome_dome: Impossible ISState 81"

This is probably an uninitialized variable coming from somewhere (the valid values are 0 and 1), which would be easy to find with a debugger and breakpoint at the error print in sstateStr function in indidevapi.c. If you can do that if would help a lot, but I can try to pinpoint the source as well. If you could enable driver debug logs as well, it might help narrow it down. My own dome has the older USBCard 2.1 controller so it's better tested, but I have the Arduino controller at hand too, though not connected to actual dome.

Read More...

Jarno Paananen replied to the topic 'ScopeDome' in the forum. 4 weeks ago

Some details would help, do you have the older USBCard 2.1 or newer Arduino based controller? Do you use USB or ethernet connection? Have you set the card type, port and baud rate correctly (9600 for Arduino card, 115600 for USBCard 2.1) before connecting? Also if you can enable debug logging in Ekos and post the snippet on connection would clarify things if those don't help.

Read More...

Thanks for the links and instructions Ferrante, just additional point that after git clone you need to switch to the correct branch called lynx_astro with command "git checkout lynx_astro".

Read More...

The parameter passing warning is harmless (and you can't do anything about it except disable the warning with -Wno-psabi) if you aren't mixing libraries compiled with pre-GCC 7.1 with GCC 7.1+ which is very rarely the case when the same distro compiler is used for everything (and GCC 7.1 was released already in May 2017). GCC 7.1 documentation states: "On ARM targets (arm*-*-*), a bug introduced in GCC 5 that affects conformance to the procedure call standard (AAPCS) has been fixed. The bug affects some C++ code where class objects are passed by value to functions and could result in incorrect or inconsistent code being generated. This is an ABI change. If the option -Wpsabi is enabled (on by default) the compiler will emit a diagnostic note for code that might be affected."

Read More...