101–110 of 165 posts
Earlier quoted context omitted.
It is SpaceX also, so presumably in some regard piggybacks on StarLink.
No. It was purchased by SpaceX last year, but uses their own hardware.
This looks like a fantastic tool for ensuring the obsolescence of privacy.
This product is not for attaching to people, but things that you actually want to be tracked.
…like people’s cars.
Not that I think the sky is falling and this is the end of privacy or anything.
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...
https://www.reuters.com/article/us-usa-satellite-fine/fcc-fi...
Earlier quoted context omitted.
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.
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!
Earlier quoted context omitted.
What might somebody (or some company) use this for? 192 bytes * 750 packets = 144000 bytes per month at what speed/latency?
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 table…
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.
Earlier quoted context omitted.
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!
Inqtel also funds Anaconda, Mongodb and Gitlab, interesting
disclaimer: I work with In-Q-Tel investments almost daily, but am not affiliated.
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.
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_...
Earlier quoted context omitted.
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 us…
> 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 -…
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...!
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.
I literally watched a large excavator from a dealer break sanctions and show up digging in Iran.
Earlier quoted context omitted.
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 o…
Zstd dictionary mode? At small sizes using a dictionary is generally the way to go.