[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


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.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]