{"id":695,"date":"2026-05-19T08:22:53","date_gmt":"2026-05-19T16:22:53","guid":{"rendered":"https:\/\/salemdata.net\/johnpress\/?p=695"},"modified":"2026-05-19T08:22:53","modified_gmt":"2026-05-19T16:22:53","slug":"from-python-prototype-to-c-protocol-core-a-ble-reticulum-milestone","status":"publish","type":"post","link":"https:\/\/salemdata.net\/johnpress\/?p=695","title":{"rendered":"From Python Prototype to C++ Protocol Core: A BLE Reticulum Milestone"},"content":{"rendered":"

highly technical<\/strong><\/h3>\n

The goal is simple to state and hard to implement: move the Reticulum node closer to the radio hardware, so the T-Beam is no longer merely a modem for a phone, but a Reticulum participant in its own right.<\/strong><\/p>\n

\"an
torlando<\/figcaption><\/figure>\n

GitHub user torlando-tech<\/a> designed a Bluetooth protocol for Reticulum<\/a>. Bluetooth is not easy. A BLE interface has to manage discovery, connection direction, dropped connections, identity, fragmentation, reassembly, and recovery. It is not a simple ON\/OFF radio link.<\/p>\n

Torlando also built a Python scaffold around that protocol. My goal was to see whether the protocol behavior could be migrated into C++ so it could eventually support a Bluetooth interface for the LilyGO T-Beam SUPREME running Chad Attermann\u2019s microReticulum.<\/p>\n

Torlando has also built a Reticulum client application named Columba, described as:<\/p>\n

\u201ca simple messaging and voice app for the Reticulum<\/a> network on Android. Send LXMF<\/a> messages and make LXST<\/a> voice calls without relying on the internet, cell towers, or any central servers.\u201d<\/p>\n

\"skull
Chad Attermann<\/figcaption><\/figure>\n

Chad Attermann\u2019s microReticulum is written in C++. I have compiled microReticulum and run it on a T-Beam. It worked well for my simple test, but the T-Beam\u2019s built-in interface is a tiny screen intended mostly for status messages. My test used predetermined messages; it did not provide a practical human interface for typing, reading, or managing conversations.<\/p>\n

The usual approach is to run a Reticulum client on Android, where a person can read and compose messages, while the T-Beam acts as a LoRa modem. That works, but it keeps the Reticulum node conceptually higher up the stack, on the phone side.<\/p>\n

What interests me is the opposite architecture: run the Reticulum instance on the T-Beam itself, and let the phone or other human-friendly device connect over Bluetooth as the user interface. In that model, the T-Beam is not merely a modem. It is the Reticulum node. The phone becomes the keyboard, screen, and operator console.<\/p>\n

Moving the Reticulum instance down onto the T-Beam creates a more self-contained communications device. If cellular service or the internet is unavailable, the T-Beam still has its LoRa radio, its Reticulum identity, and its mesh-network role.<\/p>\n

To make that architecture practical, the Bluetooth protocol cannot remain only in Python. A future T-Beam\/microReticulum implementation needs the BLE protocol and session behavior available in C++.<\/p>\n

So I set out to migrate the protocol-relevant parts of Torlando\u2019s BLE Reticulum work into a C++ core. The important point is not merely that C++ code was compiled. The milestone is that the BLE protocol behavior was separated from the Python\/Linux scaffolding and moved into a C++ library that Python can call for testing.<\/p>\n

Python still serves as the Linux test harness and adapter. The protocol\/session core is now C++. That is the bridge toward eventually using the same logic inside microReticulum on ESP32-S3 hardware.<\/p>\n

Mind you, this is not the type of programming I did at Oracle \u2014 far from it. In retirement I have become fascinated with smaller electronic devices, radio, and embedded systems. I used OpenAI\u2019s ChatGPT as a high-level architectural tutor and reviewer, and I used OpenAI Codex inside Visual Studio Code to inspect, modify, build, and test the code on my workstation.<\/p>\n

My role was part programmer, part test operator, and part project manager. I maintained the Forgejo repository, moved code between my Intel workstation and two Raspberry Pi Zero 2Ws, ran field tests, preserved logs, and forced the work through a staged validation process.<\/p>\n

Over a couple of days, with ChatGPT and Codex assisting, I reached a working C++ protocol\/session core based on Torlando\u2019s BLE Reticulum protocol. The major intellectual credit for the protocol belongs to Torlando. My contribution was to help distill that behavior into C++ and prove that it could still move Reticulum traffic in a live test.<\/p>\n

For a field test, I used two Raspberry Pi Zero 2Ws. Each ran the Reticulum BLE test harness, explicitly configured to require the C++ session backend and the C++ fragmentation backend. I then had the two devices exchange the complete text of the United States Constitution over Reticulum using BLE.<\/p>\n

The point of this test was not literary patriotism, although the Constitution is a convenient piece of public-domain text. The point was to force a non-trivial bilateral transfer through the BLE Reticulum stack and verify that the C++ protocol\/session core was actually being used.<\/p>\n

Here are the consoles for the two Pis:<\/p>\n

\n
\n
jlpoole@zerodev1: \/usr\/local\/src\/ble-reticulum \u2014 Konsole<\/div>\n