Here are the major problems faced by developers when working with AT-based modules, and how ATCommander helps to solve them.

Problems / solutions

Controlling a module with AT commands

To communicate with GSM/GPS modules provided by manufacturers like SIMCom or u-blox, we must send AT commands, we can't simply burn a C program or firmware to it, instead, you must have a external hardware sending AT command to control them via a serial interface.

The AT command set is huge and every manufacturer has its own set of AT commands for executing tasks, though some essential AT commands are the same between manufacturers. Also output of a given command might differ from manufacturer to manufacturer, and parsing the output is non trivial.

Creating an AT controller program requires deep understanding of the AT command set provided by the manufacturer, something normally found in on-line PDF/datasheet.

When you are testing modules of different manufacturers, consulting every datasheet can be very time consuming. Sometimes proper documentation of an AT command is not even available, and yet, documentation is always something hard for reading.

Solution:

Connect the module to your computer (via USB), fire up ATCommander, open the corresponding COM port, and quickly start sending AT commands with a user-friendly UI based around buttons and input elements.

In ATCommander you can select which manufacturer you are working with, and it takes care of sending the manufacturer specific AT commands.

Executing procedures

Producedure/tasks like HTTP requests, or TCP communication, requires the execution of specific sequence of AT commands, where again, one needs to consult every manufacturer docs for the proper sequence.

Also, you must always check every command output for errors, and you need to learn which AT commands need to be previously issued to prevent such errors.

Solution:

ATCommander offears many built-in procedures that let you execute HTTP/TCP/UDP request with the click of a button, properly cheking for errors, and showing to you the returned data from server.

State keeping

Working wih GSM modules reveals to be to quite challenging when you are faced with the need to ensure the correct state of the module before issuing requets.

For example, before making any GPRS request, you must ensure that the module is attached to GPRS network, and you should not reconnet to GPRS if you are already connect to GPRS (obviously, but not for your code).

Also working with cellular networks is something subject to disconnections, and your code must manually issue reconnections.

If your scenario requires to make multiple requests at the same time, a state-machine is a must.

Solution:

ATCommander keeps a internal state-machine with the status of the module, which is displayed in the Status tab.

This status is used accross the many requests you issue in the others tabs, which allows it to reuse on-going connections when possible (like GPRS attachment).

Conclusion

Developing for AT-based GSM/GPS modules is a big bottleneck for software development due to the many problems intrinsic to AT-based programming style and the many challenges when dealing with manufacturer specific command set.

With ATCommander you have a tool that aims to increase your productivity by solving such problems, leading to better time-to-market for your M2M/IoT products.