Portable standalone messenger with Lilygo T-Deck #501
Replies: 8 comments 9 replies
|
I could have a crack at it. I've actually been trying to build something similar to this for a while, but lack hardware. |
|
Thank you, can you show experience on similar tasks? Your profile only shows 4 empty repositories. |
|
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. |
|
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. |
|
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. |
|
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. |
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? |
|
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. |
|
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. |
|
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 |
|
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? |
|
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'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:
***@***.***>
|
|
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. |
totally agreed. I am currently working on a very simple & light javascript lib, and I think a very BYO-approach, like no UI, no network-transport, no files, etc, helps a bit. Like there are lots of existing libraries for "store this blob on disk/SD" or "send these bytes over lora/serial/etc", so if you have things a bit more separated, it makes it easier to use it however makes sense. The biggest challenge for me has been simplifying the stack, so it's just a few functions, but I made some tests and stuff in python, and you can sprinkle My goal with the JS is to not support anything except basic reticulum operations (with a strong focus on stuff in existing end-user clients, like nomadnet, meshchat, sideband) and you just wire it up to your own interface however makes sense. In nodejs or web USB/bluetooth/websockets/etc, I get a lot of that for free (using libraries and browser APIs.) I think the same is true with arduino/micropython. A lot of other people have done the work for the individual parts, so really we just need the building-blocks for actually parsing/encrypting/decrypting/building bytes. |
|
I started laying out some notes here for sort-of-related project. I think if I separated RNode+client library (leaning heavy on existing RNode + microreticulum code) from UI, we could share a lot of code, and it'd be easier to glue different target-specific UIs to the radio & reticulum stuff. I think a cheap & combined device would be ideal. Like if you are on-the-go, you can use the less-nice touchscreen, but also use it on a phone or computer, like a regular RNode. One idea is that it just starts, by default, in "rnode mode" and has some buttons on screen (or TDeck key-combos) for basic-operation (bluetooth pairing, etc) and switching to "client mode". Like it doesn't even have to run both at once (although there is a lot of code-overlap.) I'm pretty busy right now, but this is the next project I want to work on. Maybe we could split up the work a bit, to speed things up. |
|
I also made a mostly complete client library that works on micropython. Still needs some features and examples, but it seems to be able to handle offline messages fine and in cpyhton, it can fully communicate with a regular client. It probably works fine with that in micropython, too, but I need to setup a bunch of other stuff to test it. |
Uh oh!
There was an error while loading. Please reload this page.
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.
All reactions