[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] UCLA ZigBee and the Capture Effect
From: |
Matthias Wilhelm |
Subject: |
Re: [Discuss-gnuradio] UCLA ZigBee and the Capture Effect |
Date: |
Thu, 23 Feb 2012 13:39:53 +0100 |
Hmm,
there is a clock recovery block (gr.clock_recovery_mm_ff) that may lock to the
stronger signal. Maybe you can find a way to stop it from changing things after
you found an SFD, and turn it on again after the packet. I don't know what the
block is doing exactly, but changing its parameter at runtime might have such
an effect.
However, if there is some lower level behavior, you should rather see damaged
packet (such as a preamble in the payload) than only correct (sender) packets,
right? When two preambles collide, then the stronger packet is received, if
packet and preamble collide then the first packet should be damaged, in the
best case containing symbols from the stronger (second) packet at some point.
--Matthias
Am 23.02.2012 um 12:29 schrieb address@hidden:
> Hi,
>
> Quote "you can modify the receiver to just continue receiving anyway"
>
> This is already done within the packet_sink by saying
>
> if (min_threshold < d_threshold or true)
>
> hence as soon as the receiver got into the decode_chips loop, it should stay
> there! ((c == 0xff) should never hapen!)
>
> couldn't there be something in some lower level influenceing this behavior? I
> need to figure out what mechanism it is, that enables the increase in packet
> delivery rate between sender and receiver.
>
> any suggestions?
> best regards and thanks again
>
> B