Make smart smarter

To paraphrase Mark Twain, the rumours of the demise of serial ports are greatly exaggerated. Serial ports are everywhere, in everything from industrial automation systems to scientific instrumentation. Too many people have too much invested in serial-equipped devices for the standard to disappear any time soon. But as data communications technology continues to evolve, the humble serial port is sometimes left behind. This article reviews serial device server technology, its usefulness and drawbacks, and demonstrates how to access serial data from locations that are either remote or restricted and therefore out of range of a WiFi network.



Back when the first serial device servers were introduced they closed a connectivity gap between connected devices and remote networked PCs. The development of the serial-to-Ethernet device server in the late 90’s was another huge step forward. Later, the advent of USB made accessing serial data from desktops and laptop PCs easier than ever.



But as tablets and smart phones become more ubiquitous in the corporate and M2M business world, connecting to serial ports has become a bit more complicated. Tablets and smart phones don’t have serial ports. In fact they tend to have limited wired connectivity of any kind, largely relying upon wireless communications for their interaction with the rest of the world. They’re wonderful devices, but they’re not natively designed to interact with serial equipment.



How does it work now?

Serial device servers can be wired or wireless. The most popular types are network or TCP/IP device servers. In either case — wired or wireless — the serial server translates the serial data into an Internet Protocol (IP) format that can be transmitted across a network.



Wired serial device servers use Ethernet cable to connect to the local area network. Wireless device servers contain a WiFi client similar to the one in your laptop and connect via WiFi, or 802.11. (The most common standards are 802.11b/g and 802.11b/g/n.) Wireless servers can connect to either an infrastructure network or to an AdHoc network.



When the Serial Device Server network interface is connected to a LAN it provides an IP address that all other network devices can use for sending and receiving information. This address is unique to the SDS. Since this address is the location for all interactions, a secondary reference is used to locate the information or resource required for the specific interaction. This is called a port number.



Using the combination of IP address and port number it is possible to uniquely locate any serial port on the network. It works like this: a serial device server has a physical serial port connected to port 8023 on the network interface. The network interface connects to the network and gets an IP address of 192.168.2.100. After combining the two pieces of information the full address of the serial port would be 192.168.2.100:8023. Any network-connected device capable of accessing that address can receive data from — or send data to — the serial port (Figure 1).



##IMAGE_2_C##

The venerable serial port can still be part of modern networks



So what’s the problem?

Current network SDS devices are designed to be used with an existing network infrastructure. If you have a manufacturing facility, warehouse or office, odds are that you already have a network installed, wired, wireless or both. Connecting to these networks has become much easier with the latest versions of SDS technology (Figure 2).



##IMAGE_3_C##

A wireless network uses Access Points to connect a variety of computers and equipment, allowing them to share resources and information. Referred to as Wireless Local Area Networks they use the Internet Protocol Suite for data communication between computers, networks and devices.



But what happens when you want to talk to a device that isn’t covered by an existing wireless network? A large portion of the desired serial data may come from remote locations that are out of the coverage range of the corporate WiFi network, or in an area where access to the available network is restricted because of IT policy and security rules. How can users access the data from these devices?



Historically, a wireless network type called AdHoc has been used where no available infrastructure network exists (Figure 3).



##IMAGE_4_C##

An AdHoc network is a peer-to-peer based network that does not use a central resource (Access Point) to manage the network connections and structure. AdHoc networks can be established when just two clients are within range of each other, with each group of devices being referred to as a cell. They use the Internet Protocol Suite for data communication between the devices in the AdHoc network.



AdHoc, however, has certain issues. Static IP addresses are needed; a service called DHCP, often used on large networks to provide IP addresses to the devices connected to the network, is not usually available on an AdHoc network. This has several drawbacks:



-It requires manual assignment and distribution of unique addresses to devices;

-It creates a static subnet for the network and for all devices on the AdHoc network. This restricts interaction between different networks;

-It requires manual configuration of IT (laptop) equipment when connecting to the AdHoc network, as personnel are required to enter a static IP address;

-AdHoc networks are not self healing. Even if you have multiple AdHoc networks within the same geographical location, and they are utilising the same network name, devices in one network cannot talk to devices in the other. This can therefore limit or prevent access to serial data.



There’s an additional issue with AdHoc networks. The latest Android tablets and smart phones don’t connect to them without advanced modification of the devices. There are also known issues with certain iOS devices that make it impossible to use them with AdHoc networks that employ wireless SDSs, which forces users to carry bulky laptops for remote access.



How about an embedded hotspot?

There is emerging technology that supports embedded Access Point functionality without changing the SDS functionality. As an example, B&B Electronics’ SDS technology features an embedded AP device (Figure 4) that creates a small, self-sustaining WiFi network around the remote equipment that isn’t all that different from the hotspot in a coffee shop. As your technician comes into range of the network, his WiFi tablet or smart phone sees the network, connects to it and receives an IP address from the embedded AP. His device can then access the serial port on the AP using the appropriate IP address and port number. It doesn’t change the way the SDS devices are used, it just makes them easily accessible to tablets and phones.



##IMAGE_5_C##

Embedded wireless module from B&B Electronics



Benefits of embedded AP:

-Tablets and smart phones will be able to access serial data in addition to existing network devices like laptops;

-Network devices won’t need reconfiguring to use static IP addresses;

-A self-maintaining network won’t lose devices or compromise their access;

-Users can simultaneously add and access wireless and wired devices on the embedded hotspot;

-There is no change to the existing use paradigm of networked serial device servers.



The example B&B device can support up to two serial devices, an Ethernet 10/100 network and multiple wireless clients simultaneously. It provides WPA/WPA2 security and an embedded DHCP server. Both external box and embedded module versions are available.



Serial ports have been around for a long time, and they represent an earlier generation in communications engineering. But that doesn’t mean that tablets and smart phones shouldn’t talk to them. They still have a lot of information to share.





Author profile: Andrew C. Ross is Director of Wireless Applications for B&B Electronics.