×

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: 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.

  • Posts: 1009
  • Thank you received: 133
 Ah, it's in 99-indi_auxiliary.rules now.  Was wondering, too.  But I had checked that the setting was at 256, so that was/is not the issue.
But if things work with the previous SDK and not with the latest, it's either a bug in the SDK, or some change in the API (or responses) the is not reflected by the INDI code.  The SDK changelog however is not very helpful, just referring to 'bug fixes' :(
 
2 years 11 months ago #69951

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

  • Posts: 1009
  • Thank you received: 133
Addendum: I had not checked the syslog so far. It actually says
Apr 12 11:27:52 woodstock.pitnet kernel: usb 2-1: Process 28984 (indi_asi_ccd) called USBDEVFS_CLEAR_HALT for active endpoint 0x81
Apr 12 11:27:53 woodstock.pitnet kernel: indi_asi_ccd[28976]: segfault at 35 ip 00007fb5551d4646 sp 00007fb53e442b90 error 4 in libusb-1.0.so.0.3.0[7fb5551ca000+e000]

(I also noticed that the new udev rules no longer contain the chmod to 0666 for ASI devives; but it also crashes when run as root....)
2 years 11 months ago #69952

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

  • Posts: 22
  • Thank you received: 4
Running ASI1600mm, ASI120mm mini, EFW, EAF, building from git on RPI4. No issues (anymore).

I did have an issue with the ASI1600mm where it would fail to capture, and the image from the ASI120mm would occationally pop up in the preview instead.
Deleted xml-files from .indi, and set everything up from scratch again. After deleting the xml-files, I saw that the ekos driver setting for both ASI120mm and ASI1600mm were both set to main scope. I set ASI120mm to guide scope, and everything were working again. Not in front of kstars at the moment, so tick boxes could have different names.
2 years 11 months ago #69954

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

  • Posts: 472
  • Thank you received: 165
Yup, SDK regression isn't out of the question, though it seems to be either camera or architecture specific as my ASI120MM-S with ARMv7 and 178MC with x64 I test with both work fine. API hasn't changed, at least the header files were identical when I updated the SDK and they usually haven't changed existing things, just added new ones.
2 years 11 months ago #69972

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

  • Posts: 28
  • Thank you received: 17
In the latest SDK, the problem with damaged frames during long exposure is fixed.
Probably it required more library modification and maybe something got corrupted.
I still offer cooperation for ZWO, unfortunately without success.
2 years 11 months ago #69990

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

  • Posts: 1009
  • Thank you received: 133
Just for confirmation:
With latest, you refer to 1.17, yes? So that one fixes the original issue in this thread, but causes crashes for some?
2 years 11 months ago #69991

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

Time to create page: 0.978 seconds