axm-lsrback2future-v2b

Time to Go Back to the Future? Modern Alternatives to AT Commands to Control Wi‑Fi Modules For IoT

Dave Burleton – Vice President, Marketing, LSR

Ready to Get “Smart”?

Converting traditional consumer and commercial products into wireless-enabled, “smart” products is one of the biggest trends shaping the pipeline of projects being assigned to electronic design engineers today—with very good reason. Regardless of whether your company makes toasters, home security systems or children’s toys, there is big money to be made in offering customers a wirelessly-enabled product line that has all the bells and whistles that come with smartphone controllability, real-time data and other “gee whiz” features.

This is leading to an avalanche of high-priority projects for electronic design engineers related to Internet of Things (IoT) capabilities. Regardless of whether it is labeled as IoT, M2M, “wirelessly-enabled” or just “smart,” these redesign projects are coming fast and furious at electronic design engineers in industries across the spectrum—all with aggressive timelines driven by companies’ desire to improve user experience, respond to customer needs and capture market share. It’s not simply a matter of “slapping an antenna” on the product and “getting one of those iPhone apps” to run it, however. It’s a lot more complicated. But there are some key ways that engineers can shorten the development cycle and also get an elegant final design.

Faster … and More Elegant

One key way to get your connected product design project across the finish line faster is to take advantage of an IoT Platform-as-a-Service (PaaS), which allows you to offload a significant amount of “work” that would ordinarily go into the product itself, placing it, instead, in the cloud with pre-built infrastructure and software. Taking advantage of an existing platform saves time, minimizes risks, reduces the drain on internal resources and gives the product itself far fewer moving parts in terms of its wireless connectivity.

Utilizing the cloud is a topic for another piece, though. This article focuses on another huge time saver and simplifier for your connected product project: evolving beyond the use of AT Command sets for addressing a number of key functions such as Wi-Fi control. Most product redesigns to add wireless connectivity will look to utilize a product’s existing microcontroller (MCU) as a host controller of the RF module to minimize the design efforts, rather than replacing the MCU and making the redesign much more complicated in the process. For many engineers, their comfort-level will nudge them towards an AT Command set approach to that serial communication.

AT Commands were created in a pre-Internet world…

AT Command sets were first utilized in the early 1980s as a creative solution to the challenge of transmitting commands between embedded systems and communications devices that act as a go-between with the world at large. AT Command sets have been popular ever since because they utilize very small data packets, allowing a lot of work to be done with very small batches of instructions and data. In the 1980s, that was really, really important, given the computing power and memory constraints and data processing capabilities that systems had at the time. Anyone who had a Commodore 64 or other early PC can attest to that. For that era, AT Commands were an elegant solution that worked around the miniscule memory and single serial ports that were the apex of technology at the time, allowing engineers to communicate sophisticated commands with very short ASCII strings. These strings started with the iconic two-character AT script that gives AT Commands their name.

More than 30 years later, AT Command sets still remain a common approach offered by RF module manufacturers to facilitate host control of their products. As a developer with a long history of utilizing AT commands, it may seem like the shortest putt because of your familiarity with that approach. However, to paraphrase a famous quote from the classic 1980’s movie mentioned in this article’s title, when it comes to IoT, “Where we’re going, we don’t need AT Commands.” Think of it this way: if the design problem is not just to get the data from the MCU to the Wi-Fi module but to get that data up to the cloud to enable a robust IoT design, newer innovative software can be leveraged that abstracts all the minutiae of facilitating Wi-Fi through AT Commands for the developer. Things have truly evolved, and it means a simpler and faster design implementation for your project team.

The Limitations of AT Commands

AT Commands are not an ideal approach for IoT projects because of the inherent limitations of traditional ASCII-based commands for supporting the communication of data to and from the device itself out to the cloud; where it can then be accessed and interacted with by users. AT Commands were created in a pre-Internet world, which means that designers need to do some clever things in order to write AT Commands in a way that successfully, reliably communicates data from the device to the web-based language that a Wi-Fi network uses; and on to the cloud where it can then be accessed anytime/anywhere by the user. Typically, a series of commands all executed in the exact proper order must be created to achieve even the most basic building blocks of Wi-Fi communications.

When an engineering team is working on a cloud-connected design project that brings together a wirelessly-enabled product…using JSON-RPC creates a common ground that the web and app developers on your staff will already be familiar with.

Yes, it can be done. But should it be? Is it worth the investment in time and brain power to figure out that puzzle? Or is there a way to bypass those ASCII-to-Wi-Fi hurdles so that there is a simpler, cleaner, more elegant solution for getting data out of the device and out to users? There is, and it results in a stronger, more flexible end product. That alternative is to use a human-readable, object-oriented approach to embedded code in an IoT design product, which is much better suited to the task of creating a product-to-the-cloud link.

axm-back2future-secondary-atsetcommand-v1

With a minimal increase in on-chip memory and packet size in the serial communications between MCU and RF module, a design team can utilize a much more modern and better-suited approach to creating the instructions and communication that is needed in a product enabled with Wi-Fi connectivity. By using a format such as JSON or XML, design teams can dramatically reduce the timeline for a project while also minimizing the programming headaches that come from traditional AT Commands. The key is that these more modern, object-based languages are compatible across each of the platforms that a connected product utilizes: the embedded technology inside the product itself, the cloud server that the product communicates with via Wi-Fi and the web/smartphone app that the end user utilizes to interface with the product.

A Better Way to Communicate from Host to RF Module… and Beyond

JSON-RPC (Remote Procedure Call) is an example of a human-readable solution that is well suited to IoT design projects, and the approach utilized in the TiWiConnect LIFT software solution that is part of the TiWiConnect™ IoT Platform. JSON-RPC is inherently an object-oriented approach to data communication. Rather than having one command per parameter, groups of related parameters are supplied to function calls. The result is a much simpler, cleaner and more intuitive interface for the developer. In addition to the benefits of human readability, JSON-RPC integrates seamlessly into existing server infrastructures and web services platforms. This provides crucial benefits for connected products with remote data sharing requirements, and it does so in a way that would be nearly impossible with traditional AT Commands.

There is another reason why this alternative to AT Commands makes sense, and it is not a trivial one. When an engineering team is working on a cloud-connected design project that brings together a wirelessly-enabled product, cloud servers and mobile apps into an integrated solution, using JSON-RPC creates a common ground that the web and app developers on your staff will already be familiar with. This is significant because not having that common ground can cause a project team to get bogged down when it comes time to create the mobile apps and web-based user interface. An alternative like JSON means everyone will be speaking the same language, literally, when that phase of the project arrives.

Every engineer I have ever worked with believes in the power of design elegance. Often times, the simplest design with the fewest moving parts and the least complexity ends up being the most effective, and the most reliable. At one time ASCII-based AT Commands were the most elegant solution to the design challenges of that day and they still are relevant for many tasks, but IoT projects have requirements that call for a software approach designed for today, not a relic from the past. AT Commands still have their place, but a human-readable, object-based strategy—especially one that utilizes the pre-built platforms that are available for design projects—will remove one of the major bottlenecks for your IoT project. Ready to go back to the future to find a better way to architect your host to RF module to Cloud communications?

For a deeper dive into alternatives to AT Commands for IoT product redesign projects utilizing the TiWiConnect platform, see this white paper co-authored by me and some of my colleagues at LSR and visit http://www.lsr.com/resource-center.


DOWNLOAD THIS ARTICLE (PDF, 653k)