discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Bandwidth switching per symbol


From: bjoernm
Subject: Re: [Discuss-gnuradio] Bandwidth switching per symbol
Date: Thu, 28 Jul 2011 15:56:14 +0200
User-agent: Internet Messaging Program (IMP) H3 (4.2)

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

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











reply via email to

[Prev in Thread] Current Thread [Next in Thread]