Detecting collisions

I’m wondering whether it’s possible to detect packet collisions?

Many of the well placed repeaters in the SoCalMesh have channel util >9%. I wonder how many packets don’t make it due to collisions. Would be interesting to have some stats!

The main counter argument would be that there’s not much that can be done. (LoRa doesn’t really lend itself to something like RTS/CTS. Could maybe do some time-slotting.)

I don’t see anything obvious signaling corrupted packets in the sx1262 datasheet. The closest may be to count failed CRCs. Maybe that’s already done? (didn’t see it)

Well, LoRa is old technology, been using it since 2014.

If there was an easy way of detecting collisions you would think there would be heaps of demonstrations of it by now.

You can detect a transmission in progress, with CAD, and if the packet with CRC error is fairly strong then its more likley to be caused by a collision than if the packet is very weak.

1 Like

That’s an idea.

I saw that RadioInterface tracks rxBad but it looks like that is not exported and doesn’t seem easy to incorporate into stats, which is a bummer. Would be interesting to see rxBad stats for nodes in fixed locations. Of course rxBad could be incremented just because the signal doesn’t make it because it’s very marginal, or fades due to transmitter location change, or gets wiped out by other interference, but still would be an interesting metric to track over time or compare between locations.

I also noticed that “channel utilization” is based on the packet lengths reported by the radio. If the header CRC check fails I assume the radio aborts the RX and the length must be zero, so channel utilization is bound to be an underestimate.

The only way to get a better channel util would be to do CAD non-stop, but that prevents RX due to the short preamble length chosen by meshtastic.

The CRC of the packet is at the end, so the whole packet has already been received.

The Meshtastic software might well abandon the processing of the packet with a failed CRC, but if you want to have a look at the contents of the packet (with errors) its there in the buffer.

Yes, the CRC for the payload is at the end. However, the header also has a CRC so the radio can abort the RX early if the header CRC fails. The primary motivation for that design as far as I understand is to avoid getting stuck erroneously trying to receive a very long packet just because the header was corrupt and the packet length byte was decoded as a large number.

On an SX126x yes, but SX127x only has a header valid flag.

Anyway, how would it help to detect ‘collisions’ ?

All the CRC failures indicate RX problems and times where the radio is busy receiving and nothing comes of it. There are several reasons that can lead to a failed CRC so it’s not a clean indicator of a collision per-se, but in some sense it doesn’t really matter. If a router in an “awesome high spot” has a high RXbad/RXgood ratio then that indicates that the spot is less awesome than thought. Some experiments can tease out whether it’s collision or other interference (not clear it matters). If the RXbad/RXgood data was propagated to the maps (like chan util and tx util is) I bet we could start to see a pattern where beyond a certain chan util the ratio goes south.

The SX1276 is indeed less transparent and doesn’t signal failed header CRCs in an easy to access manner. Presumably it just silently restarts its preamble detector.

Possibly, let us know how you get on.

But in summary, it does not appear to be possible to actually detect a collision with a standard LoRa device, although maybe its possible with something like an SDR.