Transport Ability

[jlpoolen]

I have built a Bluetooth Interface (C++) for Reticulum. I'm in the process of testing it. I have seven LilyGO! T-Beam SUPREMES name AMY, BOB, CY...GUY. I performed a test yesterday where DAN and BOB where sending/receiving packets over the BLE interface and I was able to pair when DAN was on the 2nd floor of my home and BOB in the basement. When BOB moved outside, the connection was broken, so I reached a distance threshold between the two units when BOB moved outside.

So I'd like to set up an experiment where BOB and DAN are beyond reach between each other, i.e. BOB is out in the street, but I stick AMY in between, i.e. inside at the back door, which can connect to BOB and DAN. AMY then would become a forwarder or transport for the BOB<->DAN link. I'm not intimately familiar with Reticulum and wonder if I need to configure it to act in a certain mode and whether that mode is supported in microReticulum.

[attermann]

What you’re describing for AMY is transport mode, so just be sure that’s enabled in `microReticulum` on that node: ``` reticulum.transport_enabled(true); ``` … and that the BLE Interface is placed in `GATEWAY` mode (or some other mode of your choosing that supports announces and path requests across the AMY node): ``` ble_interface.mode(RNS::Type::Interface::MODE_GATEWAY); ``` Refer to the `lora_transport` example app in the repo for more details.

…

On May 21, 2026, at 4:07 AM, John Poole ***@***.***> wrote: I have built a Bluetooth Interface (C++) for Reticulum. I'm in the process of testing it. I have seven LilyGO! T-Beam SUPREMES name AMY, BOB, CY...GUY. I performed a test yesterday where DAN and BOB where sending/receiving packets over the BLE interface and I was able to pair when DAN was on the 2nd floor of my home and BOB in the basement. When BOB moved outside, the connection was broken, so I reached a distance threshold between the two units when BOB moved outside. So I'd like to set up an experiment where BOB and DAN are beyond reach between each other, i.e. BOB is out in the street, but I stick AMY in between, i.e. inside at the back door, which can connect to BOB and DAN. AMY then would become a forwarder or transport for the BOB<->DAN link. I'm not intimately familiar with Reticulum and wonder if I need to configure it to act in a certain mode and whether that mode is supported in microReticulum. — Reply to this email directly, view it on GitHub <#53>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACXDLGIHMLPZ2P3A4THTUR3433IOFAVCNFSM6AAAAACZHNPZKCVHI2DSMVQWIX3LMV43GRDJONRXK43TNFXW4OZRGAYTANJYG4YA>. You are receiving this because you are subscribed to this thread.

[jlpoolen]

Thank you @attermann. I got distracted from this topic today and wanted to test the BLE Interface on different platforms. For example, see: https://mastodon.online/@VogueLaGalere/116615360035516264

3+ clients is a whole different party that is going to require some careful thought and I need to read up on the Reticulum modes.

[jlpoolen]

I created an exercise where I load predefined identities to 7 of my T-Beams, they are disciplined to satellite time, and then each has a specified transmission window within every 30 seconds, e.g. AMY at 4 seconds past the top of the minute, BOB at 8, CY at 12 &etc. Then I have each T-Beam LINK to another and send "Hi" messages. In tests with four units, the LINKs are working and each unit talks to the other three.

Then to simulate physical distances that would be out-of-range between two units, I created blocks on two units, BOB & CY, so that packets to or from are skipped. This radio blockage at the software level forces transport behavior through DAN and/or ED (see detailed explanation below). What has happened is the transported ANNOUNCEMENTS from BOB to CY go through, but then CY does not respond using transport, but instead tries to directly reach BOB. I then wondered if having two possible transports, DAN & ED, added complexity, so I turned off ED leaving BOB, CY & DAN where DAN is the only transport available. In that test:

• BOB sends routed LINKREQUEST to CY via DAN
• CY receives it as a LINKREQUEST, accepts it, and sends proof
• BOB felt it had an established LINK with CY.

But still CY's response via transport fails. So my focus now is to get transport through DAN working, then I'll revisit what is happening when there are two possible transports, e.g. DAN & ED.

We activated the debugging of Transport.cpp and it looks like I'm going to have to carefully study the logic of microReticulum's Transport.cpp and possibly LINK.cpp.

Before undertaking that effort, I thought I would share the issue I am facing and ask:

1. were Transport.cpp and Link.cpp migrations from the Python reticulum code, or are they pretty much code @attermann created?
2. Has microReticulum been field tested with two possible transports between two units that are isolated from each other?

Blocking Implementation

Here is Codex's explanation of our blockage:

We are simulating BOB/CY RF separation below microReticulum, inside the T-Beam LoRa interface adapter. microReticulum packets are not inspected, parsed, or altered for the block decision.

Each transmitted LoRa frame gets a small 4-byte simulation envelope prepended by TBeamSupremeLoRaInterface:

[ SIM PHY ENVELOPE ][ local LoRa fragment header ][ raw microReticulum packet bytes ... ]

SIM PHY ENVELOPE:
  byte 0: 0xC2          magic
  byte 1: 0x04          exercise marker
  byte 2: 0x01          envelope version
  byte 3: NODE_SLOT     physical transmitter ID

NODE_SLOT:
  1 = BOB
  2 = CY
  3 = DAN
  4 = ED

On receive, the LoRa adapter strips that 4-byte envelope before passing bytes to microReticulum. So microReticulum receives the same byte stream it would have received without this simulation wrapper.

The block rule is only:

if local node is BOB and physical transmitter is CY: drop before microReticulum
if local node is CY  and physical transmitter is BOB: drop before microReticulum
otherwise: strip envelope and deliver to microReticulum

Example: direct BOB -> CY is blocked before microReticulum sees it:

LoRa air frame:
  c2 04 01 01 | H | <microReticulum packet bytes>
           ^^
           physical_tx = 1 = BOB

CY receives:
  local = 2 = CY
  physical_tx = 1 = BOB
  decision = DROP

Result:

InterfaceImpl::handle_incoming() is not called.
microReticulum never sees this packet.

Example: BOB traffic transported/rebroadcast by DAN is allowed:

LoRa air frame:

  c2 04 01 03 | H | <microReticulum packet bytes>
           ^^
           physical_tx = 3 = DAN

CY receives:

  local = 2 = CY
  physical_tx = 3 = DAN
  decision = ACCEPT

Adapter strips envelope:
H | <microReticulum packet bytes>

Then calls:
InterfaceImpl::handle_incoming(<microReticulum packet bytes>)

So the important point is: the BOB/CY block is a physical-link simulation in TBeamSupremeLoRaInterface, not a microReticulum-layer rule. A packet physically emitted by DAN or ED is allowed through even if the Reticulum payload originated from BOB or CY.

[jlpoolen]

I was hoping for some sort of reply. Nevertheless, I proceeded with field testing the LoRa interface and learned:

• physical proximity of the units does affect my code's ability to transmit and receive. First I had 3 T-Beams side by side on my desktop near my workstation: antennas about 2-3 inches apart. Then I tried placing the units 120 degrees and around the Sabrent powered Hub that their 3 foot USB A->C cables were connected to, that, was not very good. Then I separated the units: DAN is in the kitchen above my basement office where I have BOB running off my workstation, and then CY is in a separate structure nearby about 60' feet from the kitchen. Then things started to work. It looks like proximity of units' antenna was having cancellation/interference issues. I'm still testing and capturing logs for all three a tweaking microreticulum both with debug wrappers and we did make a change concerning LINK setup.

The upshot is, placement on the field test matters, so try various degrees of separation.

[attermann]

Apologies for not getting back to you yet. Your previous message was packed with detail so I've been waiting for a break to proerly digest it.

Two answer your two direct questions:

1. Yes Transport and Link are both direct translations of the Python reference implementation, although Transport was born first ans was originally based on an older v1.0 version of RNS. Both have since been updated extensively to pull in changes from the Python ref impl, but that process isn't yet complete.
2. I have not personally tested with more than one transport node in the vicinity. I have heard chatter about challenges with asymmetric routing recently but haven't been able to delve into it yet. Not sure if that could be what you're experiencing.

If there are other questions in there you're hoping to have answered then lmk.

[jlpoolen]

@thatSFguy , I do not know what you mean by "asymmetric links."

I've been creating "LINK"s with three units where each has a designated time envelope within a 30 second slice and all units are time disciplined, so my estimate is that none of the units are more than a few 100 milliseconds, if that, off. I started with blocking BOB & CY from direct connections so that DAN would act as a transport node. Ran into problem which I now think were bench test related, i.e. antennas too close together. So I backed off and let any of the three establish a LINK with the other two and I separated the units, e.g. basement vs. kitchen upstairs vs. another nearby structure. Again, had some problems and then when Codex suggested a HEX code, it seemed like we were embarking on a new protocol and that's when it came to my attention current practice is to use LXMF.

In my earlier tests, I did not pay attention to what LXMF, but did confirm I could get microReticulum to communicate between two T-Beams. It wasn't until I began to feel Codex was charting new territory that I became more attentive and learned of LXMF and that my assumption was erroneous. (See my blog post of today: https://mastodon.online/@VogueLaGalere/116705200434453200.) That's when I learned of your project, reticulum-specifications. So I copied your model for purposes of helping me learn about LXMF so I could have a specification to study and analyze.

I'm hoping my efforts in Reticulum arena might be beneficial to all concerned.

[jlpoolen]

I asked ChatGPT for it's interpretation of asymmetric links. Interesting, that kind of problem is a perfect example of why specifications help isolate focus on design. Perhaps I should preserve and post on my web site some of the logs for posterity?

[jlpoolen]

The latter part of this analysis, Chapter 11: Transport Layer from the Reticulum Protocol Textbook, enlightening, especially with the timeouts. My testing code is constructed to have 30 of 60 seconds be a unit of time after which everything repeats itself; example: BOB sends to CY "BOB says Hi to CY" every minute and CY is suppose to do likewise. "LINK_STALE_TIME" piques my curiosity and does not seem well-addressed in the Chapter 11 summary, but see the two references in Chapter 8: Link Communication.

[jlpoolen]

Food for thought: https://codeberg.org/Lew_Palm/leviculum/issues/17 causes me to realize that in my test, unit DAN is give the burden of transmitting as a forwarder and I do not think I have addressed when it might forward to avoid contention with other transmitters. Another was of writing this is: by using the transport, I am adding transmissions to the airwave that may be competing with other units. My model of dividing a 30 second time slice and allocating time points for each unit to send on a LINK, did not take into account that any unit acting as a transport has additional transmission responsibilities which might compete in other unit's allocated time. hmmm.

[thatSFguy]

Here's the deal on asymmetric lengths. When you're using reticulum it uses the same forward path as the return path. So node A goes to node B and return. Everything works fine. However, when you're introducing a transport node, especially with Lora, you have node A going to node T to node B. But if node A knows about node B, you have no guarantee that it's getting routed through node T. Hence, if it doesn't take the same forward path as return path, then it fails. In order to prove that transport nodes work, you can have node A block the learning of node B and node B block the learning of node A. That way, you can guarantee that everything is routed through node T and your messages should go through.

[attermann]

That’s a good point. RNode_Firmware has pretty sophisticated CSMA for LoRa that helps units cooperate in sharing the same band. I don’t know much about the low levels of BLE but perhaps you’ll need something similar.

…

On Jun 7, 2026, at 6:02 AM, John Poole ***@***.***> wrote: Food for thought: https://codeberg.org/Lew_Palm/leviculum/issues/17 causes me to realize that in my test, unit DAN is give the burden of transmitting as a forwarder and I do not think I have addressed when it might forward to avoid contention with other transmitters. Another was of writing this is: by using the transport, I am adding transmissions to the airwave that may be competing with other units. My model of dividing a 30 second time slice and allocating time points for each unit to send on a LINK, did not take into account that any unit acting as a transport has additional transmission responsibilities which might compete in other unit's allocated time. hmmm. — Reply to this email directly, view it on GitHub <#53?email_source=notifications&email_token=ACXDLGMGIZ7VSAX2QHEBZ2T46VKTVA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZSGA4TGMRTUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-17209323>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACXDLGK4RYSJXNXW2EUD6HL46VKTVAVCNFSM6AAAAACZHNPZKCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTOMRQHEZTEMY>. You are receiving this because you were mentioned.

[jlpoolen]

I'm back to LoRa now, the Bluetooth was to establish a way for a T-Beam to communicate with an Android. CSMA ("Carrier-sense multiple access is a medium access control protocol in which a node verifies the absence of other traffic before transmitting on a shared transmission medium, such as an electrical bus or a band of the electromagnetic spectrum...[u]nder CSMA, a transmitter uses a carrier-sense mechanism to determine whether another transmission is in progress before initiating a transmission") is something I recall hearing about, but never gave much thought about. Now, I'm thinking of the airwaves as akin to the old telephone party line and not a network where prioritization and traffic is all magically handled for you.

[attermann]

Have you been able to come up with any proposed solution for this in your testing, short of manually configuring nodes to avoid direct communication? Wondering if this could be resolved with a straight-forward change to routing or if it’s something more fundamentally wrong at the protocol level. Also curious if Mark has chimed in yet.

…

On Jun 7, 2026, at 7:11 AM, Rob ***@***.***> wrote: Here's the deal on asymmetric lengths. When you're using reticulum it uses the same forward path as the return path. So node A goes to node B and return. Everything works fine. However, when you're introducing a transport node, especially with Lora, you have node A going to node T to node B. But if node A knows about node B, you have no guarantee that it's getting routed through node T. Hence, if it doesn't take the same forward path as return path, then it fails. In order to prove that transport nodes work, you can have node A block the learning of node B and node B block the learning of node A. That way, you can guarantee that everything is routed through node T and your messages should go through. — Reply to this email directly, view it on GitHub <#53?email_source=notifications&email_token=ACXDLGICYGOOY6KCV5DFHHD46VSZVA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZSGA4TOMZTUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-17209733>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACXDLGN66GBEXFYWRXQORIL46VSZVAVCNFSM6AAAAACZHNPZKCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTOMRQHE3TGMY>. You are receiving this because you were mentioned.

[jlpoolen]

I do not reach out to Mark, he's very busy, you know and seems over-burdened. I did request (here) some source files for the OpenModem project and there has been no response.

I was going to dive deeper in LINK, and then ChatGPT brought to my attention LXMF [Lightweight Extensible Message Format] and when I tried to find a specification for the LXMF "protocol," I stumbled upon the fact that the use of the term "protocol" in the Reticulum sphere may encompass reference implementation and no specification. The lack of a specification brought me to reticulum-specification project and I marveled at what you had to go through to build out microReticulum. The more I test, the more I add debugging code so there is a record to review and to document. I am pivoting now to extracting and building specifications that can track Mark's work so I know I always have a gold standard to reference. When I get that pinned down and can fully understand LXMF and the LINK mechanisms, I come back to 7 unit testing platform and create further debugging statements so an accurate record can be created to serve as examples and document. (I did a lot of appellate brief writing and creating a record is just something that's ingrained in me, along with knowing whom I am working with.)

By the way, I found Lew Palm's Reticulum Protocol Textbook really really helpful, I imagine it would have been a boon when you were building microReticulum.

[thatSFguy]

Realistically, there is a reason both MC and MT use flood routing and I'm not going to look up the quote, but IIRC the response was like"because it's what works best". In a mesh with unequal peers, RX de-sense, TX with more power, and antennas that don't perform equally on RX/TX, it makes difficult to have symmetric links and why should we? if someone has a weak node and needs a boost through a "repeater" to get to a destination node... be my guest. However, the receiver has a better antenna and more power and go directly back to the origin node and that just created asymmetry, but the receiving node is expecting the response from the "repeater".

Partially the problem is that there is no link quality metric. Any announce will trigger an entry into the routing table. Mark made a comment, I don't recall where, so I'm paraphrasing: "generally the last announce is also the best path" or something like that. When he came up with that, most nodes were probably limited to around 17dBm and all performed equally, so it was probably a true statement.

Well, now with these "crazy meshes" where you order a node from Amazon and flash it and bam you are part of "network" where one node yells louder than the next, the simple rule is not so simple, so flood routing wins.

The paths are:

1. Switch to flood routing and max hop count like MT (less efficient)
2. Ensure that you have proper isolation between nodes and setup your LoRa network carefully.
3. Build something new that uses routing, observes link quality, and like a cellular network have a box that optimizes nodes.

3 is the best, but also the hardest. you have to track link quality, but don't track how messages are routed for security purposes, optimize links by adjusting the power output, and have each node understand how to route a packet most efficiently by balancing the routes to not overload one single path. Anyway, it's difficult problem and maybe if it's still there in November I'll take a(nother) shot at solving it. Food for thought, it needs to be a standalone network, not controlled by a mobile app or desktop app, but by internal logic that lives in the node. One additional item to consider is to how to minimize writes to the nodes flash as you could quickly burn out a node (in weeks) that generally should last years.

This probably sounds like deep thought, because it is. :-)

[attermann]

Do you know exactly what it is about asymmetric Links that cause them to fail? I’m wondering if it’s something to do just with Links that requires that the forward and reverse paths be identical, or is it a more fundamental issue of packet routing in general and not something specific to Links?

The reason I ask is because I’ve been exploring this deeper, and it seems to me that the issue (or at least one of the issues) is that fundamentally RNS assumes that all next-hops are symmetrical. That is, when a transport node receives an announce from a peer, it automatically assumes that communication with that peer is bidirectional and records the route. But if in fact that peer can not hear the transport node due to RF asymmetry, then ALL packets destined for the announcing node that traverse that transport node will stall there due to that entry in the path table.

If there’s more to it than that then I’d like to know. I’m designing a protocol to identify asymmetries and fix the low-level packet routing issue, but if there are also separate Link-level issues, I’d like to consider those too as part of my design.

[thatSFguy]

I honestly don't know. I have 4 repos that I tried to fix it in. I thought is was something I was doing wrong, until I tried the same test with python with the exact same failure. I'm currently working on a agnostic LoRa network, that is not specific to MT, MC or RNS. I'll let you know how it works when I have several nodes in operation.

[thatSFguy]

I'm working on an alternative...

An app-agnostic LoRa mesh backbone — a dumb, efficient transport that moves addressed packets between nodes the way the internet moves IP. Applications ride on top as opaque payload (a Reticulum app, a phone over BLE, anything); the backbone itself is never programmed per-app.

The novelty (vs. Meshtastic/MeshCore/Reticulum): link-quality-aware routing with independent per-direction paths — asymmetric/one-way links are used, not discarded.

[jlpoolen]

For what it is worth, I think I achieved successful LINK transports from BOB through DAN to CY. But then I found I had not checked in everything and performed another test, with more intensive logging, and BOB & CY got their transported LINK messages, but DAN was missing CY's direct. That causes me to wonder if the extra debugging is crippling DAN. Now git is acting up with a suggestion of corruption on my compiling server. So all this is to say that I had a glimmer of success, but I'm trying to reproduce that specific version which had less debugging to verify. So I may be very close. I used up my weekly Codex allowance, but the "week" refreshes in the next 1/2 hour. I'll update once I've rerun the previous version and then consult with a renewed Codex.

[jlpoolen]

I was able to reproduce the results. I had Codex review the logs, here are its comments. I think this should be good news for Chad and the project.

Results

Both runs used the same reverted firmware build:

BOB build=20260612_034703
CY  build=20260612_034704
DAN build=20260612_034704
rns_log=notice

Both report git=unknown, but their README files identify git checkout 360be71.

10.5-Minute Run

BOB-CY transport through DAN was completely successful:

Direction	TX	RX	Result
BOB → CY	10	10	100%
CY → BOB	9	9	100%
BOB → DAN	10	10	100%
DAN → BOB	10	10	100%
DAN → CY	10	10	100%
CY → DAN	9	0	0%

For every BOB-CY message:

• DAN logged MR TRANSPORT LINKFWD.
• The recipient reported phy=Dan(3).
• There were no Link retries.
• There were no stale Links.
• There were no transport drops.
• BOB-CY successfully changed from BOB-initiated Link 8822cd... to CY-initiated Link 89b4ad... after the second announcement.

This is strong evidence that sustained bidirectional Link transport through DAN works reliably at notice logging level.

Why CY → DAN Fails

The logs expose a scheduling/half-duplex issue.

At CY’s slot, CY sends:

210211.301 CY says Hi to BOB
210211.652 CY says Hi to DAN

DAN receives the first packet and immediately forwards it:

210211.527 RX PHY: phy=2 len=100
210211.528 MR TRANSPORT LINKFWD: dest=8822cd...

While DAN is forwarding CY’s first packet to BOB, CY sends the second packet addressed directly to DAN. DAN is transmitting and cannot receive it. This repeats every minute.

That explains why:

• CY → BOB succeeds through DAN.
• CY → DAN consistently fails.
• DAN records only one CY physical frame during each CY slot.

The single CY → DAN success in the shorter run occurred when DAN apparently missed or did not forward the preceding CY → BOB frame, leaving it available to receive CY → DAN.

Debugging Hypothesis

These results substantially strengthen the concern about trace logging:

• Three notice-level BOB/CY/DAN runs now show successful transport.
• The 10.5-minute notice run delivered every BOB-CY message.
• The earlier trace-level seven-unit run had 39 retries, six transport drops, and poor delivery.

It is not yet a controlled proof because the trace run also had seven transports instead of three. However, synchronous trace logging remains a credible contributor.

Conclusion

Revision 360be71 with notice logging demonstrates stable BOB-CY Links through DAN. The remaining loss is not a transport-Link failure; it is caused by CY sending back-to-back peer messages while DAN is forwarding the first and therefore cannot receive the second. No code was changed.

[attermann]

What I am gathering from this: - TRACE logging may be contributing to a failure to meet tight scheduling requirements - There is a flaw in app-level test process scheduling that is leading to collisions If that’s accurate then the latter is obviously something to address in your test process, but both actually might be vastly improved if not completely resolved by some low-level work in the bluetooth Interface. Is it safe to assume that it’s all currently running in user-space synchronously in the same thread as uR and your test app? If so then I think you’d really benefit from some lower-level high-priority threading, buffering, and ideally kernel-level asynchronous interaction with the bluetooth physical interface so that sending and receiving becomes a tighter controlled and better synchronized independent process from the rest of the app. This plus adding some flavor of CSMA if it’s not already present would work wonders imho.

…

On Jun 11, 2026, at 10:19 PM, John Poole ***@***.***> wrote: I was able to reproduce the results. I had Codex review the logs, here are its comments. I think this should be good news for Chad and the project. Results Both runs used the same reverted firmware build: BOB build=20260612_034703 CY build=20260612_034704 DAN build=20260612_034704 rns_log=notice Both report git=unknown, but their README files identify git checkout 360be71. 10.5-Minute Run BOB-CY transport through DAN was completely successful: Direction TX RX Result BOB → CY 10 10 100% CY → BOB 9 9 100% BOB → DAN 10 10 100% DAN → BOB 10 10 100% DAN → CY 10 10 100% CY → DAN 9 0 0% For every BOB-CY message: DAN logged MR TRANSPORT LINKFWD. The recipient reported phy=Dan(3). There were no Link retries. There were no stale Links. There were no transport drops. BOB-CY successfully changed from BOB-initiated Link 8822cd... to CY-initiated Link 89b4ad... after the second announcement. This is strong evidence that sustained bidirectional Link transport through DAN works reliably at notice logging level. Why CY → DAN Fails The logs expose a scheduling/half-duplex issue. At CY’s slot, CY sends: 210211.301 CY says Hi to BOB 210211.652 CY says Hi to DAN DAN receives the first packet and immediately forwards it: 210211.527 RX PHY: phy=2 len=100 210211.528 MR TRANSPORT LINKFWD: dest=8822cd... While DAN is forwarding CY’s first packet to BOB, CY sends the second packet addressed directly to DAN. DAN is transmitting and cannot receive it. This repeats every minute. That explains why: CY → BOB succeeds through DAN. CY → DAN consistently fails. DAN records only one CY physical frame during each CY slot. The single CY → DAN success in the shorter run occurred when DAN apparently missed or did not forward the preceding CY → BOB frame, leaving it available to receive CY → DAN. Debugging Hypothesis These results substantially strengthen the concern about trace logging: Three notice-level BOB/CY/DAN runs now show successful transport. The 10.5-minute notice run delivered every BOB-CY message. The earlier trace-level seven-unit run had 39 retries, six transport drops, and poor delivery. It is not yet a controlled proof because the trace run also had seven transports instead of three. However, synchronous trace logging remains a credible contributor. Conclusion Revision 360be71 with notice logging demonstrates stable BOB-CY Links through DAN. The remaining loss is not a transport-Link failure; it is caused by CY sending back-to-back peer messages while DAN is forwarding the first and therefore cannot receive the second. No code was changed. — Reply to this email directly, view it on GitHub <#53?email_source=notifications&email_token=ACXDLGOXLPDJUAZD5TPBBTL47OAGVA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZSG42DQNJQUZZGKYLTN5XKY43UMF2GKX3DNBQW4Z3FUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-17274850>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACXDLGJONDPXS6RYXCHPAT347OAGVAVCNFSNUABIKJSXA33TNF2G64TZHM3TAMJVGYYDGNJTHNCGS43DOVZXG2LPNY5TCMBRGA2TQNZQUF3AE>. You are receiving this because you modified the open/close state.

[jlpoolen]

Yes, the burden of TRACE looks to be an inhibitor. Moreover, I want to be clear that these tests reults in the last 5 days are LoRa, not Bluetooth. I've halted Bluetooth testing for now and moved back to LoRa. Let's close this discussion which started with Bluetooth and has pivoted (in my mind) to LoRa so the dichotomy does not haunt further consideration.

[attermann]

Ah I see. If you said that I must have missed it. So is your transport node running “microReticulum_Firmware” or some other variant? If so then the extra work being done for TRACE should not (in theory) affect the radio, but it could be trampling your own app scheduling if it’s pretty tight.

…

On Fri, Jun 12, 2026 at 10:28 AM John Poole ***@***.***> wrote: Yes, the burden of TRACE looks to be an inhibitor. Moreover, I want to be clear that these tests reults in the last 5 days are LoRA, not Bluetooth. I've halted Bluetooth testing for now and moved back to LoRa. Let's close this discussion which started with Bluetooth and has pivoted to LoRa so the dichotomy does not haunt further consideration. — Reply to this email directly, view it on GitHub <#53?email_source=notifications&email_token=ACXDLGIJW47V54Q2XRMB34T47QVTBA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZSHAZDCMZWUZZGKYLTN5XKY43UMF2GKX3DNBQW4Z3FUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-17282136>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACXDLGJGWGXC74HGLEO4D6L47QVTBAVCNFSNUABIKJSXA33TNF2G64TZHM3TAMJVGYYDGNJTHNCGS43DOVZXG2LPNY5TCMBRGA2TQNZQUF3AE> . You are receiving this because you modified the open/close state.Message ID: ***@***.*** .com>