Issue with USB3 grab or perhaps Display output...

I’m using three 1.2 Megapixel USB cameras (@20FPS) connected to the USB3 port of the Jetson TX1 through a powered Sabrent USB 3.0 Hub.

There are a couple of issues:

  1. When two or more cameras are streaming (using multiple instances of guvcview), the HDMI output of non-video windows has obvious pixel jitter generally on the right half of the screen. Although right now it’s 3/4 of the screen starting on the left side with all three cameras going. It manifests as complete columns of data the full height of the screen a varying width bouncing back and forth semi-randomly. I do not care about this issue, as I’ve seen lots of bad behavior from the drawing engine while using Ubuntu 14.04. I just find it interesting that this issue only shows itself when a high bandwidth DMA engines are writing main memory and / or blitting to the screen.

  2. Data from the camera(s) is corrupt with green stripes that make it seem as if the data is all 0x0 or all 0xFFFF for every pixel. Sometimes the green stripes occur on just the bottom of the image, sometimes for much of the image. The incident of green stripes seems to be higher the more cameras are running. I cannot tell, at this time if this is an USB 3.0 fetch issue (considering the error detection that happens with SERDES, I suspect not) or if it’s a blit issue with the openCV interface that I’m using to display the data or some other video related hardware issue. If it’s a problem with displaying the data, I really don’t care as I don’t need to see the data, I just need to operate on it. But if it’s an USB 3.0 DMA issue, I really care. I just did more testing and this may be related to a specific camera or to the Sabrent USB hub. I’ll have to do more testing.

I’ll be writing more code in the coming days and will eventually be able to figure out of the data is being corrupted by the USB fetch process or the display process but I wanted to give you guys a heads up, as it makes the system feel unstable. Actually the whole HDMI output drawing seems rather unstable.

Thanks for listening.

Are the cameras all the same model (using the same driver)? Are all the cameras USB2 (which simplifies things)?

All the cameras are the same model and all of them are USB3.

If you look at “lsusb”, you’ll see an “ID” field. You can narrow the response of lsusb to just the one ID via “-d ‘0000:0000’” (replace “0000:0000” with your ID). You may want to post the response of “lsusb -d ‘…:…’ -v” for verbose listing of one of the cameras.

Although the devices do not require a lot of bandwidth (even USB2 should work), I have to wonder how USB might be interacting with 3 isochronous devices at once (USB may have no bearing on the issue, but this is something that needs to be looked at).

Also, is the HUB powered or unpowered?

The hub is powered. I noticed that it is designed to transfer the power of the jetson to the first port, then the other three are powered by the external supply…

It just occurred to me that the camera that fails is on that first port.

Aha! Break through! I plugged the three sensors into the externally powered ports of the sabrent hub and voila! no more bad pixels.

It looks like the power going out over the USB3 connection needs a little more capacitance in the sabrent module.

Earlier, when I tested for a few minutes with just one camera directly connected to the Jetson TX1 there were no errors. So based on this testing, my guess is: either the power on the Jetson isn’t quite enough or (more likely) the sabrent hardware / cabling has too much inductance and there are power stability problems, perhaps ground bounce… Hmmm. SERDES is supposed to compensate for all that, but…

Anyway, the picture stability is infinitely better, so I’m sure I can move forward with what I have.

The firefox window I’m typing this into has many jittering pixels though so there’s still something else going on with the distplay.

Thanks for the help!

(Update: Just saw a bad frame after several minutes of being okay, it is much better. I suspect I’ll need to wire the boards directly in the prototype. I suspect the cabling and power is at issue I bet a common ground wire might help. Perhaps some shielding for the camera modules as well.)

I just had the system dead lock when I got my new code running for the first time.

Then I couldn’t get it to boot anymore, until I removed the SSD I had connected to the sata port.

If that drive is blank EXT4, will the system try to boot it? I ask because the system LEDs turn green for a few seconds, then turn off. When I remove the drive, that happens once more, then when I press the power button a second time, it boots properly.

I’ve let it run the new code for a while now and without the sata drive connected (which may just be a coincidence) it seems to be running just fine.

I need the sata drive to work and I know I can’t hot plug it.

Does anyone done anything with a sata drive?

Should I start a new thread for this?

The SATA drive should never be attempted as a boot drive unless extlinux.conf says to use that for rootfs (or of flash says put the boot loader itself on SATA). Whether it is mounted is a different story…possibly it would auto-mount it somewhere even if no entry in “/etc/fstab” is set for it. You could specifically add an entry with UUID or dev special file in fstab which says noauto.

Even if the drive is not mounted or used for boot, it should attempt to spin it up (and draw power) unless it is in a standby mode. I doubt initial startup stops power to SATA prior to at least some startup script. Of course no SATA port on any computer is hotplug unless it was designed that way…hotplug on something not specifically marked as such is asking to cause hardware failure (and it’d really be warm swap and not hot swap unless the proper software is also running…no guarantee drivers of hot swap hardware will respond properly to yanking a drive without proper hot swap software).

In terms of testing, you could put the SATA drive in a powered enclosure and run power from an external source just to see if that matters.

For the USB3 HUB, I don’t know of any case where any port of any powered HUB (with power present) should ever use host power for any port. That seems like a bad design or a hardware failure that the first port would be host powered while others are not. Some of the over-current protection is sometimes a thermal based polymer device which would disconnect the power during over-current and require a few days of cooling to be certain it is back up and reset; should one of those devices trip from over-current it is possible that the port itself would then be host powered…a sign that the camera exceeded capacity or the component was cheap (and cheap components on cheap HUBs are very common).