LoRaWAN fits exactly this use-case and depending on the region, can operate on any of the ISM bands. This article is very bare on technical details, but I'm so confused. LoRa's made so much effort in this space by literally mapping out every single ISM band they can (sub-GHz) and reaching out to regulators where they couldn't find a compatible match. Amazon can't possible think 900 MHz device is "free" globally.
LoRa is a great technology, with longer range and 1/10 of battery usage comparing to its major competitor, NB-IoT. NB-IoT is backed up mobile operators, as far as I know, in China they even outlawed LoRa to pave the way for NB-IoT because the latter can bring revenue for big guns.
I will be happy to see LoRA got more attention and used more widely. You can build your own LoRA network across large area with zero monthly fee once it is up and running, and you pay monthly fee to NB-IoT just like your cellphone plan, which one you prefer? Not to mention LoRA is technically better.
> NB-IoT is backed up mobile operators, as far as I know, in China they even outlawed LoRa to pave the way for NB-IoT because the latter can bring revenue for big guns.
it's everywhere, NB-IoT is a sub-standard of whatever the mobile operator is running(3g,4g,LTE,etc), the devices are installed along aside with those radios on the celluar towers, yes they're fully owned by your cell phone providers.
Is your question about how to avoid monthly fees with LoRa? You don't have to pay a third party if you've set up your own devices. Your private LoRa network would be akin to your private WiFi network.
For those of you in the UK or willing to travel, Andreas will be speaking at The Things Conference UK next month: https://thethingsconference.uk
We have discounts for various groups including Women in Tech and Students, so just contact the organisers and we can sort out any support that you need.
Because of broad signal spectrum LoRa has a built-in problem of handling large number of devices. I hope Amazon came up with something narrow-band, like SigFox.
Could you elaborate? I was under the impression that LoRa's slow updates result in a large number of devices being able to operate smoothly. Also, while the ISM band may be considered "broad," in a sense, LoRa takes a small amount of the band's width (low bandwidth), which translates into a long-range.
The problem is two-fold. First, LoRa is a spread spectrum technology that also has a problem with collisions. Spread spectrum is where the signal bandwidth of your transmission is higher than the information bandwidth, meaning your transmission's spectral efficiency is terrible. But usually spread spectrum systems are designed such that multiple transmissions can occur at the same time without colliding, so the network spectral efficiency is just as good as a narrowband system. But LoRa is a spread spectrum technology that still suffers from collisions, so the network spectral efficiency is really bad.
Second, LoRaWAN uses an ALOHA medium access scheme, which also suffers from poor network spectral efficiency compared to basically every other medium access scheme out there. So these two things combined mean that a LoRaWAN network probably won't be able to handle much traffic.
Almost all of the media I see about LoRa and LoRaWAN talk about the great range, which is really good, but then gloss over the network performance. So in my opinion LoRa is a bit too hyped at the moment. I also think that when LoRa came out, it was the only PHY that bothered to go down to really low bit-rates, and then the range basically comes from the Shannonn-Hartley theorem. People think that LoRa gets its range from some fancy signal processing tricks or whatever, but I think it's just the fact that they bothered to drop the bit-rate very low. That's basically what SigFox is doing as well, but they're using a more typical narrowband PHY and so probably won't suffer from the same network capacity problems.
The problem of LoRa is that is just slotted ALOHA, which maximum data throughput is only 36.8% of the available bandwidth. The more you transmit the more packets collide and data must be retransmitted in a spyral of death, so the system needs to operate using a small portion of the bandwidth not to collapse. Practically if everyone in New York would use LoRa and have dozen of devices in their homes using those bands, the bands would be jammed and nothing would work.
LoRa is just a PHY, LoRaWAN is the MAC. And last I checked LoRaWAN used ALOHA, not slotted-ALOHA, which is even worse. But I knew a few years ago they were talking about adding beacons to the MAC to enable slotted-ALOHA, so maybe my knowledge is out-of-date?
Maaaan, why in gods name do companies have to keep re-inventing the wheel. There's so many protocols and specifications out there already that they just have to pick one and improve upon it with the goal of making it backwards compatible with "older" versions of the protocol.
Are you sure they haven't "just picked one"? Amazon, and AWS in particular, have a long history of not reinventing anything, just packaging an existing open/free thing up and selling access to it.
I suspect the quickest way to find out if this is LoraWAN or Zigbee or Weightless will be to keep an eye on who switches to a Mongo/Redis style "commons clause" of "SSPL" license... ;-)
>> just packaging an existing open/free thing up and selling access to it.
Just like Apple packaging up CPUs and memory chips. I think most people in tech having a hard time to understand that UX is everything. You can take the Athena example of AWS, even though it is just PrestoDB the difference of UX is enormous. A data scientist (end user) cannot download presto compile it, create a EC2 cluster with failover push it there, configure it, performance tune it and keep updating it but she/he can got to AWS console and pull up the Athena interface and type in a query. This is why "just packing" is very important and people are willing to pay for it.
Oh, don't get me wrong, I'm not saying that like it's a bad thing. I'd _much_ rather be able to us their api to Ansible-up or point-n-click a MySQL database in RDS than to only have them offer some proprietary "Amazon Enterprise SQL Server". It's a good thing.
(I do, though, have some sympathy for the problems companies/projects like Mongo and Redis have where Amazon makes all the money off their products without contributing to the development of them. )
It's not as easy as "improving" existing protocols. Look at the ipv4 -> ipv6 mess. And even then ipv6 suffers from issues that are tied to how networks were built, etc. See this great article: https://apenwarr.ca/log/20170810
If I'm building something to give connectivity to dog tags, why not do something simpler?
What profit would companies have made if they'd privatized TCP and the internet as we know it never was able to take off?
A world in which you build an extremely valuable network which benefits everyone, is a world where the profit itself is more valuable, the value of anything is higher.
Um... this is HN. Half the people reading this want to develop their own proprietary protocol for something and become the next billionaire unicorn thingamajig.
Could be an implementation over Weightless-N which is open source, sub-GHz and works on the ranges this is supposed to work. http://www.weightless.org/
It has to be related to zigbee, zwave or LoRA, I don't think Amazon would be silly enough to reinvent the wheel. Probably one of the above with its own custom software stack on the tiny computer running it.
They only mention Bluetooth and wifi... Are we pretending zigbee and zwave don't exist? This just feels like an excuse to create yet another proprietary protocol.
How would that ever happen? They're operating on the same bands and are limited to the same wattage restrictions as everyone else. It's not like they purchased some private band that they can do something unique on.
That is if you have a few devices. But if you have a mesh network of 200+ nodes exchanging health and routing information and at the same time trying to send and receive some actual data, bandwidth quickly becomes a rather important concern.
I also forgot to mention the other big issue with sub GHz: certification. Each country has their own frequency, from 800-900 MHz. Unless you buy a pre-certified package, you’re looking at expenses for certs probably higher that cost cost of development.
Why is that an issue? Presumably firmware updates are at best a monthly occurrence. Why do I care if it takes two days to push? Just make sure you have reliable resume and error checking.
While this seems simple, most mesh network protocols use different routing protocols, network topography will be unique for every network, and even the nodes are ephemeral (especially if battery / mobile). All this means that your data throughput is highly unpredictable.
Assuming that you have a border router (or similar persistent member of the network) who is in charge of disseminating your firmware over the mesh, you can either go with an algorithm that is unicast or multicast.
Unicast can be tricky because you don't really want different firmwares running on the same network (especially if the firmware includes a networking stack update). It also takes a long time, because you have to send X bytes N times.
Multicast can easily flood a network, even with rate limiting, because the amount of hops or rebroadcasts required can result in exponential growth in network activity.
Simply extending the amount of time it takes is problematic. What if a device restarts? What if it drops off the mesh?You are definitely correct in that it is solvable. It is not incredibly simple, though.
> Amazon already sent out 700 test devices to households in LA to test the access points
I don't think it's a mesh. My first reading of this was the same as yours, but on a second read I think they've just set up a network of base stations, in the same way that something like LoraWAN works.
I'd personally be happy with email and ssh at low bandwidth if it worked everywhere. I don't stream video while I'm walking down the sidewalk or driving.
If the communication is bidirectional, you could include a GPS that only turns on when polled. That way, the GPS is only using power when you are actually looking for a lost dog.
It's not a tracker, it's an alert that your dog has left a perimeter at the moment it happens. It's a lot easier to track your dog down if you start the instant they get out of the yard.
LoRa can provide rough location data by tower triangulation, similar to our current cell phone location. Obviously not as accurate as GPS but better than nothing!
I'm building something similar (https://gethuan.com/) using augmented BLE and long range sensors. Maybe if I get big enough Amazon will buy me out. Ok, back to work!
A lot of devs these days have a similar mentality, and it's really, really sad.
I mean, I get it, getting bought out is how you get money. Competing is not an option. But in the end, it's like the only options in tech are to innovate for free (ie not sell out, but get copied) or innovate on your own dime and get paid way less than they make after buying you out.
Looks interesting; installed. I toyed around with gps/locator collars(findster) but unfortunately the quality was junky and the battery life was horrible, so I had no faith it would do its job when I needed it.
How close does someone with the app need to get to the tag before it phones home?(nevermind, FAQ says ~300 ft, which is really good. It seems like if you can see the animal, you can probably get it's beacon id?)
Do you triangulate positions from multiple users, or show a general track of the animal over time?
Are you partnering with big driving orgs (ups, Uber, etc) or parks departments to get more readers on the streets?
Can be several hundred feet in an open field, YMMV in an urban environment. On the other hand, I don't want to have too big of a radius in town, closer is better.
There's a reason you don't really see dogs wearing GPS collars - even with LTE-M, the experience is still not good and I don't think there's product market fit.
Absolutely - partnering up with Ride shares is on my roadmap, as well as sticking antennas in Drones and I'm filing a patent for automatically dispatching rideshares that can triangulate a missing pet even if there's no other sensors around.
Revenue is subscription based - people pay for higher range or custom tag designs. Making the product nice to touch and having multiple designs is extremely important. People really like that!
I think the last 30 years of development pushed us towards a inefficient high power usage direction that was not followed by a revolution in energy storage. The end result is that we charge our phones at least once a day. If energy storage was developing the same pace we would be charging once a year.
Your app appears to be incompatible with my Android smartphone. It's a fairly new, mid-range phone and I haven't had any issues installing other apps. Any idea why it might be incompatible?
Incompatible how? I'm testing using most poplar brands in the US, and haven't had an issue. Google Play also reports I'm compatible with most phone vendors but Android always manages to surprise me :) What vendor?
I'm not sure, Google Play just says, "This app is incompatible with all of your devices." Both devices are Xiaomi smartphones. My new phone is running Android 9.
There's two main reasons to prefer 2.4 GHz to 900 MHz. First, there's more spectrum available (100 MHz vs 26 MHz). More importantly, though, the 2.4 GHz license-free ISM band allocation is worldwide, whereas the 900 MHz allocation is Region 2 (the Americas) only.
Even out here in the rural part of the country, the 900 MHz band is already so crowded and full of interference. I can't imagine what it looks like in more heavily populated areas!
That's actually pretty disappointing to hear. I wanted to try using long range ISM with seismometers. I guess I can use directional antennas though, as the units are stationary after all.
[0]: https://lora-alliance.org/about-lorawan