Pick the right wireless sensor/controller for your connected MCU-based design - Embedded.com

Pick the right wireless sensor/controller for your connected MCU-based design

A plethora of competing wireless technologies are sprouting all around us. But even before you take the first steps to implementing one of them into your design you need to ask yourself: How can we introduce this into our products at low cost? What benefits are there for the users of the products we design? The range of benefits are significant:

* Wireline connections for sensors can be eliminated simplifying analysis, production and control systems.

* Universal remote control devices like tablets and phones can be supported at low cost.

* Lower cost installation is achieved through the elimination of wiring for control signals.

* Lower cost maintenance results from elimination of troublesome wireline connections and the need to move wires from time to time.

* Significantly more data can be captured and retained.

* Enabling new types of analysis based on the new or integrated data leads directly to improved management decision making.

* Simple connectivity of a broad range of devices using a variety of alternate wireless technologies can be easily achieved.

MCU and MPU Design Pitfalls
Because there are so many competing technologies you have to factor in several things as you make your assessment. First, as a designer, you must choose wisely to avoid obsolescence. Ultimately, the technologies will be standards driven but experience tells us that different standards will dominate different application areas and that competing standards may evolve in parallel for long periods of time. Defacto standards can also be successful for narrow applications if pushed by the dominate player in that segment.

Click on image to enlarge.

Figure 1: This shows the various competing technologies and their various data rates along with some measure of range. The GPRS 2G, 3G and 4G are shown in terms of their distance and power from the tower, as all options can be back hauled through a wireline network. This provides a direct technology comparison. The difference is that GPRS comes complete with the back haul system while other wireless choices do not necessarily have this .

Tradeoffs between power, range and data rate are critical. Figure 1 above shows the various competing technologies and their various data rates and ranges. Figure 2 below shows the required power for the various technologies. When the application is analyzed, be sure to leave margins in the system that you choose (in data rate, power and range) for future expansion.

Click on image to enlarge.

Figure 2: This figure shows the combination of data rates and ranges by technology along with battery requirements for prolonged use. It is expected that GPRS options require much greater much more power which is reflected in their much greater range.

The cost of using a particular technology may be an issue. While a GPRS connection carries a cost based on traffic or time, a wireline internet connection may not. Be sure to choose a technology that fits your application in terms of the business model for the system.

Different protocols offer different capabilities. Consider various options for radios conforming to IEEE 802.15.4 and how the selection of the protocol stack can influence the overall system. The protocol options are:

* 6loWPAN
* TI SimpliciTI
* Microchip MIWI
* Zigbee

The 6loWPAN/IPv6 solution offers adhoc network configuration and the best long term prospects while SimpliciTI and MiWi are fully operational today but proprietary. Zigbee has a large following and specialized subsets have been completed for specific applications. Only time will tell which protocol dominates for a given application; however, by understanding the needs of users for your particular application, a wise protocol selection is possible.

All these protocols can do the job for most applications but which protocol will dominate for which specific application? 6loWPAN will become the most widely used with IPv6 compatibility and lower cost. The other protocols will be around for many years and may dominate specific applications or segments.

A further protocol consideration is making sure that you have the right end of the protocol selected. Often protocols come in separate client and server versions: for example a web browser (http requests) and a web server (http responses). This may seem like an obvious observation, but with the myriad of protocols in use it is difficult to keep all the aspects of all protocols in a coherent picture and it should always be double checked.

If you consider a wireless web server design, what would the best underlying transport protocol be? Clearly, IP is required for a web service; however, the wireless connection could be provided by Bluetooth, WiFi or 6loWPAN with an 802.15.4 radio. A simple application of the second rule shows that data rate would be poor with 802.15.4 and that WiFi would provide the best data rate. In comparison Bluetooth offers lower power consumption with good bandwidth. The decision gets more complex though because the radio module becomes important as a part of the design decision.

Most designers choose to include a wireless module in their design. This eliminates the need for telecommunications certifications and also eliminates the need for antenna design in most cases. Unless volumes exceed 50K units, this is generally the lowest cost approach. Given that most designers will use a module, certain restrictions exist depending on the module selection that limit flexibility, increase module costs and may lead to unexpected development costs. Again, careful attention to the protocols and the application are required.

Migrating your wireless protocol implementation onto wireless chips and modules you lock your application to the vendor’s module or chip. The perception is that implementation time and cost will be reduced because the protocol implementation is already done; however, this is often not the case in the longer term. The apparent short term benefit often turns into a medium or longer term limitation, or worse still, a near term system limitation that can endanger the entire design.

WiFi Modules
WiFi modules come in two fundamental architectures. One architecture assumes an MPU with large memory space and a Linux or Windows like operating system with the OS providing many of the features required. The second architecture choice assumes an embedded design with most functionality provided on the module. This later approach is much more suitable for MCUs due to the limitations of performance and security.

Depending on the MCU and operating system, both architectures can be used for embedded designs. The key factors which influence this choice are:

* Required performance (better with more services on the host processor)

* Available memory space (more features on the host processor take more memory)

* Operating system driver availability

If moderate performance is required then the fully embedded solution is lower risk and easier to implement.

WiFi modules often have an on board TCP/UDP stack and may include other higher level application protocols. This may or may not be useful depending on the required features and the implementation of the remainder of the system.

By using these on board protocols the design of the system is less flexible. Requirements for routing are a good example of the limitations of on board TCP/UDP capabilities. It also requires a special driver to provide access to the functions which is module specific and therefore requires extra integration.

Higher performance WiFi modules do not include the protocol stack on the module. These modules have support for lower level WiFi functions and provide an interface to integrate a new network driver into an existing TCP/UDP/IP stack on the host MCU or MPU.

The major additional requirement on the MCU or MPU is an 802.1X supplicant along with some additional configuration routines. This approach offers the best flexibility and integration with the cost of some extra Flash space. Performance and features are far superior to embedded modules.

Bluetooth modules
If your requirement is for a serial profile then the protocol support for a Bluetooth or Bluetooth LE module may be sufficient. One of the significant limitations of Bluetooth modules is the lack of on board profiles. If you are outside the very basic profiles you need to use the HCI interface and add an external Bluetooth stack.

For the on board profiles, interfaces may be less than optimal. They have the same integration issues that WiFi modules have. Vendors offer interface software but this still must be integrated into the MCU and/or MPU environment to provide an integrated environment.

UHF and Proprietary Radios
These modules come without protocols or with proprietary protocols. Although proprietary radios may be a good choice, proprietary protocols can create long term support and maintenance issues.

GPS Modules
GPS modules are generally easy to use and easily integrated. Often these features are included in other modules today, typically GPRS modules.

GSM/GPRS modules may have network specific requirements built in at the protocol level. Implementation using TCP/UDP is required and PPP or SLIP support is mandatory. A separate network server is required for internet connectivity to provide the other end of the serial line and depending on the vendor the integration might not be easy.

Implementation of a TCP/UDP stack with GPRS is a good example of why on board TCP is inflexible. In this case, the TCP stack requires a second network driver to talk to the rest of the system that the GPRS supports. This second driver can’t run on the GPRS module and must run on the external MCU or MPU.

802.15.4 Alternatives
A variety of protocols can be chosen, but some are very complex and others are evolving. The most common options were discussed above with 6loWPAN the leading candidate in the long term.

For the most part, these radios come without protocols on a single chip rather than in a module because they are unregulated in the ISM band and do not require rigorous certification. Some chips come with on board modules and although simpler from a hardware point of view offer limitations if the protocol stack does not have all the required features because flexibility is much lower.

How to get started on your design
With the broad range of choices outlined so far it is no small wonder that designs are confused. Here are some simple rules to get started:

1. Know the data rate, power and range. This will immediately limit the choices.

2. Choose a business model for wireless service that fits the application.

3. Have a specific set of requirements once the technology choices are narrowed and try for industry standards if possible. This will determine the type of protocols that will be needed and keep you in the mainstream of implementation which will reduce costs and increase flexibility.

4. Target multiple module vendors to create choices, reduce costs and reduce risks for moderate volume applications.

5. For high volume applications, prototype with modules and move to a custom implementation.

6. On the MCU or MPU, select an operating system with support for the type of wireless you require. For example, if using a WiFi high performance module on an MCU, make sure that the OS has support for this type of module.

Kim Rowe is the founder of RoweBots Research Inc., the manufacturer of the Unison OS. which offers a complete set of wireless support for a broad set of applications, chips and modules – WiFi, Bluetooth and Bluetooth LE, 6loWPAN, SimpliciTI, MiWi, Zigbee, GPS, GPRS/GSM and proprietary radios – all of which are integrated with the Unison TCP/UDP/IPv4/IPv6 protocol stacks, BSD sockets interfaces and other serial line disciplines as required. Bluetooth profiles, drivers for specific chips, custom protocol support and other more custom offerings are available on demand.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.