Using LoRa frequencies to leverage the reach of briar

changed the description

@akwizgran tried with a small LoRa adapter once and only got very bad range.

@grote You tried this with Briar? Have you anything documented about that? Would you mind to write a few words? I'd like point others to it, in hope it might catch their interest to play around getting LoRa for briar.

I did play with LoRa, but not with Briar. Like I said @akwizgran had played with it. @chas9 (in mattermost) is currently working getting LoRa to work with briar.

I did some experiments with an ISM band radio module - I don't think it uses LoRa. But I gave up pretty quickly, before trying any Briar integration, because I couldn't get long enough range for practical use.

My experience is that we get pretty good range with the right antenna. I would love to see briar support via meshtastic®

https://meshtastic.discourse.group/t/practical-range-test-results/692

Using meshtastic and LORA I've achieved a range of more than 10 miles usings a mesh node on a mountain side overlooking los Angeles. Briar and LORA seems like the next natural progression. check it out ! https://meshtastic.discourse.group/t/my-giant-battery-node-ive-place-on-a-hill-in-los-angeles/1513

If I remember correct, the person that made those two prototypes shown in the image and in the video says, they reach 1-2km and can be used for around 8 days before recharging.

added T: feature request Usability User feedback labels

removed Usability label

some input from a user at mastodon:

"If you want to implement longer range without internet, i would use ham radio. Ham is widespread, and gets busy in crisis, so one sender does not stand out. The other traffic is good camoflage. Cheap portable trancievers are sold worldwide under 50$. Even self built analog devices or grandpas old ham radio would do. The only connection needed is an audio cable plugged into the headset jack of phone and ham radio. https://en.wikipedia.org/wiki/List_of_amateur_radio_modes#Text_and_data"

source: https://fosstodon.org/@rudolf/105595238840745932

While the use of LoRa requires a specialized device , that is unlikely to be commonly available (at least for now), I'd like to encourage exploring the use of Walkie Talkies as a means to leverage Briar's reach, too.

Why Walkie Talkies?

they are commonly available and relatively cheap
many people/collectives have such a device already
Walkie Talkies are commonly used at protest sides to organize
Walkie Talkies are useful at its own, even if the smartphone breaks

Thanks for the suggestion, I like to add:

LoRa devices have much better range
encryption is allowed on LoRa frequencies
Briar is also not running on Walkie Talkies if the phone is broken
LoRa devices are very low power and very cheap, they also come preinstalled with meshtastic, so no hassle for new users

It might be worth to check out what the PINE64 community is working on. They seem to explore to make LoRaWan integral part of their future hardware. (Pine64 builds smartphones, labtops, tablets, single-board computers...)

To quote from their Feburary report:

LoRa and LoRaWAN PINE64 Ecosystem Integration

In the past 6 months I’ve mentioned LoRa and LoRaWAN on many occasions and in multiple posts. If it wasn’t clear until now, we have been quite interested in the technology and its potential for novel applications. After extensive internal considerations, we now feel ready to double-down and make LoRa an integral part of the PINE64 ecosystem. I’ll explain a bit more about the core premises of our vision further down in this section, but let me start by writing about the actual equipment we’re planning to deliver. For one, we will offer next generation modules for all our devices – this includes, but is not limited to, the PinePhone, the PineTab and Pinebook Pro. We will be using next generation LoRa chipsets in our expansion modules, which deliver better performance while consuming less power. We will simultaneously introduce LoRa modules for North America, Asia and Europe, that conform to the respective regional regulations.

We will also build our own LoRaWAN base station, which too will utilize next generation LoRa technology. This chipset does not only allow for higher efficiency and lower power consumption, but also for an improved data-transfer rate when compared to presently available technology. We intend to introduce two versions of our base station, the first of which is intended for deployment indoors, while the second arrives enclosed inside an aluminum waterproof container for use outdoors. The theoretical range of the base station is measured in tens of km’s, at least in unobstructed line of sight. That said, a range of 5-6km is much more realistic in most scenarios due to terrain and other obstructions found in urban areas. As you have come to expect from us, the brains of the base-station will be running FOSS software atop of mainline Linux.

So, then, why are we doubling-down on this? While LoRaWAN is usually used for a variety of IoT type deployments, we wish to use it for text-based communications. In its implementation we expect the functionality to be more akin to HAM radio rather than SMS or instant messaging. Most importantly of all, however, we see LoRaWAN as a means for communication without a middleman. To allow communication over vast distances, each base station can be connected to the internet. We hope that, in time, urban areas will see some degree of coverage and that people will be willing to join in on the fun. And yes, in the initial phase of this experiment, the purpose of LoRaWAN stations is to have a bit of fun, whilst simultaneously exploring the limits of the technology’s application for communication. Needless to say, getting developers onboard to support this novel implementation of the technology will prove crucial. Over the next months I’ll do my best to convince relevant parties that it makes sense to explore this LoRaWAN application and that it may be a first step in rethinking secure communication mediums.

full report: https://www.pine64.org/2021/02/15/february-update-show-and-tell/

PINE64 is about to bring LoRa to all their devices. They are also going to build LoRaWAN base stations.

we wish to use it for text-based communications

Needless to say, getting developers onboard to support this novel implementation of the technology will prove crucial.

see the reply above, there's a complete quote from their Feburary report about LoRa. @akwizgran @chas9 @grote

Update from PINE64: "LoRa back cases available in June" https://www.pine64.org/2021/05/06/lets-make-mirakles-happen/

@syster thank you for these sources! I wonder if Pine64's base stations could be configured in a p2p internet mesh similar to ipfs or bittorrent DHT to bridge gaps between cities and countries (while the internet is up). Also could be interesting to research how LoRa gateways connected to a wifi based mesh system like Qaul.net or sudo mesh impact the resilience of an offline communication network.

it's a while I read about Pine64 base stations, but as far as I remember their goal is meshnet.

Some relevant projects I found while researching LoRa as a transport layer:

RNode

This is an open source LoRa hardware device with additional open source tools for Linux. Using the RNode config tool you can use a LoRa radio as a normal USB networking card on a Linux machine and make connections to other nodes using IP addressing.

Packet radio network stack

This project connects a wide range of radio devices and modems into a radio network, from the readme it supports: "Data radios, modems, LoRa radios, serial lines, AX.25 TNCs, amateur radio digital modes, ad-hoc WiFi, free-space optical links and similar systems" I'm still very new to packet radio but it could be interesting to see how they make their program accessible to such an array of devices.

Android LoRa Messenger

This project uses a LoRa radio connected by USB to an android phone as the transport layer for it's android messenger app. Similar to how I imagine the Briar mobile app would use a LoRa radio. Unfortunately this project is closed source.

@paul-lorenc thanks, that's great research! Any idea what bandwidth can be achieved over what distance?

I had a look at 3 and wonder how to assign the node IDs without a central instance.

The RNode creator managed to achieve 2.6 kbps at a range of 15.75km using two RNode devices. One with a 2m tall Diamond Antenna X200 at his house, and a car mounted Diamond NR770 antenna. I'm not sure how many bits are passed in a Briar handshake, but they were able to finish a SSH handshake in about 40 seconds. He was able to use 21.8 kbps at shorter distances.

A Youtuber Davy Wybiral used a slightly different LoRa board with the out of the box antenna and found a range of about 0.72km in an urban setting. Shown here. It's also worth noting any LoRa radio can also be used as a repeater by swapping the software. Mr. Wybiral has a video on a quick and simple repeater here

Hi,

great to hear there's interest about LORA, it feels as if this would be a needed option in the nearby future as there's much talk about internet falling down/not functioning/etc.

as far as I've learned LoRa can reach 50-60 km .

Would be very happy to hear about some progress :) .

Hello! I’m currently iterating on a basic LoRa transport here if you are interested: https://notabug.org/paul-lorenc/lora-rose Currently works with Heltec ESP32 LoRa devices connected via USB to Linux computers. Working to add android support.

if its of any help i know that there are ways to bridge between IP devices and LoRa devices..

LoRa radio parameters and how they impact range and bandwidth:

I'd be particularly interested to see Briar working over Meshtastic. As a data point, I've sent messages over ~8km using ~$30 hardware.

The ad-hoc mesh network makes it much more interesting to me than a Star network.

For completeness, I'll also mention https://disaster.radio/ which I used to be involved with, but is mostly inactive now. The transport layer is this: https://github.com/sudomesh/LoRaLayer2 The documentation was pretty good: https://github.com/sudomesh/disaster-radio/wiki/Protocol It is also available as an Arduino Lib.

just some thoughts on bandwidth: voice call is an requirement for time sensitive information, in situations that require high awareness about the environment, and that require you to move anytime, while communicating.

Basically conflict zones require voice call. Obviously not for everything, and text only is still useful, but there's still the need for voice call.

For completeness of this thread, I'd like to mention Wi-Fi HaLow a relatively new WiFi standard (IEEE 802.11ah) for low power consumption and wide range of transmission. https://en.wikipedia.org/wiki/IEEE_802.11ah

Did you recognize PicoAPRS from the ham Taner Schenker, DB1NTO? APRS in Wikipedia. When it is available it will be sold for ~350€ from Wimo. I guess the price is a nogo for briar user and stops all discussions and blocks any development.

Since it is for hams using about 144MHz in Europe, I was thinking, if it would be possible for the vendor to lock the device to ISM frequencies and create a device usable by non-hams. Because of the price this is just for the records.

The Reticulum project is maturing well.

Now usable with Android app (Sideband)
Over the internet
Or with ~$20 LoRa devices

Briar could talk to the Reticulum API. https://reticulum.network/

Hello everyone

PicoAPRS uses the original MicroAPRS modem I wrote back in 2014 or so. Taner licensed it from me when he designed PicoAPRS. The device is basically build around the MicroAPRS firmware with some additions wrapped in a nice package with a radio transceiver and display.

While there are definitely use-cases, and PicoAPRS is a great device for stuff like actual APRS, it is not a good general-purpose solution for Briar, or as a general purpose communications device, for the following reasons:

The firmware platform lacks several functions needed for reliable general purpose communications. PicoAPRS can get away with this since it is mostly used for APRS, which is a very, very simple "send-and-forget" protocol.
If you really want to run a system like Briar over packet radio, a much more usable platform would be something like OpenModem, which lets you build a more powerful, general purpose AFSK modem.
That being said, Using AFSK1200 modulation on the ISM bands is not really a viable option for Briar or other more complex applications. It works really well in an amateur radio context (or when you have licensed spectrum available), but you do need a lot more output power for it to work well over usable distances. The ISM frequencies are quite limited in allowed output power.

A much, much better solution is to use modern modulation schemes like LoRa or 802.11ah. RNode is a great example of an open platform that creates a general-purpose, long-range data transceiver from all kinds of LoRa hardware.

In the near future, the RNode platform will support several other PHYs, like 802.11ah, raw 2.4GHz, ESP-now, and even various "raw" G/M/FSK schemes.

Something like that is a lot more useful, since you can actually shape it into a product that can be viable commercially, within the various different regulatory frameworks that exist when dealing with RF devices. Laws and regulation on the area are complex, and often very harsh against creating actually useful devices. You need a lot of flexibility and headroom to get around that, and a decades-old 1200 baud modulation-scheme is not going to fare well in that, unfortunately.

Don't get me wrong, I am very fond of 1200-baud AFSK, having written and published several software and hardware implementations of it, but it's uses does have limits :)

And as a follow up to the above, once you start using any sort of data exchange system over wide-area networking with open access (anyone can join and communicate), you need some sort of system that can actually handle that. The Internet Protocol cannot, neither IPv4 nor IPv6 will work well in a situation like that. They are also very inefficient with bandwidth, and require way too much "chattiness" to work over very slow mediums like LoRa.

Here's an example: Someone joins a wide-area radio-based network to send a briar message. IPv4 simply has no reliable way of handling this. In an IPv6-based system, everyone now needs to know and agree on a new address for this device, which results in several dozens of packets being exchanged before the device can even start sending a message. As a result, the physical channel is now congested and communication breaks down for everyone. This is obviously not workable. Let's not even start looking at what happens when you try to set up some sort of encrypted channel between devices.

Reticulum is currently the only protocol that offers modern functionality, an easy API, and actually works for open-access, wide-area networks. If there is any interest in integrating it into Briar in the future, I will be more than happy to answer any questions and help guide things as good as I can.

For an example of some of the things that are possible with Reticulum, you can also have a look at the Sideband app. I made it as an example of how you can create a messaging system that runs purely over Reticulum. It already supports all kinds of physical mediums like LoRa, packet radio, local WiFi and Ethernet, paper message transport and more.

Hi Mark

I guess your assessments are right and I don't know the briar protocol, but there is a way to copy briar messages to e.g. USB storage and transport the stick (sneakernet ;) ). Isn't that a fire and forget, too?

The firmware platform lacks several functions needed for reliable general purpose communications. PicoAPRS can get away with this since it is mostly used for APRS, which is a very, very simple "send-and-forget" protocol.

but there is a way to copy briar messages to e.g. USB storage and transport the stick (sneakernet ;) ). Isn't that a fire and forget, too?

Very good question! You are completely right, actually. But the key difference to note is this: In that situation you have (literally) over a million times more bandwidth available, and nobody else to share the channel with. Then you can do stuff like that.

With a shared channel of only 1200 bits (150 characters) per second available, stuff like that is only possible if you are of an extremely patient mindset, and don't care about your messages actually reaching anyone ;)

mentioned in issue #2359

Some more ideas:

Vision: Enable Briar to be my single messenger solution that I can use both at home when connected to the internet and also when away from the internet. When away from the internet, Briar should keep on working with my well-known contacts who are hiking with me in a remote place - or maybe even within a rescue organization that is deployed to a place where the mobile phone network and the electric grid are dead.

Hardware:

Normal Android mobile phones with Wifi and Bluetooth capability.
Cheap LoRa modules (e.g. Heltec LoRa 32 V3 for 20$), one per team. (A team being all people that are typically close enough to each other to be able to use Briar via Wifi or Bluetooth.) Communication between teams is provided via LoRa through the phone of each team's "LoRa operator".
If needed, additional cheap LoRa modules are placed on tall objects (houses, poles, mountains) to act as repeaters.

Software:

On each mobile phone: Briar app.
On each LoRa operator's phone:
- Meshtastic app.
- Briar forwarder plugin. This plugin would use a plugin interface that would have to be added to Briar. The plugin would be similar to the ATAK Forwarder, see https://meshtastic.org/docs/software/community/community-atak
On all LoRa modules: Meshtastic firmware.

Known challenges:

Coding of plugin interface for Briar required. This could be based on ATAK's plugin interface.
Coding of forwarder plugin required. This could be based on the ATAK Forwarder.
Maybe some radio discipline is required when using the system, as bandwidth is limited.

@thorn, this is exactly how the Sideband app (built on Reticulum) works. All of those things you speak of already work.

There's no need for cumbersome forwarders or a lot of convoluted configuration, since everything is running over Reticulum, which automatically handles network topography, routing, bridging, forwarding and even roaming between different interface types such as between your WiFi, LoRa radios and the Internet.

The Android version can also act as a router/ap/hotspot for any of the supported interfaces (including LoRa radios) in Transport mode.

I thought you might be interested in that

Rather than a quite complex setup using Meshtastic, ATAK plugins, and all kinds of other stuff glued together, I think Briar would be a lot better off with just using something like Reticulum directly, since it is so much better suited to handling stuff like this in a way that actually scales and remains stable in a lot of different conditions.

@unsignedmark Thanks, interesting project.

I tried to read through the available documentation and then search more info on specific aspects. This is not easy, because the name "Sideband" of the app is quite generic in the field of communication and "RNode" is apparently interpreted as a typo of "node", which is again very generic.

Some questions:

Do I understand correctly that the Sideband app currently only handles one-to-one conversations and does not (yet) support groups or forums? Also, Reticulum currently only has very limited support of this (as stated under "Group" on https://reticulum.network/manual/understanding.html)?
Do I understand correctly that RNode can only serve as a "transport instance" (Reticulum term) or router or repeater (Meshtastic terms, see https://meshtastic.org/docs/settings/config/device) if it is accompanied by an Android device running the Sideband app set to "Enable Reticulum Transport"? (based on this discussion: https://www.reddit.com/r/preppers/comments/10h1mpx/rnode_is_a_free_and_open_source_selfreplicating/ )

Some ideas:

My impression is that the Briar app has a more advanced look and feel, which probably makes it easier to use than the Sideband app. Therefore, it might be interesting to add support for additional communication stacks (Meshtastic, Reticulum, ...) to Briar. However, additional communication stacks should not be added to mainline Briar as long their code is under development (requiring frequent updates) and their security has not been audited to the same standards as mainline Briar. A plugin interface might be a solution to allow flexible extension without compromising integrity of the main Briar app. Therefore, it might be interesting to review an existing open-source messaging plugin interface like the one used between ATAK and the ATAK Forwarder plugin.
It would be good to have structured and compact documentation available that provides an overview of the concepts of Sideband/Reticulum/LXMF/RNode, maybe in a similar way as provided for Briar and its stack, see https://code.briarproject.org/briar/briar/-/wikis/home and https://code.briarproject.org/briar/briar/-/wikis/A-Quick-Overview-of-the-Protocol-Stack . (This structured documentation might trigger more intuitive naming of the terms used for the parts of Reticulum, e.g. LXM format = LXMF, LXM protocol = LXMP, LXM system = well, that's Reticulum, right? Please excuse if I'm nitpicking, this is probably an occupational disease in my job :-) I suppose that a discussion of this idea should probably take place on a Reticulum forum instead of this Briar forum.

I think it was never posted here: This is the only known working Briar prototype that worked over LoRa:

Using LoRa frequencies to leverage the reach of briar

issue:

example of possibilities:

Designs

Child items 0

Activity