[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Bandwidth switching per symbol
From: |
Matthias Wilhelm |
Subject: |
Re: [Discuss-gnuradio] Bandwidth switching per symbol |
Date: |
Fri, 29 Jul 2011 14:22:12 +0200 |
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
- [Discuss-gnuradio] Bandwidth switching per symbol, bjoernm, 2011/07/27
- [Discuss-gnuradio] Bandwidth switching per symbol, bjoernm, 2011/07/27
- Re: [Discuss-gnuradio] Bandwidth switching per symbol, Matthias Wilhelm, 2011/07/27
- Re: [Discuss-gnuradio] Bandwidth switching per symbol, bjoernm, 2011/07/27
- Re: [Discuss-gnuradio] Bandwidth switching per symbol, Matthias Wilhelm, 2011/07/27
- Re: [Discuss-gnuradio] Bandwidth switching per symbol, bjoernm, 2011/07/28
- Re: [Discuss-gnuradio] Bandwidth switching per symbol, Matthias Wilhelm, 2011/07/28
- Re: [Discuss-gnuradio] Bandwidth switching per symbol, bjoernm, 2011/07/29
- Re: [Discuss-gnuradio] Bandwidth switching per symbol,
Matthias Wilhelm <=
- Re: [Discuss-gnuradio] Bandwidth switching per symbol, bjoernm, 2011/07/29
- Re: [Discuss-gnuradio] Bandwidth switching per symbol, Matthias Wilhelm, 2011/07/29
- Re: [Discuss-gnuradio] Bandwidth switching per symbol, bjoernm, 2011/07/29
- Re: [Discuss-gnuradio] Bandwidth switching per symbol, bjoernm, 2011/07/29