Re: [Discuss-gnuradio] UCLA ZigBee and the Capture Effect

[bjoernm]

Hi, thanks for the hints!

I was thinking about the clock recovery too. Its pretty complicated in  
there, but I keep trying.

I just discovered that the performance of sender and receiver also  
depends on the interpacket times of the sender ...

(remember I mentioned before that the sender sends a packet every  
millisecond while the jammer transmits nonstop (actually the jammer  
sends nonstop SHR PHR SHR PHR SHR PHR ...))

... The performance gets worse when I increase the interpacket times  
at the sender from one millisecond to 10 ms and it drops to 0 % packet  
delivery rate when I set it to 100ms. Would this confirm that the  
issue must be in the clock recovery part?

> 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.

I guess so, but I think its rather going to be nonsence symbols due to  
different clock recoveries...!?

best
B

Zitat von "Matthias Wilhelm" <address@hidden>:

> 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