Many companies who develop and sell specialized electronics have realized the benefits of adding network connectivity to their products. It can, however, be a daunting task for an engineering group that specializes in some other facet of the industry (medical, security, building automation, industrial, etc.) to build and design wired 802.3 or wireless 802.11 networking into their end device. In addition to time-to-market concerns, stability, robustness, RFC compliance, agency certifications, support and other challenges, can become overwhelming.
To help mitigate the risk and headaches for designers, complete off-the-shelf communication modules are widely available. Such solutions support a wide variety of topologies including 802.3, 802.11, Zigbee and cellular and typically provide all the essential networking components in one, easy-to-implement solution. From a hardware standpoint, they are generally very easy to integrate and contain rich firmware functionality. Some vendors also supply deployment and management software which further reduces the effort on the part of the original equipment manufacturer (OEM).
As time-to-market is one of the biggest challenges for an OEM, off-the-shelf technology can significantly decrease design time by up to 18 months. On the other side of the coin, the cost per unit is higher and the module will likely be sole sourced. While such solutions are essentially plug-and-play, it is important for designers to consider a number of hardware and software topics.
Hardware Considerations
Most vendors make it extremely easy to integrate an embedded networking module (see figure 1) and generally leverage the ubiquitous RS232 interface or a logic level version of the same. This allows the hardware engineer to simply hook up the main processor’s serial port’s receive and transmit lines for communications. An OEM may also find it desirable to hook up the serial handshaking lines (RTS and CTS); however this will depend on the performance and the type of application. Some modules may be able to handle data (with no loss) at 230kbps without handshake lines while others may drop characters at anything above 9600bps.
|
Figure 1
|
Some modules also support digital input/output (IO) lines. These can be used to sample digital inputs remotely over the network or to activate digital outputs via the network.
In regards to the printed circuit board (PCB) layout, some module vendors recommend layout configurations which are good to follow whenever possible. It is important to note, the reference layout was most likely used to validate conducted and radiated emissions. By mimicking the vendor’s layout, the designer can be more confident they will pass agency testing on their end device.
Vendors also make deploying various network types easier with modules that leverage a common footprint. With these solutions, designers can create a single layout, supporting a variety of modules that can vary in topology, processing power and wireless standards. Such pin and form-factor compatible modules may be ideal for designers who have the flexibility to connect either wired or wirelessly.
Another benefit to off-the-shelf solutions is module certifications and approvals. Some module vendors have already garnered industry approvals on their modules, which the designer can leverage to gain approval on their end device. This can save the designer tens of thousands of dollars and months in testing if leveraged. The U.S. (FCC), Canada (IC) and Japan all allow OEMs to leverage a vendor’s module approval as long as certain rules are followed. For wireless implementation, these include some limitation on the type and gain of the antenna, and the distance between the antenna and the operator. Being cognizant of these rules can save the designer money and time.
Another hardware consideration is power. Make sure to consider the amount of power the module requires including the nominal and peak requirements. A typical 802.3 wired Ethernet device may consume 200mA nominally at 3.3 volts. A wireless 802.11 module may require close to 400mA at 3.3 volts.
|
Firmware
Most modules have a very rich set of functionality that makes it easy to network enable products (see figure 2). Some networking companies have invested decades of person-years in their firmware adding advanced functionality, RFC compliance, and bullet-proof reliability. These labor intensive areas of development are done for you – another benefit of an off-the-shelf solution. They generally all offer a way to virtualize an asynchronous serial stream across the network. Some may have built in web servers that allow the data from the attached product to be viewed on a web page or received via an RSS (Real Simple Syndication) feed. These technologies allow end users to manage attached equipment from any familiar web browser. With RSS, not only can users monitor attached devices in real-time, hundreds of devices can be simultaneously monitored from one single RSS-enabled web page or from a user’s client email. This provides end users with additional flexibility to manage and monitor its equipment anywhere at anytime. While modules make things much easier than rolling it all yourself, there are some specifics to consider, including:
Packing the data
An area that can be a challenge when introducing networking to a product is data packing. Existing protocols designed for asynchronous serial communications (i.e. RS232) may have problems when virtualized over an Ethernet network. Data fragmentation, network delays, and other challenges related to the non-deterministic nature of Ethernet can be frustrating. A well-implemented module will provide the designer with several options to mitigate these problems. These include:
Send characters – The existing protocol may have a very specific end of transmission character, carriage return (CR), line feed (LF), or end of transmission (EOT) for example. The ability to instruct the communications module to wait until these characters are observed in the data stream until sending the payload across the network, can spell the difference between success and failure of network enabling a product.
Case in point, a customer was using software handshaking to pace the data on the serial line. They used the communications module to virtualize the serial connection to a remote host. They needed the ‘stop’ character (control S in this case) from their equipment to get back to the host in a timely fashion so that the host would stop sending data. Due to packing delays and network latency, at times the host would not get the stop character in time and overrun the incoming buffer. By specifying the ‘stop’ character as the send character, the problem was rectified. As soon as the module saw this character in the data stream, it would immediately send the packet containing it to the host rather than continuing to build a packet of a certain size or after a certain amount of time had elapsed.
Time based packing – It is helpful to have the option to adjust how long the module builds up data into a network packet. hile this functionality is often used to optimize network utilization, it can also prove valuable in tailoring the module to a particular protocol.
Custom packing – Some modules are protocol-aware. They understand the make up of a data stream and pack the data into TCP packets appropriately. A good example of this is the industrial automation protocol, Modbus RTU. Trying to simply tunnel this protocol across a network can be frustrating. Utilizing a module that understands a specific protocol and can convert it automatically to something more suitable for networking (like Modbus/TCP) is a valuable feature.
It is important to spend time analyzing your protocol and make sure it is network-ready or that the communications module you select can be tailored to fit its requirements/needs.
Who’s going to call who?
Think about your application. If you are converting a serial-based application over to the Internet, it may be obvious which side is the host and which is the device (or slave). Other applications may be less well defined as the serial line was always open between the two connected devices. When networking with TCP (transmission control protocol), one side of the transaction will need to setup the connection. The other side must be ready to accept the connection. Many networking modules have a variety of methods to accomplish this. For example, if the networking module is to initiate the TCP connection, it can be configured to do so when it sees a character (any or specific) on the serial line, when DTR (data terminal ready – a control line) goes active or on power up of the module. If the communications module is the listener, it can be setup to always accept incoming connections on a given port number or only accept them if DTR is active.
Some modules also allow legacy “AT” style modem commands to be sent to initiate a connection. For example the embedded system can send the following text via the serial connection to the module: “ATDT172.19.1.3, 10001”. This will initiate a TCP connection to the host at Internet Protocol (IP) address 172.19.1.3 on port number 10001. This is great if your existing embedded firmware is already programmed to talk to modems. Finding a solution with this feature can save a lot of development effort.
TCP versus UDP (User Datagram Protocol) – Most modules allow you to select between TCP and UDP network protocols. An in-depth study is out of scope but both have their place. If, for instance, you are sending temporal data on a regular basis where any given piece of data is not mission critical, UDP may be perfect as it is fast and easy. An example would be a water tower monitor that sends out water level information every 30 seconds. If a UDP datagram (packet of information) gets lost, no problem. A medical application may not tolerate such tenuous transmission and would call for TCP. TCP is slower, requires more housekeeping, but is reliable.
While wired and wireless networking modules offer many benefits, time-to-market is always of the essence. Off-the-shelf solutions typically provide essentially everything designers need to get their end device up on the network quickly and easily, and can save both time and money. Regardless of your application, it is important to understand the different parameters of networking and the different features available. It is important to carefully review your networking needs along with the specifics of your product design as this will make module selection easier.
