rns.recipes

Hello!

Anyone knows the difference between running microReticulum_Firmware and
RTNode-HeltecV4 , both with transport mode on?

In theory, there should be none, however, I can see in the HeltecV4 repo references to issues between the s3r2 vs s3r8, as well as very tight limitations on the Hash list and path request tags etc . These limitations are not present on the microReticulum_Firmware, which leads me to think: these two pieces of software might be the same thing at all, because hardware limitations are evidently there for everyone.

I tried contacting jrl290 (if you are here, let me know :) - but couldn't find a gh discussion page, or LXMF address.

Thank you!

Both are based on Attermann's microReticulum library, but RTNode runs a vendored, customized version.

I've found the biggest practical difference between the two is that RTNode only runs on Heltec v4 and v3 ESP32 hardware, whereas microReticulum_Firmware runs on these two plus many other boards. Most significantly, it can run on the nRF52-based RAK4631 board which is much more power efficient. This makes it well-suited for smaller solar/battery-powered LoRa repeaters. Another useful feature it offers for remote repeaters is a nomadnet status page, and there is even early work on remote node admin over LoRa. It also has support for the RAK15001 flash module which makes the minimal nRF52 hardware more functional for storing RNS transport node routing tables on larger networks.

RTNodes are designed specifically to act a bridge between 1) LoRa mesh nodes, 2) local WiFi/TCP client nodes, and 3) remote internet/TCP backbone nodes (it also recently added Bluetooth bridging but I haven't tested this yet). Combined with battery-powered WiFi router/APs, this can create an access hub that allows anyone with a WiFi-capable device running a Reticulum app to communicate over a very resilient (and hopefully less likely to be bandwidth congested) hybrid of both LoRa and whatever TCP is still online/accessible. RTNodes can also still run on solar/battery, they just need to have a bigger power setup or they won't last as long in winter or otherwise less favourable conditions.

I will also highlight an important difference because it has caused problems for me during earlier rounds of testing: RTNode supports IFACs, but microReticulum_Firmware still does not! Therefore, for testing of LoRa repeater nodes, there can't be any LoRa interfaces with IFACs enabled if you're trying to use a microReticulum_Firmware node.

oh wow, thank you for this very detailed reply! much appreciated!

ones vibecoded ones not

evil prns

prns is slopiculum

Cleeyv wrote:

Both are based on Attermann's microReticulum library, but RTNode runs a vendored, customized version.

I've found the biggest practical difference between the two is that RTNode only runs on Heltec v4 and v3 ESP32 hardware, whereas microReticulum_Firmware runs on these two plus many other boards. Most significantly, it can run on the nRF52-based RAK4631 board which is much more power efficient. This makes it well-suited for smaller solar/battery-powered LoRa repeaters. Another useful feature it offers for remote repeaters is a nomadnet status page, and there is even early work on remote node admin over LoRa. It also has support for the RAK15001 flash module which makes the minimal nRF52 hardware more functional for storing RNS transport node routing tables on larger networks.

RTNodes are designed specifically to act a bridge between 1) LoRa mesh nodes, 2) local WiFi/TCP client nodes, and 3) remote internet/TCP backbone nodes (it also recently added Bluetooth bridging but I haven't tested this yet). Combined with battery-powered WiFi router/APs, this can create an access hub that allows anyone with a WiFi-capable device running a Reticulum app to communicate over a very resilient (and hopefully less likely to be bandwidth congested) hybrid of both LoRa and whatever TCP is still online/accessible. RTNodes can also still run on solar/battery, they just need to have a bigger power setup or they won't last as long in winter or otherwise less favourable conditions.

I will also highlight an important difference because it has caused problems for me during earlier rounds of testing: RTNode supports IFACs, but microReticulum_Firmware still does not! Therefore, for testing of LoRa repeater nodes, there can't be any LoRa interfaces with IFACs enabled if you're trying to use a microReticulum_Firmware node.

Do you know if the WiFi hub component of RTNode works when utilizing heltec v4's new power saving features?

b1LL wrote:

Do you know if the WiFi hub component of RTNode works when utilizing heltec v4's new power saving features?

I haven't specifically looked at power saving features before, so I just checked the RTNode repo. A recent planning/testing document seems to indicate that the firmware is using the modem sleep power saving mode which turns off wifi when the board has been idle for a while.

burger wrote:

ones vibecoded ones not

I think this is an oversimplification. jrl290 has been quite open, and I would even say humble, about his use of AI assistance to develop RTNode, which I appreciate.

MicroReticulum started being developed before LLM-based coding was even an option, and Attermann hasn't publicly acknowledged use of it as far as I have seen. However, it is pretty clear that at least some of the work he has been doing since at least early July 2026 has been done through Claude code. This is most obvious on the ReticulumAPI repo if you look at its commit history, and especially this commit which adds links in documentation to a CLAUDE.md file which does not actually exist in the project. And then some of the subsequent commits to the microReticulum_Firmware repo also have very verbose commit messages, which he could have written himself, but also look a lot like Claude code output.

Personally, I think that it is the intention, commitment, and skill of a developer or team that are the more important factors for the quality and usefulness of the software they create, not primarily whether or not LLM assistance has a role in their process. A practical problem we all face now in open source communities is that by lowering the barrier to entry for code generation, LLMs have rapidly increased the quantity of low quality projects that are superficially emulating the appearances of higher quality projects. This adds an extra "sort out the slop" step for those us trying to figure which projects to test out, locally document, integrate into our plans, and eventually deploy.

Regardless of the role of LLM coding in their current or future development process, Attermann and jrl290 have both been doing really important, necessary work to make RNS/LXMF more practically usable over LoRa-based autonomous infrastructure.