Hacker News Reader

Author here -- thanks for engaging in the discussion! You won't find any pushback from us on using Zephyr -- we are contributors, the firmware example in the post is using it (or Nordic's NCS distribution of it), and we offer free Zephyr training [0] every month :)

[0]: https://training.golioth.io/

> It is often seen as more cost-effective to purchase a cellular modem with an internal MCU rather than a separate cellular modem and a host MCU to run the networking stack.

This one isn't just cost--the compliance restrictions that the cellular carriers place on you are idiotic.

The big one we bumped into is "must allow allow carrier initiated firmware updates with no restrictions on scheduling" which translates to "the carrier will eat your battery often and without warning".

In addition, many IoT devices may not call home more than once every couple of months. And the carrier will happily roll out tower firmware that will kill those being able to call home.

If I use a module with my own firmware, the modem folks will simply point fingers at me. If I use a module with integrated SoC and firmware and it gets updeathed, I get the "joy" of yelling at the cellular module manufacturer.

(I had the wonderful experience of watching a cellular IoT project go gradually dead over 3 days as the carrier rolled out an "upgrade" across its system. We got a front seat as the module manufacturer was screaming bloody murder at the carrier who simply did "We Don't Care. We Don't Have To. We're the Phone Company.")

Your experience is bizzare. Was it Verizon (or AT&T/T-Mobile) and did you use a Cat-1bis/Cat-M/NB-IoT or higher class modem?

Normally US carriers require Firmware-Over-The-Air (FOTA) capability for the modem firmware. This is not the case for deployments outside of the United States, to my knowledge.

It would be interesting to hear more about your story!

Sounds like you need a more watertight contract and more lawyers.

A cellular carrier has a legal budget whose rounding errors are likely larger than your company's total worth.

Good luck litigating.

All the lawyers in the world won't protect you from paying the penalties in the contract you signed when you overtly and deliberately failed to deliver.

What makes a separate cellular modem better than an internal cellular modem? Is it because software updates are available for the separate modems?

I am evaluating some Nordic semiconductor parts for a project. They seem to have an internal modem but Nordic uses zephyr. Any thoughts?

> What makes a separate cellular modem better than an internal cellular modem?

When using a separate cellular modem, you can connect it to your MCU via either a USB or UART interface. In IoT applications, UART is the more common choice. Then you can multiplex the interface with CMUX, allowing simultaneous use of AT commands and PPP.

With frameworks like lwIP or Zephyr supporting PPP, you can get your network running really quickly and have full control over the networking and crypto stacks. Using Zephyr you get POSIX-compliant sockets which allows you to leverage existing protocol implementations.

In contrast, using a SoC's often requires reintegrating the entire network stack, as they typically do not support POSIX sockets. I've worked on SoC's that only support TLS 1.1 and the vendor refused to upgrade it, as it would require them to re-certify their modem. Switching to a different SoC can mean repeating this process from scratch as different vendors implement their own solutions (sometimes even the same vendor will have different implementation(-s) for different modems).

> I am evaluating some Nordic semiconductor parts for a project. They seem to have an internal modem but Nordic uses zephyr. Any thoughts?

It runs on Zephyr RTOS and can be built as a standalone modem (https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/appli...). You can either use Zephyr's native networking stack or offload it to the modem while retaining the same API. This means you get access to all of Zephyr’s protocol implementations without additional effort. The design makes it feel as though you have a completely independent MCU connected to an external modem.

That said, it does have quirks and bugs, particularly when offloading networking. It also has relatively limited resources, with only 256 kB of RAM and 1 MB of flash storage.

Overall, it is the best SoC I’ve worked with, but it is still an SoC. Whether it suits your project depends on your specific use case. If you plan to integrate additional radios in the future (e.g., UWB, BLE, Wi-Fi), I’d recommend using a separate MCU if your budget allows. This will provide significantly more flexibility. Otherwise it is definitely one of the better SoC's currently in the market, to my knowledge.

PS. It only supports Cat-M (& NB-IoT but I'm going to skip over it intentionally!) which is not globally supported, so you should make sure the region you want to deploy in supports that technology.

cellular modems go nonfunctional/obsolete much faster than other systems. 3g is almost entirely gone worldwide. 4g is still around, but providers are already reducing how much their towers dedicate to it. The standards body is working on 6g, who knows when that will come and push out older stuff.

If the case of my car I don't care - I have never found a use for the cellular connectivity it has (if any). However there are lots of other devices where the cellular connectivity is important and users will want to upgrade the modem to keep it working. If cellular connectivity is just a marketing bullet point nobody cares about then integrated is good enough, but if your device really isn't useful without the modem make that modem replaceable for somewhat cheap.

4g should survive better than 2g and 3g, because the 5g standard allows for mixed mode deployments where the coordination channel runs as 4g, and the slots can be 4g or 5g dependening on what the client device is capable of. Running the coordination channel with 5g encoding could be a little more efficient, but it's not a big loss compared to running a minimum size 2g/3g allocation.

EDGE and E-GPRS is going to survive for at least another 5-10 years. Although this statement might not be globally accurate.

Generally the modem would support EDGE/E-GPRS (2G) and 3G simultaniously. In Europe, EDGE/E-GPRS is still quite popular and unlikely to be sunsetted in the next 5 years. It is a pity that many manufacturers tightly integrated the modem into their PCB, instead of creating a separate "communication box" - especially as some use-cases have the budget for it.

> What makes a separate cellular modem better than an internal cellular modem?

The US 3G shutdown required some rather expensive and unexpected upgrades. Vendors signed long-term contracts with 3G providers, and then "someone" was on the hook, to replace something, when the 3G vendors terminated their contracts prematurely.

The deeper the modem was integrated into a product, the harder it was to change. The shallower the modem was integrated, the easier it was to change.

For example:

One of my cars just lost its internet connectivity, and the automaker never offered any way to fix it. (I didn't care, I only used Android Auto in that car.)

My employer (IOT) sent out free chips to our customers. They had to arrange someone to go do a site visit and swap a chip while on a phone call with us. We're small and early enough that it wasn't a big deal.

My solar panel vendor wanted me to $pend big buck$ on a new smart meter and refused to honor their warranty. I told them to run a cable to the ethernet port in my meter.

Car manufacturers should abandon developing their own entertainment systems and instead collaborate with Apple (CarPlay) and Google (Android Auto) to improve integration and support a wider range of use cases. Unfortunately, they seem to revive these efforts every 4-6 years (e.g. Mercedes Benz)

The only feature I need to control remotely in my car is preheating during winter—I wonder how they could achieve that without using cellular connectivity as paying a subscription for such a service would make it less attractive to me.

I like the Tesla car computer a lot more than Android Auto. I just wish I could install 3rd party apps.

Part of the reason is there's no delay waiting for my phone to connect, and no random disconnections while driving.

There are issues with infotainement systems in older vechicles supporting Android Auto and Apple Car Play. This is primarily because car manufacturers (or subcontractors) aren't good at integrating these systems. Often they are tight on budget too!

Personally, I’m not a fan of Tesla’s car computer. My main annoyance is the lack of physical buttons. All I want from my car is reliable navigation, seamless audio playback, and easy mobile call handling.

> All I want from my car is reliable navigation, seamless audio playback, and easy mobile call handling.

That's pretty much what the Tesla computer has. I do agree that the lack of physical buttons is a problem; and now that there are more EV makers on the marketplace the market can speak very loudly and choose other automakers.

Security.

On one hand, licensing requirements and regulation often mean that modems are locked down in terms of firmware updates, reference documentation, source, and capabilities. This often translates into a larger "black box" area, and one embedded inside your SoC instead of physically separate and connected over a serial bus.

On the other, on-chip modems often (not sure about those Nordics) have DMA.

The combination of those two is scary.

> The combination of those two is scary.

Could you clarify what you mean by this?

> The blog post mentions Session IDs as a solution, but these require servers to be stateful, which can be challenging in most deployments.

Doesn't this just move the 'state' into the operating system, or networking layer, in the form of an active TCP connection?

You can use Session Ticket's w/ UDP too.

Nevertheless, with modern cloud providers moving the state into the OS/Networking layer is still easier to scale. You don't need to write your own services to handle it.

Is DTLS a workaround for the session issue? Haven't had much experience with it myself but it does cut down some of the statefulness.

The post details the use of CoAP over DTLS, employing Connection IDs.

You don’t want to redo the handshake (which, as far as I know, is identical to TLS) every time you send a packet using DTLS. Therefore, you still need to retain state information. In my opinion, using DTLS (UDP) is considerably more nuanced than using TLS (TCP) in an embedded IoT context.