Codex Thoughts<\/figcaption><\/figure>\nI asked Codex to create a post mortem<\/em> to document the cycles it went through along with the reasoning it applied at each juncture.\u00a0 Codex basically overcame a very low level design flaw at the byte level where a buffer specification was too large and causing data to disappear.\u00a0 This kind of debugging and testing would have taken hours and hours of time.<\/p>\nThe rest of this post is the technical post mortem Codex generated after the successful run. Readers who only want the story can stop here: the important point is that the debugging cycle moved from \u201chuman observes, uploads logs, asks for next step\u201d to \u201cCodex observes, modifies, compiles, uploads, tests, and repeats.\u201d For those who want the byte-level details, the report follows.<\/p>\n
\n
Exercise 305: microReticulum BLE file transfer<\/h1>\n
This exercise builds on Exercise 304’s equal-peer BLE transport. Both boards run the same dual-role BLE interface, form a Reticulum Link, and then send the selected text file across that Link at the same time.<\/p>\n
The file transfer protocol is intentionally small and visible on the serial console:<\/p>\n
FTB -> file begin, with file name, byte count, chunk count, and checksum\r\nFTD -> numbered file data chunk\r\nFTE -> file end, with verification metadata repeated\r\n<\/code><\/pre>\nEach receiver checks byte count, chunk count, and FNV-1a checksum. After a sender completes a transfer, it rests for 10 seconds and then starts the same selected file again.<\/p>\n
Sample Set<\/h2>\n
Exercise 305 uses the same payload files as the Pi Zero BLE Reticulum tests:<\/p>\n
texts\/If.txt 195 bytes\r\ntexts\/If_full.txt 1583 bytes\r\ntexts\/US_Constitution.txt 44225 bytes\r\n<\/code><\/pre>\nThe selected file is compiled into the firmware. The transfer code does not care which file is selected; platformio.ini<\/code> chooses the source text through custom_text_source<\/code>, and scripts\/embed_text.py<\/code> generates SelectedText.h<\/code> in the build directory before compilation.<\/p>\nTransfer Profiles<\/h2>\n
The transfer pressure is selected in platformio.ini<\/code> with build flags:<\/p>\n-D FILE_TRANSFER_CHUNK_SIZE=32\r\n-D FILE_TRANSFER_CHUNK_INTERVAL_MS=500\r\n<\/code><\/pre>\nFILE_TRANSFER_CHUNK_SIZE<\/code> is the number of text bytes placed in each application-level FTD<\/code> message before microReticulum wraps and encrypts it as a Link packet. Larger chunks reduce the number of packets needed for a file, but each encrypted packet becomes larger. If it grows beyond what the ESP32 BLE transport can reliably carry under simultaneous two-way traffic, Reticulum may log Link decrypt\/HMAC failures because ciphertext arrived damaged or incomplete.<\/p>\nFILE_TRANSFER_CHUNK_INTERVAL_MS<\/code> is the delay between application-level file chunks. Smaller intervals increase throughput, but also increase BLE write\/notify pressure. With both nodes transmitting at the same time, too short a cadence can overflow buffers or expose ordering\/loss issues in the current ESP32 BLE transport.<\/p>\nThe conservative bring-up profile uses:<\/p>\n
32 byte chunks, 500 ms between chunks\r\n<\/code><\/pre>\nThe Pi-Zero-comparison profile uses:<\/p>\n
300 byte chunks, 100 ms between chunks\r\n<\/code><\/pre>\nThat is the apples-to-apples starting point for the previous Zero-to-Zero tests. Those commands requested --message-chunk-size 900<\/code>, but the Python sender intentionally applied an internal board\/Link-budget cap before sending. The run17 report for the Constitution transfer shows effective chunk data around 300 to 316 bytes, not 900 bytes, with roughly 100 ms sender pacing.<\/p>\nVERIFY_FAIL<\/code> means the file protocol received an incomplete or corrupted transfer. A Reticulum Link HMAC\/decryption error means corruption happened earlier, before the file protocol could parse the packet.<\/p>\nPriority<\/h2>\n
See Exercise 304_microReticulum_ble_dual_role_ping_pong README.md for explanation of “deterministic tie-breaker” of the role of client and server based on the ESP32 MAC.<\/p>\n
Environments<\/h2>\n
Conservative ESP32 bring-up environments:<\/p>\n
tbeam_if\r\ntbeam_if_full\r\ntbeam_constitution\r\n<\/code><\/pre>\nPi-Zero-comparison environments:<\/p>\n
tbeam_if_pi_zero_profile\r\ntbeam_if_full_pi_zero_profile\r\ntbeam_constitution_pi_zero_profile\r\n<\/code><\/pre>\nBuild Once, Upload Twice<\/h2>\n
Each selected text environment produces one firmware image. Build it once, then upload that same image to both boards.<\/p>\n
Build the short If sample:<\/p>\n
source \/home\/jlpoole\/rnsenv\/bin\/activate\r\ncd \/usr\/local\/src\/microreticulum\/microReticulumTbeam\r\npio run -d exercises\/305_microReticulum_ble_file_transfer -e tbeam_if\r\n<\/code><\/pre>\nBuild the Pi-Zero-profile Constitution sample:<\/p>\n
source \/home\/jlpoole\/rnsenv\/bin\/activate\r\ncd \/usr\/local\/src\/microreticulum\/microReticulumTbeam\r\npio run -d exercises\/305_microReticulum_ble_file_transfer -e tbeam_constitution_pi_zero_profile\r\n<\/code><\/pre>\nAfter the build succeeds, upload the same environment to both boards. These commands may be run one after the other:<\/p>\n
pio run -d exercises\/305_microReticulum_ble_file_transfer -e tbeam_if -t upload --upload-port \/dev\/ttytAMY\r\npio run -d exercises\/305_microReticulum_ble_file_transfer -e tbeam_if -t upload --upload-port \/dev\/ttytBOB\r\n<\/code><\/pre>\nUse the same -e<\/code> value in upload commands that you used for the build.<\/p>\nFor strict parallel uploads, use esptool.py<\/code> directly against the already-built artifacts. This avoids two concurrent pio run<\/code> processes touching the same .pio<\/code> build directory:<\/p>\ncd \/usr\/local\/src\/microreticulum\/microReticulumTbeam\/exercises\/305_microReticulum_ble_file_transfer\r\nesptool.py --chip esp32s3 --port \/dev\/ttytAMY --baud 460800 write_flash -z \\\r\n 0x0000 .pio\/build\/tbeam_if\/bootloader.bin \\\r\n 0x8000 .pio\/build\/tbeam_if\/partitions.bin \\\r\n 0xe000 \/home\/jlpoole\/.platformio\/packages\/framework-arduinoespressif32\/tools\/partitions\/boot_app0.bin \\\r\n 0x10000 .pio\/build\/tbeam_if\/firmware.bin &\r\nesptool.py --chip esp32s3 --port \/dev\/ttytBOB --baud 460800 write_flash -z \\\r\n 0x0000 .pio\/build\/tbeam_if\/bootloader.bin \\\r\n 0x8000 .pio\/build\/tbeam_if\/partitions.bin \\\r\n 0xe000 \/home\/jlpoole\/.platformio\/packages\/framework-arduinoespressif32\/tools\/partitions\/boot_app0.bin \\\r\n 0x10000 .pio\/build\/tbeam_if\/firmware.bin &\r\nwait\r\n<\/code><\/pre>\nFor another environment, replace each .pio\/build\/tbeam_if\/<\/code> path with that environment’s build directory.<\/p>\nMonitor:<\/p>\n
pio device monitor -p \/dev\/ttytAMY -b 115200\r\npio device monitor -p \/dev\/ttytBOB -b 115200\r\n<\/code><\/pre>\nExpected Output<\/h2>\n
Once the Link is active, both nodes start sending:<\/p>\n
Selected file=If.txt bytes=195 chunk=32 interval_ms=500 repeat_rest_ms=10000\r\nTX FILE BEGIN: round=1 file=If.txt bytes=195 chunks=7 crc=...\r\nTX FILE DATA: round=1 seq=1\/7 bytes=32 preview=\"If you can keep your head...\"\r\nTX FILE END: round=1 file=If.txt bytes=195 chunks=7 crc=... next_round_in_ms=10000\r\n<\/code><\/pre>\nThe receiver verifies the transfer:<\/p>\n
RX FILE BEGIN: from=Node-... file=If.txt bytes=195 chunks=7 crc=...\r\nRX FILE DATA: from=Node-... seq=1\/7 bytes=32 preview=\"If you can keep your head...\"\r\nRX FILE END: from=Node-... file=If.txt received=195\/195 chunks=7\/7 crc=... status=OK\r\n<\/code><\/pre>\nTen seconds after TX FILE END<\/code>, the same selected file starts again. This rest interval is measured after transfer completion, so large files get the same 10-second pause before the next round.<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"Highly Technical Harnessing AI to control USB-connected devices can dramatically shorten hardware debugging cycles. I have successfully integrated the ble-reticulum C++ (protocol created by Torlando) interface into the microReticulum code. I built a binary image for the ESP32-based LilyGo! T-Beam SUPREME which I loaded into two T-Beams.\u00a0 The two T-Beams then negotiate a Bluetooth “pairing” […]<\/p>\n","protected":false},"author":1,"featured_media":713,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[37,127,126,26,121],"tags":[128,125],"class_list":["post-710","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai","category-chatgpt","category-codex","category-electronics","category-t-beam","tag-ble-reticulum","tag-reticulum"],"_links":{"self":[{"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=\/wp\/v2\/posts\/710","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\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=710"}],"version-history":[{"count":5,"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=\/wp\/v2\/posts\/710\/revisions"}],"predecessor-version":[{"id":719,"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=\/wp\/v2\/posts\/710\/revisions\/719"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=\/wp\/v2\/media\/713"}],"wp:attachment":[{"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=710"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=710"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=710"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
![\"Screenshot](\"https:\/\/salemdata.net\/johnpress\/wp-content\/uploads\/2026\/05\/20260519_182904_Tue-300x249.png\")
![\"CODEX](\"https:\/\/salemdata.net\/johnpress\/wp-content\/uploads\/2026\/05\/20260520_054506_Wed-300x201.png\")