Re: [Discuss-gnuradio] Bandwidth switching per symbol

[Matthias Wilhelm]

Am 29.07.2011 um 13:44 schrieb address@hidden:

> Hi again,
> 
> Thanks a lot for your mail from yesterday!
> 
> In order to figure out what changes are needed at the receiver, I do not 
> change the bandwidth per symbol, but constantly, by using the following lines 
> within ucla_qpsk_modulator_cc.cc.
> 
>  *out++ = gr_complex(0.0, 0.0);
>  *out++ = gr_complex(iphase * 0.38268343, qphase * 0.38268343);
>  *out++ = gr_complex(iphase * 0.70710678, qphase * 0.70710678);
>  *out++ = gr_complex(iphase * 0.92387953, qphase * 0.92387953);
>  *out++ = gr_complex(iphase, qphase);
>  *out++ = gr_complex(iphase * 0.92387953, qphase * 0.92387953);
>  *out++ = gr_complex(iphase * 0.70710678, qphase * 0.70710678);
>  *out++ = gr_complex(iphase * 0.38268343, qphase * 0.38268343);
> 
> Now in the file: ieee802_15_4.py @ ieee802_15_4_demod
> I have changed the variable sps from 2 to 4, as previously suggested.
> The result is, that the receiver receives half the packet correctly, and the 
> whole second half appears to be random.
> 
> I don't think that we need to change the file 
> "ucla_ieee802_15_4_packet_sink.cc" in this case.
> 
> Now it would be great if I could just tweak the parameters in 
> "ieee802_15_4_demod", but how?
> 
> clock_recovery and the iir filter are gnuradio specific functions, hence 
> tweaking the parameters should in general work in a constant BW case, right?
> 
> Do you have any suggestions on those parameters?
> 
> many thanks and have a good weekend soon,
> Bjorn

Hi, 

to clarify, do you get a good half packet each time a packet arrives, or are 
50% of the packets good and 50% broken (or undetected)?
I understand that you have something like (g means good symbol, b means bad):
gggggggggggggbbbbbbbbbbbb
for all packets you see, which would be a rather strange behavior. It would 
suggest that everything is working fine and robust for the first half, and 
somehow breaks down in-between.
 My remote diagnose in this case is that the state machine in the packet sink 
detects the preamble and SFD (and maybe the header as well) for each packet, 
but has some hard-coded parts that expects the default bandwidth, producing 
arbitrary results for the rest of the packet. You should check how far the 
state machine works correctly, and debug the problem case. You can active the 
debug symbols in the UCLA code (VERBOSE and VERBOSE2) to see what is happening 
in the state machine of the receiver.

If it's 50/50% good/bad packets, then I would suspect the timing recovery, but 
the parameters are also rather magical for me. But I think its the standard(?) 
Mueller&Müller clock recovery algorithm, so there should be some info in 
textbooks how it works and what parameters are suitable. I found this: 
http://www.mail-archive.com/address@hidden/msg12723.html

Regards,
Matthias