×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

ASI usb3 camera retries 3 times on exposure and fails - git builds

  • Posts: 61
  • Thank you received: 10
I compiled from git just an hour before. The problem is not solved: ASI1600mm-pro crash the asi-cam-driver and kstars as well.

I played a bit with this stuff
 
The crash comes in with the new ASI-Cam-SDK 1.17.  "libASICamera2.so.1.17" is a shared library and dynamically loaded. I told my system to load the old SDK instead ( "libASICamera2.so.1.16.3" ). Result: No more crash. All is working well. So going back to SDK 1.16.3 should fix the problem

Edgar
Last edit: 2 years 11 months ago by Edgar Scholz.
2 years 11 months ago #69883

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

I can't replicate the crash with multiple ZWO cameras here, so what's going on?
2 years 11 months ago #69900

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

  • Posts: 61
  • Thank you received: 10
Jasem, which cameras did you use?

The little ASI120mm-s gives no crash for me. All is fine.
The big ASI1600mm-pro crash the cam driver and finally kstars.

That´s hat happen on my Linux-PC
Edgar
Last edit: 2 years 11 months ago by Edgar Scholz.
2 years 11 months ago #69902

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

  • Posts: 28
  • Thank you received: 17
This can actually be a problem for a specific camera.
Each camera has its own implementation of receiving data.

For example, Jasem keeps mentioning to me that he has no problems running 2 cameras at once.
Of course it is, the ASI178MM and ASI120MM-Mini cameras have a similar communication implementation, in a cooperative global variable. So you can't run them all at once.
The ASI178MC and ASI120MC cameras can already be run together, they have completely different communication implementations.
2 years 11 months ago #69903

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

  • Posts: 1009
  • Thank you received: 133
No idea. I started kstars from the terminal, and got messages about the xml device file,
Dispatch command error(-1): Device ZWO CCD ASI183MC Pro not found
<setTextVector device="ZWO CCD ASI183MC Pro" name="DRIVER_INFO" state="Idle" timeout="60" timestamp="2021-04-11T09:39:07">
<oneText name="DRIVER_NAME">
ZWO CCD
</oneText>
<oneText name="DRIVER_EXEC">
indi_asi_ccd
</oneText>
<oneText name="DRIVER_VERSION">
1.9
</oneText>
<oneText name="DRIVER_INTERFACE">
2
</oneText>
</setTextVector>


I deleted the xml files, then it started without the error, but it still crashed. I was running in local mode. So I tried running indiserver manually and connect to remote localhost. Also crash, and the indiserver says
2021-04-11T09:45:29: Driver indi_asi_ccd: stderr EOF
Child process 17789 died

Also tried deleting ~/>ZWO/ASIconfig.xml, without change.

I tried running it in gdb, not sure if that is successful (I started indiserver manually, then connected via 'gdb -p PID').
Here's the output:
Thread 4 "indi_asi_ccd" received signal SIG33, Real-time event 33.
[Switching to Thread 0x7ffff55ad640 (LWP 18722)]
0x00007ffff6ef9a9a in __futex_abstimed_wait_common64 (
    futex_word=futex_word@entry=0x5555555ade98, expected=expected@entry=0, 
    clockid=clockid@entry=0, abstime=abstime@entry=0x0, 
    private=private@entry=0, cancel=cancel@entry=true)
    at ../sysdeps/nptl/futex-internal.c:74
Downloading source file /usr/src/debug/glibc-2.33-4.1.x86_64/nptl/../sysdeps/nptl/futex-internal.c...
74          err = INTERNAL_SYSCALL_CANCEL (futex_time64, futex_word, op, expected,
(gdb) bt
#0  0x00007ffff6ef9a9a in __futex_abstimed_wait_common64 (
    futex_word=futex_word@entry=0x5555555ade98, expected=expected@entry=0, 
    clockid=clockid@entry=0, abstime=abstime@entry=0x0, 
    private=private@entry=0, cancel=cancel@entry=true)
    at ../sysdeps/nptl/futex-internal.c:74
#1  0x00007ffff6ef9aff in __GI___futex_abstimed_wait_cancelable64 (
    futex_word=futex_word@entry=0x5555555ade98, expected=expected@entry=0, 
    clockid=clockid@entry=0, abstime=abstime@entry=0x0, 
    private=private@entry=0) at ../sysdeps/nptl/futex-internal.c:123
#2  0x00007ffff6ef3260 in __pthread_cond_wait_common (abstime=0x0, clockid=0, 
    mutex=0x5555555a2860, cond=0x5555555ade70) at pthread_cond_wait.c:504
#3  __pthread_cond_wait (cond=0x5555555ade70, mutex=0x5555555a2860)
    at pthread_cond_wait.c:619
#4  0x00007ffff6da50e0 in __gthread_cond_wait (__mutex=<optimized out>, 
    __cond=0x5555555ade70)
    at /usr/src/debug/gcc11-11.0.0+git183291-1.4.x86_64/obj-x86_64-suse-linux/x86_64-suse-linux/libstdc++-v3/include/x86_64-suse-linux/bits/gthr-default.h:865
#5  std::__condvar::wait (__m=..., this=0x5555555ade70)
    at /usr/src/debug/gcc11-11.0.0+git183291-1.4.x86_64/obj-x86_64-suse-linux/x86_64-suse-linux/libstdc++-v3/include/bits/std_mutex.h:155
#6  std::condition_variable::wait (this=this@entry=0x5555555ade70, __lock=...)
    at ../../../../../libstdc++-v3/src/c++11/condition_variable.cc:41
#7  0x00007ffff7e4dfa7 in std::_V2::condition_variable_any::wait<std::unique_lock<std::recursive_mutex> > (this=this@entry=0x5555555ade70, __lock=...)
    at /usr/include/c++/10/condition_variable:321
#8  0x00007ffff7e4d768 in std::_V2::condition_variable_any::wait<std::unique_lock<std::recursive_mutex>, INDI::SingleThreadPoolPrivate::SingleThreadPoolPrivate()::<lambda()>::<lambda()> > (__p=..., __lock=..., this=0x5555555ade70)
    at /usr/include/c++/10/condition_variable:330
#9  operator() (__closure=0x555555597b28)
    at /home/pit/Sources/indi/libs/indibase/thread/indisinglethreadpool.cpp:31
#10 std::__invoke_impl<void, INDI::SingleThreadPoolPrivate::SingleThreadPoolPrivate()::<lambda()> > (__f=...) at /usr/include/c++/10/bits/invoke.h:60
#11 std::__invoke<INDI::SingleThreadPoolPrivate::SingleThreadPoolPrivate()::<lambda()> > (__fn=...) at /usr/include/c++/10/bits/invoke.h:95
#12 std::thread::_Invoker<std::tuple<INDI::SingleThreadPoolPrivate::SingleThreadPoolPrivate()::<lambda()> > >::_M_invoke<0> (this=0x555555597b28)
    at /usr/include/c++/10/thread:264
#13 std::thread::_Invoker<std::tuple<INDI::SingleThreadPoolPrivate::SingleThreadPoolPrivate()::<lambda()> > >::operator() (this=0x555555597b28)
    at /usr/include/c++/10/thread:271
#14 std::thread::_State_impl<std::thread::_Invoker<std::tuple<INDI::SingleThreadPoolPrivate::SingleThreadPoolPrivate()::<lambda()> > > >::_M_run(void) (
    this=0x555555597b20) at /usr/include/c++/10/thread:215
#15 0x00007ffff6daade4 in std::execute_native_thread_routine (
    __p=0x555555597b20) at ../../../../../libstdc++-v3/src/c++11/thread.cc:82
#16 0x00007ffff6eed299 in start_thread (arg=0x7ffff55ad640)
    at pthread_create.c:473
#17 0x00007ffff6a9a3b3 in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Does that help in any way?
 
2 years 11 months ago #69904

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

  • Posts: 1009
  • Thank you received: 133
I can at least confirm that, while the ASI183MC is crashing the driver every time, the 290MMmini works without issues...
 
2 years 11 months ago #69906

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

  • Posts: 139
  • Thank you received: 31
For what it's worth, my own experience :

SW EQ6-R Pro (eqmod)
ASI1600mm Pro
ASI290mm
ZWO EAF
ZWO EFW

Every hardware on a Raspberry Pi3 running Fedora. ASI290mm + ZWO EFW on the hub of the 1600mm
EQ6 and ZWO EAF on the others USB ports.

Kstars on a distant laptop, WIFI connected to the Pi under Fedora 33.
Every thing built from scratch, latest git (2021-04-10)

Everything works fine. Absolutely no problem detected (?)

Just one thing, I had to add the famous line giving some more memory to my own
/usr/lib/udev/rules.d/99-astro.rules

<
# Add some memory for ASI cameras
ACTION=="add", ATTR{idVendor}=="03c3", RUN+="/bin/sh -c '/bin/echo 256 >/sys/module/usbcore/parameters/usbfs_memory_mb'"

# EQMod Mount
SUBSYSTEM=="tty", SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6015", ATTRS{serial}=="EB30E0KY", MODE="0666", SYMLINK+="ttyUSB.EQ6-Marco"
SUBSYSTEM=="tty", SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6015", ATTRS{serial}=="EB46CW9V", MODE="0666", SYMLINK+="ttyUSB.EQ6-Greg"
>

I need it for the planetary software FireCapture which, by the way JASEM, is fully compatible with INDI, both the Linux AND the Windows versions.
(Starting with 2.7beta-02)

A new add to your list of compatible softwares.

- Marc
2 years 11 months ago #69911

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

  • Posts: 535
  • Thank you received: 109
Very nice, Marc. I have a similar equipment configuration, and last I checked (clouds and life), my 1600s and 290 mini were also working together with the EFW8.

BTW, not sure if you are aware or not, but I put together a Fedora Copr for INDI, Kstars, stellarsolver, and ekosdebugger that keeps the most recent packages built in RPM format, available here:

copr.fedorainfracloud.org/coprs/xsnrg/

Jim
The following user(s) said Thank You: Marc
2 years 11 months ago #69912

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

  • Posts: 139
  • Thank you received: 31
Hi Jim,

Yes, I know copr.fedorainfracloud.org/coprs/xsnrg/, of course :)

All my Raspberry PIs run under Fedora.
This distro works really fine on PIs, i've been using it for years, and I love setting up my network both the old way AND with nmcli) ...

That would be nice to have those 'bleedings' (with the appropriate fedora-repoxx) under Raspberry Pi..

Last time I checked, I dindn't find them.

- Marc
2 years 11 months ago #69927

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

  • Posts: 1009
  • Thank you received: 133
Addition:  If I downgrade only libasi, in my case to 1.9.0-21_gd9a5e309 from March 11, everything runs fine.  That is the old SDK, 1.16.3.0.  So it obviously is an issue of the ZWO SDK?
 
2 years 11 months ago #69931

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

  • Posts: 472
  • Thank you received: 165
Libasi package also contains the udev rule file, which has that usbfs 256MB memory line in the old version, but not in new one.
2 years 11 months ago #69937

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

  • Posts: 535
  • Thank you received: 109
This is true, but it still exists. It was just moved to INDIlib, and should have the same effect. This change has been working for me now for  some time. Jasem moved it there because many devices require it, so indilib is a good central place to manage it.
I still suspect changes in the SDK/driver from ZWO as having some differences to figure out.

Jim
2 years 11 months ago #69941

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

Time to create page: 0.933 seconds