BROWSE BY TECHNOLOGY



RTC SUPPLEMENTS


TECHNOLOGY CONNECTED

Wireless Device Connectivity

Embedding Wi-Fi—What’s Involved?

Wi-Fi as a technology has become widespread in the consumer market. Such maturity ensures that companies in the embedded market can jump on board with little risk. But what is involved and how does one choose the right solution?

AMIR FRIEDMAN, CONNECT ONE

  • Page 1 of 1
    Bookmark and Share

Article Media

Wi-Fi has changed the way we communicate and access information. According to the Wi-Fi Alliance, about 200 million households use Wi-Fi networks, and there are about 750,000 Wi-Fi hotspots worldwide. Wi-Fi is used by over 700 million people and there are about 800 million new Wi-Fi devices every year.

The fact that Wi-Fi evolved in the consumer/PC market has a big effect on how it is adopted into the embedded market. We all know that PCs and embedded devices differ in resources such as processing capability, memory capacity, energy requirements, operating systems and costs. Because of this, moving a technology from the PC world to the embedded world is usually not a smooth and easy process.

Typically, due to the complexity of designing and deploying RF applications, the embedded market has struggled implementing wireless technologies, and Wi-Fi is no different. Making it easy to embed Wi-Fi into small, low cost and resource-constrained devices is the task at hand for those supplying Wi-Fi solutions for embedded devices. There are a number of decision points in the process.

Wi-Fi as an M2M Technology

Machine-to-machine (M2M) communication has been mostly associated with cellular connectivity. In fact, if you look for an M2M market study, you will find studies discussing cellular modules that are embedded inside devices. However, M2M is much broader and encompasses many wired and wireless communication technologies such as Ethernet, serial, PLC, Zigbee, Wi-Fi, cellular and more. M2M means connecting machines regardless of the communication medium.

Wireless technology usually implies portable or mobile applications—if something is on the move, it can’t be tied down with wires. Having no wires also implies not having to run new wires to stationary applications, which in turn means stationary installations become easier and less costly to set up and maintain.

Wi-Fi, or wireless LAN, is exactly that—LAN over the air. Wired Ethernet applications can be converted to Wi-Fi fairly easily, thereby reducing the installation cost of new Ethernet wires. Combine the efficiencies of using Wi-Fi together with its widespread existing infrastructure, and you come up with a technology that brings much value at a reasonable cost.

Which Wi-Fi Standard to Choose?

Like other technologies, Wi-Fi standards such as the IEEE 802.11 family of protocols have evolved over the years (Table 1).

Table 1
Wi-Fi technology has evolved over the years, gaining in speed and range.

Standards 802.11a and 802.11b are the older versions and they are not compatible with each other—802.11a devices operate in the 5 GHz band while 802.11b devices operate in the 2.4 GHz band. The most recent release of the standard 802.11n is backward compatible to the 802.11b and 802.11g versions—all three encompass operations in the 2.4 GHz band, while 802.11n can also operate in the 5 GHz band in the case that all devices on the network are 802.11n compatible.

802.11n is based on a multiple input, multiple output (MIMO) architecture with more than one antenna, enabling devices to increase data rates due to more than one transmission/reception path. Mixing standards will cause most access points to reduce speed to the older standard connected to it.

Those are dry facts regarding the standards, but there are other issues to consider. Most embedded applications do not need the high rates provided by the newer standards. But does that mean that product designers should stick with the older standard because it’s enough for their needs?  

Not necessarily. Here is where real life comes in regarding availability of components. Because the PC and smartphone markets are driving the usage of Wi-Fi baseband chips, it is likely that many older standard chips will go end-of-life since there is not enough demand for them. Because the embedded market usually lags the consumer market by a few years, the challenge of retaining a supply of Wi-Fi chips is not an easy one. Wi-Fi baseband chip manufacturers leave behind old standards and move to the new standards, and designers find that after they have invested many months of non-recurring engineering time into designing a specific baseband chip into their product, they have to start over a year later.

Some older baseband chips are more popular than others, however, and have been adopted in enough designs to make it worthwhile for the chip manufacturer to continue producing them. An example of such an older, but resilient, baseband chip is the 88W8686 b/g chip from Marvell. This baseband chip is being packaged by several system-on-a-chip (SoC) companies and sold into many Wi-Fi designs.

So, since the n, g and b versions of 802.11 are backward compatible, the lesson to be learned regarding what standard to choose is not so much that you need to choose the newer, faster standard, but a chip that you will be able to source for a long time.

SoC vs. Module

The next decision to consider is whether to design in a chip-level solution or a module solution (Figure 1). In general, choosing a module solution over a SoC solution reduces the risk that the Wi-Fi baseband chip will become unavailable, at least as long as the module manufacturer stays with the same module footprint when moving from one Wi-Fi standard to the next.

Figure 1
With a Wi-Fi SoC solution you need to implement drivers in your application and rely on the continued supply from your SoC vendor.

An SoC solution requires drivers, which are usually available from the manufacturers of the baseband chips for Linux or Windows (again, PC-centric). If you are designing an embedded Linux product, then this solution may work out well if you have experience in certifying Wi-Fi designs for FCC/CE/etc.

If you are OK with certifying your own product but do not want the hassle involved with the drivers, you can choose a Wi-Fi/IP controller and design it between your host CPU and the Wi-Fi SoC. More about the Wi-Fi/IP controller will follow.

If the cost and challenge of certification is prohibitive, you can opt for the next level up, an SoC that has been designed onto a small, already-certified module (Figure 2).

Figure 2
For Linux developers, a certified SoC with antennas on board or external provides a good choice.

If you are not running Linux but some real-time smaller O/S, you can opt for a full-module solution where all protocols, security and management functions are already on the module, in addition to it being fully certified (Figure 3). These types of modules can Wi-Fi-enable any CPU/OS design.

Figure 3
Developers using compact, embedded RTOS solutions can cut time-to-market even further by choosing a module that includes the latest connectivity protocols, security and management functions.

Of course, as you move up the integration chain, the solutions become more expensive, while time-to-market and reduced development costs can quickly justify the increased cost of an integrated solution. In general, and depending on quantities and functionality, SoCs range from $5 to $15; certified small SoC modules range from $10 to $25, and full modules from $20 to $40. Wi-Fi/IP controllers cost from $5 to $10. Certification (FCC/CE) at a certified lab can run about $20,000 per design, depending on what actual testing is required.

Some full module manufacturers will use the same form factor for their “b/g” offering as their “n” offering, which will not require a redesign of the product they fit into. In addition, product designers looking to connect their products to either LAN or Wi-Fi can choose a module form factor that enables them to swap a LAN module and a Wi-Fi module in the same design.

Choosing a full module solution reduces the risk, cost and time associated with embedding Wi-Fi into a product, but it does come with a higher price tag. Ultimately, product designers need to weigh their options and choose the best solution for their situation.

Internal or External Antenna

Designing antennas into products requires careful analysis of the product and its use. Products using plastic enclosures can usually use internal antennas, while metal enclosures usually require external antennas to allow the RF signal to propagate freely. Most Wi-Fi modules are available in onboard antenna and external antenna versions. The external antenna versions come with a small RF connector on the module, where a pigtail cable can be connected to an external antenna that’s mounted on the outside of the product.

Depending on antenna gain, most internal antenna designs will have less Wi-Fi range than external antenna designs—usually 20 to 50% less range. Wi-Fi range for external antennas is usually 100 to 200m, depending on obstructions like walls.

Depending on product requirements and use, the Wi-Fi solution may need to operate in client or access point mode. Client mode is the most common mode whereby the product connects to Wi-Fi access points in order to send/receive data on the network—similar to the way a computer connects to the network via Wi-Fi. An example would be an energy meter sending data to a remote server on the Internet via the local Wi-Fi network.

In access point mode, the product becomes an access point and allows other Wi-Fi clients to connect to it. An example would be a medical device that enables an iPhone/iPad/Android device to connect to it to view patient information without another Wi-Fi access point nearby. Not all Wi-Fi solutions support both modes of operation—most support just client mode.

Wi-Fi/IP Controller

So far we have discussed embedding Wi-Fi as basically embedding the Wi-Fi baseband/RF/antenna, and the options to doing this. However, a communication solution does not end with just the Wi-Fi part. The use of a dedicated Wi-Fi/IP controller solution provides an immediate, cost-effective and highly secure solution. It allows designers to focus on their companies’ core competencies while offloading all communications and security tasks to an external field-proven controller (Figure 4).

The Wi-Fi/IP controller first serves as a controller for the Wi-Fi baseband chip. It contains the necessary drivers, stacks and application software to operate the Wi-Fi chip in all its modes of operation. Working with Wi-Fi becomes seamless to the Host CPU.

The Wi-Fi/IP controller also serves as a hardware “firewall-on-a-chip,” shielding the application from malicious attacks originating from the Internet, similar to the way a firewall resides at the edge of a network to protect the network from the Internet.

The controller also contains the TCP/IP stack and protocols such as HTTP, FTP, SMTP, DHCP, etc., so that the application residing in the host CPU need only send simple commands to the controller in order to invoke these high level protocols. SSL3 is also implemented by the Wi-Fi/IP controller, encrypting the data to/from the device from end to end.

Management is a key component of deploying devices, so the Wi-Fi/IP controller contains secure built-in web servers that can manage the operation of the device remotely over the network using a standard browser.

Other Considerations

People often confuse the security of the Wi-Fi RF medium with the end-to-end security of the connection between the device and a remotely located device/server on the Internet. WEP, WPA and WPA2 are security protocols for the Wi-Fi RF medium—they are in play only between the device and the local Wi-Fi access point it connects to. From the local Wi-Fi access point and onto the Internet, the data sent/received is not secure unless a higher level security protocol like SSL3 is employed to encrypt the data end-to-end.

Since encryption protocols are resource intensive, the Wi-Fi/IP controller offloads this task from the host CPU, and with little effort, the host CPU can open a secure end-to-end connection.

The ability to deploy devices in the field and maintain them is an important issue to consider during the design phase. An internal web server is a good method for managing devices over the network. By building a small web site inside the device, installation and maintenance can be performed using a standard browser over the network. To manage a device remotely, look for a Wi-Fi solution that provides tools to embed such a small web server inside the product.

One of the more useful functions provided by a Wi-Fi/IP controller for applications that are deployed where there is no Wi-Fi/Internet infrastructure is Wi-Fi to cellular routing. The Wi-Fi/IP controller on one side is connected to the Wi-Fi baseband chip, and on the other side to a cellular 2G/3G/4G cellular modem.

This is a standalone operation that enables designers to embed 3G router functionality inside their products. With this 3G router functionality, product designers can provide Internet connectivity for their products and others via a cellular connection without the need for someone else’s Internet connection.

A recent customer example came from a Laundromat where dozens of washing machines and dryers are wirelessly connected to a dedicated and customized embedded 3G router. The application sent operation, payment and maintenance information on an ongoing basis to a remote management location, bringing all of the accounting detail and maintenance information together and decreasing the need for an onsite person.

The benefits of Wi-Fi-enabled products are enormous, but only when the design is executed properly. So, when marketing tells you, “Customers want Wi-Fi…,” make sure you ask all the right questions about the customer’s product requirements before starting your design. These include determining the proper speed and Wi-Fi range and the enclosure characteristics such as size constraints and whether it will be plastic or metal. Will the product be sold and if so, what certifications will be required and for what countries? What is the targeted life of the product?

If the time-to-market is tight, you need to consider full module vs. SoC integration. This also reflects cost constraints determining if a full module solution is affordable. How will the product connect to the Internet? Where is it to be used or will you need to provide your own network as in a 3G router solution?

With answers to these questions, analyze the design cost/risk associated with your design choices—SoC being the lowest cost, but higher risk—full module being the higher cost, but lowest risk. Based on the considerations discussed above, in the context of the application, you can easily arrive at a solution that will give you the best solution at a price point that fits your market.  

Connect One
San Jose, CA.
(408) 572-5675
www.connectone.com