this is actually really great for applications like tracking, remote instrumentation, and other services that have a small amount of relatively important data in hard-to-service or critical applications which is not that wildly specific.

Critical applications that are only sending one data point per hour. It's limited to 750 packets per month.

Lots of sensors with a restricted pipe isn't uncommon - in the electrical transmission substation world they've been dealing with the problem of how to do a lot with a tiny amount of bandwidth for decades. An industrial fieldbus protocol even exists for it called DNP3.

The answer is your end devices only signal on meaningful change, whatever that may be, and stay quiet the rest of the time. How meaningful that change must be depends on how much bandwidth you have. When you get right down to it you can do a lot with a little in the industrial controls and remote monitoring space.

We get so used to overly verbose communications protocols and overly abstracted data structures and methods, it's refreshing once in a while to care about each bit!

Your hardware can record many datapoints, and bundle them up together into one packet for transmission in one big bundle. If you are reading a float off a sensor, you can get nearly 1 data point per minute, transmitted hourly, with a very naive implementation.

Much more with compression specialized to your use case and clever packet design.

You can also aggregate some stuff on the sensor and the send the aggregations.

What do you mean 1 data point? It transmits bytes, not data points. I could easily stuff 60 temperature and humidity readings into one hourly 192b packet(ie per-minute weather data). That's 120 data points, not 1. And you could easily double that with simple differential encoding or beyond other compression techniques

Yeah what I meant to underline was that for a critical application you won't be able to react faster than one hour in case the data reports a critical issue. So not suitable for security or any application where you need less than one hour latency. I guess if you need satellite coms maybe the sensor is not in a place you can go in one hour anyway.

You aren't going to be streaming video from the Atacama through this but it is no where near useless. 192 bytes is actually substantial amount of data depending on what you're interested in.

It's for global IoT connectivity, just as it says. That is a very specific application.

Our use case is industrial IoT sensing in extremely remote deployments.

In the past this cost even more.