Re: [Discuss-gnuradio] wfm_tx and nbfm_tx
Hi Dimtris, --- On Fri, 12/19/08, Dimitris Symeonidis wrote: > the description should be changed to show that: > - blks2.wfm_tx can receive a maximum audio rate of <=16k > (instead of > the declared >= 16k) > - blks2.nbfm_tx can receive a maximum audio rate of <= > 4.5k (instead of >= 16k) > > I hope this is clear enough... > > > Dimitris Symeonidis I think you have mixed between audio frequency bandwidth and audio digitizing rate. The following example will explain it : Suppose that you want to transmit nbfm signal for an input audio signal with maximum bandwidth of 3 KHz. Suppose also that this audio signal is digitized by (lets say) 32K PCM encoder which results in digitized audio rate of 32K. To produce nbfm signal, we do the following: 1) Ensure that the incoming digitized signal (32K) does not contains any frequency components above 4.5 KHz (this is done by a digital FIR low pass filter). 2) Software interpolate the output of the digital FIR (32 K) to a rate suitable for transmission (lets say 256K) with interpolation rate of 8. 3) Do an FM Pre-emphasis to this 256K signal (this is how it was done in the nbtx.py). The output is also 256K. 4) Feeding this 256K to a frequency modulator (VCO) which produces complex output signal. 5) Stream this output complex signal to the USRP with interpolation rate of 500 to produce 128M which is fed to its DAC. I hope this is clear now. Best Regards, Firas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] wfm_tx and nbfm_tx
Hi Firas, the description should be changed to show that: - blks2.wfm_tx can receive a maximum audio rate of <=16k (instead of the declared >= 16k) - blks2.nbfm_tx can receive a maximum audio rate of <= 4.5k (instead of >= 16k) This both in the code, and in the pdf file On a different mistake, both files contain a line reading: # FIXME audio_rate and quad_rate ought to be exact rationals while this issue seems to be fixed in both... I hope this is clear enough... Dimitris Symeonidis "If you think you're too small to make a difference, try sleeping with a mosquito!" - Amnesty International On Fri, Dec 19, 2008 at 18:38, Firas Abbas wrote: > Hi, > > --- On Fri, 12/19/08, Dimitris Symeonidis wrote: > >> Hi list, >> >> I think I found two errors in the wfm_tx.py and nbfm_tx.py >> blocks: >> >> >> Dimitris Symeonidis > > > Where is the error,can you explain please ? > > > Regards, > > > Firas > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OFDM-Code: DC-Carriers and ofdm_mapper
Hi, I'm currently trying to get a hang of the OFDM-internals and I'm stuck in gr_ofdm_mapper_bcv. I hope someone might be able to enlighten me... First of all, how exactly does gr_ofdm_mapper_bcv decide which carriers are used? I really, really hate having to ask this kind of question when I have the source code right here, but - with all respect to the authors - I find some of the code pretty obscure. Say I want to use an IFFT length of 16 (for academic reasons). A call like gr.ofdm_mapper_bcv(constellation, 2, oc, 16) will always throw an exception unless oc is 14 or 16. Using 8 subcarriers should not be a problem physically? What's the rule of possible combinations of FFT-length occupied carriers? Next, I noticed that the DC carrier(s) are left unused. Logically, this should happen in gr_ofdm_mapper_bcv, but I can't really find where. However, this is slightly confusing: say you set options.occupied in ofdm_mod to 200, then what you really get are 198 occupied subcarriers, or am I mistaken? By the way, why can't I use try:except to catch an instance of 'std::invalid_argument'? Is this a SWIG-problem? Thanks for any insight you may have! Cheers, MB -- Dipl.-Ing. Martin Braun Phone: +49-(0)721-608 3790 Institut fuer Nachrichtentechnik Fax: +49-(0)721-608 6071 Universitaet Karlsruhe (TH) http://www.int.uni-karlsruhe.de/ pgp8U2aG5GhO9.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Usrp2 Fpga Synthesis Question - Ucf related
On Wed, Dec 17, 2008 at 06:19:09PM -0500, alfa...@aol.com wrote: > Hi, > > I've recently started looking at the Spartan3 ISE projects.? I started trying > to re-synthesize the ISE projects, while using the "u2_rev3.ucf" file, I > realized that I had to enable the "Allow Unmatched LOC Constraints" option, > which seems okay since some declared signals might be used.? However I also > had to comment out the following signals from it > > #NET "clk_to_mac" TNM_NET = "clk_to_mac"; > #TIMESPEC "TS_clk_to_mac" = PERIOD "clk_to_mac" 8 ns HIGH 50 %; > > #NET "clk_fpga_p" TNM_NET = "clk_fpga_p"; > #TIMESPEC "TS_clk_fpga_p" = PERIOD "clk_fpga_p" 10 ns HIGH 50 %; > > #NET "cpld_clk" TNM_NET = "cpld_clk"; > #TIMESPEC "TS_cpld_clk" = PERIOD "cpld_clk" 40 ns HIGH 50 %; > > #NET "GMII_RX_CLK" TNM_NET = "GMII_RX_CLK"; > #TIMESPEC "TS_GMII_RX_CLK" = PERIOD "GMII_RX_CLK" 8 ns HIGH 50 %; > > #NET "ser_rx_clk" TNM_NET = "ser_rx_clk"; > #TIMESPEC "TS_ser_rx_clk" = PERIOD "ser_rx_clk" 10 ns HIGH 50 %; > > #NET "cpld_clk" CLOCK_DEDICATED_ROUTE = FALSE; > > I looked for the signals to see if they're used in any of the verilog files, > I saw them instantiated but never used I'm also assuming that the "clk_fpga" > signal is the main FPGA clock.? Since the signals I commented out are clocks, > did I just do something wrong and the project supposed to synthesize without > this modification.? Or are my change wrong? > > Thanks in advance, > Al Fayez You shouldn't have to change anything. We build from the command line using the Makefile in usrp2/fpga/top/u2_rev3/Makefile. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] wfm_tx and nbfm_tx
Hi list, I think I found two errors in the wfm_tx.py and nbfm_tx.py blocks: while the description says: @param audio_rate: sample rate of audio stream, >= 16k for both of them, they have an low-pass interpolating filter which cuts off at 16kHz for wfm and 4.5kHz for nbfm... this is wrong also in firas's user manual... regards Dimitris Symeonidis "If you think you're too small to make a difference, try sleeping with a mosquito!" - Amnesty International ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 GigE Reports
Matt Ettus writes: > I have started a page on the wiki to collect information about various > GigE cards and how well they are working with the USRP2. Please check > it out and update it with your experiences. > >http://gnuradio.org/trac/wiki/USRP2GigEReports > > > Also, here is some basic background info about choosing a card if you > don't already have one: > > > http://gnuradio.org/trac/wiki/USRP2UserFAQ#WhatGigabitEthernetInterfacedoyousuggest > > > It should also be noted that I believe that all of the ethernet > problems we are seeing are a result of bad settings in either the > ethernet interface on the host computer, or the USRP2 firmware. It is > very unlikely that there are hardware compatibility issues. The > quicker we get an idea which systems are affected, the quicker we can > resolve the issues. dear list, please excuse my unbuffered intrusion here with a generic request for advice on USRP / USRP2 matters: from what i could glean so far from list and wiki, going for a USRP2 doesn't make much sense unless i would have a system featuring a PCIe bus or doing a lot of preprocessing on the FPGA. it seems getting a PCMCIA gigabit interface will not be doing much good. since my budget will be burned for the radio hardware, getting an adequate laptop will be delayed for some time. since i aim more at RXing, the USRP also seems a better option since it immediatly supports using both ADC channels with two daughterboards instead of having to build a custom frontend for the basicRX module, as would be the case with a USRP2? thanks for any elaborations or remarks on this. regards, opt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
