[Discuss-gnuradio] USRP News -- April 18th, 2006
USRP News -- April 18, 2006 In this Issue - New Daughterboard Announcement - New Daughterboard Naming and Contest - TVRX Status - Inventory Status - American Express New Daughterboard Announcement We are pleased to announce the availability of the "Daughterboard Which Would Have Been Called Flex900", or the DBWWHBC-Flex900. For the reasons why it will not actually be called the Flex900, please see the next section of this announcement. The DBWWHBC-Flex900 is a transceiver very similar to the DBFKA-Flex2400 (Daughterboard Formerly Known As Flex2400). It is a transceiver covering the 800-1000 MHz range which includes the 902-928 MHZ ISM band, cell phones, and several other interesting bands. The transmit power is adjustable up to well over 20 dBm (100 mW). It includes an ISM-band filter for reducing interference which can be enabled by removing one capacitor. For operation outside of the ISM band, simply leave the capacitor in place. The DBWWHBC-Flex900 costs $250, and will begin shipping next Wednesday. You can order it from the standard web ordering page, http://www.ettus.com/custom.html New Daughterboard Naming and Contest While we have never claimed to own the word "Flex", we have recently received a Cease and Desist letter from a company which believes it does own it. FlexRadio Systems, a maker of HF and VHF SDR equipment for amateur radio, has "requested" that we completely discontinue the use of the word "Flex". Not wishing to fight this, we have decided to comply. In order to choose a new name for the Flex-series of daughterboards, we have decided to have a naming contest. To enter, please send your suggestions to [EMAIL PROTECTED] with the subject "Contest". On April 30th, we will choose the best entry, and from then on, the boards will be known by the new name. The winner will receive one free Flex-series (oops, said it again...) daughterboard of their choice. All decisions are final. Just to clarify the naming system, we have created this handy chart: Old NameInterim Name Final Name == Flex400 DBFKA-Flex400 ? 400 Flex900 DBWWHBC-Flex900? 900 Flex2400DBFKA-Flex2400 ? 2400 Best of luck to all entrants! == TVRX Status == We have been able to locate a source of the tuner modules used in the TVRX boards. This will allow us to continue to provide TVRX boards for the forseeable future. == Inventory Status == As of April 18th, all items are in stock except for the USRP motherboard. We expect to have USRP motherboards back in stock in early May. We are sorry for any inconvenience this may cause. == American Express == By popular demand, we are now able to accept American Express credit cards from the same web order page. Simply enter the card info in the fields provided. == Thank you, Matt Ettus President, Ettus Research LLC +1 (650) 814-8943 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Embedded control of USRP
On Tue, Apr 18, 2006 at 06:18:55PM -0400, Lee Patton wrote: > On Mon, 2006-04-03 at 11:20 -0700, Eric Blossom wrote: > > ... unless you're a glutton for punishment, don't get the Celeron > > version, spend the extra bucks and get the Pentium M. > > Besides the dearth of on-board cache, what are the other drawbacks of a > Celeron? > > To fit the dimensional requirement I was given (5"x5"x~1"), the SBC must > be passively cooled. However, I'm not finding a Pentium-M solution that > can be passively cooled and meets our availability requirements. I have > found a 600 MHz Celeron solution, but has half the L2 cache. > > In our application, we'll be pulling full throttle from the USRP, maybe > FIR filtering, and then pushing back out to USRP. Not too heavy on the > signal processing. > > All advice appreciated. > > - Lee > > P.S. > > Some potential solutions: > http://www.gms4sbc.com/P60x_BO.html (can't meet availability) > http://www.kontron-emea.com/index.php?id=82&cat=58 (JRex-PM, can only > air cool Celeron M 600 MHz) You should be able to benchmark this, including cache performance using oprofile. To track cache misses you'll need to enable a non-default set of counters in oprofile, but it's possible. http:://oprofile.sf.net You should be able to determine the cache hit/miss ratio for you existing configuration using oprofile. Benchmark the app you want to run on whatever you've currently got. The closer in architecture/microarchitecture, the better. Then scale by CPU freq, and a big wild-ass guess on cache size differences. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Embedded control of USRP
On Mon, 2006-04-03 at 11:20 -0700, Eric Blossom wrote: > ... unless you're a glutton for punishment, don't get the Celeron > version, spend the extra bucks and get the Pentium M. Besides the dearth of on-board cache, what are the other drawbacks of a Celeron? To fit the dimensional requirement I was given (5"x5"x~1"), the SBC must be passively cooled. However, I'm not finding a Pentium-M solution that can be passively cooled and meets our availability requirements. I have found a 600 MHz Celeron solution, but has half the L2 cache. In our application, we'll be pulling full throttle from the USRP, maybe FIR filtering, and then pushing back out to USRP. Not too heavy on the signal processing. All advice appreciated. - Lee P.S. Some potential solutions: http://www.gms4sbc.com/P60x_BO.html (can't meet availability) http://www.kontron-emea.com/index.php?id=82&cat=58 (JRex-PM, can only air cool Celeron M 600 MHz) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Autotools tutorial
On Tue, Apr 18, 2006 at 03:07:52PM -0700, Jonathan Jacky wrote: > > I recently ran across this tutorial, that discusses automake and autoconf, > among other things. > > Learning the GNU development tools > http://autotoolset.sourceforge.net/tutorial.html > > I have not yet read it thoroughly. Some of the sections are still > incomplete, including the one on libtool. > > Other documents about the autotools have been noted here before. > > http://lists.gnu.org/archive/html/discuss-gnuradio/2005-02/msg00301.html > > Jon Jacky FWIW, the manuals that come with autoconf and automake are pretty good. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Autotools tutorial
I recently ran across this tutorial, that discusses automake and autoconf, among other things. Learning the GNU development tools http://autotoolset.sourceforge.net/tutorial.html I have not yet read it thoroughly. Some of the sections are still incomplete, including the one on libtool. Other documents about the autotools have been noted here before. http://lists.gnu.org/archive/html/discuss-gnuradio/2005-02/msg00301.html Jon Jacky ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] templates in "gr-howto-write-a-block-0.3"
On Tue, Apr 18, 2006 at 05:45:40PM -0400, Achilleas Anastasopoulos wrote: > > I have handwritten a couple of blocks in the howto > directory and am able to compile/install them. > > I would like to generate versions of these blocks for > different input/output variable types, thus I have written the > appropriate template files _XX.i.t, _XX.h.t, _XX.cc.t > (I followed some examples in core/src/lib/general/) > > > My question is how to automate the compile and install step > to generate the appropriate code from the templates. > > Thanks > Achilleas Take a look at gnuradio-core/src/lib/general/Makefile.am to see how we do it there. FYI, this is the Makefile rule that runs the code generator: $(GENERATED_H) $(GENERATED_I) $(GENERATED_CC): $(CODE_GENERATOR) PYTHONPATH=$(top_srcdir)/src/python srcdir=$(srcdir) $(srcdir)/generate_all.py All of the $(srcdir) and $(top_srcdir) stuff is required to make this work when doing VPATH builds. That is, builds where the source and objects are in different directories. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] templates in "gr-howto-write-a-block-0.3"
I have handwritten a couple of blocks in the howto directory and am able to compile/install them. I would like to generate versions of these blocks for different input/output variable types, thus I have written the appropriate template files _XX.i.t, _XX.h.t, _XX.cc.t (I followed some examples in core/src/lib/general/) My question is how to automate the compile and install step to generate the appropriate code from the templates. Thanks Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] swig error in compile, gr-atsc stuff
Gang - Wonder if any of the block writing wizards could take a gander
at this and spot why the blocks compile, but error out on the - I don't
even know what you call it - the swig file?
output:
creating libatsc-qa.la
(cd .libs && rm -f libatsc-qa.la && ln -s ../libatsc-qa.la
libatsc-qa.la)
if /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H
-I. -I. -I../.. -pthread -I/usr/local/include/gnuradio
-I/usr/include/python2.4 -I/usr/local/include-g -O2 -Wall
-Woverloaded-virtual -pthread -MT atsc.lo -MD -MP -MF ".deps/atsc.Tpo"
-c -o atsc.lo atsc.cc; \
then mv -f ".deps/atsc.Tpo" ".deps/atsc.Plo"; else rm -f
".deps/atsc.Tpo"; exit 1; fi
g++ -DHAVE_CONFIG_H -I. -I. -I../.. -pthread
-I/usr/local/include/gnuradio -I/usr/include/python2.4
-I/usr/local/include -g -O2 -Wall -Woverloaded-virtual -pthread -MT
atsc.lo -MD -MP -MF .deps/atsc.Tpo -c atsc.cc -fPIC -DPIC
-o .libs/atsc.o
atsc.cc:2178: error: `atsc_ds_to_softds_sptr' was not declared in this
scope < OH NO
atsc.cc:2179: error: expected `,' or `;' before '{' token
Here are the files I added:
http://webpages.charter.net/cswiger/atsc_ds_to_softds.cc
http://webpages.charter.net/cswiger/atsc_ds_to_softds.h
http://webpages.charter.net/cswiger/atsc.i
Of course atsc.cc was created by swig, and the bottom of atsc.i
has what magic worked for the other modules I added.
tia
--Chuck
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Design FIR filters by number of taps
On Tue, Apr 18, 2006 at 08:37:55AM -0700, jjw wrote: > > In looking at the tools for designing FIR filters, I see that you can do it > by selecting cutoff frequencies and transition bandwidths. Is there a block > already in existence that allows you to design an FIR filter based on cutoff > frequency and maximum number of taps where the transition bandwidth would be > variable based on the taps? I didn't notice one, but this would be very > helpful to me. Thanks. > > John There are lots of ways to design filters. We provide two: gr.firdes.* (windowed design) and optfir.* (Parks McClellan) In both of them, you specify the characteristics that you want, and the code figures out the number of taps that it takes to get what you asked for. This approach seemed to make the most sense. If you want to specify the number of taps, you're on your own. The guts of the windowed design code may be useful. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Basic USRP AM Transmission
Robert Roberts wrote: > I added an interpolating FIR filter (used a lowpass filter) that stepped the > signal rate back up to 128mS/s, but it does not sounds any better. I have > been > playing with the interpolation value, as well as the filter values. Since the bandwidth of the usb bus is limited, the maximum samplerate you can send to the usrp is 8Ms/s Since the interpolation factor of the usrp is also limited (I think max 256) the min samplerate you can send to the usrp is 128/256 = 500 kS/s Usrp interpolator must be in [4, 512] and a multiple of 4 So the min samplerate you can send to the usrp is 128/512 = 250 kS/s The bandwidth of the signal of interest also has to fit in the samplerate. And then you also need integer interpolation factors (unless you use a rational resampler) usb bus rate: min 0 max 8 MS/s usrp interpolator factor : min 4, max 512 DAC : min 128 MS/s max 128 MS/s So I would come to the following: src 32 kS/s software interpolator: interpolation factor 10 => 320 kS/s usrp interpolation factor 400 => 128 MS/s Also pay attention to signal levels, and any filter parameters you use. If this all still doesn't help. Try what happens if you use a non DC baseband freq. (That is, multiply your 320 kS/s signal with for example a 100 kHz complex sine (gr_sig_source_c)) Also make sure that the signal you use as input is not bigger then the const you add. You add 1.0, which would mean that your input signal should be between -1.0 and 1.0. You can check with a scopesink. Greetings, Martin > > I'll keep chugging away. Thanks for your help! > > ~Chris~ > > ** > > *- Original Message -* > > *From*: Martin Dvh <[EMAIL PROTECTED]> > > *Date*: Tuesday, April 18, 2006 1:01 am > > *Subject*: Re: [Discuss-gnuradio] Basic USRP AM Transmission > > > Robert Roberts wrote: > > > > > > - Original Message - > > > From: Martin Dvh <[EMAIL PROTECTED]> > > > Date: Monday, April 17, 2006 3:06 pm > > > Subject: Re: [Discuss-gnuradio] Basic USRP AM Transmission > > > > > >>Robert Roberts wrote: > > >> > > >>>Hello everyone, > > >>> > > >>> > > >>>I have been experimenting with the Flex400 board and have been > > >> > > >>trying to > > >> > > >>>implement a basic AM transmitter. I have a WFM and NFM transmitter > > >>>working, but I cannot get the AM one to transmit correctly. > > The > > >> > > >>code> below generates a much higher frequency tone. Any advice > > to > > >>what I am > > >> > > >>>doing wrong? Does my output need filtering befor! e connecting > > to > > >> > > >>the> sink? > > >> > > >>> > > >>>self.u = usrp.sink_c () # the USRP sink > > >>> > > >>># Code here for setting up the USRP, omitted > > >>> > > >>>src = gr.file_source (gr.sizeof_float, "audio-1.dat", True) # > > >> > > >>440Hz tone > > >> > > >>>file > > >> > > >>What is the sample_rate of the audio file > > >>What is you interpolation rate of the usrp > > >>What is the duc frequency of your usrp. > > > > > > > > > I have the file source sampled at 32kS/s > > > > > > I use the following code for setting up my usrp: > > > > > > self.dac_rate = self.u.dac_rate() # > > 128 MS/s > > > self.usrp_interp = 400 > > > self.u.set_interp_rate(self.usrp_interp) > &! gt; > self.usrp_rate = self.dac_rate / self.usrp_interp # > > 320 kS/s > > > self.sw_interp = 10 > > > self.audio_rate = self.usrp_rate / self.sw_interp # > > 32 kS/s > > > > > > # determine the daughterboard subdevice we're using > > > if options.tx_subdev_spec is None: > > > options.tx_subdev_spec = usrp.pick_tx_subdevice(self.u) > > > > > > m = usrp.determine_tx_mux_value(self.u, > > options.tx_subdev_spec)> self.u.set_mux(m) > > > self.subdev = usrp.selected_subdev(self.u, > > options.tx_subdev_spec)> print "Using TX d'board %s" % > > (self.subdev.side_and_name(),)> > > > self.subdev.set_gain(self.subdev.gain_range()[1]) # > > set max > > > Tx gain > > > self.set_freq(options.freq) > > > self.subdev.set_enable(True) # > > enable> transmitter > > > > > > > > > This is the same code I used for both a! NFM and WFM transmitter, > > both of > > > which appeared to transmit without problems. > > But do you actually put a software interpolator in there somewhere. > > I didn't see any in your code: > > >>>self.connect (src, const) > > >>>self.connect (const, conv) > > >>>self.connect (conv, gain) > > >>>self.connect (gain, self.u) > > should be: > > self.connect (src, const) > > self.connect (const, conv) > > self.connect (conv, gain) > > self.connect (gain, softwareinterpolator) > > self.connect(softwareinterpolator,self.u) > > > > greetings, > > Martin > > > > > > Sincerely, > > > ~Chris~ > > > > > >>If the sample rate of your audio file is for example 48000 Herz > > >>Then the usrp interpolation rate should be 12800/48000 = 2666 > > >>Which is I think
[Discuss-gnuradio] Design FIR filters by number of taps
In looking at the tools for designing FIR filters, I see that you can do it by selecting cutoff frequencies and transition bandwidths. Is there a block already in existence that allows you to design an FIR filter based on cutoff frequency and maximum number of taps where the transition bandwidth would be variable based on the taps? I didn't notice one, but this would be very helpful to me. Thanks. John -- View this message in context: http://www.nabble.com/Design-FIR-filters-by-number-of-taps-t1468910.html#a3970609 Sent from the GnuRadio forum at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
