[HN Gopher] Swarm - Low cost, global satellite connectivity for IoT
___________________________________________________________________
Swarm - Low cost, global satellite connectivity for IoT
Author : jsmorph
Score : 142 points
Date : 2022-11-03 18:31 UTC (4 hours ago)
(HTM) web link (swarm.space)
(TXT) w3m dump (swarm.space)
| differentview97 wrote:
| This is not affiliated with SpaceX if I read the site correctly.
|
| Super-interesting though.
|
| Edit: Wrong, see below
| java-man wrote:
| "View Open Positions" link points to SpaceX page
| https://www.spacex.com/careers/?search=swarm
| xd1936 wrote:
| SpaceX purchased them last year.
|
| https://www.space.com/spacex-to-acquire-swarm-
| technologies-s...
| kasperni wrote:
| It is a wholly-owned subsidiary of SpaceX [1].
|
| [1] https://en.wikipedia.org/wiki/Swarm_Technologies
| jcims wrote:
| I can't get to their documentation but it looks like it's using
| LoRa for the RF.
|
| 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.
| googlryas wrote:
| Yep, it seems like you get a transmit window every ~2 hours
| max. All in all this service is much more
| reasonable(cost/antenna size/transmit rate/power) than I
| expected. You can basically send 2kb/day from a large chunk of
| the world(with a view of the sky) for $5/mo. Somehow even
| cheaper than m2m cell plans I've encountered, though granted I
| haven't looked at services in the past few years.
| delabay wrote:
| Helium has a competitive Lora network at 100x less cost, in
| western Europe and US.
|
| _Ducks_
| byw wrote:
| Looks like their documentation site is down. Any idea what kind
| of bandwidth we're talking about here?
| ttul wrote:
| 1 kbps
| gnarbarian wrote:
| are you sure?
| jobigoud wrote:
| Roughly 0.44 bits/s. Data is 750 packets of 192 bytes per month
| on the $5 plan.
| stefan_ wrote:
| And what latency. "Webhooks" and "REST API" isn't exactly
| screaming useful duplex communication channel.
| initplus wrote:
| High. At least if it's anything like Iridium, probably
| seconds to minutes depending on coverage. Really not designed
| to be used like general purpose networking.
| csmarshall wrote:
| So this is a division of spacex? Since that's where there
| "careers" page goes right.
| alsodumb wrote:
| SpaceX acquired them last year.
| notfried wrote:
| I love how they define "activation date" for the data plan!
|
| > 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.
| exhilaration wrote:
| So 50 messages for testing and calibration before they charge
| you? I wish all wireless providers were this nice.
| [deleted]
| notfish wrote:
| SpaceX acquired swarm in 2021:
| https://www.google.com/amp/s/www.cnbc.com/amp/2021/08/09/spa...
| SideburnsOfDoom wrote:
| Unrelated to Bruce Sterling's Space Swarm
| https://readerslibrary.org/wp-content/uploads/Swarm.pdf
| H1Supreme wrote:
| What does the data collection end of this look like? In a home
| IOT setup, for example, you'd typically have a single machine
| (Border Router in a Thread setup) collecting all the data from
| each node.
|
| 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.
| jcims wrote:
| Looks like they have a SaaS product called Hive to poll/push
| data from devices to your application. I don't see any
| indication of point to point message passing capability but it
| may exist.
| googlryas wrote:
| You get a REST API to to query to get your data.
|
| Eg GET api.swarm.space/devices/$id/recent
| ClumsyPilot wrote:
| You dont buy a sattelite terminal yourself , they company has
| their own terminal and will make it avaliable to you over an
| API
| mirashii wrote:
| Huh, for some reason, I thought that the FCC would fine and
| regulate this company into oblivion after their unauthorized
| launch stunt. Looks like that didn't quite happen the way I
| expected.
|
| https://spacenews.com/swarm-ceo-talks-past-mistakes-future-g...
| [deleted]
| arriu wrote:
| Minimum order of 25, so roughly $3725 for one year unless you get
| the "eval kit" @ $449.
|
| 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
| ge96 wrote:
| Curious how it compares to Iridium, I've seen those with
| Sparkfun
| initplus wrote:
| I don't have numbers in front of me but it looks waaay
| cheaper. Seems they are trying to undercut Iridium SBD on
| price.
| I_dev_outdoors wrote:
| There's also a sparkfun dev board linked from that page which
| is around $150. It mentions that if ordering less than 25
| MuffinFlavored wrote:
| What might somebody (or some company) use this for?
|
| 192 bytes * 750 packets = 144000 bytes per month at what
| speed/latency?
| _jal wrote:
| Security is an obvious use.
|
| 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.
| proee wrote:
| 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.
| LeafItAlone wrote:
| 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.
| themgt wrote:
| _In-Q-Tel, the venture capital arm of the CIA, lists Swarm
| Technologies as one of their startups._
|
| I bet the military/intelligence community has all sorts of
| ideas!
| schleck8 wrote:
| Inqtel also funds Anaconda, Mongodb and Gitlab, interesting
| LinuxBender wrote:
| 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.
| jcims wrote:
| 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.
|
| eg https://marketplace.att.com/products/att-iot-
| dataplans-lte-n...
| bredren wrote:
| I worked on a project for a carrier focused on monitoring
| temperature of seafood (oysters to start) from water to
| store.
|
| They were anticipating some legislation that would require
| full auditability of supply chain.
| Retric wrote:
| 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.
| iwillbenice wrote:
| anigbrowl wrote:
| 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.
| [deleted]
| jgalt212 wrote:
| It's a perfect fit for the Yo app.
|
| https://en.wikipedia.org/wiki/Yo_(app)
| eddsh1994 wrote:
| Wait, this is a real app?!
|
| https://www.youtube.com/watch?v=OVoFzu-vH4o
| eterevsky wrote:
| Weather station or any kind of remote sensor that you want to
| keep in some remote area.
| reaperducer wrote:
| Silence sense and FCC-required logging for a mountaintop
| broadcast transmitter.
| skykooler wrote:
| 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.
| initplus wrote:
| 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.
| jcims wrote:
| 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.
| nwatson wrote:
| 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.
| eternityforest wrote:
| Sparkfun has evaluated boards for $149 although they are SparkX
| experimental and could go away.
|
| Could always do a groupgets anyway.
| reaperducer wrote:
| _Provides 750 data packets per device per month (up to 192
| Bytes per packet)_
|
| 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.
| arriu wrote:
| 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 :)
| moralestapia wrote:
| 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.
| Leherenn wrote:
| 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.
| delabay wrote:
| Helium charges 0.00001$ per packet (about 24 bytes) using
| Lora protocol.
|
| 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.
| WJW wrote:
| 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].
|
| [1] https://cointelegraph.com/news/critique-on-
| helium-s-6-5k-mon...
|
| [2] https://scwcontent.affino.com/AcuCustom/Sitename/DAM/
| 031/Sen...
| initplus wrote:
| 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.
| wildzzz wrote:
| 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.
| moralestapia wrote:
| 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.
| eternityforest wrote:
| 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.
| initplus wrote:
| 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.
| Taniwha wrote:
| 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
| dmitrygr wrote:
| > 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
| tspike wrote:
| This looks like a fantastic tool for ensuring the obsolescence of
| privacy.
| shswkna wrote:
| This product is not for attaching to people, but things that
| you actually want to be tracked.
| NoImmatureAdHom wrote:
| Well this is terrifying. Pretty soon you'll have to crack open
| your appliances to snip the antennas to prevent them from calling
| home, rather than just not giving them the wifi password...!
| citilife wrote:
| You're already carrying around a device that monitors your
| location, what you are saying (and audio in the surrounding
| area), to some extent how you are moving (gyroscope), your data
| ingress and egress patterns and where you share virtually all
| your public thoughts (and most private thoughts).
|
| 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.
| jlmorton wrote:
| While that's true, I have a little bit of faith in Apple and
| Google. But how about the $18 humidifier I bought on Amazon?
| bagels wrote:
| This is already possible with cell connectivity. Many cars have
| this now, for instance. Nothing is stopping the telcos from
| offering something to compete with this other than in remote
| tower-free locations.
| kube-system wrote:
| People's appliances are almost all within range of cellular
| connectivity, which is cheaper and higher bandwidth.
| mmazing wrote:
| Not likely with those data rates, for better or worse
| frenchie4111 wrote:
| Data will get cheaper, fast
| multiplegeorges wrote:
| Is this a new offering released today?
| NKosmatos wrote:
| Why isn't this mandatory on ALL planes? A simple device like this
| (or similar ones) would make real-time tracking of all flights a
| reality.
|
| We'll see many new things and interesting technologies in the
| coming years, like this one and also the one in iPhones.
| Integer wrote:
| ADS-B is mandatory these days, and Aireon [1] has a
| constellation of satellite receivers for 24/7 global coverage.
|
| [1]https://aireon.com/
| initplus wrote:
| ADS-B is essentially mandatory nowadays, but it's just a radio
| that transmits location to others in the same local area. Get
| enough volunteers with receivers spread throughout the world
| and you do get real time location tracking of every aircraft.
| See https://www.adsbexchange.com/
| pnemonic wrote:
| >SpaceX
|
| Ignored completely. Musk was cool until he opened his mouth all
| the way.
| panick21_ wrote:
| Musk has literally been saying tons of stuff an talking a lot
| for 15 years.
| krm01 wrote:
| Any idea what the speeds are going to be, especially when
| compared to connecting IOT devices to a Cellular network?
| djmanning wrote:
| You can purchase a single breakout board from Sparkfun:
| https://www.sparkfun.com/products/19236
| ec109685 wrote:
| Surprised dedicated ultra low bandwidth satellites are the way to
| go when developing a service like this versus piggybacking on
| something like StarLink.
| jjtheblunt wrote:
| It is SpaceX also, so presumably in some regard piggybacks on
| StarLink.
| girvo wrote:
| No. It was purchased by SpaceX last year, but uses their own
| hardware.
| panick21_ wrote:
| They will defiantly unify this stuff more over time.
| jjtheblunt wrote:
| No? SpaceX purchased it, so it's theirs now. They may for
| instance be using shared ground network hardware and
| software post acquisition. Do you have reason to think
| otherwise?
| jcims wrote:
| This was a separate company originally. In this case the RF
| protocol is completely different (~140MHz vs 12+GHz) as well so
| you'd have to add hardware to the StarLink satellite to support
| this (which obv. could be done moving forward)
| dsr_ wrote:
| Under 150KB per month, $5.
|
| 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.
| THENATHE wrote:
| With numbers like that, this seems completely useless except
| for all but the most wildly specific of applications
| panick21_ wrote:
| In the past this cost even more.
| googlryas wrote:
| 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.
| idiotsecant wrote:
| 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.
| jobigoud wrote:
| Critical applications that are only sending one data point
| per hour. It's limited to 750 packets per month.
| initplus wrote:
| 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.
| panick21_ wrote:
| You can also aggregate some stuff on the sensor and the
| send the aggregations.
| googlryas wrote:
| 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
| kube-system wrote:
| It's for global IoT connectivity, just as it says. That is a
| very specific application.
| [deleted]
| peterweyand wrote:
| Ultimately what this means is that data transfer speeds will be
| faster, yes? (That's a question.) If most internet usage is
| direct to satellite and then satellite to endpoint this would
| mean that tier one hub networks would no longer be used. So laser
| replaces fiber for most of the distance, with a peer to peer
| satellite network that would make outages less common. Which
| would be both faster and more reliable. The only issue I see is
| for there to be an intentional or unintentional satellite debris
| event that would be self propagating, but that issue has been
| around for a while anyway.
___________________________________________________________________
(page generated 2022-11-03 23:00 UTC)