USB 2.1 when plugging in slowly. #2311
Comments
|
Slow-insertion is currently a known issue, we are looking for firmware work-arounds, but as you mentioned using Type-C to Type-C cable also solves this issue. Regarding the second part of your question, it is probably not related to cable insertion speed, but rather to the general setup. What platform and usb controller do you use in the robot? I'm not an electrical engineer, but perhaps there are some power jumps during take-off? Is it possible to put the camera on a dedicated power-source? |
|
There was a case involving RealSense in robotics where the USB cable reportedly jostled out of the camera's USB port a bit and caused disconnection. I have a similar issue with the joypad controllers on my USB hub, where the cable can wiggle back out of the port a little during play as the pad is moved around and cause the pad to disconnect (stopping control inputs). My wired mouse also does disconnects and connects in the same hub when moving the mouse around Either side of the camera's USB port are two small holes. These can be used with a USB cable with locking screws on to firmly fix the cable into the port. The subject was discussed on the Intel support forum in the link below. The cable supplier Newnex, which can provide equipment for extending the 400 Series' cable length up to 100 m over fiber cable, offers a locking cable and gives a link for the cable at the end of the discussion. |
|
A good to hear, I was hoping for a firmware fix for the slow insertion issue. Any kind of time frame? As it happens, I can only reach the usb-c side on the drone and when aforementioned other connection issues appear I go from bad to worse. FYI we are now using the UP Core board (switched from an Odroid, which we really couldn't get stable with the Realsense; the complete usb system would crash too often in erratic ways). On the particular drone I'm working on right now, the [DelftaCopter](https://www.youtube.com/watch?v=wj0gV08Hdr8 , here still with previous vision system), the power system for the vision is system is completely separate and has quite large margins, so it is unlikely that it causes issues (if you want to know, we are powering from a dedicated 10A 5V BEC, which gets power from a 6S lipo. Voltage drop (e.g. during take off )on the 6S will never come close for the BEC to come into problems, at least not before very vital other systems fail :) ) Like I said, the problems we now still have are not reproducible easily, if they will be and if they point to the RealSense I will probably be posting issues soon thereafter. For instance, it seems, that one day a particular USB cable works perfectly, but the next day we have nothing but trouble with it. But then the cable still works fine on my laptop+realsense... |
|
Are you using the camera in a full-size USB 3.0 port on your Up Core board? If your Up Core model has a USB 3.0 OTG port (a micro USB port that needs a special adapter or cable to connect a USB 3.0 device to it) and you have the camera plugged into one of thise then these may encounter power problems with RealSense 400 Series cameras. Intel support agent Juan mentions it: |
|
It's a full size USB 3 type A connector, the Core doesn't have an OTG port broken out as far as I know. |
|
Thanks! The Up Core Plus model has an additional USB 3.0 OTG port, so I just wanted to make sure whether you had an ordinary Core or a Core Plus. |
|
Well, I just managed to repeatedly reproduce one of these weird usb problems...! Not 100% sure the Realsense is to blame completely, but it's in the mix I'd say. On the drone (which was static on the table at all times during these tests) with the Up Core I'm interacting with the autopilot hardware through a standard ftdi uart usb cable. However, for the purpose of this test I'm not using it at all, it is just connected. My software starts the realsense api, but does not activate any of the streams. So, basically, it's just spinning. After a few seconds (up to a few minutes), funky stuff starts to happen: the ftdi device loses connection. Relevant dmesg og: This basically continues until I stop my software. I have been having similar issues with other USB devices like a usb wifi stick , so I don't think it is the ftdi cable (which we use very regularly anyway, without such problems) I would greatly appriciated any insights you might have on this! |
|
With spinning I basically mean: |
|
A complete dmesg log before starting my software, the dmesg log after start, and the realsense log with export LRS_LOG_LEVEL="DEBUG" |
|
Programming is not my best area of expertise. When you say 'while(i) in your script, I believe that is equal to saying 'while(i != 0) ... i.e the instruction frame = cam.wait_for_frames(); should keep running until i = 0, at which the while loop would terminate because the its while(i) condition was no longer true. So I would guess that unless there is a way for the while loop to return to 0 (like how 'i = 0 to 60 terminates the loop after 60 cycles) then the frame = cam.wait_for_frames(); instruction would continue to run indefinitely? 'While' loops are tricky things in RealSense coding. If there is a mistake in them (e.g an instruction that should be inside the loop is placed outside of it) then processing resources can get eaten up over time, leading to instability and then program termination. |
|
After dozens of tests all eventually resulting in loss of ftdi usb I made an important step. Things I tried that don't work: No, as it turns out, I had to change the USB C cable to the realsense! I have now gone back and forth beween the two usb cables that cause / solve this issue, and it seems quite reproducible. So, I'm observing that using certain usb-c cables to the RealSense result in a crash on other totally unrelated usb (2) devices... erratically after a few seconds/minutes. I'll spare you the memes to express my amazement. Any comment on what I have to look for in cables that won't have this problem? |
It says while (1), (in other words: while(true) ), anyway what I meant in any case that I'm just reading the images in an endless loop and not doing anything with them. |
|
Yes, it is known that some USB-C cables will work better than others, because there can be quality issues in USB-C cables. This is why using the USB cable supplied with the camera tends to work best, as it has been carefully rated by Intel for use with the 400 Series camera. Newnex cables are proven for use with the 400 Series, as shown in the YouTube video below, where Newnex demonstrate the camera being used successfully with their equipment up to 100 m. |
|
OK nice. THe thing is that I need short cables, preferably as lightweight as possible. It seems those Newnex cables won't go shorter than 1m, while I need 20cm.... 1 meter is definetely too long. |
|
A search term you could google for is 'usb-c industrial grade 20cm'. For example, one source that this search term leads to is this 20 cm cable: |
|
@MartyG-RealSense that's not even an usb 3 cable... ! I do request that the Realsense team should maybe investigate this problem a bit deeper. I think it is very weird that the Realsense can cause another USB device to disconnect just by using an apparently coincidentally different cable. I imagine many Realsenses will be connected with short cables when the prototypes go into production right? If anything can be done e.g. in the firmware to make the Realsense more robust it would definitely help me to keep choosing Realsense in future projects |
|
My apologies for the example chosen. The 400 Series data sheet says about the USB cable that "The max cable length should not exceed 15 inch with target loss of 7.5dB@2.5GHz" |
|
Well, I doubt that's going to be a problem on 20 cm cables :) |
|
I made another discovery: we've been using a 4g USB modem stick to enable in-flight internet access, which I initially ruled out due to the combination of other problems (like the original USB 2 slow connect issue) . This also holds for the original USB cable that came delivered with the RS. But, I don't think this a Realsense problem specifically, might be standard USB 3 related, or simply by the Huawei stick sending too much interference. In case anyone wonders: can reproduce this with both a Huawei E8372h and an E3372. |
|
I am experiencing the exact same issue as described above in which slow insertion results in the RealSense camera being detected as USB2.1. I've used multiple cables with firmware 5.11.01 and 5.09.14 |
|
If you are writing your own application then a way to help avoid unplug-replug to reset the camera would be to put a hardware_reset() instruction at the start of the script so that the script resets the camera instead of you having to physically plug the cable. https://forums.intel.com/s/question/0D70P0000068r7PSAQ Alternatively, if you are using the RealSense Viewer program then you can reset the camera in the menu opened with the 'More' option at the top of the options side-panel.
|
|
I also have the same issue. But it does not happen when I use D435i. Is it fixed in this new device? |
Issue Description
When I plug in the realsense USB-C side too slow, the realsense enumerates as a usb 2 device. If I replug the other side, it enumerates as 3.2... See a video here: https://youtu.be/4IFmsG6Wk_U
I have reproduced this issue with:
-3 Realsenses new out of the box
-5 different types of cables (longer, shorter, usb 3, usb 3.1), among which the original black cable that came with the Realsense
Some cables required a gentler touch than others, but with the cable in the video it is almost always happening like that.
Mysteriously, I cannot reproduce the issue when using a USB C to USB-C cable... (my laptop also has usb-c directly)? The Realsense is then detected as a 3.0 device by the way, which may be notable to debug this problem.
On a side note, we are putting Realsenses on drones, but we've been having many connection issues. We have now switched cables and boards to the point things seem relatively stable, but still we seem to lose connection to the camera every now and then. Sometimes that even seems to take down all other USB devices with it. Of course, these problems are very hard to reproduce as they tend to happen after take off, so I'm jumping at any connection issue which I can reproduce :)
The text was updated successfully, but these errors were encountered: