[Discuss-gnuradio] ofdm - adjust subcarriers
Hi out there, I'm trying to send an ofdm signal. I don't want to tramsit any data, I only want to see the reslting spectrum. Now I'm wondering how to turn off certain carriers. I know this is possible by adjusting the transmitted data but is there a better way to do this? For example by commandline? Hope someone can help. Hanno ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] switching filter taps in rational resampler
Dear All, I'm trying to correct for clock drift, and implement clock recovery, reading data from a USRP1. I can't use MM clock recovery. The signal is DSSS, and I can produce accurate estimates of the phase / timing error, but not on a continuous stream in real time. I hope therefore to make periodic measurements and feed this correction information back to the main data stream. I'm using a rational resampling filter to pulse shape and produce a chip rate data stream at a ratio of interp/decim. In order to sample the signal at the centre of its energy, it occurred to me that I could adjust the phase of the filter by shifting the polyphase taps over; essentially padding with zeros at one end. This moves the centre of the filter over by 1/decim chips for each pad zero, allowing me to sample the signal at any selected sub-chip phase. I'm short of CPU power, so can't afford to do too much processing to the signal, hence combining pulse shaping, resampling and clock phase correction into a single filter step. The USRP sampling clock has a frequency error in it. I'm typically seeing about 8 samples error per second, sampling at 8MHz (ie. decimating by 8 on the USRP), though this varies considerably with temperature. At rational resampling decim = 23, this would mean changing the filter taps around 8*23 times a second to track the clock phase and sampling error, though I can probably tolerate a worse error than 1/23 of a chip, so, perhaps 1/3 of this rate. How efficient is it to alter the filter taps on the fly? Is there much overhead? If instead I switched between a bank of 23 filters, how would I ensure continuity of data? When I wrap around, ie. change to / from filter (delay == 0), to (filter delay == (decim-1)), I will need to adjust the data stream to repeat or skip a chip. I would probably subclass the rational_resampler class and override the general_work() method to achieve this. I would have to make the private data protected in the resampler code too; perhaps it should be protected to allow this generally? Does this approach make sense? Is there a better way? -- Dave Berkeley ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 802.11 BBN Code TX - filter fix?
If someone writes a Fast Walsh Transform block, then 5.5 and 11 Mbit is possible. Only a few changes need to be made to the MAC block to accommodate this change. Getting G (OFDM) to work seamless with B will be be a bit difficult I think. You are then switching rates, 20 MHz vs 11 MHz if I remember correctly. On Mon, Nov 23, 2009 at 4:34 AM, Doug Geiger doug.gei...@gmail.com wrote: George Nychis wrote: Hi all, I was taking a look with Brian at the 802.11 BBN code for the USRP2 in CGRAN (usrp2_version), in specific the transmission path. I don't konw if anyone ever got to try out the TX code with the USRP2, but we found that the low pass filter after spreading was too small, causing a quick dropoff in frequency response. This would likely lead to high BER at the receiver. I kind of based this off of the Simulink 802.11b model, as it seemed like the frequency response of the 802.11 BBN code was odd. If you look at matlab_spectrum.png and compare it to old_spectrum.png, the shape of the GR BBN old spectrum is very rounded in terms of the fall off and the fall off happens very quickly. So what we did next is take a look at the taps used in the filter, and confirmed from plotting them that the sampling frequency and the cutoff frequency was incorrect. If you look at filter_orig_vs_new.png, you can see the difference between the two filters. In the end, we get new_spectrum.png which shows a much better waveform! Hopefully this helps BER of transmitting over the air. I haven't gotten a chance to try this yet. - George Interesting - I had only done a couple tests with TX on the USRP2: enough that I was able to see proper frames in Wireshark with a commercial card. I never hooked it up to a spectrum analyzer (or another USRP2 to do similar) - but from your figures it does look like it's rolling off pretty fast. Doug -- Doug Geiger doug.gei...@bioradiation.net doug.gei...@ieee.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Problem converting old GRC flowgraph
Josh, Is there some separate program to convert old-style GRC flographs (ie - grc_0.69) to the new-style ones required by the GRC included with GnuRadio 3.2.2? I tried to simply use GRC to open the older flowgraph (which worked fine on grc 0.69 and gnuradio 3.1.3) directly, but got hundreds of error messages which started off with ...:2:0:ERROR:VALID:DTD_CONTENT_MODEL: Element flowgraph does not follow the DTD, ... @(^.^)@ Ed ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem converting old GRC flowgraph
You missed the window of opportunity. There was such code, it existed for about a year in the svn trunk. You need to checkout the svn trunk from about a year ago, and use that grc/gnuradio to open the files (this will convert them). Now you can use those converted files with the grc in the git master or 3.2 -Josh Ed Criscuolo wrote: Josh, Is there some separate program to convert old-style GRC flographs (ie - grc_0.69) to the new-style ones required by the GRC included with GnuRadio 3.2.2? I tried to simply use GRC to open the older flowgraph (which worked fine on grc 0.69 and gnuradio 3.1.3) directly, but got hundreds of error messages which started off with ...:2:0:ERROR:VALID:DTD_CONTENT_MODEL: Element flowgraph does not follow the DTD, ... @(^.^)@ Ed ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CDMA in GNURadio
It is possible I think. The current synchronization method only uses the inserted preambles. If you don't change the preamble, it will not affect the synchronization. You may add a Code block into the transmitter diagram, also you need to change some parameters of other blocks. But for the receiver side, it is not as easy as the TX side. Because for the receiver path: ofdm receive -- ofdm demod only two blocks. You have to go deep into them and modify them. Lin 2009/11/21 Brook Lin gnu.f...@yahoo.com Hi Brian and All, Thanks for your last reply about implementing CDMA in GNURadio. I read some materials on synchronization and also the OFDM examples in GNURadio. Is that possible if I add a Code block into the OFDM block diagram to implement MC-CDMA? For the OFDM Transmit path: frame source - symbol modulation - insert preambles - IFFT - add cyclic prefix - scale - USRP Can I add a code block into this path to get MC-CDMA, like frame source - symbol modulation - code - insert preambles - IFFT - add cyclic prefix - scale - USRP Is this possible for implementing the MC-CDMA. Can I apply the same synchronization method for OFDM into MC-CMDA? Please advise me. Thanks, Brook Brian Padalino wrote: On Mon, Oct 26, 2009 at 6:31 PM, Brook Lin gnu.f...@yahoo.com wrote: Thanks for your reply, Brian. Is there any examples that I can reference? Though I have never read any of the books, these seem to have a lot of good information: Spread Spectrum and CDMA: Principles and Applications # ISBN-13: 978-0470091784 CDMA: Principles of Spread Spectrum Communication # ISBN-13: 978-0201633740 They both have sections on synchronization, and other details you will encounter in a CDMA system. Good luck! Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/CDMA-in-GNURadio-tp26067547p26447376.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
