Hacker News Reader

Comment by kazinator | Hacker News Reader

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.

View on HN

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

Reply on news.ycombinator.com