Ignored completely. Musk was cool until he opened his mouth all the way.
We’ll see many new things and interesting technologies in the coming years, like this one and also the one in iPhones.
And engine makers and airframe makers already do it, much like heavy equipment makers already do it. https://www.boeing.com/commercial/aeromagazine/articles/qtr_...
…like people’s cars.
Not that I think the sky is falling and this is the end of privacy or anything.
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
144,000 bytes. Almost the capacity as a Commodore 1541 disk drive.
40 years ago it would have been unfathomable that a regular schmoe could transmit a floppy disk via satellite for just $5.
Also, not sure where to find a decent Commodore system these days to utilize this plan :)
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.
192 bytes * 750 packets = 144000 bytes per month at what speed/latency?
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.
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.
I bet the military/intelligence community has all sorts of ideas!
Their suggested architecture was basically to use this for notifications for very remote sensors: "battery below 20%. Come help" etc
The other way is for things like Garmin InReach: "Send message 1" (which is "I'm ok and don't need help") etc.
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.
Hopefully some resellers pop up that let you buy them onesie-twosie to tinker with.
I wonder how much total bandwidth each of these satellites can push per month. Anyone know the backend aggregate sustained data rate per sat?
They were anticipating some legislation that would require full auditability of supply chain.
Could always do a groupgets anyway.
> The hardware will be charged upfront but the subscription data plan will not be charged until the device is activated. The activation date (and $60/yr billing date) for a device is the first of the following month once ≥50 messages are sent. For example, if your device sends its ≥50th message on April 8th, your device would be charged on May 1st. And would renew annually on May 1st until you opt-out.
(I live on a side of a hill and had the entire dev kit standing on my roof that was tall enough to have a view over a large part of the city and out into the bay)
At the time, I heard from support that they were launching new satellites that would improve the connectivity in built up locations (such as a city) but I eventually gave up.
At the time, there were 2 satellites a day that were prospects to connect to based on my location, but we met an invisible issue that couldn't be debugged. Potentially it was a satellite visibility issue but could have also been that the available satellite connection was backlogged with other devices / the satellite didn't have a large enough window of connectivity to perform the upload / there was noise interfering with the connection / other mysterious reason that would need expensive test equipment to root cause.
I took it with me into the plains one day (Livermore) and it connected once in the 8.5 hours I was there so it was functional and the RF signal strength was good for the received packet.
My takeaway was that the tech is well suited for rural areas all over the globe where there is no other connectivity options and there exists applications that can work well with the high latency / low bandwidth payloads. Well monitoring jumps to mind as does CO2 gas monitoring in mines - slow moving signals, rural locations, expensive to send a truck to go and monitor.
https://spacenews.com/swarm-ceo-talks-past-mistakes-future-g...
https://www.reuters.com/article/us-usa-satellite-fine/fcc-fi...
- IMHO, price could be prohibitive for many use cases (e.g. water meters)
- Signal strength could be an issue for urban environments (e.g. inside buildings)
- There aren't many small business use cases for IoT connectivity that does beyond WiFi (both wrt range and power budget). What I have seen is that there are usually several big players (e.g. utilities, municipality, factories) that at some point deploy LoRa based or similar connectivity. LoRa can actually cover a huge area with just a handful of self operated gateways (similar to Helium in this respect).
- Wave paths are more complex (buildings, multi path propagation etc). Hence base stations need to be positioned more densely.
- Finding optimal locations for base stations and contracting the building/land owners is not straightforward.
- Using the less congested, licensed spectrum instead of the crowded ISM bands may be preferable in the city.
I suspect there is some underlying issue with these high-latency / low-bandwidth solutions that just makes them impractical in real life.
If these truly are just 11x11x2.8cm - then in a few years we will have bunch of super fast and very destructive mini bullets orbiting earth and destroying very expensive space equipment.
Can we please consider the amount of trash we send out in space before it is too late?
https://blog.semtech.com/satellite-iot-qa-with-swarm
Pretty cool. Just checked coverage over my house using their pass checker and it's already ~50% coverage through the course of the day. No good for realtime alerting but good enough for daily reporting.
Ducks
I understand the "field device" -> "satellite" uplink step. But, what's the next step? Another device just for downlink data would eat through the data cap in no time.
Eg GET api.swarm.space/devices/$id/recent
Is this LoRa? I guess if it was they wouldn't need their own modems. There have been some hobbyist attempts to put LoRa gateways on satellites and from what I remember it worked reasonably well.
Under 300KB per month, $10.
Under 450KB per month, $15.
Up to 600KB per month, $20.
Note, that's total number of bytes, not bytes per second.
1. Long distance communication require HF frequencies which requires very large antennas.
2. If you’re talking specifically about the HF amateur radio bands, you may not use those for commercial purposes.
Super-interesting though.
Edit: Wrong, see below
https://www.space.com/spacex-to-acquire-swarm-technologies-s...
Some people even connect their watches, which monitor (or will soon monitor) everything from their heart rate, sleep schedule, oxygen levels, BMI, etc.
I frankly don't think it can get much more intrusive.
If someone could get their hands on my data, it'd be a bunch of extra work to determine who it's coming from.
>>Some people even connect their watches, which monitor (or will soon monitor) everything from their heart rate, sleep schedule, oxygen levels, BMI, etc.
You can easily have a watch that does all these things but doesn't share any data, and you can be sure of that based on more than just promises. Open hardware, open software, local data storage and zero-knowledge for anything touching the internet. It's well within our grasp technically, we the people just need to demand it.
I literally watched a large excavator from a dealer break sanctions and show up digging in Iran.
Ignoring exactly how effective a crypto it has been or will be.
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.
https://www.insideradio.com/free/fcc-slaps-birach-broadcasti...
https://www.inmarsat.com/en/solutions-services/enterprise/se...
But we’re using IDP as it’s not really out yet. Next year hopefully!
We’re eagerly waiting for them to, as it should increase what we can do with their product!
The $60/yr plan allows for 750 _messages_ per month. Up to 3000 messages per month if you stack 4 plans together.
So on the base plan, you're limited to ~1 message per hour if you spread it out across the month.
How so? 6 messages per day is one message per 4 hours.
Err, no - at 750 packets/month, you’d burn through your allocation in 12.5 hours at that rate.
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!
Much more with compression specialized to your use case and clever packet design.
disclaimer: I work with In-Q-Tel investments almost daily, but am not affiliated.
Do you see any interesting trends? In terms of one layer deeper than the general trends such as AI, space, etc.
eg https://marketplace.att.com/products/att-iot-dataplans-lte-n...
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.
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.
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.
Something like msgpack might be able to compress ints to some degree since it can represent them as smaller data types.
Zstd dictionary mode? At small sizes using a dictionary is generally the way to go.
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
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)
But it's associated with crypto so people hate it.
It also undercuts everything by a factor of 100x and is ubiquitous in US and western Europe.
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].
[1] https://cointelegraph.com/news/critique-on-helium-s-6-5k-mon...
[2] https://scwcontent.affino.com/AcuCustom/Sitename/DAM/031/Sen...
* 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.
