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 address@hidden:
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 Wilhelm" <address@hidden>:
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 Halperin, 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 address@hidden:
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