{"id":777,"date":"2026-05-31T14:33:06","date_gmt":"2026-05-31T22:33:06","guid":{"rendered":"https:\/\/salemdata.net\/johnpress\/?p=777"},"modified":"2026-05-31T14:49:39","modified_gmt":"2026-05-31T22:49:39","slug":"herding-t-beam-cats","status":"publish","type":"post","link":"https:\/\/salemdata.net\/johnpress\/?p=777","title":{"rendered":"Herding T-Beam Cats"},"content":{"rendered":"

Highly technical, <\/strong>but written for those who are blessed with curiosity<\/span><\/span><\/p>\n

Introduction<\/h2>\n

I’m testing microReticulum<\/a>, a C++ implementation of the Reticulum protocol developed by Chad Attermann<\/a>, on 7 LilyGo T-Beam SUPREME<\/a>s.<\/p>\n

\"circuit
T-Beam Interior boards<\/figcaption><\/figure>\n
\"circuit
Disassembled T-Beam<\/figcaption><\/figure>\n
\"circuit
T-Beam (assembled) with battery<\/figcaption><\/figure>\n
\"Circuit
ESP32-S3<\/figcaption><\/figure>\n

The T-Beams use the ESP32-S, a game-changing small processor.\u00a0 I’ve built an elaborate testing bench which I wanted to document should someone in the same arena want to streamline their software workbench and leverage the efficiencies I have developed.\u00a0 Below is a description of a\u00a0practical, console-driven embedded-systems workflow for testing seven T-Beam nodes with PlatformIO, synchronized clocks, structured logs, and AI-assisted debugging.<\/p>\n

Development Environment<\/h2>\n
\"screenshot
Arduino IDE 1.8.5<\/figcaption><\/figure>\n

First off, I do not use the windowed based Arduino<\/a> integrated development environment (IDE 2<\/a>).\u00a0 I found the interface too complicated with options I’ll never use and you have to move around with a mouse and click which really slows you down.\u00a0 Instead, I prefer a command line interface, e.g. a console, where I can script and tweak commands that I repeatedly use.<\/p>\n

\"orange
PlatformIO<\/figcaption><\/figure>\n

While the Arduino IDE is very popular and an excellent beginner’s tool, I’ve moved on to the Platform IO<\/a> 1<\/a><\/sup>.\u00a0 PlatformIO appears to be an open source project with a for-profit company, PlatformIO Labs<\/a>, aligned to it.\u00a0 PlatformIO Labs is headquartered in Estonia, and notes with pride that its R&D unit is located in Ukraine 2<\/a><\/sup>.\u00a0 PlatformIO touts:<\/p>\n

A place where Developers and Teams have true Freedom! No more vendor lock-in!<\/span><\/p>\n

PlatformIO’s philosophy really resonates with me, I who worked for the world’s largest database software company for 24 years.\u00a0 Moreover, the ability to “get things done” 3<\/a><\/sup>, or “Git-R-Done!” 4<\/a><\/sup>,\u00a0 in a command console and with scripts is especially efficient and to me, less complicated to understand.<\/p>\n

 <\/p>\n

I created a virtual Python environment<\/a> since Gentoo Linux<\/a> 5<\/a><\/sup><\/p>\n

\"Gentoo
Gentoo<\/figcaption><\/figure>\n

is my preferred platform.\u00a0 You do not want to pollute or corrupt Gentoo’s installation of Python since Gentoo Linux heavily relies upon Python to manage its environment.\u00a0 Instead, you create a micro universe with a copy of Python so you can install all kinds of risky packages and if you break your environment, then you just dispose of it and build another and you do not compromise your operating system.<\/p>\n

PlatformIO is easily installed within a [virtual] Python environment. When you are working with compiling C++ code, say in the microReticulum project, PlatformIO creates a directory “.pio” and stages and builds everything thereunder.\u00a0 You can control your PlatformIO in the file platformiol.ini.\u00a0 In mine, I have entries for each of my T-Beam devices identified by name: AMY, BOB, CY, ED, FLO & GUY.7<\/a><\/sup>\u00a0 The ability to differentiate the T-Beams is helpful, for instance, because GUY is a T-Beam with a different and more expensive GPS chip and circuit, so it needs to have different libraries to successfully compile.<\/p>\n

\"7
AMY, BOB, CY, DAN, ED, FLO & GUY<\/figcaption><\/figure>\n

T-Beam development<\/h2>\n

When I stage a project, I do so under the path: \/usr\/local\/src.\u00a0 This is an old-time practice I learned early on when I learned Linux.\u00a0 On any<\/em> given server or workstation I control, I can always know what customized software I have installed outside of the Gentoo package system by seeing what is staged under \/usr\/local\/src.\u00a0 Think of it as a sort of a mental quarantine area.\u00a0 We used this protocol, for the most part, for the many servers my team controlled.<\/p>\n

This T-Beam world was all new to me.\u00a0 So I decided to creates studies, or “exercises”, to learn about the many functions of the T-Beam as well as to test its stated features. 6<\/a><\/sup>\u00a0 I did not want to take the fast track and develop something only to learn later that a certain hardware capability existed that could improve the experience.<\/p>\n

\"Linux
Exercises<\/figcaption><\/figure>\n

 <\/p>\n

 <\/p>\n

Building Firmware<\/h2>\n

Compiling the code and building the “firmware” \u2014 a binary blob that is the operating system for the T-Beam \u2014\u00a0 for each T-Beam takes over 1 minute on my 2012 Intel-based workstation.\u00a0 So if I want to test a simple change in the code with all 7 T-Beams, I’m looking at 8 – 10 minutes to build the 7 firmwares.\u00a0 When Codex starts making tiny incremental changes, this amount of time adds up real quickly making progress about 4 increments per hour.\u00a0 I determined a solution is to have an identical workbench on my more powerful server, ryzdesk (chip: AMD Ryzen 7950, tons of memory), and build the firmware for each unit there.\u00a0 On ryzdesk, I can build all 7 firmwares in 1 minute 4 seconds.\u00a0 That is a time saving of about 8 minutes+.\u00a0 So my method of work is to edit and interact with Codex on my slower “jp” workstation, check-in the changes and push [transfer] the revised code to my Forgejo server (running on a Raspberry Pi 4B), pull the changes down to ryzdesk and compile, then copy the build tree back to my workstation and load the firmwares into the respective T-Beams.\u00a0 Much of this is facilitated using scripts.<\/p>\n

Trial Runs<\/h2>\n

With the T-Beam inoculated with new firmware, I then run them.\u00a0 I have a requirement that each unit must have its clock “disciplined” to satellite time every 24 hours.\u00a0 This is to assure the time on each T-Beam is very close so when events are time-stamped, I know all the units are referencing the same time.\u00a0 My procedure is that time synchronization must occur every 24 hours, if at start-up the unit sees that it has been over 24 hours since it last synchronized with satellites, it forces me to take the unit to a window or outside so it can obtain satellite signals and adjust its internal clock.\u00a0 I maintain a stratum 1 time server<\/a> (Raspberry Pi5) which my workstation, jp, is synchronized to.\u00a0 So time codes on the T-Beams and my workstation should clearly be within 1\/1,000th of a second.\u00a0 It is imperative to have synchronized time to fully analyze log files.<\/p>\n

I want the trial runs to start relatively at the same time and end at the same time, so I have designed Bash and Perl scripts which launch a new console and connects via a serial port to a given T-beam.\u00a0 What is printed out in the console has filters highlighting entries of interest in color and prepends high precision time codes to the entries as they are printed out in the console.<\/p>\n

\"screenshot
7 Console Monitors on their own desktop<\/figcaption><\/figure>\n

In addition to displaying in the console, the serial port stream coming from the T-Beam is routed to a log file with a date and time stamp in the file name.\u00a0 With my Perl script (clump_tbeam_logs.pl) I combine the log files generated from the recent trial into a subdirectory so I can just reference the subdirectory, e.g. ~\/logs\/20260531_1046<\/strong>, to Codex who can then find them and focus only that run.<\/p>\n

\"directory
Logs from T-Beam synchronized trial runs<\/figcaption><\/figure>\n

Post Trial Analysis<\/h2>\n

The log files are a wealth of information, and using grep, I can filter out entries of interest such as what each unit received decrypted into readable text.\u00a0 For instance, I have the firmwares configured so that BOB and CY are supposed to communicate via the Reticulum “transport” through DAN, but the results below show that neither BOB nor CY are receiving their LINK Transmission (“RX LINK”) messages, only the ANNOUNCE messages. (This is, therefore, a problem\/bug either in my code or in the microreticulum code yet to be solved\/fixed.)<\/p>\n

\"console
Log Search Results<\/figcaption><\/figure>\n

This organization makes my interaction with Codex very efficient.\u00a0 Codex will tweak the code, I’ll compile and run a trial using the modified code, and then I have log files in an isolated directory which Codex can analyze.\u00a0 I actually had Codex connecting directly to my T-Beams: Codex could compile the code, upload it to the T-Beams, and then open parallel serial monitors and monitor in real time what was happening.\u00a0 While that is all amazing, it is a very expensive use of Codex and I found my 5 hour allotments or AI time skyrocketing.\u00a0 In the interest of husbandry and permanence, I opted for this method of running trials and then having log files so both Codex and I have the same results in a permanent location which can be referenced later on.\u00a0 This workflow also makes Codex more useful and less wasteful. Instead of letting Codex burn time directly controlling hardware, I run the trial myself and preserve the evidence in a timestamped log directory. Codex can then inspect the same files I inspected, reason from the same run, and propose the next small change. That keeps the AI bounded by evidence rather than wandering through guesses.\u00a0It also forces me to have to read stuff and learn and not hand over the keys to the kingdom to AI like many unsophisticated managers and CEOs of companies do thinking they can replace their software developers with AI and save money [in the short term].<\/p>\n

During my testing, I brought to the attention of the manufacturer, LilyGO, that they published the T-Beam SUPREME’s specification touting a microphone.\u00a0 When I set up an exercise to test the microphone… I learned there was no built-in microphone and contacted LilyGO. They admitted the error and have since updated their specifications removing mention of a microphone.<\/p>\n

\n
    \n
  1. https:\/\/docs.platformio.org\/en\/latest\/what-is-platformio.html?utm_source=chatgpt.com#philosophy Some “PlatformIO Labs<\/a> is headquartered in Estonia, with representation in the USA and an R&D center in Ukraine.” \u00a0 \u00a0familiar companies use PlatformIO:\n
    \"Compilation
    PlatformIO Users<\/figcaption><\/figure>\n

    \u21a9<\/a><\/li>\n

  2. \u00a0Ukraine — Commentary<\/em>: it seems that Ukraine is emerging as a pre-eminent leader in drone technology which necessarily involves single board computers, aka “SBC”.\u00a0 The T-Beam is an SBC with steroids, so it seems to be a natural fit that PlatformIO Lab’s R&D unit would be in Ukraine.\u00a0 I can only speculate that the expertise needed to advance drone technology is in the same universe as work with the Espressif ESP32 series, so working with a tool set such as PlatformIO makes me feel like I’m on the cutting edge.\u00a0 It certainly is meeting my expectations of what a tool set should do.\u21a9<\/a><\/li>\n
  3. \u00a0 “getting things done” – a trite, to being the point of amusing, phrase usually broadcasted by incumbents during their re-election campaigns.\u21a9<\/a><\/li>\n
  4. \u00a0 Git-R-Done! Catch phrase from Larry the Cable Guy <\/a>\u21a9<\/a><\/li>\n
  5. \u00a0https:\/\/en.wikipedia.org\/wiki\/Gentoo_Linux \u21a9<\/a><\/li>\n
  6. \u00a0I had my Forgejo<\/a> repository (https:\/\/salemdata.net\/repo)available and was getting barraged by AI bots, so I configured it to registered-users-only access.\u00a0 If you would like access, submit your email, preferred username, and real name in the form below (which will not be published) and I’ll contact you by email to arrange for an account.\u00a0 No charges, I just do not want my servers and Internet connection flooded by AI bots. \u21a9<\/a><\/li>\n
  7. The case design is the Lilygo T-Beam SUPREME TS2 Case<\/a> by Alley Cat<\/a>.\u00a0 Most were printed on a Sovol SV06 ACE<\/a> 3D Printer (5\/31\/26 $259 Amazon<\/a>).\u00a0 Most of the cases in the photo are PLA [polylactide<\/a>] filament, the red DAN was ASA [Acrylonitrile styrene acrylate<\/a>]. The ASA requires high constant ambient temperature, so I have the SV06 inside the YOOPAI 3D Printer Enclosure (5\/31\/26 Amazon<\/a>).\u21a9<\/a><\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"

    Highly technical, but written for those who are blessed with curiosity Introduction I’m testing microReticulum, a C++ implementation of the Reticulum protocol developed by Chad Attermann, on 7 LilyGo T-Beam SUPREMEs. The T-Beams use the ESP32-S, a game-changing small processor.\u00a0 I’ve built an elaborate testing bench which I wanted to document should someone in the […]<\/p>\n","protected":false},"author":2,"featured_media":792,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[127,126,80,131,130,121],"tags":[],"class_list":["post-777","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-chatgpt","category-codex","category-meshtastic","category-microreticulum","category-reticulum","category-t-beam"],"_links":{"self":[{"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=\/wp\/v2\/posts\/777","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=777"}],"version-history":[{"count":20,"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=\/wp\/v2\/posts\/777\/revisions"}],"predecessor-version":[{"id":810,"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=\/wp\/v2\/posts\/777\/revisions\/810"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=\/wp\/v2\/media\/792"}],"wp:attachment":[{"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=777"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=777"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=777"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}