Re: [Discuss-gnuradio] Bandwidth switching per symbol

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

Zitat von "Matthias Wilhelm" <wilhelm@informatik.uni-kl.de>:

> 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 bjoernm@ee.ethz.ch:
>
>> 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" <wilhelm@informatik.uni-kl.de>:
>>
>>> 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 bjoernm@ee.ethz.ch:
>>>
>>>> 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
>>>> Discuss-gnuradio@gnu.org
>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>>
>>
>

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio