I love this type of tech and want to get in on that sweet 144,000 bytes of data at 5 per month, but... it's not just 5 per month, it's a minimum investment of 500 unfortunately.
Also, not sure where to find a decent Commodore system these days to utilize this plan :)
Sure, but 40 years have passed since then and 144K peanuts for any real world application.
A quick example, you have a sensor that sends a single metric every minute. Suppose that you can pack that info (sensor id, metric type and data) in 32 bytes. You're looking at about 1.2MB/month of data (8 times your 144K), which will come to about $40/month.
Quite expensive for a single data point, but I can imagine several use cases where that cost can be easily justified.
For use cases of this product you will be packing much tighter than this.
You get terminal identification from the carrier, no need to waste precious packet space on identifiers. And it's probably also a waste to encode field names into your packet - just record fields at the same offset every time. If 16 bits of precision is enough for you (it likely is) you can squeeze 16 metrics (or 16 time series recordings of the same metric) into every packet.
Up to the minute sensor data for something so remote that it needs a satellite uplink is either going to be for something incredibly critical or totally overkill and a waste of money. With Swarm, you could be waiting up to 2 hours between passes that last anywhere between 10 and 50 minutes so it's not like you'll have your data instantly for large portions of the day.
Yes, but then IoT usually invokes a sense of (almost) real-time monitoring of things and lots of packets etc...
But I get your point, also you can always do a lot of things to save on bandwidth, like do not send info which is not interesting (i.e. no point in sending 100s of "no fire was detected" messages).
Btw, anyone here knows if there's compression schemes designed specifically for small data packets? Gzip and others would be overkill as headers vastly exceed payload size. Just using raw LZ77 may work but it's 2022 so there's probably a specific thing for that already.
Also, what about data that follows a specific format, like only integer numbers, it would be nice to have an algorithm that takes a "string" of 32-bit ints and gives you back a binary buffer with a smaller lossless representation of it.
This product is targeted at actual users of "IoT", think remote monitoring in remote locations. Not "smart microwave" style IoT.
Not sure there is any automatic solution for compression here. If you know your own use case you are in the best position to choose where to sacrifice accuracy with a lossy compression scheme. But this relies on understanding of the accuracy of the input data, possible ranges of values, importance of accuracy in different fields etc. Not sure how an automated algorithm could take these real world constraints into account.
A clever compression algo can't help you if you try compress 4 doubles, but in reality you only needed byte precision on some fixed 0-100% range.
Yeah and that's probably why IoT devs absolutely crank up the data rate and spew dozens of Bluetooth advertising packets in the air for no apparent reason, probably significantly reducing battery life that could have been 5yrs, for applications that really don't need instant response.
Something like msgpack might be able to compress ints to some degree since it can represent them as smaller data types.
> Suppose that you can pack that info (sensor id, metric type and data) in 32 bytes
I suppose you haven't worked with such constraints before, so that's why you think this needs 32 bytes. In reality, 4 or 6 will likely do.
Send diff in metric value if applicable, use variable-length encoding to not waste bytes. Allocate bits and not whole ints to things (like metric type). ID is already part of lower level protocol - the address, so you do not need it
How do you use variable-length encoding in a limited-length package? You either allow a situation where this variable-length encoding would not fit in a package and then it's not really clear what to do. Or you just saving bytes for nothing, because you could use fixed-length encoding instead and satellite does not care whether you sent 65 or 69 bytes of data.
At work we’ve been experimenting with what amounts to a pre-calculated/pre-shared dictionary to allow for compression of small data, but just picking what data you send and it’s representation gets you very very far.
Because we need to put nearly arbritrary data into our NB-IoT UDP socket, Inmarsat or Swarm, saving bytes let’s us pack more data into a message so we can send fewer messages: saving money and increasing reliability (because if you miss a Swarm upload time you can have hours before the next one, for example, or our Simcom modem might hit a black spot and such)
I don't think the general use case is once per minute though, more like once per hour unless something goes wrong. Something like ensure pipeline pressure is still nominal for remote parts of the pipeline.
The reason people are skeptical about its long-term longevity is that the vast majority of the income of the project is coming from the sale of hotspots, rather than from paying customers [1]. This means pricing for users is heavily subsidized by hotspot revenues right now. Eventually, the hotspot market will be saturated and prices will have to come up to keep the project afloat; it remains to be seen how competitive the pricing will be at that point.
PS: Saying LORA is "ubiquitous" in the US oversells it quite a bit. It is quite available in cities but most rural areas are completely devoid of coverage, see [2].
Oh boy, where to start with all the problems in this post.
* you can buy helium hotspots for $100 now, on par with other lora gateways
* " vast majority of the income of the project" is vague and incorrect. The hotspot OEMs (of which there are 50+) receive sales revenue, not "the project".
* You're referencing a Senet chart, which is actually a roaming partner on Helium. This isn't actually a helium coverage map.
I will correct myself on the coverage, about 98% of Americans are covered, not 98% of land in America. Oops. America is a big place.
Yeah but once a minute is overkill for lots of things - remote river flood warning every 15 minutes, river water quality once an hour, temp or rain fall once and hour
Inmarsat is surprisingly more competitive to Swarm than we expected, but man it is difficult to get passed all the bullshit resellers, which is where Swarm is way easier. But for our use cases Inmarsat has been a better fit right now, though we use both on our board depending on the deployment: if we don’t need as much bandwidth and are okay with the black out times where we’re not covered by Swarm, it’s great
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.
USD $5/MO PER DEVICE
Provides 750 data packets per device per month (up to 192 Bytes per packet), including up to 60 downlink (2-way) data packets