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" <wilh...@informatik.uni-kl.de>:
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 bjoe...@ee.ethz.ch:
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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
