Inverting Bits to Avoid Interference

A project log for QMesh: A LoRa-based Voice Mesh Network

Developing a synchronized, flooded mesh network to carry codec2-encoded voice over LoRa

Dan FayDan Fay 08/03/2021 at 12:340 Comments


One (experimental) parameter I'm exploring for COMA (Chirp Offset Multiple Access) is to invert the data bits on some transmissions as a way to help keep keep LoRa chirps from overlapping and interfering with each other. The idea here is that LoRa is a chirped version of an m-ary FSK. Basically, it appears that the "breaks" in the chirps correspond to a tone in this m-ary FSK. Moving around the "breaks" in the chirps should thus move around the chips somewhat in space-time.


There's no direct way for the receiver to know whether the bits have been inverted. Instead, the receiver attempts to decode both the inverted and non-inverted versions of the received packet. The correct one is then determined using the CRC. One issue I did encounter was that the Reed-Solomon decoder would fail on the "bad" packet, and produce a packet with all zeros. The CRC-8 algorithm used would treat this as correct, as the CRC algorithm would deliver a 0x00 value for an all-zeros packet. Since the CRC extracted from this all-zeros packet was 0x00, the CRC check would cause the packet to appear correct. Changing to the CRC-8 parameters to the ones used by CDMA2000 fixed this issue.


Of course, to really know whether this helps to mitigate interference will require some thorough testing with multiple nodes, which will...take some time.