Register    Login    Forum    Search    FAQ

Board index » Software » Linux




Post new topic Reply to topic  [ 11 posts ]  Go to page 1, 2  Next
Author Message
 Post Posted: Sun May 21, 2017 12:38 pm 
Offline

Joined: Thu Oct 13, 2016 4:32 pm
Posts: 8
Hi,

please help me - I don't know what to do anymore.

I recently updated from Debian 8 to 9 (Stretch, Kernel v 4.9.0-3-amd64) and recompiled the software I wrote - basically an autoguider for my homemade mount based on an arduino. The camera I use is the 120MM USB2 (I know, not the best choice for Linux) on a Sony Laptop with i5. Before the update everything worked fine. I received up to 20fps at max resolution and around 200fps at the lowest. In my program I use the old v0.3.0324 SDK and call all functions in the recommended order.

Now, I receive a timeout during capturing the video frames (timeout set to 2*exp+300ms). I have tried all combinations of different bandwidth overload values with and without high speed mode, both set to auto and fixed. The camera still times out.

Then I changed the firmware from the originally installed to the compatible one. This helped in some sense, as I now get the video data, but with low and unstable frame rates. On top, as soon as I connect to the arduino, the frames time out again, unless I select 320x240 as resolution - then I get ~100fps. So this again seems to be some USB controller problem, but why did it work before? The libusb1.0 update from jessie to stretch seems to be very minor.

I also tried to update to the latest SDK, which improved the framerates a bit and makes them more stable. But the frames get corrupted and mosaiced. Also, this did not solve the problem that connecting the arduino crashes the video capturing. Using different USB ports doesnt help either. There seem to be two USB hubs, but all external devices get connected to Bus002:

lsusb
Bus 002 Device 010: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter (Arduino)
Bus 002 Device 006: ID 03c3:120a (ASI Camera)
Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0c45:6409 Microdia Webcam
Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

I also tried to install oacapture, but without success. Some library is missing, which is seemingly not available for Debian 9 (but I'm sure there is a workaround I don't know).

What else can I do? Thanks in advance for your support.


Last edited by MonsterMax on Mon May 22, 2017 11:15 pm, edited 1 time in total.

Top 
 Profile  
Reply with quote  
 Post Posted: Mon May 22, 2017 11:14 pm 
Offline

Joined: Thu Oct 13, 2016 4:32 pm
Posts: 8
I patched my Linux kernel (now v4.9.25) - this solved the problem. User chripell described here http://zwoug.org/viewtopic.php?f=17&t=6901, which lines have to be altered. It is not as hard as one might think.

To sum up what has been said elsewhere in this forum:

The USB standard defines so called "endpoints", which can send or receive data. They come in different types for different purposes. See here: http://www.makelinux.net/ldd3/chp-13-sect-1 For transferring large amounts of data there are the "bulk" and the "isochronous" endpoints. The USB2.0 standard specifies for each endpoint type how many bytes can be sent in one packet. For bulk endpoints the standard says 512 bytes, for isochronous 1024 bytes. The problem now is, that the standard ASI firmware uses bulk endpoints, but tries to send 1024 bytes. Newer Linux kernels refuse to accept this and try to enforce the official standard. Windows does not do that. The result is that the camera doesn't work. The compatible firmware version fixes this by setting the correct value of 512, but in turn gets much lower transfer rates which render the cameras almost unusable in some cases. Linux acts so strict for software security reasons.

The correct fix for the firmware / USB drivers would be to use isochronous endpoints for the video data transfer in order to comply with the standard. This would probably erase many of the problems Linux users have - unless there is a very good reason not to use isochronous endpoints. I am not an expert, so my judgment might be wrong.

DEAR DEVELOPERS: You might really consider this, as I am probably one of the first to get a newer kernel with version 4.x - many more will follow as soon as Debian 9 is officially released, so you will get a lot more complaints. And not everybody can patch the kernel.

_________________________________________________________________________

The Linux kernel is the "heart" of the system. It handles everything that happens at a low level - including USB cameras. I did this for kernel version 4.9.25.

Follow the instructions given here, but handle them with care:

http://www.makeuseof.com/tag/compile-linux-kernel/
https://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official (Section 4.5)

What I did:

sudo apt-get install linux-source - and all the other stuff needed, you can specify the kernel version and can take the same you already have or a newer one, google how to specify package versions

change directory, unpack etc

Go to the file /drivers/usb/core/config.c

Find the following lines and comment them out (as chripell described earlier) - this is the dirty fix to make the camera work:

if (maxp > j) {
dev_warn(ddev, "config %d interface %d altsetting %d endpoint 0x%X has invalid maxpacket %d, setting to %d\n)",
cfgno, inum, asnum, d->bEndpointAddress, maxp, j);
// COMMENTED OUT maxp = j;
// THIS TOO endpoint->desc.wMaxPacketSize = cpu_to_le16(i | maxp);
}

Save the changes (as root/sudo).

sudo make nconfig -> just press F9 and save, creates a .config file which says what needs to be compiled

IMPORTANT:
sudo scripts/config --disable DEBUG_INFO -> otherwise the created kernel is huge and the compilation takes ages

sudo make deb-pkg -j $(nproc --all) -> wait around 40 minutes - around 2GB of files are created, but in the end you use only 400MB or so

sudo dpkg -i ../linux-image-XXXXXX.deb -> this installs the kernel.

reboot

Don't be afraid - you can still use the older kernel versions if everything fails by selecting them in the GRUB bootloader. You can then uninstall the failed kernel and try again or become desperate.

________________________________________________

I hope I described the problem and its solution more or less correctly and was able to help you. And I look forward to a proper driver/firmware solution! I now get 20FPS at 1280x960 and 200FPS at 320x240 with the 120MM again, with other USB devices connected and operating.


Top 
 Profile  
Reply with quote  
 Post Posted: Wed May 24, 2017 2:25 pm 
Offline

Joined: Wed Mar 08, 2017 10:16 am
Posts: 4
Hi,

I just tried to solve my problem with an ASI174MM camera, that produces the very same error that you and chripell described earlier. I went through the kernel module patching, but I still have massive timeouts. (I'm using the linux-image-4.9.0-0.bpo.3-amd64 kernel from the jessie-backports on a jessie system, with the latest ASI SDK v0..6.0414.)

I suspect that this might be due to the fact that I use USB3.0 ports and you mention that this patch solves the problem using USB2.0 ports. Do you only use USB2.0 ports for the ASI120MM camera?

Thanks!


Top 
 Profile  
Reply with quote  
 Post Posted: Wed May 24, 2017 10:34 pm 
Offline

Joined: Thu Oct 13, 2016 4:32 pm
Posts: 8
Yes, I only have and therefore only use USB2 ports for my camera. The patch only fixes USB2 compatibility problems that may occur since kernel v3.16.39. Inherently, this very specific problem should only arise when using a USB2 camera, no matter on which port. As pointed out before, the camera firmware sends "illegal" packet sizes, that are then rejected. So I assume something else causes your issues.

0) The ASI174 is a USB3 cam, right? I think so, but correct me if I'm wrong.
1) Are you 100% sure you use an USB3 port? USB3 cameras on USB2 ports could show similar behaviour.
2) Which software do you use to access the camera? Did you write it?
3) In case you wrote it on your own: Try to use different SDK versions. The old version 0.303 worked best for me, but I have not tried the newer ones after the patch. But the comments in the other threads suggest, the newer versions act strange sometimes.


Top 
 Profile  
Reply with quote  
 Post Posted: Thu May 25, 2017 7:37 am 
Offline

Joined: Wed Mar 08, 2017 10:16 am
Posts: 4
MonsterMax wrote:
0) The ASI174 is a USB3 cam, right? I think so, but correct me if I'm wrong.

Yes, indeed.

MonsterMax wrote:
1) Are you 100% sure you use an USB3 port? USB3 cameras on USB2 ports could show similar behaviour.


Code:
[60658.326243] usb 2-1: new SuperSpeed USB device number 40 using xhci_hcd
[60658.353318] usb 2-1: New USB device found, idVendor=03c3, idProduct=174b
[60658.360056] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[60658.367233] usb 2-1: Product: ASI174MM
[60658.371016] usb 2-1: Manufacturer: ZWO


It does show up as a USB3 camera with SuperSpeed connection and using the xhci_hcd driver.

MonsterMax wrote:
2) Which software do you use to access the camera? Did you write it?


I'm using SDK v0.6.0414, the latest one, and I also tried 0.6.0214 previously.

MonsterMax wrote:
3) In case you wrote it on your own: Try to use different SDK versions. The old version 0.303 worked best for me, but I have not tried the newer ones after the patch. But the comments in the other threads suggest, the newer versions act strange sometimes.


Reverting to an older SDK version may be an option, I can try that. Do you know where can I download the older SDK versions?


Top 
 Profile  
Reply with quote  
 Post Posted: Tue May 30, 2017 11:33 pm 
Offline

Joined: Thu Oct 13, 2016 4:32 pm
Posts: 8
Sorry for the late reply. You can find the SDKs here: https://astronomy-imaging-camera.com/software/

Edit: I just saw that it only dates back until version 0.4.xx. If you really want or need to try v0.3 I could send it to you. Were you able to solve your problem in the meantime?


Top 
 Profile  
Reply with quote  
 Post Posted: Wed May 31, 2017 10:24 pm 
Offline

Joined: Wed Mar 08, 2017 10:16 am
Posts: 4
MonsterMax wrote:
Sorry for the late reply. You can find the SDKs here: https://astronomy-imaging-camera.com/software/

Edit: I just saw that it only dates back until version 0.4.xx. If you really want or need to try v0.3 I could send it to you. Were you able to solve your problem in the meantime?


I'm actually not sure. For the time being, I worked around the problem by letting the ASI174MM control its gain and exposure time parameters automatically, and with this setup it works quite okay, having a captured frame ratio of about 95-98%. There are still timeout errors, but much less than before.


Top 
 Profile  
Reply with quote  
 Post Posted: Thu Jun 01, 2017 1:59 am 
Offline
User avatar

Joined: Thu Feb 21, 2013 2:51 am
Posts: 2170
thanks for MonsterMax's explanation of our usb2.0 camera's problem under linux
that's exactly where the problem is
and our USB3.0 camera don't suffer from such problem
you can try to turn down "USB Bandwidth Limit", maybe just your host is not fast enough to accept the data from 174

_________________
ZWO Founder
Location:lon=120.6 lat=31.3
SuZhou China


Top 
 Profile  
Reply with quote  
 Post Posted: Thu Jun 01, 2017 11:22 am 
Offline

Joined: Thu Oct 13, 2016 4:32 pm
Posts: 8
Now that you mention your problem varies with exposure times, another thing came to my mind: To which value do you set the timeout in ASIGetVideoData? It should depend on the exposure time. I have set it to:

error = ASIGetVideoData(camID, buffer, bufferSize, int(2*exposure*1e-3) + 300);

Where the exposure is in microseconds and the timeout is in milliseconds (at least I think so, hence *1e-3; it works fine for me). So here the timeout scales with exposure time and is at least 300ms.


Top 
 Profile  
Reply with quote  
 Post Posted: Thu Jun 01, 2017 2:26 pm 
Offline

Joined: Wed Mar 08, 2017 10:16 am
Posts: 4
MonsterMax wrote:
Now that you mention your problem varies with exposure times, another thing came to my mind: To which value do you set the timeout in ASIGetVideoData? It should depend on the exposure time. I have set it to:

error = ASIGetVideoData(camID, buffer, bufferSize, int(2*exposure*1e-3) + 300);

Where the exposure is in microseconds and the timeout is in milliseconds (at least I think so, hence *1e-3; it works fine for me). So here the timeout scales with exposure time and is at least 300ms.


I had (exposure time)+100ms for the timeout value of ASIGetVideoData, now I changed it to the recommended (exposure time)*2+500ms, and it seems to me that I'm receiving less timeout errors. There are still some timeout errors, and I would need a much longer test to check their rate, but this timeout settings might have something to do with them.


Top 
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
 
Post new topic Reply to topic  [ 11 posts ]  Go to page 1, 2  Next

Board index » Software » Linux


Who is online

Users browsing this forum: Bing [Bot] and 4 guests

 
 

 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: