Comment by cbdevidal
2 days ago
That's funny. I clicked on the HN article on the home page about the AT Protocol[1] expecting an article on the Hayse set. And then I scrolled down and saw this article.
2 days ago
That's funny. I clicked on the HN article on the home page about the AT Protocol[1] expecting an article on the Hayse set. And then I scrolled down and saw this article.
My first job in IT was at AOL tech support and we could rattle off modem strings from memory :-)
I still think to Hayes AT commands almost every time I see an article about the AT protocol, thinking "who is still using analog phone modems"?
They're still used today for cellular modems
Yep. And not your grandpa's AT command set - it's been extended to support HTTP.
https://computer.rip/2026-04-26-voice-modems.html
> Modem vendors continue to build on AT. If you look at LTE modems made for IoT applications, for example, it's common for them to provide a complete HTTP implementation (and sometimes MQTT, and sometimes some kind of proprietary message broker protocol) accessible via AT commands. That means you can implement an IoT device without a network stack at all, deferring all network operations to the modem itself. With a JSON-over-HTTP backend, for example, you might send AT commands with JSON payloads over the serial control channel and then get JSON back. You never interact with the network at all, the modem is a completely self-contained system. At the extreme, you might implement your entire device using exclusively the modem. This is a common approach for telematics devices like GPS trackers: they consist of nothing but a cellular modem, the telemetry application is built for the modem using an SDK from its vendor, and you interact with it using AT commands. IoT-class modems frequently provide GPIO and user flash for just this purpose.