Reticulum Testing: Seeing the Invisible Transmissions

highly technical

I’m testing microReticulum, a C++ implementation of Reticulum.  I’ve specifically been testing the LINK and transport mechanism.  I have three units:  BOB, CY & DAN.  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.  This is to simulate the condition of DAN being in the middle between BOB & CY who are too far apart to directly communicate.  The result is that BOB & CY have to send their transmissions through DAN.

I have been having problems, and it is not clear what the cause is.  One theory is that I may be causing collisions in the airwaves.  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.

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

jlpoole@jp ~/logs $ tail BOB_raw_20260611_214401.log 
20260611_215802.799 FW IMAGE: unit=BOB build=20260612_043238 git=unknown 
20260611_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 
20260611_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 
20260611_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
tor=0 callback=1 iface=Interface[TBeamSupremeLoRa] link_obj={Link:9ea6d838b3db8b1489584332a48afa81} 
20260611_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
link_obj={Link:9ea6d838b3db8b1489584332a48afa81} 
20260611_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
nc_key_crc32=D3E41A6F link_obj={Link:9ea6d838b3db8b1489584332a48afa81} 
20260611_215811.983 RNSLINKRX ms=849217 board=library role=unknown event=decrypt_ok link_id=9ea6d838b3db8b1489584332a48afa81 plaintext_len=25 plaintext_crc32=31675BF3 text=CY say
s Hi to BOB iter=12 link_obj={Link:9ea6d838b3db8b1489584332a48afa81} 
20260611_215811.983 RNSLINKRX ms=849218 board=library role=unknown event=callback_enter link_id=9ea6d838b3db8b1489584332a48afa81 plaintext_len=25 link_obj={Link:9ea6d838b3db8b148
9584332a48afa81} 
20260611_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 
20260611_215812.016 RNSLINKRX ms=849251 board=library role=unknown event=callback_return link_id=9ea6d838b3db8b1489584332a48afa81 link_obj={Link:9ea6d838b3db8b1489584332a48afa81} 
jlpoole@jp ~/logs $

So I thought I’d try a radio waterfall display that I had used in an earlier project: openwebrx.  Unfortunately, openwebrx does not have any time tracking in the display.  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.  Here is a table of transmission time slots assigned for each unit.

If the blobs appear outside the expected slot, or overlap another unit’s slot, I have a visual clue that timing drift, retransmission, or collision behavior may be involved.

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..  This lets me correlate the colored blobs in the waterfall with a time which gives me a clue of which unit is currently transmitting.

While the display is fuzzy, it at least gives me something to visualize.

Note: I can also capture IQ packets, but doing so creates huge log files easily getting into the 100 MBs size.  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.  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..