Access a USB device connected to the TX2 over Ethernet


I’m looking to expose the USB port to be accessible over the native ethernet port of the TX2.

I have a software installed on a windows server on the same network as the TX2. The TX2 is in a remote location without keyboard, mouse or monitor. I’m wondering if I could configure the TX2 such that I can directly access the USB device from the windows server.


That depends what you mean, and it also depends on the USB device. Do you mean to have a program which goes over ethernet and accesses the device as if it is local USB to the Windows machine? That’s possible, but it is extremely involved.

If you mean to have a port on the Jetson, which plugs into the USB of the Windows machine (not via ethernet), then it depends more on the nature of the device.

Can you give more exact details of what the device is (such as whether it is a “standard” device using “standard” drivers? For example, a mouse, keyboard, data storage device, or camera will mostly be using standard drivers from a “standard class”, but some cameras will use a custom driver for control, and some devices require custom drivers from the manufacturer. The exact nature and what cable connects where is important as to just how much trouble this would be.

Thanks for your reply.

It would be a program that goes over ethernet and access the device as if it is local USB to the Windows machine. The device is an FTDI chip RS485 to USB converter. The RS485 to USB converter is used to interface between the USB port of the carrier board of the TX2 and the other serial board we need to control.


Is it correct that your USB serial UART has RS485 protocol support, and that the Jetson (and perhaps more devices) are using the UART wiring, while the USB end needs to reach the Windows computer? Or is it the reverse, whereby the USB goes to the Jetson, and the TX/RX and other wires need to reach Windows?

The USB connects to the Jetson Tx2 while the UART wiring connects to the other device.

Ideally I would have installed the program on the Jetson and run it from the Jetson to control the other device. But, firstly the program is a windows software and we can only use the software from a GUI. Secondly the Jetson is in a remote location and is connected to the windows server via the ethernet. Hence why I’m looking for a way to expose the USB port of the Jetson over the ethernet to make it seem like the USB is connected locally to the windows machine.

If you monitor “dmesg --follow” on the Jetson, and then plug in the USB device, what log lines are added from the USB plug-in? Is it correct that this device already functions on the Jetson the way you want it to when connecting to the other device over UART, and that only connectivity to the Windows system is in question?

I can’t say for certain, but I think there are some USB-to-ethernet devices used by some server farms and data centers already which do this. Basically, you plug it in to USB, and then the ethernet into the device. These would have drivers at the Windows side.

To export this one device to ethernet would be possible, but it would be some seriously difficult work. You’d then also need to develop your own driver on Windows.

Regarding devices already set up for converting USB over ethernet, this might still not be enough. I say this because most of the software for creating virtual USB devices will only work with “standard” devices (devices using standard drivers, e.g., HID class such as keyboard/mouse, mass storage class such as USB hard drives, so on). Serial UARTs (regardless of a PHY that is RS232 or RS485) are not standard. Those devices quite often have a driver already installed since they are so common, but they are specific to the chipset (FTDI is likely the most common). This means it is a custom driver, and one might need the driver source code to modify to expose it to a networking program (perhaps not too difficult on the Linux side if you have driver source code, but it still would not be “simple”).

Instead of exposing this as a USB device over ethernet you might consider writing software on the Jetson which simply works with the device with the ability to pipe a network connection to/from the device. I’m not sure about the RS485 additions since I don’t have any RS485 devices, but if it were just RS232 then it would read or write to a device special file (with ioctl calls if you need to administrate the device, e.g., to change RTS/CTS modes or change baud rates). I don’t have any RS485 devices, so I can’t tell you how it deals with multiple device addresses from the user space software side (maybe it has more than one device special file, or maybe it uses an ioctl call to switch device address, don’t know).

It is possible to write a program on Windows which looks like a serial UART, and have a program like PuTTY talk to it and not care whether it is virtual or physical. It won’t be easy and you’ll need to know how to write drivers on Windows. Perhaps it is just user space software on Linux.

I can’t vouch for this, but it might be of interest:
(keep in mind that the Linux side software requires 64-bit ARM architecture)

The device already functions correctly on the Jetson. It’s an FTDI chip.

I can’t add another electronic component into the box the Jetson is housed, so I can’t really explore the option of a USB-to-ethernet device.

I can explore the option of snooping the commands from the windows software, send it over putty and have another program pipe connection to/from the device like you suggested.

Another option I was looking at is configuring USBIP on the Jetson and the windows server. How can I configure USBIP on my Jetson TX2 ubuntu 16.04, processor - aarch64, kernel - 4.4.38-tegra?

Are you sure it is Ubuntu 16.04? If so, then it has L4T R28.x, which was much improved with R32.x. Check “head -n 1 /etc/nv_tegra_release`”.

Also, can you tell me more about the program, and what is running on the Jetson side? Is it the Windows side that needs the GUI?

If the Jetson and Windows system talk to each other over RS-485, but “the Jetson is in a remote location and is connected to the windows server via the ethernet”, is there any kind of diagram of the ethernet and RS-485 topology available? I think you are going to be out of luck in some cases, but there is just too much unknown to really answer yet. Because you said the USB side of the FTDI chipset works, and is connected to the Jetson, then I assume that although RS-485 has some range available, that the Windows side is more or less in the local area. Knowing more about the exact topology of what goes where, and which system you sit at, and which USB function you need, might help.

Beyond that you are going to need the serial console log I think. I’ve never used it, but I do see:
(I don’t know if this is even maintained)

I’m thinking you want the RS-485 device on USB to the Jetson, and you want the Windows system to think that the RS-485 USB adapter is local to the Windows machine via ethernet. From what I saw on the USBIP URL this was using standard devices, e.g., HID (keyboard, mouse, joystick) or mass storage. I don’t think the RS-485 has a standard interface the way these common devices do (I think the RS-485 driver is not from a “framework” of standard drivers, but is instead custom). I could be wrong, but I have doubts the RS-485 could function this way.

Barring USBIP you might need to write your own program which runs on the Jetson, and relays the RS-485 content over ethernet. Then write another network-based program on the Windows system to use that network program. It wouldn’t be USB, so a question gets added here: Does the software at the Windows side depend on the USB device directly? Does the Windows side have programming already for only the case of talking directly to the FTDI chipset? If that program just needs data, and the FTDI plug-in is incidental to the function, then you are going to find it far easier to write your own program than if your Windows side demands the USB device (the FTDI chipset) to talk to.

Here is the screenshot of the out of “head -n 1 /etc/nv_tegra_release” :

Here is the system layout illustration diagram:

The Jetson communicates with the windows server via an Ethernet connection.

We’ve written a software on the Jetson that does the normal function of data capture from the camera board via a combination of sending command via the RS485-to-USB converter to change exposure, frame rate etc., and a frame grabber that actually saves out the data from the camera board to the Jetson board over USB. This works correctly.

The issue is we need to run a different command to the camera board from a windows software GUI installed on the windows server. The only direct comms connection we have to the camera system is the RS485-to-USB converter. Hence the plan to expose the USB port of the Jetson TX2 over ethernet, since there is a communicate path from the Jetson to the camera already through the USB and there is a communication between the windows server to the Jetson via the Ethernet port.

The command from the windows software GUI does not capture data, it just starts a process and receives the acknowledgement that the process is complete.

Can you type these commands in exactly from the Jetson and report the output?

  • head -n 1 /etc/nv_tegra_release
  • uname -r (actually, you can skip this since one of the uname commands contains this)

The nv_tegra_release content is important here (we know the file is there, but we need to see the first line of the file). Note that if you use serial console for access, then although it is text-only, the console program runs on the host PC and this can directly log everything without the need for screenshots. Or you could use scp to network copy content to another computer, but serial console is usually simpler and better for a number of reasons (serial console does not require network nor display drivers, so it survives and works when much of the system is burning to the ground).

It seems likely the RS-485 is used for control of cameras, or something related to what the cameras do. You’re going to find this a bit odd as an answer, but even if you choose something different, then it illustrates some points.

You could take the RS-485’s USB port (it is a device port) and use a short USB cable to connect it to one of the regular USB (host) ports of the Jetson. This would allow client software to run on the Jetson for the control. At this point you could use ssh to log in to the Jetson over ethernet, or create an ssh tunnel, and control over ethernet indirectly. A program running on Windows which requires an RS-485 protocol would not be able to do this directly, and running on Windows greatly limits your workarounds, but you could create a program which runs on Windows and emulates a virtual USB device which works over the ethernet ssh tunnel. It’s easier if all you need to do is produce a program which does what you want without requiring it to be ssh…that’s the million dollar question: What are the exact methods the program at the Windows system which allows that program to interact? If you can do this as a manual process, logged in to the Windows machine and run by a human, you’re already basically done and can do this fairly easily. If there is just data to read or write to a UART, then it can be streamed over the ssh connection (either as a tunnel or as a login session). For streaming the Linux side could use netcat; for a user login method, there are a lot of terminal programs. For custom software on the Linux side, any custom network program or serial console program is trivial. On the Linux side, if you have a USB device behavior which uses a “standard” driver (which the RS-485 is not), then it is more difficult, but not an extreme effort. For use or creation of such behavior on the Windows side, I can’t say for sure what is needed, but I expect the effort to be much more difficult.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.