×

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

Bi-monthly release with minor bug fixes and improvements

ASI294MC-Pro 16 bit download problem.

  • Posts: 79
  • Thank you received: 13
I have a problem taking 16 bit images with my new ASI129MC-Pro . (this is similar to the zwo-1600mm-16bit topic below, but I am using an "official" build)
The first few work, but then it hangs.

My normal sequence is 60 x 60 sec lights. However when I try it, the system stalls. First time after 17 images, now just trying with logs after 7. ( I used 5 sec lights but the effect is the same)

I can download some 16bit images but then after a variable number, no further images are downloaded and I need to reboot the system to unfreeze it.
In the example I logged, the system freezes after 7, it loops taking more images, but not downloading them. In a previous session it downloaded 17.
Eventually the system aborts.
If I reset and restart the sequence it continues to hang.
If I stop and restart EKOS and add a new sequence it still hangs. I need to reboot to get it to re-start

The ASi294MC is a 14 bit system, but 16 bit images preserve all the data.
I was previously using an ASi178MC, also 14 bit, and capturing a 16 bit, doing 60 images per session with no problem. Of course the file size of my new camera is much larger.
If I set the image capture to 8 bit, it all works, but only after system reboot.
So it looks like a buffer type problem, but I could not see anything in the INDI control panel.
Any ideas?

My system: Rock64 running Ubuntu(Armbian) Indi Ekos, built using the download instructions on Ubuntu
ASI294MC connected direct to USB3 port
Nightly builds , just updated: Kstars version 3.3.6 Build: 2019-09-22T09:43:47Z

The problem looks similar to the one reported in
indilib.org/forum/ccds-dslrs/5678-zwo-1600mm-16bit.html
but I used an official build that I thought would avoid it because “This rule is installed when you install the PPA along with other rules per camera manufacturer.”


Regards Max
Great fan of Indi/Ekos and appreciate the support
Last edit: 4 years 6 months ago by Max Dobres. Reason: missed a bit
4 years 6 months ago #43761
Attachments:

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

  • Posts: 1009
  • Thank you received: 133
Have you checked that the mentioned file /lib/udev/rules.d/99-asi.rules indeed exists on your system?
If it does, you can try to increase the limit from 256 to 512...
The following user(s) said Thank You: Max Dobres
4 years 6 months ago #43767

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

  • Posts: 985
  • Thank you received: 161
Hi Max,

I use the 294MC-Pro for over a year now in 16bit RAW mode and never experienced the issue that you describe. I took images as recently as yesterday, did 30x300s, 31x300s and 60x0.002s without a problem. So I assume the root cause for the issue is not 16bit. I see you connect the cam to the server directly which is perfect, no USB hub issues. What do your bandwidth settings look like?

The logfile lists

[2019-09-23T09:40:11.689 UTC DEBG ][ org.kde.kstars.indi] - ZWO CCD ASI294MC Pro : "[DEBUG] ASIGetExpStatus failed. Restarting exposure... "

I have no idea what it means other than something is going wrong.

First of all I'd try a different USB port, if there is any.
Secondly I would remove as many USB devices as possible (particularly the qhy5) and run another test on the 294. Does it perform reliably then? If so, I'd add back other USB devices one by one with the QHY last.
Does the cam hang in USB2 mode, too?
The following user(s) said Thank You: Max Dobres
4 years 6 months ago #43769

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

  • Posts: 79
  • Thank you received: 13
Derpit,
I checked and the rule does exist, I changed the 256 to 512 and rebooted.
It now reads:
ACTION=="add", ATTR{idVendor}=="03c3", RUN+="/bin/sh -c '/bin/echo 512 >/sys/module/usbcore/parameters/usbfs_memory_mb'"
# All ASI Cameras and filter wheels
SUBSYSTEMS=="usb", ATTR{idVendor}=="03c3", MODE="0666"

Did not make a difference, shame.
4 years 6 months ago #43770

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

  • Posts: 133
  • Thank you received: 33
This problem seems to be reported quite a bit. Have a look here indilib.org/forum/ccds-dslrs/5588-exposu...rockpro64.html#42635 there are links in that thread leading to other threads with the same/similar problems.
I have a NanoPC-T4 and ASI294MC Pro, with camera plugged into USB3.0 port in 8bit downloads will be successful up to around 10-20 images then goes into a loop. With 16 bit selected, usually only 1-5 images are downloaded before looping. Download always work fine when camera is plugged into a usb2.0 port.
Last week I installed Armbian 5.95 then from Armbian-config updated to kernel 5.3 and the problem is solved...but....networking doesn't work so for now I'm back to 5.95 with kernel 4.4.190.
4 years 6 months ago #43772

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

  • Posts: 985
  • Thank you received: 161
I feel like the problem mostly occurs with smaller, mobile hardware. With older much less elegant desktop hardware there seem to be fewer issues, regardless of Kernel version. My 294 was directly connected to an old chunky XPC (USB3) running Kubuntu 18.04 (Kernel 4, several versions) and is now connected to the same hardware with the OS updated to Kubuntu 19.04 (Kernel 5). No issues. My conclusion is the problem cannot be purely Kernel related (as some posters suspected in the threads mentioned). Just my impression.
Last edit: 4 years 6 months ago by Alfred. Reason: just to clarify the hardware is old and chunky but still it has a USB3 port which the cam is connected to
4 years 6 months ago #43775

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

  • Posts: 79
  • Thank you received: 13
Herrhausen, thanks for the suggestion
The solution is UNBELIEVABLE it all works if you connect the camera to the USB2 rather than USB3.
The threads quoted by starman345 point to a problem Unix Core problem, maybe only with the version running on Rock64
I assume that as I did an sudo apt update / sudo apt upgrade I have got the latest version. I am now running Armbian 5.3 but the problem persists.

It looks like it has to do with file size, the ASI294 generates an 11.7MB file which is twice as large as my ASI178MC. For smaller files including 8 bit USB3 works fine.
Just to check I set up a job to capture 120 x 5 sec 16 bit exposures with only a 1 sec delay and it works fine.

The shame is I ditched my old RPI3 to get the Rock64Pro for the USB3 port. It is however much faster on plate solving and other tasks
I wonder if any of the RPI4 early users are getting any problems with USB3 and large file size cameras?

At least it works now.
Thanks for the help!
Max
4 years 6 months ago #43776

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

  • Posts: 985
  • Thank you received: 161

Ok, this is a workaround until USB3 works properly. I'm glad you found a preliminary solution.

BTW, ASI 294 16bit RAW file size should be 22,3 MB.

I have no idea re Pi4. But USB3 definitely is worth the effort (and extra money) since it speeds things up remarkably and is a pleasure to work with. Hope you'll have a reliable USB3 port (driver issue?) soon.
4 years 6 months ago #43777

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

  • Posts: 985
  • Thank you received: 161

Ok, this is a workaround until USB3 works properly. I'm glad you found a preliminary solution.
BTW, ASI 294 16bit RAW file size should be 22,3 MB.


I have no idea re Pi4. But USB3 definitely is worth the effort (and extra money) since it speeds things up remarkably and is a pleasure to work with. Hope you'll have a reliable USB3 port (driver issue?) soon.
Last edit: 4 years 6 months ago by Alfred.
4 years 6 months ago #43778

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

  • Posts: 79
  • Thank you received: 13
BTW+ : ASI 294 16bit RAW file size should be 22,3 MB. yes on the host computer, as its expanded to 16 bit but I believe its a lot smaller on the camera where it is held on the camera in 14 bits, not sure of the exact encoding. Which raises the additional point about where the file structure encoding is done. Given 8 bit files transfer OK and 16 bit ones don't it suggests it might be done on the camera. But its not something I intend diving into.

My main concern is image quality. Is there any adverse effect in transferring the 16bit image via USB2 vs USB3? Given that the DDR Memory Buffer on the ASI294Pro was specifically designed to "minimize amp-glow, which is caused by the slow transfer speeds when the camera is used with a USB 2.0 port." maybe is does not matter
4 years 6 months ago #43781

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

  • Posts: 985
  • Thank you received: 161

Since you deduct dark frames the effect (if any!) should be invisible in your end result anyway. I would deem this alleged USB3 "advantage" a marketing story.
4 years 6 months ago #43784

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

  • Posts: 133
  • Thank you received: 33
I haven't found any image quality issues with USB2, just slower transfer speed than usb3. I have an A5X Max tv box with an older 3328 rockchip soc and the usb3 works fine with the asi294mc pro, the amp glow is still evident, less but still there. I've found the amp glow in the images is gone after calibration.

BTW, my ASI294MC Pro works fine with usb 3 plugged into my desktop PC running linuxmint
4 years 6 months ago #43786

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

Time to create page: 0.524 seconds