UCLA ZigBee and the Capture Effect

Hi everyone,

First of all thanks a lot for any support!

I’m use the UCLA zigbee PHY (IEEE 802.15.4) on three nodes, of which
one is a dedicated receiver and the other two nodes are transmitting
simultaneously (No CSMA!).

I noticed that something like a capture effect is taking place,
meaning that even though the signal is synchronized to a weaker signal
(signal 1), the receiver appears to jump to the stronger signal
(signal 2) as soon as it arrives at the receiver (if the second signal
is significantly stronger then the first one).

I would like to influence this behavior, and hence am looking for the
related parameters. I just can’t find them! Does anyone have a clue
where this is happening?

I am using the XCVR2450 Daughterboard together with the USRP1.

Any hints, suggestions or detailed help will be highly appreciated!

best regards and thanks a lot,

B

Hi Bjoern,

the receiver uses FM demodulation to track phase changes, and when two
signals collide the stronger one simply has the larger influence on the
overall phase. This is actually a good property, because you still have
the chance to receive one of the colliding packets.

Do you want to go on receiving the weaker packet? This may be quite
tricky, because you cannot just separate the signals. One way I can
think is successive interference cancelation, first receive the stronger
packet, and subtract its signal and start receiving the weaker one.
There is a (“CS-style”) paper on this:
Daniel H., Thomas Anderson, and David Wetherall. 2008. Taking the
sting out of carrier sense: interference cancellation for wireless LANs.
In Proceedings of the 14th ACM international conference on Mobile
computing and networking (MobiCom '08). ACM, New York, NY, USA, 339-350.
DOI=10.1145/1409944.1409983 http://doi.acm.org/10.1145/1409944.1409983

Regards,
Matthias

Am 22.02.2012 um 11:42 schrieb [email protected]:

Hi Matthias,

Thanks a lot for your suggestions.

The thing is, one transmitter (jammer) is sending packets nonstop at a
constant transmit power, while the second transmitter (sender) sends a
packet every millisecond or so.

In this scenario, the receiver is always synchronized with the jammer
and even if the signal from the sender is stronger, the receiver only
decodes a fraction of the packets from the sender (around 1%). This
sounds reasonable as the receiver locks itself to the signal from the
jammer when nothing else is around and stays locked (remains decoding
the incoming signal) even if a stronger signal from the sender arives.
(Only between the jammers packets, when the receiver looks for new
preambles, there’s a chance for the receiver to sync with the sender
instead of the jammer.)
But at some point, when the signal from the sender is significantly
stronger (around 7-10db), the behavior changes and all the packets
from sender 2 get decoded.

Now it surprised me that this happend at all, that the packet delivery
rate from sender to receiver increased at some point instead of only
relying on the timings of preamble and sfd of sender and jammer.
That’s why I’m looking for any phase lock loops and control mechanisms
related to the capture effect.

Any suggestions?

best regards and thanks again for your time
B

Zitat von “Matthias W.” [email protected]:

Hi,

you should check out ucla_ieee802_15_4_packet_sink.cc, the receiver
checks if a valid chipping sequence for a payload symbol was found
(after synch), and starts searching for a new SFD in case there is no
possibly matching symbol.


unsigned char c = decode_chips(d_shift_reg);
if(c == 0xff){ // something is wrong. restart the search for a sync
enter_search();
} …

What might happen is the following:

preamble, SFD (jammer) -> sync … payload (jammer) … first 0 of
preamble (sender) completely destroys a symbol such that the receiver
gives up … receiver syncs with the rest of the preamble (sender) and
happily receives packet (sender).
To prevent such “re-capture”, you can modify the receiver to just
continue receiving anyway, and picking some symbol at random when no
decision can be made. Or you can fiddle with the threshold of how many
chips must match, it may be too conservative (decode_chips should always
return a symbol in this case). I think this is also what most COTS
receivers do, they honor the packet length in the PHY header and try to
find symbols in any case.

–Matthias

Am 23.02.2012 um 11:49 schrieb [email protected]:

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

Zitat von “Matthias W.” [email protected]:

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 W.” [email protected]:

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 [email protected]:

Hi LRK,

Thanks for the reply! I thought so too, that this capture effect or
phase locking or limiting should come from the demodulator or clock
recovery block, but looking at the c++ files, I couldn’t find anything
related to this. Did I miss something?

The receiver is connected as follows:
self.fmdemod = gr.quadrature_demod_cf(1)
self.freq_offset = gr.single_pole_iir_filter_ff(alpha)
self.sub = gr.sub_ff()
self.clock_recovery = gr.clock_recovery_mm_ff(omega,
gain_omega, mu, gain_mu,omega_relative_limit)

     self.connect(self, self.fmdemod)
     self.connect(self.fmdemod, (self.sub, 0))
     self.connect(self.fmdemod, self.freq_offset, (self.sub, 1))
     self.connect(self.sub, self.clock_recovery, self)

But looking at eigher
gr_clock_recovery_mm_ff.cc
http://gnuradio.sourcearchive.com/documentation/3.2.2.dfsg/gr__clock__recovery__mm__ff_8cc-source.html
or
gr.quadrature_demod_cf.cc
http://gnuradio.sourcearchive.com/documentation/3.2.2.dfsg/gr__quadrature__demod__cf_8cc-source.html

didn’t help me… any suggestions?
In front of the demodulator is also the Low pass filter:
self.channel_filter = gr.fft_filter_ccc(sw_decim, chan_coeffs)

best regards, B

Quoting LRK [email protected]:

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs