Instead of a trivial use-case of existing technology it would be far more beneficial to model (1) RF subscriber characteristics and how an unmanaged network of point-to-point devices can support crisis communications when a potentially (very) large number of devices can flip over to long-range point to point. How is congestion managed and mitigated? how is available spectrum, channel space and bandwidth most effectively used?
And (2) The paper mentions an upstream message board and the underlying networking features provided by DTN7 describe a range of routing protocols. If nodes are taking part in a self-organising mesh network that can route in and out to central services then the management of layer-1 & layer-2 is crucial to maintain a working network. It doesn't model any of the characteristics of the medium and any strategies for how the underlying physical characteristics can be leveraged to support a mesh.
LoRa is excellent at long range, but with Long Range transmission comes a greater opportunity to interfere with other transmissions. Sure you can reach a long way so a low number of rural casualties can be serviced effectively, but what happens when you have a dense urban scenario and there are 10's/100's/1000's of nodes all hitting refresh on twitter and they are all interfering with each other and the few low-bandwidth gateway nodes are attempting to carry the traffic?
> 10's/100's/1000's of nodes all hitting refresh on twitter
That's not going to happen with Lora. This it completely different scale of messaging. Your message is limited in bytes and takes multiple seconds to transmit. You can assume the messages will be significantly delayed if 100 people around are actively using it.
But it's designed for a specific purpose and there's no active refreshing/polling that's going to happen.
Mostly what we need is fewer restrictions on some better radio frequencies. Legalizing encrypted Ham radio would be a good start. If there was an ecosystem of infrastructure around those frequencies, we would have no problem whatsoever building robust mesh networks with higher bandwidth that could operate uninterrupted through crisis scenarios.
As it is, we've been left with scraps; and this article describes an amazing tool which shouldn't have to exist.
I used to think that allowing encrypted ham radio would be a good idea, but the more I think about it, it isn't. It's supposed to be a place for radio hobbyist experimentation. To permit encryption there would see it used for commercial applications pretending to be hobbyists, and other exploitation outside its purpose.
I feel that other solutions would be better, for example having bands for community mesh networking or similar that has different restrictions to the ISM bands. No idea really how the mechanics would work, but I feel that allowing encryption on ham bands would just see it abused to the detriment of its actual goal.
I think selling it as a communicator for skiing/hiking is maybe a better idea than as a disaster radio, solely because a disaster radio is never really going to be used. If it's a useful, well used system that happens to be highly resiliant, that makes it much more likely to be available when a disaster hits.
yep - I'm one of the meshtastic devs and that was our thought as well.
* use off the shelf hardware, so user can just buy a finished device from China
* make it cheap
* Make something useful for people in general (without disaster) - then they will have it when the disaster happens.
GoTenna is definitely similar in its use-case and appearance.
The problem with GoTenna is similar to FireChat for offline communication: they are closed ecosystems, single purpose and cannot easily be changed to fit specific needs.
If you need something consumer-grade, ready to use: go for GoTenna (or Sonnet or maybe even a Garmin InReach or Spot X).
We propose different proof of concepts in the paper that are nowhere near the product quality of commercial solutions. Also, the chat application is single-hop and does not yet use a DTN underlay, at least not in the published version.
But all code is open and can easily be extended. Even better, the rf95modem firmware is designed to be used as-is. Once loaded on a LoRa board anyone can implement anything over device-to-device LoRa, be it a msg app, local news broadcast, IoT monitoring. This works via AT commands over USB serial interface, local esp32 WiFi or BLE.
I like the solar integration. My ideal product would be a programmable LoRa transceiver integrates into a waterproof battery bank with solar, gps and a small touch screen. Should be about the size of a large handheld which could mounted on a house, tree, mast or carry it in a pocket/bag. Apps could be, SOS messages, chat and weather information. If it’s extensible (e.g. something like an app store or package manager), I’m sure folks will dream up additional uses.
Sort of like a more hackable/accessible phone and long range radio.
So... what exactly is the crisis scenario this is modeled for?
I can't come up with a reasonable situation where mobile networks are completely f*cked, yet my smartphone is still running medium- to long-term. Maybe I'm not creative enough.
(The only thing that comes close is a large-scale power outage, but then after a day or two my smartphone battery is dead too. Also, the same measures to revive the smartphone [solar backup, generators, etc.] can also be used to revive the mobile network...)
[Add.: what definitely makes sense is a _dedicated_ LoRa-based emergency network, which uses dedicated user agents with low power draw and long-term batteries. Just ditch the smartphone?]
> An opkg (for e.g. OpenWRT) with this mesh software would make it possible to use WiFi/LTE routers with a LoRa transmitter/receiver connected over e.g. USB or Mini-PCIe.
I don't understand what the contribution of this paper is. The most important thing, a scability test, is missing. You don't need 16 pages to describe a LoRa-based device-to-device messaging application.
robshep|6 years ago
LoRa is excellent at long range, but with Long Range transmission comes a greater opportunity to interfere with other transmissions. Sure you can reach a long way so a low number of rural casualties can be serviced effectively, but what happens when you have a dense urban scenario and there are 10's/100's/1000's of nodes all hitting refresh on twitter and they are all interfering with each other and the few low-bandwidth gateway nodes are attempting to carry the traffic?
viraptor|6 years ago
That's not going to happen with Lora. This it completely different scale of messaging. Your message is limited in bytes and takes multiple seconds to transmit. You can assume the messages will be significantly delayed if 100 people around are actively using it.
But it's designed for a specific purpose and there's no active refreshing/polling that's going to happen.
ColanR|6 years ago
As it is, we've been left with scraps; and this article describes an amazing tool which shouldn't have to exist.
eythian|6 years ago
I feel that other solutions would be better, for example having bands for community mesh networking or similar that has different restrictions to the ISM bands. No idea really how the mechanics would work, but I feel that allowing encryption on ham bands would just see it abused to the detriment of its actual goal.
kitotik|6 years ago
leoedin|6 years ago
https://news.ycombinator.com/item?id=22540066
I think selling it as a communicator for skiing/hiking is maybe a better idea than as a disaster radio, solely because a disaster radio is never really going to be used. If it's a useful, well used system that happens to be highly resiliant, that makes it much more likely to be available when a disaster hits.
punkgeek|6 years ago
* use off the shelf hardware, so user can just buy a finished device from China * make it cheap * Make something useful for people in general (without disaster) - then they will have it when the disaster happens.
fragmede|6 years ago
https://gotenna.com/
gh0st42|6 years ago
GoTenna is definitely similar in its use-case and appearance. The problem with GoTenna is similar to FireChat for offline communication: they are closed ecosystems, single purpose and cannot easily be changed to fit specific needs. If you need something consumer-grade, ready to use: go for GoTenna (or Sonnet or maybe even a Garmin InReach or Spot X).
We propose different proof of concepts in the paper that are nowhere near the product quality of commercial solutions. Also, the chat application is single-hop and does not yet use a DTN underlay, at least not in the published version.
But all code is open and can easily be extended. Even better, the rf95modem firmware is designed to be used as-is. Once loaded on a LoRa board anyone can implement anything over device-to-device LoRa, be it a msg app, local news broadcast, IoT monitoring. This works via AT commands over USB serial interface, local esp32 WiFi or BLE.
nanomonkey|6 years ago
state_less|6 years ago
Sort of like a more hackable/accessible phone and long range radio.
eqvinox|6 years ago
I can't come up with a reasonable situation where mobile networks are completely f*cked, yet my smartphone is still running medium- to long-term. Maybe I'm not creative enough.
(The only thing that comes close is a large-scale power outage, but then after a day or two my smartphone battery is dead too. Also, the same measures to revive the smartphone [solar backup, generators, etc.] can also be used to revive the mobile network...)
[Add.: what definitely makes sense is a _dedicated_ LoRa-based emergency network, which uses dedicated user agents with low power draw and long-term batteries. Just ditch the smartphone?]
westurner|6 years ago
> An opkg (for e.g. OpenWRT) with this mesh software would make it possible to use WiFi/LTE routers with a LoRa transmitter/receiver connected over e.g. USB or Mini-PCIe.
tralarpa|6 years ago
pabs3|6 years ago
unknown|6 years ago
[deleted]
crtlaltdel|6 years ago