Re: [Discuss-gnuradio] Bandwidth switching per symbol

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

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

> Am 28.07.2011 um 15:56 schrieb bjoernm@ee.ethz.ch:
>> Hi,
>>
>> Do you by any chance know where the corresponding part to:
>>> *out++ = gr_complex(0.0, 0.0);
>>> *out++ = gr_complex(iphase * 0.70710678, qphase * 0.70710678);
>>> *out++ = gr_complex(iphase, qphase);
>>> *out++ = gr_complex(iphase * 0.70710678, qphase * 0.70710678);
>>
>> is at the receiver?
>>
>> Could it be that this is in the file: gr_quadrature_demod_cf.cc
>>
>> for (int i = 0; i < noutput_items; i++){
>> gr_complex product = in[i] * conj (in[i-1]);
>> // out[i] = d_gain * arg (product);
>> out[i] = d_gain * gr_fast_atan2f(imag(product), real(product));
>> }
>>
>> that i need to change this part?
>>
>> best regards, and thanks for your reply
>>
>> Bjorn
>
> Hi,
>
> reception is a bit trickier ...
> The receiver flow graph is constructed in
> src/python/ieee802_15_4_pkt.py in class ieee802_15_4_demod_pkts. It
> is basically [ ieee802_15_4_demod -> packet_sink/message queue ],
> first doing an FM demod, filtering, and clock recovery, then the
> packet sink is searching for chips and keep track of the receiver
> state (search preamble, SFD, frame content, ...).
>
> I think you need to change two parts:
> 1) src/python/ieee_802_15_4.py, at the class ieee802_15_4_demod,
> make it work at the highest bandwidth you need. quadrature_demod_cf
> should work fine (the chips are decided by a slicer, so sample > 0
> -> "1" and sample < 0 -> "0", a larger bandwidth only leads to
> larger samples after FM demod). There is the variable sps (samples
> per symbol), try to increase it for more samples. You must also make
> sure that the filter and clock recovery do the right thing, so tweak
> the parameters accordingly (no idea how to get the clock recovery
> working across several rates). Since at this point you don't know
> anything about symbols and their rates, your hope is to modify the
> blocks available to support all rates simultaneously.
>
> 2) The packet sink (the code is in
> src/lib/ucla_ieee802_15_4_packet_sink.cc) expects a fixed rate, so
> you should increase the used sampling rate and decimate the low
> bandwidth symbols correctly when they arrive (or maybe this is
> already solved by clock recovery somehow).
>
> The transmitter must send the preamble with a known rate so that you
> know what to look for (to be able to find out when the first real
> symbol starts), and then use if clauses again to decimate. For this
> to work, the receiver must know beforehand which rate the symbols in
> the preamble are in and what the schedule for the packet is, if you
> want to find that out on the fly, you will likely have to
> re-implement larger parts of the receiver.
>
> Regards,
> Matthias

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