Re: [Discuss-gnuradio] Bandwidth switching per symbol

[bjoernm]

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" <address@hidden>:

> 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