Re: [Discuss-gnuradio] Bandwidth switching per symbol

[Matthias Wilhelm]

Hi, 

I think you need to change the the O-QPSK modulator, it's in 
src/lib/ucla_qpsk_modulator_cc.

Currently, for each chip, it expects 2MChips/s and produces 4 complex samples 
that specify the shape of the pulse (half a sine wave up for chip "1" and down 
for chip "0" or -1):
*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);

If you add more samples per pulse by interpolating in-between (say 8), you 
halve the bandwidth while using the same chipping sequence, using only 2 
samples doubles it (when you use a fixed sampling rate). 

So if you want to increase the bandwidth, you should first adjust the default 
sampling rate/decimation of the ZigBee code as defined in the python script 
when initiating the USRP source, from 4MSamples (decim 16) to a higher value, 
and adjust the modulation block accordingly (e.g., decim 8 ->  use 8 
samples/chip), so that you still have several samples per chip even on larger 
bandwidths (to generate smooth pulses).

The changes are then straight-forward, you just specify different cases/if 
clauses and produce a different number of samples for each symbol (i.e., for a 
sequence of 32 chips), depending on the bandwidth you want. 

The larger problem may be how to get the "schedule" information from python to 
the C code so that it's synchronized with the sampling stream, I don't have 
much experience on how you can achieve this in GNU Radio. I think there is a 
way to attach meta-data to a stream of samples ... Another approach is in-band 
signaling (interleaving special tags into the stream of samples that change 
settings in the blocks and are filtered out in the end), but I think it's more 
of a hack than sound design.

Matthias

Am 27.07.2011 um 15:22 schrieb address@hidden:

> Hi,
> 
> Thanks a lot for your reply!
> 
> This is exactly what I was looking for!
> Would you by any chance have an idea in what C level files I could manipulate 
> the interpolation?
> 
> best regards and thank you,
> Bjorn
> 
> Zitat von "Matthias Wilhelm" <address@hidden>:
> 
>> Hi,
>> 
>> i think this would be hard on the python level, you would need to notify the 
>> python code after each symbol to make adjustments, which will lead to 
>> latency between symbols ...
>> 
>> (As I understand you want to keep the chipping sequences, but change the 
>> sampling rate used for each symbol. You can have the same effect by changing 
>> the interpolation between samples, keeping the rate constant, and 
>> oversampling small bandwidths. )
>> For this, I would suggest that you add a "per packet schedule" that 
>> specifies the bandwidth of each symbol, and hack the C code to follow the 
>> schedule, changing the interpolation between chips for each symbol.
>> Something like send_802_15_4_pkt (packet, "1,2,8,2,4,1"), meaning 1MChips/s 
>> for the first symbol, 2MChips/s (the default) for the second, then 
>> 8MChips/s, etc. The benefit is that you can go on working on the packet 
>> level in python.
>> On the C side, you would need to run the flow graph at 16MSamples (to get 2 
>> samples per chip @ 8MChips/s, basically fast enough to support the largest 
>> bandwidth you want), and decide for each symbol the necessary interpolation 
>> to generate the specified bandwidth (e.g., 16 samples/chip @1MChips/s).
>> 
>> Regards,
>> Matthias
>> 
>> 
>> Am 27.07.2011 um 13:31 schrieb address@hidden:
>> 
>>> Hi,
>>> 
>>> I'm currently using the UCLA ZigBee Phy implementation by Thomas Schmid and 
>>> I need to
>>> change the Bandwidth of the used wireless channel on a per symbol basis.
>>> 
>>> I managed to change it on a per packet basis, which can be done on the 
>>> python level
>>> (tunnel.py, usrp_transmit_path.py etc.). Well now, I need to do the same 
>>> thing, but on a
>>> per symbol basis, which (up to my knowledge) is not possible from the 
>>> python level...
>>> 
>>> Does anyone have an idea how I could do that? (Changing the Bitrate of the 
>>> USRP after
>>> each symbol (e.g. after sending 32 modulated bits (actually chips)))
>>> 
>>> I would be very happy for any help or suggestions!
>>> Thanks a lot!
>>> 
>>> best regards,
>>> Bjorn
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> 
> 
> 
>