Portable standalone messenger with Lilygo T-Deck

[maxbrito500]

Hello,

Since some months that Lilygo released a blackberry-look-alike ESP32 that includes LoRa builtin called "T-Deck". I've got two units to start experimenting for usage within our local community. The price is a bit heavy, especially after adding batteries and a 3D printed case but might still be worthwhile as efficient replacement for subscription-based corporate networks.

There is a LoRa messenger video and code sample here:
https://www.youtube.com/watch?v=XVYZG4bfNpA
https://github.com/moononournation/T-Deck

The code had a small bug, so attention in case you still try to use the current code without the needed changes:
moononournation/T-Deck#6

That will provide a basic LoRA messaging between devices, which is fairly good enough for an off-grid community. However, it would be good to have features like private messages, contact list and extender nodes. Meshstatic promises these things and even has crude support for the T-Deck, however, I'm just not happy with the platform limitations since a good while and thought this might be a good opportunity to (finally) learn more about Reticulum and the promise of connecting through any kind of airwaves, wires and whatever comes. For me that is an accurate future-proof-thinking and big kudos to @markqvist. Even the custom webpages served by reticulum are fantastic for off-grid where we often want to showcase more details about the location, basic rules/principles and other much needed info.

I've really enjoyed the connectivity options of Sideband/nomadnet on Android and Linux through the GUI/CLI. Makes me feel right at home since within off-grid communities you basically work with whatever is available, which are laptops, cellphones, amateur radios and some fancy LoRa handhelds if we are lucky/prepared in advance.

With this said: Would anyone here volunteer to implement a basic standalone messenger with reticulum on the T-Deck?

If so, in return I will donate one of those T-Deck handhelds for the prototype experimentation.

The GUI for ESP32 is basically available with the demo source code listed above and I'll help with the customizations. If this is done for the T-Deck, porting the messenger GUI to other ESP32 devices with touch-screen and LoRa modules is really easy.

In case someone was already doing this in the past, just me know.
Looking for similar topics was only finding options using the RNode and a topic like this: #396

Many thanks in advance.

[Greenville71]

I could have a crack at it. I've actually been trying to build something similar to this for a while, but lack hardware.

[maxbrito500]

Thank you, can you show experience on similar tasks? Your profile only shows 4 empty repositories.

[cobraPA]

This is on my -would be neat to do- list. But there are some caveats currently (Mark may also point these out.) The network stack for Reticulum presently runs over Python on the target OS (Win/Mac/Android/iOS), there is not a full port yet for ESP32 devices. There is a project to get some of that (maybe all of it someday) working. That covers the network layer mostly, but then the user interface will also need to be setup (also mostly in python/kivy/kivyMD) now. So may be do-able, but not a trivial task either.

[markqvist]

Sideband directly on an ESP32-based device is unlikely due to the Kivy GUI framework not being ported to ESP32, and the fact that it depends on OpenGL for graphics rendering.

A more manageable and likely approach would be to create a new LXMF client specifically tailored for small, low-power devices. LXMF itself could run fine on an ESP32. Couple that with a GUI written in LVGL, for example, and you'd have a nice portable messaging device.

[faragher]

Bear in mind that the display is only about 1.6 inches high. While I'd love to say just make a 40x25 terminal display and tie that into a LXMF backend, I worry about legibility. I'd be very interested in this terminal system, but wouldn't accept hardware from anyone, since I can't promise it'd be a priority project.

I suppose I could work on a library that just took commands and exposed a frame buffer so other applications can simply push data or pull to a display routine, but again, projects here are a grab bag.

[faragher]

Never mind! FabGL is the key. https://github.com/fdivitto/FabGL

Has a VT100 terminal emulator already in play, and supports both VGA and SPI LCDs. I have a few of their VGA boards, so I could do some terminal prototyping although there's no LoRa on board. I suppose I could try to hook up a HopeRF95W and give it a try, but it's sounding like this is more of a long-term project, so I don't suggest anyone wait for me. :D

Still, highly suggest someone look into FabGL for an LXMF terminal. If there's a standard, build to it.

[cobraPA]

A more manageable and likely approach would be to create a new LXMF client specifically tailored for small, low-power devices. LXMF itself could run fine on an ESP32. Couple that with a GUI written in LVGL, for example, and you'd have a nice portable messaging device.

I haven't looked at LXMF clients other than Sideband... would it be much work to have them connect to local Lora on the device?

[faragher]

Yes and no. The LXMF clients I've seen are closely linked with Reticulum, and that means using the main libraries to save time. That being said, it's not as much work as making a real network stack on an ESP32.

My understanding is this would be the program logic, and yes, it was quicker to make a flow chart than make it intelligible otherwise.

This is what I belive is a simple functional receive interrupt. Now, what you actually want to do is store the message and put up a flag to do the processing later. The ESP32 has very tight watchdogs on interrupts. But as a logical process, you can see it's very simple, you just need to run a few cryptographic processes and can ignore 99% of Reticulum. You don't even need a full identity, just a private key. To send is more complicated:

There's a lot of complications hidden in there, such as how you encrypt, how you send, if you get confirmation (which is actually part of the RX system). But generally speaking it's all straightforward work except the public keys and path. You can probably ignore most of that with opportunistic messages, group destinations, and just assuming the transport nodes know what's going on, but at some point you lose a lot of the advantages Reticulum offers.

However, porting over the LXMessage library from Python to C would be much faster than the whole network stack, and from there you mostly need the path/identity request features.

So really the LoRa connection isn't much of an additional problem over pure LXMF processing. The RNode firmware takes care of all of that, so either using it as a library or connecting via serial makes for a pretty easy integration.

[maxbrito500]

I've been gathering feedback from other portuguese off-grid groups on this topic. In addition to the standalone messenger we'll likely adopt a hybrid network as seen on the sketch (my apologies for the drawing skills) as a first building block. Our ultimate goal is connecting Coimbra to Lousã along the metrobus line being built between the mountains (about 30 kilometers) since our region is home to plenty of off-grid communities and we've been talking about the topic of autonomous networks since years now.

For now would see as feasible to place an RNode at each tram station (roughly 1~3 km apart from each other). I'd likely try to modify RNode to become a Wi-Fi hotspot and BLE beacon that connects to android phones. Each base station is expected to be autonomous (own solar energy, own storage / sensors) and maintained by a volunteer. These stations can provide weather info (e.g. temperature, lightning detector) but also get "gaming" features such as guest books (similar to geo-caching), their own webpages (with news and interesting stuff maintained by the volunteer) and hopefully some asynchronous text-based games (similar to BBS to those familiar). The idea is to keep the network interesting and fun, serving as entry point for more serious off-grid usage like chat messages and sharing images.

I've been looking to adopt reticulum everywhere because it works fantastic right on the first run. Just haven't been able to use bluetooth for android to android connections yet, that would be very helpful for direct interaction between spontaneous people on the outdoors without needing to connect with a hotspot so I'm still looking for a way to solve this.

Then are these LoRa messengers, if they get more popular then their price also goes down and more people can use them. A reason for autonomous networks is to regain digital independence and those devices are easier to verify and trust than any smartphone nowadays. It would be common good to promote them more.

[ripplebiz]

I'm a fan of Reticulum, but I have also been looking for ESP32 native solutions. I have actually been developing a different system called Ripple, and have a T-Deck firmware which also includes offline maps: https://www.hackster.io/scottpowell69/lilygo-t-deck-maps-38d95a

Also, I have started a Reticulum-inspired project, dubbed 'R2', which is a very cut-down design intended for microprocessors, written in C++: https://github.com/ripplebiz/RippleCore
I did a bit of a write-up on 'R2' and the goals behind the design here: https://www.hackster.io/scottpowell69/the-r2-mesh-system-695f4b

[maxbrito500]

Hello,

Thank you for introducing that project. However, the network is different from Reticulum. Here the interest goes to have ESP32 to interact with other devices like normal laptops and devices across the Internet. That interaction is very important for deep urbanized areas where a mix of hardware is expected and nomad has solid clients for the CLI, web and everything in between.

I've really enjoyed your work, especially the options with the maps and to have the purchase model if we want deeper level of detail (fair access to everyone). In the long run this compatibility becomes very important to make sure as many people can connect from everywhere with a common protocol.

Would you perhaps reconsider making it compatible with reticulum?

[ripplebiz]

I initially wanted to embark on something that would have better interoperability, but weren't any good options (IMO) for microcontroller + LoRa. So far, the work I've done on Ripple is really only intended for closed groups, and its design reflects that. But, having a wider reach would be great.
I'll reply in more detail to in a reply below (to 'faragher')

[faragher]

I'd also recommend making R2 Reticulum compatible. Many of the more difficult features (either to program or to fit in microcontroller capabilities) are critical to larger network functionality. If you create a Reticulum compatible end point, it can use Reticulum nodes as full routers, providing you full functionality on either Reticulum or R2 networks, providing you the lean features you require along with the advanced routing and lookup capabilities of the full stack. It also provides futureproofing, as MicroReticulum is quickly moving towards implementing the stack as a whole on microcontroller. If you're an alternative that runs on the network, then R2 would continue to be useful to your clients. If there's a fully Reticulum compliant microcontroller implementation and one that does a fraction of what it does, along with not being compatible with the main network stack, it's no longer a good alternative. If you moved to supporting MicroReticulum as your firmware, you could shift all your development and support time to Ripple. This is simply a suggestion; you know your goals and capabilities better than I do. I must apologize for the relative brevity and lack of research and links, but I'm away from my equipment for the day; thus the email response. Good hunting with Ripple! Let us know if we can help if you decide to support the RNS.

…

On Fri, Jul 19, 2024, 5:11 AM brito ***@***.***> wrote: Hello, Thank you for introducing that project. However, the network is different from Reticulum. Here the interest goes have ESP32 to interact with other devices like normal laptops and devices across the Internet. That interaction is very important for deep urbanized areas where a mix of hardware is expected. I've really enjoyed your work, especially the options with the maps and to have the purchase model if we want deeper level of detail (fair access to everyone). Would you perhaps reconsider making it compatible with reticulum? — Reply to this email directly, view it on GitHub <#501 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALIZNI64VN3ADDYYY65JMQTZNDJ3NAVCNFSM6AAAAABHS6NFVWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMBZGM3DEOA> . You are receiving this because you commented.Message ID: ***@***.***>

[ripplebiz]

I'm not sure, but I think I did notice MicroReticulum some time back, but that it was very incomplete. Have had a quick look, and seems to have gotten a lot further. I will give it a much better study in coming weeks.

However, when it comes to LoRa, in particular, I did find it concerning how long the RNS packets can get, and especially the 'split packet' mechanism. With such long 'time on air', how does RNS perform in LoRa networks with a decent amount of congestion? Packet collisions are the enemy, and my conclusion has (so far) been to minimise time on air, to minimise collisions.

Also, I'd find it very difficult to attempt an RNS port (to C++) from Python. I'm not a Python dev, but also it would be much better to instead work from some RNS 'spec'. I've read the manual, but I'm still fuzzy on quite a lot of the protocol and how it works. A lot of the 'magic' seems to happen in transport.py, which I'm sorry to say really, really should be refactored into much smaller classes. It's quite monolithic and hard to follow, and probably very hard to maintain(?).

My 'R2' design is still VERY incomplete. I've put it out there more as a 'suggestion' :-) and hoping for feedback/ideas. I still believe that for micro/embedded environments, and LoRa, that a re-think is a reasonable question to ask. And, I have wondered at the possibility of having R2<->RNS gateway nodes (with something like NAT translations on Destinations), where an R2 cluster of nodes could be for a more performant local network, with occasional interaction with endpoints in the greater RNS network(?)

But, I'm not entirely sure that is really possible, considering some of the differences currently in R2, like the suggestion of having all encryption be the responsibility of the application. (other than signing of things like Announces and Proofs) I only stumbled upon this design idea as a way to maximise extensibility, to allow for more kinds of encryption, or even NONE, and that the data involved in the application will dictate the decision, rather than the underlying network stack enforcing the decision.

Back to MicroReticulum. One thing that, to my understanding, of micro/embedded environments is being able to support extremely long uptimes, eg. a year, and that this imposes some very difficult constraints on design. For instance, only using new/malloc in the setup() phase, and crafting custom static resource pools for everything. This and many other constraints make for an entirely different environment to code for, than desktop/Python. They really are chalk and cheese. I think this is why RNS can't just be 'ported' from the Python.