Open the datasheet for almost any cellular module shipping in 2026 -- a Quectel LTE Cat-M radio, a SIMCom NB-IoT modem, an ESP32 running the stock AT firmware -- and you will find the same thing on page one: a table of commands, every one of them beginning with the letters AT. Type AT into a serial terminal, hit enter, and the module answers OK.
That handshake is older than the World Wide Web. It was designed in 1981, for a device that talked to a telephone line at 300 bits per second, and nobody has ever managed to replace it.
The problem Dennis Hayes had to solve
In 1981 Hayes Communications, founded by Dennis Hayes and Dale Heatherington, released the Smartmodem. Earlier modems were dumb peripherals: to place a call you physically dialled the phone yourself and dropped the handset into an acoustic coupler. The Smartmodem's selling point was in the name -- software on the computer could dial, answer, and hang up on its own.
That created an awkward engineering problem. The computer had exactly one serial link to the modem, and that link was already carrying data. How does the modem know whether the bytes arriving on it are meant to be sent down the phone line, or are instructions meant for the modem itself?
Hayes' answer was a mode switch plus a prefix. In command mode, every instruction begins with the two characters AT, short for "attention". ATDT5551234 dialled a number using tone dialling. ATH hung up. ATA answered an incoming call. Once a connection was up, the modem flipped into data mode and passed bytes straight through -- and a carefully timed +++ escape sequence, guarded by a pause on either side so it could not be triggered by ordinary data, brought it back to command mode.
The AT prefix did double duty. Because the ASCII bit patterns for A and T are distinctive, the modem could measure them and auto-detect the host's baud rate and parity from the first two characters of every command. The prefix was not decoration; it was a calibration signal.
Why it never got replaced
Competitors cloned the Hayes command set almost immediately -- "Hayes compatible" became a checkbox on modem boxes throughout the 1980s and 90s -- and once the entire industry spoke it, the syntax stopped belonging to any one vendor. Standards bodies eventually caught up and wrote it down: the ITU-T formalised it as V.250 (originally published as V.25ter), and when mobile networks needed a control interface for GSM data, 3GPP simply extended the same grammar in TS 27.007 rather than inventing something new.
That decision is why the pattern survived the jump from copper phone lines to cellular. A GSM module needed commands for things a 1981 modem never imagined -- SIM status, signal quality, network registration, SMS -- so the standard added them as extended commands with a + after the prefix: AT+CSQ for signal quality, AT+CGATT? to ask whether the device is attached to the packet network, AT+CMGS to send a text message. New capabilities, same envelope.
What this means if you build connected devices
For anyone doing embedded systems or firmware work, the practical consequences are worth appreciating rather than just tolerating.
The syntax is human-debuggable. When a device will not get on the network, you can open a serial terminal, type AT+CREG? by hand, and read a plain-text answer. No packet capture, no proprietary tooling, no vendor SDK required. During bring-up on a new board, being able to talk directly to the radio is often the fastest way to work out whether a problem sits in the module, the antenna, the SIM, or your own code.
The knowledge transfers. A developer who learned AT commands on a 2G module a decade ago is productive on an LTE Cat-1 module today, because roughly eighty percent of the command set is the same standardised core. That is unusual in hardware, where tooling normally churns every few years, and it is a genuine argument for choosing modules that expose a clean AT interface when you are planning a deployment meant to run for a decade.
The tradeoff is real too. AT commands are line-oriented text over a serial link with no framing, no checksums, and vendor-specific quirks lurking at the edges of the standard. Parsing responses robustly -- handling unsolicited result codes that arrive mid-transaction, timeouts, modules that echo, modules that do not -- is a recurring source of bugs. Most production firmware ends up wrapping the interface in a small state machine rather than calling it directly, and it is worth budgeting time for that instead of discovering it late.
A pattern worth noticing
The AT command set has outlived the acoustic coupler, the dial-up ISP, 2G, and 3G. It survived because it was simple enough to clone, text-based enough to debug, and extensible enough that each new generation of radio could bolt on what it needed without breaking what came before. Those are the same properties that make MQTT and HTTP durable, and they are worth keeping in mind whenever you design an interface that other people will have to live with.
Fluidwire designs IoT hardware and the web services behind it, from silicon to cloud. If you are bringing up a cellular or Wi-Fi module and want a second pair of eyes on the firmware, have a look at what we do or get in touch.
Top comments (0)