Why does windows have issues staying connected to a Jetson device?
I’m connected to a Jeston from my Windows PC using the micro USB connection. Initially Windows detects the USB device and I can ping the Jetson at 192.168.55.1. However this connection times out and disconnect/reconnects repeatedly unless I switch to a Linux based laptop (which doesn’t have this issue).
How can I reliably have Windows PC’s connect to the Jetson without having issues? I can connect to the wireless dongle connected to my Jetson using a Windows PC and this time out issue doesn’t occur.
Thanks for the response Dane.
While all of our field engineers are equipped with Linux PC hosts, the majority of our clients do not have Linux based systems.
This makes servicing requests difficult as they can not use a USB cable and connect their Windows PC to the Jetson and allow us to remote into the system.
For security measures we disable SSH into the Jetson via Wifi and do not statically set the ethernet port when flashing the Jetson. I do not have issues connecting to a Jetson via ethernet or wifi from a Windows PC, however our third party advisors have recommend disabling SSH requests other than USB.
I’m trying to determine if there are other successful methods Jetson users are connecting Windows PC’s via the USB port without having this timeout request. What is the main reason this occurs?
Besides opening the wifi for SSH requests or setting the ethernet port to static IP address and using a cross over cable to connect with the device, what other options would you suggest to allow Windows PC systems to service a Jetson (allow SSH requests without timing out).
What are you using for the cable? Are the carrier boards using a micro-OTG port at the Jetson side, or is it a USB-C? If the former, then the cable quality is always suspect since many people get “charger” cables, and these typically have very low quality (e.g., two strands of 32 gauge copper). The micro-B USB cable provided by NVIDIA are quite good on quality for data, and so if you have tested with one of those cables, then the results are probably accurate; but if you are testing with a third part “charger” cable, then the cable is likely at fault. USB-C cables tend to not have that issue, but many of the Jetson carrier boards use a micro-B USB cable (micro-OTC socket), and these have issues with bad cables.
All of the newer boards we are purchasing are USB C. I’ll have to verify if this is isolated to Micro USB Carrier boards or includes the same issue in USB C
I can’t see the image since I don’t have a login to that service. However, if the micro-B USB cable is the one which NVIDIA provides, then it is good quality and won’t be the issue. All other micro-B (“charger”) cables are suspect until validated (two out of three such cables are expected to fail). There’s never been an issue with USB 2 full-sized cables, nor has USB-C cabling been an issue.
Incidentally, there is no such thing as an A-to-A cable. This is a violation of standards. One end is always a device (type-B), and the other end is always a host (type-A connector). The reason an OTG connector can take either type-A or type-B is that it has an ID pin. That ID pin detects if the plugged in cable is type-A (host) or type-B (device). Anyone who sells an A-to-A cable is probably scamming someone (a better description might be “an accident looking for a place to happen”).
I would not worry about ports using USB-C. It is only the micro-OTG port to worry about, and it isn’t actually the port that is a problem…it is the cable at issue.
Even so, we don’t know that this is the problem. It seems likely though that without a proper micro-B cable you can’t find out.