Question on queuing #2

New Issue

2026-10-27T09:28:03+01:00

adam commented

2026-10-27 09:28:03 +01:00

With one of these LoRa hats being used as a serial interface, do we run into issues where packets are getting lost/dropped, since the LoRa hat will not have any CSMA/queueing?

With one of these LoRa hats being used as a serial interface, do we run into issues where packets are getting lost/dropped, since the LoRa hat will not have any CSMA/queueing?

adam closed this issue

2026-10-27 09:28:03 +01:00

adam commented

2026-10-27 09:28:04 +01:00

Are you referring to the Pi HATs that connect via SPI, or the TNC serial connection?
Both work a bit differently — with the SPI version, it toggles the IRQ for CAD and uses an exponential backoff. This process is attempted up to four times before the packet is sent regardless.

The serial TNC uses the same basic concept as the MC firmware I believe.

Thanks

Are you referring to the Pi HATs that connect via SPI, or the TNC serial connection? Both work a bit differently — with the SPI version, it toggles the IRQ for CAD and uses an exponential backoff. This process is attempted up to four times before the packet is sent regardless. The serial TNC uses the same basic concept as the MC firmware I believe. Thanks

adam commented

2026-10-27 09:28:05 +01:00

Hey. Thanks for the response.

I am getting my head around this type of HAT and saw your project. Nice work!

I have a meshadv hat that I have never used (I think it uses SPI as MT requires this). I could not however, find much information on this with other software and a reticulum post put me off (admittedly for a different board) as it stated that these boards meant collisions were more likely as they do not use CDMA / collision detection etc. This however, could have been specific to reticulum and rnode but it left me with doubts.

I think my question is - when using such a board is the collision detection consistent with using a standard meshcore device? I think you have answered this, thanks!

Would be interesting to understand if this is 100% correct but can't think how to prove this ATM.

Hey. Thanks for the response. I am getting my head around this type of HAT and saw your project. Nice work! I have a meshadv hat that I have never used (I think it uses SPI as MT requires this). I could not however, find much information on this with other software and a reticulum post put me off (admittedly for a different board) as it stated that these boards meant collisions were more likely as they do not use CDMA / collision detection etc. This however, could have been specific to reticulum and rnode but it left me with doubts. I think my question is - when using such a board is the collision detection consistent with using a standard meshcore device? I think you have answered this, thanks! Would be interesting to understand if this is 100% correct but can't think how to prove this ATM.

adam commented

2026-10-27 09:28:05 +01:00

This is actually quite interesting — when I implemented LBT, I took what I believe was a slightly different approach to MC, but ultimately it achieves the same result.

I do think the CAD IRQ method is the best approach, as it can be finely tuned to really dial in performance.

Personally, I believe it should be trusted to the point where a transmission is discarded if CAD has deemed it still busy within a defined time slot. That said, I’m trying to stay as close as possible to MC’s default behaviour.

Ps. I have dm'ed you on discord if you would like to discuss.

This is actually quite interesting — when I implemented LBT, I took what I believe was a slightly different approach to MC, but ultimately it achieves the same result. I do think the CAD IRQ method is the best approach, as it can be finely tuned to really dial in performance. Personally, I believe it should be trusted to the point where a transmission is discarded if CAD has deemed it still busy within a defined time slot. That said, I’m trying to stay as close as possible to MC’s default behaviour. Ps. I have dm'ed you on discord if you would like to discuss.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/pyMC_Repeater#2