Almost all of modern society is built around various infrastructure, whether that’s for electricity, water and sewer, transportation, or even communication. These vast networks aren’t immune from failure though, and at least as far as communication goes, plenty will reach for a radio of some sort to communicate when Internet or phone services are lacking. It turns out that certain LoRa devices are excellent for local communication as well, and this system known as LoraType looks to create off-grid text-based communications networks wherever they might be needed.
The project is based around the ESP32 platform with an E22 LoRa module built-in to allow it to operate within its UHF bands. It also includes a USB-based battery charger for its small battery, an e-paper display module to display the text messages without consuming too much power, and a keyboard layout for quickly typing messages. The device firmware lets it be largely automated; it will seek out other devices on the local mesh network automatically and the user can immediately begin communicating with other devices on that network as soon as it connects.
There are a few other upsides of using a device like this. Since it doesn’t require any existing communications infrastructure to function, it can be used wherever there are no other easy options, such as in the wilderness, during civil unrest where the common infrastructure has been shut down, or simply for local groups which do not have access to cell networks or Internet. LoRa is a powerful tool for these use cases, and it’s even possible to network together larger base stations to extend the range of devices like these.
“We have gone through several important stages of product development, which is very important.”
Did they have ChatGPT write their github page ?
Counter point: ChatGPT was trained on github readmes.
Hahahahaha now that makes sense
I think it’s all just poor translation. There’s a part about being able to add DIY add-ons, and it says “fast firmware (UART)” which I’m pretty sure was supposed to be “flash firmware (UART)”. Also “Li-po battery change” should be “Li-po battery charge”
Looks like these guys are in Kyiv, according to their user profile.
It’s from the Department of Redundancy Department.
ISWYDT 😉
Could have named it “Yet another lora chatboard” YALC.
Not a month goes by where I don’t read about a Lora enabled chat device.
Every time I see one I ask “why not just make a Lora dongle/modem (usb or bluetooth) for smartphones and/or laptops?” And then if that becomes a successful product category it can inevitably be killed when smartphones get it as a built-in feature.
Why would Lora need its own hardware beyond that point? Seems clear to me it is just a feature like wifi, bluetooth or cellular data.
Have you seen the PinePhone LoRa back cover?
Meshtastic already supports connecting your LoRA device over USB and use it as a dongle to send messages via LoRA to other similar devices.
The main issue is crappy USB serial support on phones, it depends on what version of what OS you’re running, some drivers may need to be manually installed. Bluetooth is pretty universal though.
That’s a good thing, more projects, more choice for people to use or contribute to :)
Yeah why do we have variety in our lives? It’s just a waste of time and effort. It would all be so much better if everybody did everything in the exact same way. Who needs new ideas or innovation or incremental progress anyway?
Did not say it is bad. It’s just not worth mentioning in this blog. Interoperable LoRa messengers for disaster relief would make sense. A ubiversal standard for Meshing LoRa messengers would make sense. A LoRa messenger that can actually use existing infrasructure (Helium or Things Network) would make sense.
But this here is just another hobbyist project that is incompatible to previous existing ones.
Wouldn’t make sense if every website created their own Transfer Protocol on top of TCP, would it? We have HTTP for a reason.
In the case of Lora, the restrictions are far harsher, so there’s a lot less room for YAGNI. To fit what you are going to need, you mostly have to leave out what other problems would have needed, and their solutions will have to leave out stuff you needed.
If you’re looking at Lora as a “send a message” abstraction, all those details seem like unnecessary complication, maybe even Not-Invented-Here syndrome. But if you’re trying to use Lora to send *your* message, in *your* environment, with *your* restrictions (all of which are subtly but critically different from the next guy’s case), you pretty much have to create your own custom solution that’s similar (but not identical with) what the other guy used.
Also, a lot of Lora’s “magic” range, power, and interference properties are only true against constant-frequency or classical variable-frequency transmission sources. In the face of large amounts of data being transmitted by other lora nodes *using the same parameters*, you start seeing significant message loss long before the channel is theoretically “full”.
Separately, the regulations in many jurisdictions are fairly harsh about a node’s transmit/idle ratio. In the EU, it’s 1% transmit (864 seconds per day) , and Things Network is much more restrictive: 30s transmit per day, and only 10 messages per day addressed to the node.
In the US, rather than duty cycle, the restriction is that no message can take more than 400 ms to transmit.
Some jurisdictions have rules about not being able to transmit for n seconds (or minutes) after even the briefest transmission, as well.
If you want to have a thousand nodes transmitting id,temperature,soil-wetness or something, Lora’s great. Use one of the low data rates (be limited to 11 bytes per transmission), and expect to see really long ranges (or very low power/short transmit duration; it’s a sliding scale)
If you want to have a few dozen nodes transmitting the occasional SMS, it still works well.
Use one of the high data rates (be limited to 242 bytes per transmission), and pick an appropriate spread for the range, power budget, and interference.
But the parameters for one are mutually exclusive with the parameters for the other. And both may conflict with mandatory parameters you’d need for Helium or Things Network.
And, if you try to do a thousand nodes sending occasional SMSes, you start seeing problems. It’s even worse if you try sending larger messages as multiple allowable-length fragments.
In a highly constrained problemspace (such as Lora), there are no universal solutions.
Universal solutions tend to have a cost. They gain their universality in the classical one-size-fits-all way: fit everything, just badly. The overhead lost to universality is often not a problem when you’re not operating near the margins of your constraints, and the convenience of having a toolbox of already-working modular solutions is often a big win.
But when you ARE right up against a margin (signal rate, power, noise sensitivity, etc), the tradeoffs you need are often not interesting to people solving for the “general case”. In that case, the existing solutions might as well not exist, since the problem you’re solving isn’t the problem they already exist to solve.
Oh, and to answer your final question:
“Wouldn’t make sense if every website created their own Transfer Protocol on top of TCP, would it?”
Yes, it would, in many cases. The websocket protocol exists specifically to make it easy to create your own protocol. It’s actually way of regaining a frame abstraction, and exists specifically so that everyone can keep using all their copious HTTP plumbing and solutions, while doing things where HTTP itself is a poor fit to the problem.
While it’s a pragmatically sound solution, protocol towers of hanoi only work well when constraints such as bandwidth, memory, etc are less expensive than programmer time.
Or, the TL;DR version? “it’s been a LOOONG time since HTTP worked well over 9600 baud dial-up.”
network stacks designed to work well with potentially gigabit (or higher) data rates and likely latencies of modern networks don’t work well at all when it can take more than a second to transmit any random packet (~960 bytes per sec), and half of those assumptions are on the other side of the link where you can’t adjust them.
for example Armchat https://hackaday.io/project/171790-armawatch-armachat-long-range-radio-messengers
One thing is undeniable. Many people want it.
This is a great idea (and I have existing plans from 5 years ago to make this exact thing).
I see problem with execution though. Too much complexity (and thus high cost). This is what I would do:
– Pick a cheap, highly available and highly configurable main CPU (RP2040 is a good candidate) to control everything (except Lora which is hard to come by integrated inside an MCU).
– Lora chip.
– Standard removable battery (AAA). A device made for disaster situations shouldn’t rely on an integrated battery that must be charged before usage.
– Sealed touch keyboard. Again, you want durability and reliability for this category of device.
– Lights and buzzers.
You’re not the first to think of this. There was a product, the Cybiko, back in 2000 that did just this (except with the tech of a quarter century ago).
Didn’t claim I was!
My contribution (should I find the time to do it) would be how it’ll be produced (as I detailed it) and that’s something that I haven’t seen anyone focusing on, specifically in context of disaster scenarios.
> A device made for disaster situations
My proposal is to remove LoRa and add HF slow CW or maybe another more efficient modulation like JT9. And to add banana plug for long external antenna wire.
This one looks very well thought-out. Credit-card sized, open, and hacker-firendly. Personally I love the e-paper and Qwerty keyboard. I’ll probably build one just to play with. Has anyone found a rough price for the BoM in the docs? Or a kit for sale?
It looks like a hackable version of the Cybiko! (which I only learned learned about thanks to XKCD.)
This is cool except there’s no protection diodes or fuses on the power inputs. The board’s designer needs to put a bit more safety into this design.
I want same, but for HF freq and with long antenna wire
There is already enough low power HF text protocols, for gods sake not another one….
But where is devices similar to discussed here, but for HF radio band?
Oh man I would definitely also buy/build an HF chatboard! Same format as this, but with a long wire antenna. Maybe not practical for texting while on the bus, but still awesome :-)
Is there a communication standard among all different LORA chatboards, or do they only work with others of the same model?
I can see a use for a really dirt cheap model you can spread around, equipped with a small solarpanel with a stand or suctioncup so you could place it in a window for it to be constantly charged.
I do not have many neighbours within range, OTOH I have plenty of antennas for different bands, so an UHF yagi pointed towards the nearest city center wouldn’t be impossible.
I do not agree that AA batterys are better then rechargables in a SHTF scenario, I have solar chargers with USB already, and 12V chargers for all kinds of batterys.
In a SHTF scenario, you have the ammount off AA batterys you have stored (and they are going bad) but sooner or later you will run out, and by that time the stores are empty because those who didn’t have batterys stored has already stocked up on fresh ones.
I have rechargables for everything, including 9V for my smoke detectors.
I’ve been trying to figure out the same thing: with all these LoRa communications platforms, are ANY of them compatible with each other? Can I take a LoRaChat and connect with a Meshtastic device a block over, who in turn is connected to the one person in the entire area with a Disaster.Radio device? While they are all using the same transport protocol, can they understand each other (barring message encryption)? I have no idea, there’s not enough users locally to experiment with, and I’m not buying/building one of each.
It seems to me that the ever-expanding option list of text-based comms devices using the LoRa protocol would do well for everyone to have some sort of interoperability capacity, if they don’t already. This is why standards exist. Could you imagine if Androids, Linux phones and iPhones were unable to communicate with each other? It would be like wireless telegraphy during it’s infancy, with multiple companies running services and refusing to talk to competitors (incidentally, that’s one of the contributing factors to the Titanic disaster).
I may be wrong and they do talk to each other which would be great.
Lora is a radio physical layer, not a communication protocol. All these devices invent their own mac layer (packet formats, exchanges etc) and so are incompatible. But that’s only a software problem…
It seems like it’s time to write a RFC! Also I do agree that having a standard protocol for communication among lora devices would be great.
> In a SHTF scenario, you have the ammount off AA batterys you have stored (and they are going bad) but sooner or later you will run out, and by that time the stores are empty because those who didn’t have batterys stored has already stocked up on fresh ones.
The nice thing about AA batteries is that they have long shelf life. That’s why it think it’s useful to have an AA-to-USB boost converter in the parts drawer. They cost $0.99 in single quantities after all.
And if I designed a device designed for SHTF scenarios it would have a buck-boost converter accepting anything from a half full AA battery, through a 9V battery to a 48 V telco equipment backup power supplies.
potato batteries
“…networks aren’t immune from failure though…”
* immune _to_ failure, you mean.
if add solar panel and some removable battery and usb input output
firmware https://reticulum.network/ and add keys altGR for other language and utf8 https://en.wikipedia.org/wiki/AltGr_key it meybe will be works.
But liligo make a T-Deck https://www.lilygo.cc/products/t-deck