4 ms·

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

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

javiermaestro 8y ago
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 :-?
- kazinator 8y ago
  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
- merlincorey 8y ago
  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...

javiermaestro 8y ago

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

kazinator 8y ago
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
merlincorey 8y ago
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...