Having an open-source communication device that is independent of any network and works without fees sounds like a hacker’s dream come true. Well, this is exactly what [bobricius]’ is aiming at with his Armawatch and Armachat devices.
Recently, [bobricius] built a LoRa based instant messaging device named Armachat. The gadget is controlled by a SAMD21 MCU with native USB and includes a QWERTY keyboard and an LCD display. Communication is based on an RFM95 LoRa transceiver which can reach a range of up to 2 km under ideal conditions. [bobricius] is a wiz when it comes to PCB design and one thing that makes his projects look so good is how he often uses PCBs as enclosures.
Armachat came in two form factors a large desktop and a smaller pocket version. The new Armawatch is another downsized version that perfectly fits on your arm by using a smaller display and keyboard. [bobricius] also did a lot of work on the firmware which now features a message delivery confirmation and the possibility to automatically resend undelivered messages. Future improvements will include message encryption, a store-and-forward function, and GPS position parsing. [bobricius] is also working on completing his portfolio of communicators with a credit-card-sized version.
LoRa is the go-to technology for off-the-grid communication devices and there are already other ongoing projects for using it to construct a mesh network.
if the communication speed (data rate) is very low you can communicate very far, there are even some coding protocols that supporting this over the lora layer
Yeah! I bet there’s some QRP techniques that might be able to wring a little bit more out of LoRa, considering the total bandwidth needed is tiny and that text doesn’t need to be a super real-time medium.
I’ve been working on something similar, but it’s for the RFM69 rather than LoRa. I believe it would be pretty easy to port, and might be useful here.
Security isn’t perfect, but I do have an attempt at replay attack prevention, and a low power beacon mode that is resistant to battery rundown attacks.
The way it works is instead of addresses, you have a “virtual channel” that is defined by the encryption key, and up to 256 nodes on that channel which can broadcast messages.
I also have error correction, switchable per-packet, automatic TX power control, and automatic configuration that works like Bluetooth pairing.
I don’t have auto TX power with multiple nodes on a channel though, it’s mostly meant to be used through a gateway node with only one device per channel, to allow using untrusted devices without giving them the whole network key like WiFi does.
Some of the tricks and methods I’ve used might be useful here, since I had IM as an intended use case.
https://github.com/EternityForest/SG1
Reported by fat fingers. Sorry.
Operation video https://youtu.be/j9qWJNcTHWI
That’s really cool. I’m always up for off-the-grid stuff like this. Is he doing store-and-forward yet?
Is it Cybiko compatible? Smaller screen and even worse keyboard. I hope its Lora gives it better range than the Cybiko, at least.
(has it been 20 years already? yeesh)
Cybiko! Holy cow, my kids had those. Wish I’d kept them, the form factor would be great for this.
lol, you’ve gotta be kidding! But you’ve made me want to dig up mine now. Wonder if I could possibly even find it.
I did something very similar but didn’t progress it. I recommend one time pad for peer to peer encryption.
This uses the LoRa network infrastructure. Doesn’t that mean precisely that it is “on grid”, not off it?
Hmmm it’s a bit like wifi, you can network two computers with it without necessarily being connected to the internet. There are LoRa network services, and there’s “peer to peer” LoRa as it were.
If you transmit and receive at random times with many repetitions you communicate over long distances at very low power with very low probability of intercept. If only the sender and the receiver know when to listen for a mark and space, intercept is difficult or impossible and if the same bit is sent 10,000 times, the processing gain will make up for using 1 mW.
how about each station repeats signals for the other stations? This way the more stations that are on the greater the coverage. It might use a dynamic mode where intermediate stations listen and when they hear (but not necessarily are able to decrypt) a message but do not hear an ack they retransmit that message verbatim. Once an ack is heard it is also retransmitted and is used to purge the message from buffers. Thought would have to go into storm prevention but it would be awesome to perfect it.
cheapest and better disaster.radio project
or pylife (smalest)
i really like this idea sadly im not tech savy enough to do something like this but damn this looks like a great one
Is there a reason that ‘Platform’ has an extra ‘t’?
Sorry if I’m being a bit thick.
I’m thinking it has something to do with the Platte River.
B^)
Back in the 1980’s I worked on a system for the military that included burst communications. We had a *ton* of error correction built in – an 8-bit byte expanded out to 32 bits with all the checksums. It was impervious to one bit errors and most two bit errors. It even did well with three bit errors.
If your message is limited to a reasonable size you can add this kind of ECC and get it to go past where it should since you can correct the errors as the signal fades.