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
