Distributed Control and Sensing with USB

Distributed I/O systems are a key element in many industrial processing settings, distributed environmental controls for buildings of all sizes, vehicles large and small, scientific research settings like large telescopes and particle accelerators, and in laboratories with equipment connected to a central data collection and processing system. Multiple microcontrollers units (MCUs) provide the sensing and control to automate systems for improved efficiency, better data collection, and enhanced safety. Without MCUs, modern life as we know it could not exist.

There are multiple ways to connect an MCU-based device to a host computer system, ranging from industrial serial interface protocols like RS-485, CAN, or ProfiBus, to conventional Ethernet or wireless protocols. USB is also a possibility, but it seems to be largely confined to small-scale and consumer type applications. But does USB have what it takes to be used for applications other than just connecting a printer to your PC? Can it be used to collect data from an automated test system, or control the various components in an industrial process?

The short answer is conditionally yes, if you don’t plan to build a distributed system that spans a warehouse or an apartment building. Active USB extenders not withstanding, USB was never intended to be used for something that involves scores of distributed microcontrollers spread across tens or hundreds of meters. It was intended to serve as a replacement for the numerous cords and cables (usually with wildly different connectors) that could clutter up the back of a PC, as well as reducing the need for unique device driver software each of those connected devices. In theory, any USB device that conformed to the standards for a particular device class could just be plugged in and be ready for use immediately.

Well, as we know, the reality isn’t quite that neat and simple, and sometimes device drivers are still necessary. The USB specification defines what are called “classes” of USB devices. These include HID (human interface device), storage, video, audio, and more. You can download the V2.0 specification from this URL at UCSD (http://sdphca.ucsd.edu/lab_equip_manuals/usb_20.pdf). My books “Real-World Instrumentation with Python” and “Practical Electronics: Components and Techniques” also contain summary information about USB that might be a bit easier to wade through than the full-up specification document. Jan Axelson’s book “USB Complete: The Developer’s Guide” is another excellent resource.

Building USB Networks

Standard USB is a half-duplex protocol, with a master and one or more servant devices. It is a command-response system, wherein only the master can initiate a communications transaction. A USB network consists of one master and up to 127 servant devices. You can use USB hubs to expand the number of devices on a USB network up to the maximum. The diagram below shows a small network with a mix of hubs and devices:

usb_network

You should note that a hub is also considered to be a device, so the actual number of endpoint devices is reduced by the number of hubs in the USB network. In the preceding figure there are actually 14 devices: 3 hubs and 11 endpoint devices. Also notice that I’ve labeled each link in the network with the maximum current capacity it can optimally support.

In accordance with the USB specification, the maximum amount of current any USB port can deliver (source) is 500 mA. An unpowered hub is limited to 100 mA per port (with 100 mA allocated for the hub itself). For flash memory or an audio output module this is fine, but plug in another unpowered downstream hub and the current budget is exhausted. The amount of current available to devices in a USB network is a consideration that is often overlooked.

Let’s say, for example, that you want to have a series of microcontrollers (AKA I/O modules) acting as remote I/O nodes spread out along a beer bottling machine (or orange soda, if you prefer). The arrangement might look something like this:

usb_bottling_machine

Now, there might be a problem here. Well, several, actually, but let’s look at the power situation first. If none of the hubs are powered, and none of the MCU devices have their own DC power, then this network will promptly crash and shut down. In order for a system like this to work reliably every hub and every device must have its own DC power source.

Another potential problem is distance between hubs and devices. USB V2.0 limits the distance of any connection between two endpoints to no more than 5 meters (about 15 feet). For a small production line this might not be an issue, since that rule also applies to the connections between the hubs, and the host PC and the first hub in the network. Assuming that the entire bottling machine is less than about 20 meters or so long, then it should be possible to keep all USB cable runs to less than 5 meters.

Lastly, the system designer will need to consider signaling and response latencies. This involves more than just the speed of the USB network itself, it also entails the processing latencies in the MCU devices, and how quickly the host PC can generate commands and process the responses. Also, don’t forget that the master has to do the work of querying each device, and that can be a stochastic (semi-random) activity. If working all this out sounds like a headache, well, it is. That’s why good industrial systems engineers get paid the big bucks (usually). A quick-and-dirty approach is to identify the most time-critical operations in the system, and use those numbers to set the bar, so to speak, for the overall system latency limit. In the case of the bottling system there is also the rate of the conveyor to take into account. If it’s moving too fast it won’t matter how quickly the system can sense conditions and respond–the bottles will start to accumulate faster than the loading robot can pick them up and put them into cartons. There is a lot more going on here than might be apparent at first glance, and it occurs to me that this would make an excellent case study for a simulation, and I might just do that (when I have the time).

Beyond 5 Meters – USB Extenders

I mentioned USB extenders earlier, and I want to show you some of those now. One unit that I own is shown below:

belkin_extender

And here is another:

rj45_usb_extender

Both of these extenders are USB V1.1 compliant at the remote end, which means it will never be any faster than 12 Mbps (megabits-per-second). The Tripp-Lite unit has a V2.0 interface at the local end, which implies that it also has some buffering built into it. The Belkin extender comes with a built-in 15 foot (4.5m) cable, whereas the Tripp-Lite unit uses a standard Cat5 Ethernet cable with RJ-45 connectors. The Tripp-Lite extender claims to be capable of a 150 foot (45 m) extension, but I’ve never had a reason to verify that. Belkin claims that you can connect multiple extenders to achieve up to an 80 foot (24 m) extension.

If you can tolerate the relatively slow V1.1 interface at the remote end, then a low-cost extender might be something to consider. V1.1 extenders are typically used for things like printers but not video cameras. They will also work with an MCU that is capable of running at V1.1 speeds, and provided that the MCU isn’t dealing with fast events or shoveling a lot of output data it will probably work just fine. One point to keep in mind is power. An extender most likely will not supply a significant amount of current to a remote device, and with a long extension there could be a significant voltage drop. For this reason the remote unit should be used with a self-powered hub if the end device doesn’t have its own power, as shown in the diagram below (with something like a printer this usually isn’t an issue):

usb_extender

There are V1.1 extenders with greater than 30m range (like the Tripp-Lite unit) and V2.0 extenders are available that claim throughput rates of 150 Mbps or better, but the longer the extension or the higher the data rate the more you can expect to pay. The Tripp-Lite U224-1R4-R (shown above) sells for around $60. A 150 Mbps full V2.0 unit can be had for between $60 to $100 US (I found one on the MCM Electronics web site for $50), and units with full V2.0 data rates of 480 Mbps start at around $250 and go up from there. There are also cheap items that claim to be V2.0 compliant but really aren’t. In fact, some so-called extenders are nothing more than a long cable with some passive components in the connector housings at each end. With others, only the local end is V2.0 and the remote end is still V1.1, although it claims to be V2.0 capable. Both the Belkin and the Tripp-Lite extenders are up-front about the remote end, but some vendors aren’t quite as honest about the limitations. If you’re curious, the Tripp-Lite costs about the same as the unit from MCM because the U224-1R4-R also has additional type A connectors at the local end–in other words, it’s a hub as well as an extender transceiver. The MCM unit only handles a single point-to-point connection.

USB Meets the Real World

So, we’ve looked at USB networks and USB extenders, but what of the devices at the ends of the network? What can we use to actually do something useful? There are, of course, the usual USB devices: printers, keyboards, mice, numeric keypads, and so on, but these aren’t particularly useful for interacting with the real world. What we need are devices that can sense voltages, current, temperature, humidity, and switch closures, and perhaps also activate relays or control indicator lights (or an alarm klaxon).

For microcontroller development systems USB is probably the method most often chosen for communications with a host system. After all, an Ardunio comes with USB built-in, and something like the Atmel ATmega32U4 or the Cypress CY7C680xx series MCUs are designed with built-in USB as the primary communications method. You can easily add USB to just about anything that has a UART in it using something like the FTDI or CH340 serial-to-USB bridge chips. We could, in theory, turn any MCU board into a remote I/O module with a little time and effort.

However, there are also lots of commercial USB I/O devices readily available. A search on Google for “USB I/O module” will turn up a number of options to choose from. Companies such as Advantech, Measurement Computing, LabJack, MicroDAQ, OMEGA Engineering, and Sealevel Systems offer a variety of I/O modules with a USB interface. Prices ranges from $30 to around $500, depending on the device’s capabilities. Each of these devices has a built-in MCU, and they typically come with set-up and controller software of some sort (usually for Windows).

If you need to integrate a COTS (commerical-off-the-shelf) USB I/O module with custom software, then read the available documentation very closely. Some vendors, like OMEGA, make their product manuals available on-line, others don’t. In some cases all you are given is a utility to manually interact with the I/O module, and some drivers to integrate it with a high-end instrumentation platform like LabView. In other cases the vendor might make it easy to integrate their I/O module into a custom system, but don’t count on it. Ask questions, because the vendor might have a solution for custom designs that they don’t advertise on their web site.

As I implied above, an alternative to the COTS modules is to build your own using an MCU board like an Arduino. Firmata  is intended for this type of application. The protocol and software is available on GitHub, and the old wiki can be found at http://firmata.org/wiki/Main_Page. Firmata allows an Arduino to behave as if it is an extension of the host PC’s own I/O capabilities. Boards based on the Cypress CY7C68013A MCU or an ARM Cortex-M3 MCU are another alternative, but defining a communications protocol and creating the firmware is going to be up to you.

Other than the software development and testing effort, another downside to building your own distributed I/O is that you will need to integrate the MCU board with some kind of I/O protection and perhaps some relays and relay driver circuits, and then put it all into a suitable enclosure. You might also need to get U/L or CE approval. This is all going to take more time and cost more money. In the final analysis, it might be more cost-effective to just buy something off the shelf and put the effort into writing the primary control and monitor software to run on the host PC. As much as I like working with microcontrollers, I think I would opt for the COTS approach first if I had to implement a USB-based distributed I/O system. Only if the situation involved producing many I/O modules to absorb the initial development cost would it start to be feasible to consider a custom solution.

Summary

So, in summary, it is possible to build a distributed I/O system using USB. Is it an optimal solution? Well, that depends on the amount of unique I/O points in the system, the physical size, and how fast you need it to respond to commands or sense inputs. Is it a low-cost solution? Perhaps, and perhaps not, particularly after factoring in the cost of development time and any necessary support and utility software. There are also other ways to get there from here, including low-cost PLC (programmable logic controller) modules using RS-485 and the Modbus protocol. Ethernet is another option.

As with most engineering decisions it comes down to the trade-offs. The implementation costs, both direct and indirect, the necessary level of effort, physical limitations, and long-term supportability must all be considered. Never settle for the first solution that presents itself–always look at the alternatives.

Advertisements

1 Response to “Distributed Control and Sensing with USB”



  1. 1 A Box of C.H.I.P. SBC (and a DIP, too) | Crankycode Trackback on January 29, 2017 at 6:19 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s




Follow Crankycode on WordPress.com

Little Buddy

An awesome little friend

Jordi the Sheltie passed away in 2008 at the ripe old age of 14. He was the most awesome dog I've ever known.


%d bloggers like this: