Re: [Discuss-gnuradio] Bandwidth switching per symbol

[Matthias Wilhelm]

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