Re: Collision detection and recovery

[Nitin Shivaraman]

Thanks a lot for the response Marcus! As the correlation is done only at the decoding level in Gr-802-15-4, the received data is mapped to one of 16 symbols to decode as 0x0 to 0xF.

As seen in the attached file, I'm trying to recreate a collision in the simulation environment by feeding two signals into an add block.

However, when the collision happens, I only receive 0x00 as the symbol for the decoder which does not correspond to any symbol. My understanding is that the collided packet can be obtained if a known original packet is subtracted and decoded from the collided signal.

Since the collided signal received is zero, I'm unable to decode any symbol. Please advise if I'm missing anything.

Thanks in advance.

Best Regards,

Nitin.

On Mon, Jun 13, 2022 at 9:19 PM Marcus Müller <mueller@kit.edu> wrote:

Hi Nitin,

not involved in gr-ieee802-15-4, I can maybe still comment on the collision detection part:

On 12.06.22 09:13, Nitin Shivaraman wrote:
> Since the preamble detection happens after the clock recovery mechanism, I want to know
> how the collision can be detected using correlation.

Yep!

> To detect collision, I intend to
> receive the collided packet and subtract part of the correctly received packet to recover
> both packets correctly.

You don't even need to subtract! You're correlating, and correlation is a linear
operation. When correlating for the preamble of the second packet, which lies within the
first packet, you simply get as correlation the sum of the autocorrelation at timeshift 0,
i.e. the energy, of the preamble (what you actually want to detect) and its
autocorrelation with the first packet at the timeshift between the two packets

By design, preambles typically have high autocorrelation at \tau=0 and low for other
timeshifts \tau. So, this should actually be pretty reliable, even without subtracting the
other packet first! You *will* get some interference, yes, and strictly speaking, this
should put your detection threshold a bit higher.


Best regards,
Marcus

Screenshot from 2022-07-11 11-37-02.png
Description: PNG image