{"id":868,"date":"2026-06-11T21:17:29","date_gmt":"2026-06-12T05:17:29","guid":{"rendered":"https:\/\/salemdata.net\/johnpress\/?p=868"},"modified":"2026-06-11T21:30:32","modified_gmt":"2026-06-12T05:30:32","slug":"reticulum-testing-seeing-the-invisible-transmissions","status":"publish","type":"post","link":"https:\/\/salemdata.net\/johnpress\/?p=868","title":{"rendered":"Reticulum Testing: Seeing the Invisible Transmissions"},"content":{"rendered":"

highly technical<\/strong><\/span><\/p>\n

I’m testing microReticulum, a C++ implementation of Reticulum.\u00a0 I’ve specifically been testing the LINK and transport mechanism.\u00a0 I have three units:\u00a0 BOB, CY & DAN.\u00a0 While all three units are within broadcast range of one another, I have purposefully caused BOB and CY not to be able to receive each other’s transmissions.\u00a0 This is to simulate the condition of DAN being in the middle between BOB & CY who are too far apart to directly communicate.\u00a0 The result is that BOB & CY have to send their transmissions through DAN.<\/p>\n

I have been having problems, and it is not clear what the cause is.\u00a0 One theory is that I may be causing collisions in the airwaves.\u00a0 You must think of the radio airwaves as a telephone party line, if two units try to transmit at the same time, you have a collision which corrupts both communications.<\/p>\n

Since radio waves are invisible to the eye, I can only know when a unit transmits or receives by looking at logs.\u00a0 Unfortunately, trying to read date & time numbers with thousandth precision is challenging:<\/p>\n

jlpoole@jp ~\/logs $ tail BOB_raw_20260611_214401.log \r\n20260611_215802.799 FW IMAGE: unit=BOB build=20260612_043238 git=unknown \r\n20260611_215811.784 SIM PHY DROP: rx=1 tx=2 len=104 RSSI=-79.0 SNR=11.0 SF=7 BW=125.0 CR=4\/5 TXP=14 blocked=19 \r\n20260611_215811.978 RX PHY: phy=3 len=100 RSSI=-48.0 SNR=12.0 SF=7 BW=125.0 CR=4\/5 TXP=14 frames=66 \r\n20260611_215811.980 RNSLINKRX ms=849214 board=library role=unknown event=enter link_id=9ea6d838b3db8b1489584332a48afa81 packet_type=0 context=0 data_len=80 hops=2 status=2 initia\r\ntor=0 callback=1 iface=Interface[TBeamSupremeLoRa] link_obj={Link:9ea6d838b3db8b1489584332a48afa81} \r\n20260611_215811.981 RNSLINKRX ms=849216 board=library role=unknown event=context_none_enter link_id=9ea6d838b3db8b1489584332a48afa81 packet_len=80 callback=1 status=2 initiator=0\r\nlink_obj={Link:9ea6d838b3db8b1489584332a48afa81} \r\n20260611_215811.981 RNSDEC ms=849216 board=library role=unknown event=attempt link_id=9ea6d838b3db8b1489584332a48afa81 token_len=80 token_crc32=D9787D14 sign_key_crc32=90F77021 e\r\nnc_key_crc32=D3E41A6F link_obj={Link:9ea6d838b3db8b1489584332a48afa81} \r\n20260611_215811.983 RNSLINKRX ms=849217 board=library role=unknown event=decrypt_ok link_id=9ea6d838b3db8b1489584332a48afa81 plaintext_len=25 plaintext_crc32=31675BF3 text=CY say\r\ns Hi to BOB iter=12 link_obj={Link:9ea6d838b3db8b1489584332a48afa81} \r\n20260611_215811.983 RNSLINKRX ms=849218 board=library role=unknown event=callback_enter link_id=9ea6d838b3db8b1489584332a48afa81 plaintext_len=25 link_obj={Link:9ea6d838b3db8b148\r\n9584332a48afa81} \r\n20260611_215811.984 RX LINK: CY says Hi to BOB iter=12 | phy=Dan(3) RSSI=-48.0 SNR=12.0 SF=7 BW=125.0 CR=4\/5 TXP=14 \r\n20260611_215812.016 RNSLINKRX ms=849251 board=library role=unknown event=callback_return link_id=9ea6d838b3db8b1489584332a48afa81 link_obj={Link:9ea6d838b3db8b1489584332a48afa81} \r\njlpoole@jp ~\/logs $<\/pre>\n
So I thought I’d try a radio waterfall display that I had used in an earlier project: openwebrx.\u00a0 Unfortunately, openwebrx does not have any time tracking in the display.\u00a0 I have my units synchronized down to the 1\/100th of a second and I have created slots of times within a 1 minute interval when they should be transmitting messages via a LINK.\u00a0 Here is a table of transmission time slots assigned for each unit.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n
Unit<\/th>\nLocal RTC second<\/th>\n<\/tr>\n<\/thead>\n
AMY<\/td>\n:04<\/span><\/td>\n<\/tr>\n
BOB<\/td>\n:08<\/span><\/td>\n<\/tr>\n
CY<\/td>\n:12<\/span><\/td>\n<\/tr>\n
DAN<\/td>\n:16<\/span><\/td>\n<\/tr>\n
ED<\/td>\n:20<\/span><\/td>\n<\/tr>\n
FLO<\/td>\n:24<\/span><\/td>\n<\/tr>\n
GUY<\/td>\n:28<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
If the blobs appear outside the expected slot, or overlap another unit\u2019s slot, I have a visual clue that timing drift, retransmission, or collision behavior may be involved.<\/p>\n
So, I had Codex modify the openwebrx project to display the Hour and Minute at the top and then a black vertical time marker on the left showing the current second within the minute..\u00a0 This lets me correlate the colored blobs in the waterfall with a time which gives me a clue of which unit is currently transmitting.<\/p>\n
\"Openwebrx
Openwebrx Waterfall with Time Correlation<\/figcaption><\/figure>\n
While the display is fuzzy, it at least gives me something to visualize.<\/p>\n
Note: I can also capture IQ packets, but doing so creates huge log files easily getting into the 100 MBs size.\u00a0 This technique may be useful further down the analysis chain, but for now, the visual waterfall gives me a rough idea of what is happening over the airwaves.\u00a0 Thanks to ChatGPT\/Codex — I could just say what I wanted with an existing open source project and Codex was able to make the OpenWebRX UI modification I needed, giving me a rough but useful visual debugging tool..<\/p>\n","protected":false},"excerpt":{"rendered":"
highly technical I’m testing microReticulum, a C++ implementation of Reticulum.\u00a0 I’ve specifically been testing the LINK and transport mechanism.\u00a0 I have three units:\u00a0 BOB, CY & DAN.\u00a0 While all three units are within broadcast range of one another, I have purposefully caused BOB and CY not to be able to receive each other’s transmissions.\u00a0 This […]<\/p>\n","protected":false},"author":2,"featured_media":869,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_gfmr_meta_descriptions":[],"_gfmr_multilingual_taxonomy_terms":[],"footnotes":""},"categories":[37,127,126,121],"tags":[],"class_list":["post-868","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai","category-chatgpt","category-codex","category-t-beam"],"_links":{"self":[{"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=\/wp\/v2\/posts\/868","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=868"}],"version-history":[{"count":4,"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=\/wp\/v2\/posts\/868\/revisions"}],"predecessor-version":[{"id":873,"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=\/wp\/v2\/posts\/868\/revisions\/873"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=\/wp\/v2\/media\/869"}],"wp:attachment":[{"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=868"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=868"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=868"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}