[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: |
Wed, 27 Jul 2011 16:15:14 +0200 |
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
>>
>
>
>
- [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 <=
- Re: [Discuss-gnuradio] Bandwidth switching per symbol, bjoernm, 2011/07/28
- Re: [Discuss-gnuradio] Bandwidth switching per symbol, Matthias Wilhelm, 2011/07/28
- 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