Re: [Discuss-gnuradio] Bandwidth switching per symbol

Hi

I figured it out... the problem was just the sender itself.
I forgot to change the parameter: static const int SAMPLES_PER_SYMBOL = 4;
to: static const int SAMPLES_PER_SYMBOL = 8;
in "ucla_qpsk_modulator_cc.cc"

At the receiver side, I actually only had to change the variable
"sps". I guess the filter and clock recovery still work, as the
parameter of those are influenced by the variable sps.

Well thank you for all your help! I hope I can get even some day...

best regards,
Bjorn

Quoting "Matthias Wilhelm" <wilhelm@informatik.uni-kl.de>:

> Am 29.07.2011 um 13:44 schrieb bjoernm@ee.ethz.ch:
>
>> 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/discuss-gnuradio@gnu.org/msg12723.html
>
> Regards,
> Matthias

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio