[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: |
Thu, 28 Jul 2011 17:15:49 +0200 |
Am 28.07.2011 um 15:56 schrieb address@hidden:
> 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] 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 <=
- 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, 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