The Quectel modems are fun parts. We are using one in a project as a kind of theft protection. I couldn't belive at first "this is a whole computer with Linux on it".
I really wonder why modem manufacturers feel the need to encapsulate everything so much. Is it for regulatory reasons, to protect their secret sauce, or for our convenience? On the one hand it makes simple things really easy with some AT commands, on the other hand it makes debugging quite frustrating because it is a black box.
Regulatory reasons. There are a lot of things that FCC regs say that devices that transmit either must or must not do, which made more sense back when everything was analog. Now that the device is a full computer and can be programmed to do whatever you want, the way the industry has decided to best fulfill all those requirements is to make the computer do exactly and only what is required and then lock it down into a black box.
If you just unlocked everything, it would probably be better at what it does, but it would also not be possible to sell to consumers.
Do those regulations explicitly say that the RF device is not allowed to be programmable by the user? And isn't the user legally forbidden from substantially modifying the RF behaviour in any case?
I can't find it now but there was an article posted a while ago that explained the existence of just such rules back when the very first mobile phones used analogue transmission, which of course was easy to intercept. So the FCC forced radio manufacturers to prevent users being able to tune to those frequencies and additionally specified that manufacturers be responsible for making this limitation very hard to defeat... rather than fix the original problem of course.
Those rules exist to this day but have no relevance. However I suspect there are other similar but slightly more sane rules in play since modems are now just software defined radios that can be made to do nearly anything you want given the right access - i.e you can cause a lot of trouble, even if you don't intend to.
Off-topic, abstracting laws away from the harm they aim to prevent has always bothered me a bit. By punishing behaviors (e.g., making a device with a certain set of capabilities) other than the ones people care about (e.g., careless or malicious RF activity) you're nearly guaranteed to introduce unwanted loopholes and second-order effects.
E.g., CA requires tags for your vehicles (fair enough -- gotta charge people for the privilege of driving at all, not just incrementally through gas taxes and whatnot /s), but the law isn't that your vehicle be registered and have tags purchased; it's that valid tags must be displayed on the vehicle.
That makes enforcement super easy because an officer can just walk up and down a line of cars handing out tickets, but it also means that people can break the law for no fault of their own even after having taken the action the law was intending to promote (paying CA in this case). If you tried to renew your tags at the right time in 2020, even months before they were set to expire, you couldn't pick them up in person (covid) and wouldn't receive them in the mail till after the governor's order temporarily allowing you to drive with expired tags had expired. Moreover, at least one police department was excited to cash in on that discrepancy :)
The problem in that example is that the behavior the law is supposed to encourage (paying CA if you own a car) only partially aligns with what the law punishes (not displaying a valid tag on your car). That lack of alignment leaves room for exploitation.
That's just a small example (intentionally so -- hopefully it's simple enough so as to not be controversial), but it's a constant pattern in our legal system:
- Taser-immune meth-heads robbing people at knife point is bad, so let's make a hint of a whiff of any kind of drug anywhere near an individual for any reason a felony.
- Child pornography is bad, so let's (try to) make encryption illegal.
- Pump-and-dump scams are bad, so let's make [thousands of pages of financial legalese] illegal.
- (intentional hyperbole on this point) Low quality medical devices hurting people is bad, so let's give a private corporation the privilege to write up a set of standards, never change them no matter how far the world progresses, and charge people for the privilege of reading them to know what's legal or not.
> I really wonder why modem manufacturers feel the need to encapsulate everything so much.
The alternative would be using an RTOS of some sort, implementing a full network stack (with > 100Mb throughput) and a USB device, as the bare minimum. Then you also have I2S audio, GNSS, etc.
It probably makes more sense using an entire OS at some point.
BTW, this is typical Qualcomm, that makes the chipsets for these modems.
I've been playing with the ESP32's a lot more recently (which go the RTOS route), and in reading the code for network stacks for these devices, it did occur to me how simple they were in terms of features. I wouldn't say that one needs the entirety of the Linux kernel to be able to implement all of those things, but it does build off of a more well used stack and reuses a lot of well-tested components.
So from this perspective, it's honestly more secure probably, too, as opposed to trusting a hardware company to hire embedded software engineers to reinvent an entire stack from scratch. The latter of which are in rare supply and we all know that reinventing things is a process that often leads to vulnerabilities.
Locking down the communication to just AT commands then makes sense for similar reasons.
LTE et al is wayyyyy more complicated than WiFI/BlueTooth for what it's worth. I can get the idea that process boundaries help the large heterogeneous teams needed to ship a full featured LTE modem, similar to how microservices help large heterogenous teams ship code at FAANGs. It's infrastructure for dealing with human inadequacies rather than a technical requirement.
Why not offload all that to the driver running on the main application processor? The risk of having a second, black-box running Linux is that it’ll get outdated and/or compromised and used as a persistence mechanism for malware.
Because you can also use the modem coupled with a low-end MCU, communicating through a serial port. This configuration is more common than one might think (I was personally involved in many of projects with that configuration).
Most of these can probably receive updates from the host OS if it's really needed, but I think what it boils down to is that the manufacturers just don't care, unfortunately.
I really wonder why modem manufacturers feel the need to encapsulate everything so much. Is it for regulatory reasons, to protect their secret sauce, or for our convenience? On the one hand it makes simple things really easy with some AT commands, on the other hand it makes debugging quite frustrating because it is a black box.