That command set is still in use! I was working with it just last week to control an LTE module.

AT commands are still in use inside your smartphone. On an iPhone, when the main CPU wants communicate with the baseband chip to make a call or send SMS or whatever, it literally sends AT commands.

In fact, one of the earliest iPhone jailbreak exploits relied on a vulnerability in the AT command interpreter inside the baseband.

Commands that have to prefixed with AT are still in use. Most of the actual commands after the "AT" part are not recognizable to someone who knows dial-up modems; they have nothing to do with the Hayes set other than the AT prefix/misfeature.

Yeah, that's what always confused me about it when I worked on GSM phones back in the mid-2000s - if you're going to overload an old protocol so heavily, it's time for a new one.

Probably nostalgia! That would be good enough for me.

At commands are used for many nonmodem things too.. Bluetooth adapters, zigbee adapters, HC12 transceiver, other various proprietary devices tied to a UART in addition to LTE, GSM/GPRS (I guess technically some of those are modems but they’re pretty far removed from the original design)

Absolutely! While it's not my preferred method of control, you can send AT commands encapsulated in SMS to update/troubleshoot BGAN terminals.

Iridium modems use it too!

Its embedded into GSM modules; Phones need it to do anything, to check firmware versions, to send and retreive SMS messages, to make calls etc. I used it to control the 3G dongle I had (basically, a GSM module in a stick). Most times the device will act as a serial device.

Also used in the esp8266 when it's configured in wifi-serial mode.

This irksome AT prefix is still jused in mobile modems, all the way up to LTE. You'd think they'd drop this "Simon Says" sequence once and for all from the commands; they would work just fine without it.

Why can't I just type !GSTATUS instead of AT!GSTATUS?

  at!gstatus?
  !GSTATUS: 
  Current Time:  555877           Temperature: 29
  Modem Mitigate Level: 0         ModemProc Mitigate Level: 0
  Reset Counter: 14               Mode:        ONLINE         
  System mode:   LTE              PS state:    Attached     
  [...]

There should be an AT command to disable the AT prefix.

The AT prefix is to get the ATtention of the /serial/ device, which modems almost always are in some respect.

I don't know how much low level serial protocol programming you have done, but in my experience, there is possibility of random line noise, and such. This is why generally these low level protocols have both PREFIX and POSTFIX for commands.

In the case of Hayes commands for modems, the prefix is AT, and the postfix is carriage return and line feed.

> how much low level serial protocol programming you have done

Tons!

The AT prefix, as such, does nothing whatsoever for error detection or recovery. If we add an AT prefix to an N-character command, the possibility of corruption in the N-character command part is exactly the same as before. Now, the AT also has to be correctly received, too.

An example of a textual protocol whose framing actually means something is the Mobitex MASC: http://www.mobitex.com/resources/masc/MASC_Guide.pdf

MASC frames have a checksum and length field in addition to the framing (frames start with ^ and end with a CR). MASC also dictates the use of 7 bits with even parity; so parity checking is possible by both endpoints. Still, that leading is a fluff feature that contributes nothing; the protocol could work fine with frames just being sequences of non-CR characters terminated by CR.

Modems usually have a solid connection to the host, often a short one; it's the actual end-to-end traffic that is susceptible to corruption; not so much the local commands between the host and modem. These modern LTE modem is often integrated onto the same chip as the host processor which is sending it the AT commands.

> The AT prefix, as such, does nothing whatsoever for error detection or recovery. If we add an AT prefix to an N-character command, the possibility of corruption in the N-character command part is exactly the same as before. Now, the AT also has to be correctly received, too.

I did not claim it does any such thing.

In historical contexts, and even in some modern contexts, the data stream may include random noise data.

If we did not have a state machine looking for "AT" before beginning command processing, then we would potentially process some of this line noise as a command, which could potentially be bad.

Mmmm maybe I'm missing something, but... what's preventing the rest of the command from being corrupt? Imagine two commands, CM and DM. CM is good and DM is bad. Noise gets in and changes ATCM into ATDM. Boom.

Unless you have error detection / correction, etc, I don't think the AT would add anything else to the equation :-?

Consider instead that you do not have a prefix command, but you poll the line and there is data, so you retrieve it.

Now what do you do? Well, you check the first byte and see if it's a valid first byte for a command. There are hundreds of them, so basically every uppercase ASCII character should do.

In the happy path, you get a byte stream like "DT 1234\r\n".

Sometimes, the data stream has noise in it, so you get bytes like "%$DT 1234\r\n".

There are no commands that start with "%" or "$" so you can just drop it.

However, in the unhappy path, you might get bytes like "CMDT 1234\r\n".

CM is a valid command! But "DT 1234" are not valid arguments.

If only there was a way to get the ATtention of the parser before parsing commands...

Don't get me wrong; it's useful to have an AT command which responds with OK. That way we know that we are in the modem's local command mode rather than online.

(More or less; there is the obvious ambiguity of something on the remote end also responding to AT with OK.)

This useful AT just doesn't have to be a prefix of every other command.

  AT
  OK         # I have the attention of the modem)
  DT5553535  # dial this number now that I have your attention)
  DIALING
  CONNECT