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 bjoe...@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" <wilh...@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 bjoe...@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
