Hourly data collection for science like stream gages, earthquakes, air quality, precipitation, or similar in very remote areas.
Sensors along a pipeline etc to monitor remote infrastructure.
Texting in remote areas for logging, cattle, forestry services, etc.
Redundancy for boats, emergency services etc that may have primary and secondary communication channels, but still greatly benefit from the capacity for redundant txt messages.
A wire like that is a single point of failure. Great for sending lots of data, but using two different systems is safer than using two different wires along the pipe, both of which could be severed in the same event.
It's ideal for asset tracking - you can fit a GPS fix, timestamp, and accuracy estimate (based on # of satellites visible) into 12 bytes, which is enough to ping once per minute and still only use half your allocated bandwidth. If your asset tags call in every 5 minutes or once per hour lots of options open up.
2 way communications aren't much more demanding because most of what you need can be done with lookup tables, and there aren't that many different commands you would need to send to an asset tag for local scanning. If you want to do person-to-person, 2 bytes per word is sufficient for a fairly large vocabulary (especially a tightly specified one like military brevity codes) - not exactly chatty but sufficient for many operational/emergency purposes.
Not to mention that people could have internet connected crap without even knowing it. No way to block it using PiHole, pfsense or other local routers and access points.
Given there's mobile service where most people are spending time, this situation is already much worse with cellular data b/c of the substantially higher bandwidth capability.
It's a circuit that alerts people to dead carriers.
People in radio station studios generally don't listen to the over-the-air signal because there is a delay. A silence sense is a circuit that monitors the over-the-air signal and takes action when it's been too quiet for too long. This is usually an indication that something has failed, either at the transmitter, or in the studio-transmitter link. It is sometimes triggered by dramatic pauses in classical music and talk show content, but in those cases is ignored by the DJ/host/producer.
They've been around forever, and can be made from simple analog circuits. In the stations where I've worked, if the silence sense activated, a red light lit up in the DJ booth, and the engineering department. Some stations had a secondary silence sense that would wait a bit longer, and light up a light bulb at the receptionist's desk because she had the master list of phone numbers to call the right people in case of a transmission failure.
There are thousands of radio station transmitters that are far enough away from the originating studio that it's not possible for the studio to hear the over-the-air signal, so a silence sense on top of a mountain, next to the transmitter could send an alert packet via this satellite service back to the studio to let someone know something is wrong.
This service is high latency at present and only supports sending uplink data a half-dozen times per day when satellites are overhead. It would likely not be suitable for this application.
I'm speculating, but certain FCC licenses require you to transmit without significant gaps on your licensed frequencies or be fined. (The theory being that others could be making better use of your frequency since you aren't using it.) If your transmission gear goes down for whatever reason, you want to notify the FCC before others do. E.g.,
I could see this being very useful for scientific beacons, for example to track ocean currents or bird migrations. The latter currently use cellular connections, but can only track birds through areas where reception is present.
If I was asked to engineer such a tracker, I would definitely buffer data inside to flush when connected to celluar network. Not always real time, but much more useful.
Remote communication in places without cellular connectivity. Air quality, water quality, remote weather stations, aviation, industrial applications... Latency anywhere from a few seconds to minutes. Not used like normal networking, it's something you build around for very specialized applications.
How about for check points on an ultra-marathon desert run, where you are crossing the Sahara. Each check point could have an RFID reader that gives feedback on the racers. If Bob doesn't get to the next checkpoint in say 2 hours, you know he's probably lost.
A good use of IOT is agriculture. At proper cost, having satellite connected devices across huge sprawling farms would be extremely useful. There are already solutions, like LoRA, but these have their own disadvantages.
In the normal case, you send a heartbeat once per (interval calibrated to threat model). Should be plenty of packets left to encode "send lawyers, guns and money" when necessary.
Given the low cost and power requirements of LoRa this could be fantastic wildlife and natural habitat monitoring. Could act as a backup emergency contact mechanism for folks that spend a lot of time away from civilization.
Hopefully some resellers pop up that let you buy them onesie-twosie to tinker with.
I don’t have the numbers, but at least for Iridium the data service is basically an afterthought. They allocated so much of their bandwidth to voice (using older insufficient voice codecs no less) and are now essentially locked in to a suboptimal bandwidth allocation. They must didn’t realise the importance of data when originally designing their hardware. And hardware in space is expensive to change.
Unfortunately, command and control for terrorist drone networks, sending coordinates to low-use credit-card gas pumps for night-time refills, and coordinates to targets. Give it ten years.
192 bytes * 750 packets = 144000 bytes per month at what speed/latency?