Time Out errors with ASI-178MM /Linux SDK

pdb

Hi,

testing again on Linux now with the ASI178MM camera. That cam is giving me a lot of problems. Used oaCapture, Planetary Imager and now the first Linux version of FireCapture.

Tested on several machines, different USB ports and different cables. All (Linux) software suffers from severe time-outs. Seems to be related to the speed of the machine (happens less on my 4790K) but it happens.

I have installed 1 machine which is multi boot: Win10 and Ubuntu 16.04 (kernel 4.10); and tested the camera running Windows 10 (FireCapture and AstroGenika). No problems occurs, and camera runs at maximum speed. Booting the same machine with Linux (same cables, same ports ...) and test with Planetary Imager or FireCapture, problem occurs. Reducing USB traffic to 40% does not solve the problem (little bit better, but not gone) Have recompiled Planetary Imager with a longer timeout for reading video data (5 seconds : ) and that helps, but framerate goes down dramatically. So not usable.

Every time a time-out occurs Linux DMESG shows following line:

WARN event TRB for slot xx ep yy with no TDs queued?

So guys what's wrong here?

Camera firmware

ZWO Linux ASI SDK

Linux USB driver

Think we can exclude computer hardware or cable problem sice same machine with W10 gives no problem

Wonder what would happen if I would start testing an ASI1600?????

Regards,

Paul

chad

Hi，

I tested it on the VMware station (Version.5) and the OS is Ubuntu16.04, and there didn't seem to be a lot of timeouts. It works fine.

I have 2 advices:

1, check your USB power supply. I found that it is not stable when connected to the USB port of the front panel of the PC. I am not sure yours.

2, check your OS. Sometimes systems have problems that can lead to similar problems. You can look at the load on the system.

Thanks

chad

pdb

sorry chad but i cannot accept that answer as valid.

If I run on the SAME hardware once with W10 and then with Linux (real machine, not VM) and one OS runs without problems and the other OS not, than there is nothing wrong with power supplies.

I have tested this on 3 different machines: I7 laptop (W10 and Ubuntu 16.04), I7 desktop (Ubuntu 16.04) and AMD Ryzen deskop (W10 and Ubuntu 16.04) all with the same results. I agree it has to do with performance but none of the machines is loaded over 50% when this happens. (It happens more frequent on the lower end machines)

I wonder how you tested on a VM. I always found it very difficult to pass USB ports to a camera.

Did you run in 16 bit mode and ad full resolution 3096x2080?

Paul

chad

Hi paul，

The attachment is my test screenshot.

Because VM does not support USB3.0， so we're using USB2.0, and you can try it.

Let's find out why.

Thanks

chad

pdb

Thanks Chad. That is exactly what I see but then on my USB 3.0 ports (land shows up as high-speed device, so that looks ok) If I did the calculations right (not that good in these) the data stream would be just over 3Gb/sec in 16 bit (correct me if I am wrong) so still plenty of speed left on 5Gb usb port.

What I also noticed: i have a machine with the newer USB3.1 Gen 2(10Gb speed) ports. Using these under W10 no problem, in Ubuntu (claimed that should work) the camera is either not found or performs at USB 2.0 speed. But that could be a Linux problem. (Tried different fora, but nothing found yet about bat USB3.1 Gen2 problems / support on Linux)

To me the problem looks like the SDK can't handle the data fast enough within the needed time for next exposure. (Interupted? To low priority?)

Let's see.

Thanks,

Paul

chad

Hi paul，

I'm not sure what you mean: on my USB 3.0 ports (land shows up as high-speed device, so that looks ok)。

I guess you pluged in USB3.0, and then Ubuntu shows you plug in a High-Speed device, right?

If I was right, I think that's probably the reason。High-Speed means USB2.0, USB3.0 is called super-speed device. You can use other USB3.0 device to check it, like U-Disk.

About the USB3.1, I'm also not sure why。I, like you, have no useful information。

Timeouts are usually the problem of transmission and the instability of the camera， not SDK.

Thanks

chad

pdb

Sorry for the confusion. Of course I meant SuperSpeed (it was a busy day yesterday)

See: log

usb 4-1: new SuperSpeed USB device number 3 using xhci_hcd

usb 4-1: New USB device found, idVendor=03c3, idProduct=178c

usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0

usb 4-1: Product: ASI178MM

usb 4-1: Manufacturer: ZWO

Paul

chad

That's ok. I'll have a dual system to test it. We can communicate with each other, can we?

Thanks

chad

Hi Paul,

I installed dual systems on my PC( Win7 & U16.04.10.0-28),and installed FireCapture_v2.6beta for X64 Linux.

Then I tested 178MM, It still works fine.

On USB3.0, USBTraffic 60%, 16bit, max size, fps=20. No timeout.

Can you execute this command: cat /sys/module/usbcore/parameters/usbfs_memory_mb

You should get the result is 200. If not, maybe that's why.

Thanks

chad

pdb

Hello Chad.

Did run the command and the output was 16 :?

Then i remembered seeing a note on the FLir pages about default 2 MB by default assigned in Linux to image capturing.

So i changed this in Grub: GRUB_CMDLINE_LINUX_DEFAULT="quiet splash usbcore.usbfs_memory_mb=1000"

updated grub and rebooted.

Now the output is 200 :)

Then started FireCapture and selected ASI178 in 16bit.

Looks much better!

I now only get the errors when I start capturing to disc, and the capture buffers are full. Then of course "slow" disk speed comes in to play. (looks normal)

Now I need to test it on my machine that I will as my main "Astro Computer". That one has a fast M2 SSD in PCie mode, sho should give better disk performance as well.

Will let you know, but looks ok for me now.

Kudos

Paul

chad

Ok, please let me know any other questions.

Thanks

chad

pdb

Hello Chad,

an update:

tested again, now on my ASTRO machine.

Changed there also the usbfs memory and run firecapture again. There is some improvement but still lots of errors, even without recording to disc. In 8 bit mode seems to be better (even when recording, only a few errors)

In 16 bit when recording, camera speeds jumps between 4fps and 29 fps with lots of errors 11.

Then I rebooted that same system in W10. Started firecapture with camera in the same usb port. Started in 16 bit mode ans started recording. Camera speed stays steady around 29 fps. Even when starting browser and browse internet or do something else. (On Linux, when I touch any other ap, I can see errors coming when reading the camera)

Very strange, starting to loose my confidence in Linux ...

The processor on that machine (AMD Ryzen3-1200) is not the fastest, but cam works in W10 like a charm. (And even on my I7-4790K it is not completely without those errors) Do you have any experience how it works on Mac? (Don't have a Mac to experiment :( )

Regards,

Paul

chad

Hi Paul,

Have you checked the value of usbfs_memory_mb? Make sure your modifications are successful.

In addition, try to increase the value to no more than 1024 to see if there is any improvement， like change it to 512.

About the browser, other users have responded, but we're not sure why.

Linux is very flexible, so it's inevitable to have some strange problems. Sometimes, solving these problems can be a great pleasure.

On a Mac, it's better than Linux, but there are people who have problems.

Thanks

chad

pdb

Hi Chad,

Yes I checked, but for some reason when setting it up from grub it will not go over 200. Tried setting manually, but no idea if that really set the value higher. (You never know in Linux). You are right it can be a battle to make things work.

Looks like I will have to use my W10 license for the astro machine for the moment (had other plans for that) and do some more testing on my main machine.

Best regards,

Paul

chad

Hi paul，

Use this command:

"echo 200 > /sys/module/usbcore/parameters/usbfs_memory_mb" to write it.

It failed, add sudo before it.

then using "cat /sys/module/usbcore/parameters/usbfs_memory_mb" to check it.

Generally speaking, it supports to set from 0 to 2048.

Thanks

chad