[javiermaestro]

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 :-?

[merlincorey]

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...

[kazinator]

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