[Discuss-gnuradio] Clock input level
Hi, What is the voltage level for the USRP external clock? Is 1V peak to peak ok? I am planning to drive the board using a high accuracy reference clock. juha ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC on OSX?
On Oct 4, 2007, at 12:35 AM, Josh Blum wrote: Basically, the test imports are all things that the Editor uses. gtk, pyxml... and wx for running the flow graphs. I decided on the import tests after many emails of error verbose because something like pyxml was not installed. Thoughts? I'm 100% with you on these import checks. It's easier on the user to hear that such and such module isn't installed instead of getting some whacky Python error that doesn't really help. try: __import__(module) sys.modules.pop(module) #of course, import sys at the top No difference. I also tried just del as well as del sys.modules (module), neither of which worked. I'm using WX 2.8.4 currently, so I'm trying downgrading to 2.6.3 as well as upgrading to 2.8.6. I'm open to any other suggestions as well. - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] build failure (svn fedora F7 qwt)
I'm having problems building on fedora F7 (x86_64) current svn source. g++ -g -O2 -Wall -Woverloaded-virtual -pthread -o .libs/qt_examples fftdisplay.o qt_examples.o moc_fftdisplay.o -lqwt -L/usr/lib64/qt-3.3/lib -lqt-mt -lmng -ljpeg -lpng -lz -lXi -lXrender -lXrandr -lXcursor -lXinerama -lXft -lfreetype -lfontconfig -lXext -lX11 -lm -lSM -lICE -ldl -lpthread ../../../gnuradio-core/src/lib/.libs/libgnuradio-core.so /usr/local/src/gnuradio/omnithread/.libs/libgromnithread.so -lrt -lfftw3f moc_fftdisplay.o: In function `fft_display::qt_property(int, int, QVariant*)': /usr/local/src/gnuradio/gr-qtgui/src/lib/moc_fftdisplay.cc:103: undefined reference to `QwtPlot::qt_property(int, int, QVariant*)' moc_fftdisplay.o: In function `fft_display::qt_emit(int, QUObject*)': /usr/local/src/gnuradio/gr-qtgui/src/lib/moc_fftdisplay.cc:97: undefined reference to `QwtPlot::qt_emit(int, QUObject*)' moc_fftdisplay.o: In function `fft_display::staticMetaObject()': /usr/local/src/gnuradio/gr-qtgui/src/lib/moc_fftdisplay.cc:54: undefined reference to `QwtPlot::staticMetaObject()' moc_fftdisplay.o: In function `fft_display::qt_invoke(int, QUObject*)': /usr/local/src/gnuradio/gr-qtgui/src/lib/moc_fftdisplay.cc:90: undefined reference to `QwtPlot::qt_invoke(int, QUObject*)' moc_fftdisplay.o: In function `fft_display::qt_cast(char const*)': /usr/local/src/gnuradio/gr-qtgui/src/lib/moc_fftdisplay.cc:81: undefined reference to `QwtPlot::qt_cast(char const*)' collect2: ld returned 1 exit status I have installed rpm -q qwt qwt-5.0.2-5.fc7.i386 qwt-5.0.2-5.fc7.x86_64 [EMAIL PROTECTED] ~]$ rpm -q qwt-devel qwt-devel-5.0.2-5.fc7.i386 qwt-devel-5.0.2-5.fc7.x86_64 [EMAIL PROTECTED] ~]$ rpm -q qwtplot3d qwtplot3d-0.2.7-1.fc7.i386 qwtplot3d-0.2.7-1.fc7.x86_64 [EMAIL PROTECTED] ~]$ rpm -q qwtplot3d-devel qwtplot3d-devel-0.2.7-1.fc7.x86_64 qwtplot3d-devel-0.2.7-1.fc7.i386 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC on OSX?
I'm using WX 2.8.4 currently, so I'm trying downgrading to 2.6.3 as well as upgrading to 2.8.6. I'm open to any other suggestions as well. 2.6.3 and 2.8.6 work. So it was something to do with WX 2.8.4. Go figure ... [EMAIL PROTECTED] OSS !} Thanks for all of the help. Now on to the real work. - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Clock input level
I looked it up from the schema. It seems that a basic 1V peak to peak should be fine. juha On 10/4/07, Juha Vierinen [EMAIL PROTECTED] wrote: Hi, What is the voltage level for the USRP external clock? Is 1V peak to peak ok? I am planning to drive the board using a high accuracy reference clock. juha ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Making and Installing a New Block
OK I did some more trouble shooting to narrow down the problem. I decided to start with C++ code from a block that I knew already worked. I extracted the file gr-howto-write-a-block-3.0.4.tar.gz. I then installed the block using the normal configure, make, and make install procedure. I then created a python program called squaredaudio.py to test the howto_square2_ff block. It worked correctly. I've attached this file. Then I created new c++ source files in the topdir/src/lib/ directory. They were howto_square3_ff.cc and howto_square3_ff.h. The goal here was to create a copy of the howto_square2_ff block only under another name. I copied the source files for the square 2 block into the source files for the square 3 block. I changed the names from square2 to square3.I modified the howto.i with the additional lines of codes for the new block. I based these off of what was already in the file for square_ff and square2_ff. Next I modifed the file topdir/src/lib/makefile.am. I added the file names howto_square3_ff.cc and howto_square3_ff.h next to the places where the file names for the other blocks were. All other files were left as they came in the tar.gz file. When the block is installed I don't get an error. However when I run my test program I get an error which I've included in error.txt. The main part seems to be: /usr/local/lib/python2.5/site-packages/gnuradio/_howto.so: undefined symbol: _Z21howto_make_square3_ffv This error is the same whether I try to use the howto_square2_ff or howto_square3_ff block in squaredaudio.py. I get the feeling I'm supposed to modify some other files but I can't figure out what to change. Any ideas? Thanks, Keith squaredaudio.py Description: Binary data Makefile.am Description: Binary data howto.i Description: Binary data howto_square3_ff.cc Description: Binary data howto_square3_ff.h Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Making and Installing a New Block
On Thu, Oct 04, 2007 at 10:24:51AM -0500, Franklin Sands wrote: OK I did some more trouble shooting to narrow down the problem. I decided to start with C++ code from a block that I knew already worked. I extracted the file gr-howto-write-a-block-3.0.4.tar.gz. I then installed the block using the normal configure, make, and make install procedure. I then created a python program called squaredaudio.py to test the howto_square2_ff block. It worked correctly. I've attached this file. Then I created new c++ source files in the topdir/src/lib/ directory. They were howto_square3_ff.cc and howto_square3_ff.h. The goal here was to create a copy of the howto_square2_ff block only under another name. I copied the source files for the square 2 block into the source files for the square 3 block. I changed the names from square2 to square3.I modified the howto.i with the additional lines of codes for the new block. I based these off of what was already in the file for square_ff and square2_ff. Next I modifed the file topdir/src/lib/makefile.am. I added the file names howto_square3_ff.cc and howto_square3_ff.h next to the places where the file names for the other blocks were. All other files were left as they came in the tar.gz file. When the block is installed I don't get an error. However when I run my test program I get an error which I've included in error.txt. The main part seems to be: /usr/local/lib/python2.5/site-packages/gnuradio/_howto.so: undefined symbol: _Z21howto_make_square3_ffv This error is the same whether I try to use the howto_square2_ff or howto_square3_ff block in squaredaudio.py. I get the feeling I'm supposed to modify some other files but I can't figure out what to change. Any ideas? Thanks, Keith What directory are you in when you try to run your program? Be sure to NOT be in the directory containing the code. This avoid potential problems with how python resolves imported files. Have your done a make install? Note that the error message above indicates that it's looking in the installed path. If you haven't installed the code yet with make install it'll be pulling in the old libs. Let me know if this helps. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Problem: Package fftw3f was not found in the pkg-config
Hello! I´m new to GNU Radio. I´m working on a project now and trying to get it to compile. I´m using cygwin and followed the Installing GNU Radio with Cygwin instruction step-by-step. The only problem i hade on the way was with wxPython because i tried the 2.8.6.0 and the instructions are for version 2.8.0.1 and i am missing the config.patch file in the 2.8.6.0 version. Anyhow...i tried it despide my failure with wxPython because the instruction sais it is not necessary. Everything else was fine and worked. Now i tried to configure gnuradio 3.0.4 and i get the following message: checking for fftw = 3.0... Package fftw3f was not found in the pkg-config search path. Perhaps you should add the directory containing 'fftw3f.pc' to the PKG_CONFIG_PATH enviroment variable No package 'fftw3f' found configure: error: Libary requirements (fftw3f = 3.0) not met; consider adjusting the PKG_CONFIG_PATH enviroment variable if you libaries are in a nonstander prefix so pkg-config can find tham. swhat do i have to do? edit the PKR_CONFIG_PATH? I googled and found out it FC5 could be the answer but FC5 installatin isw not explained in the cygwin instruction (http://gnuradio.org/trac/wiki/FC5Install) so anybody can give me a hint? thx! Tomek -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem: Package fftw3f was not found in the pkg-config
On 10/4/07, Tomek [EMAIL PROTECTED] wrote: Hello! I´m new to GNU Radio. I´m working on a project now and trying to get it to compile. I´m using cygwin and followed the Installing GNU Radio with Cygwin instruction step-by-step. The only problem i hade on the way was with wxPython because i tried the 2.8.6.0 and the instructions are for version 2.8.0.1 and i am missing the config.patch file in the 2.8.6.0 version. Anyhow...i tried it despide my failure with wxPython because the instruction sais it is not necessary. Everything else was fine and worked. Now i tried to configure gnuradio 3.0.4 and i get the following message: checking for fftw = 3.0... Package fftw3f was not found in the pkg-config search path. Perhaps you should add the directory containing 'fftw3f.pc' to the PKG_CONFIG_PATH enviroment variable No package 'fftw3f' found configure: error: Libary requirements (fftw3f = 3.0) not met; consider adjusting the PKG_CONFIG_PATH enviroment variable if you libaries are in a nonstander prefix so pkg-config can find tham. swhat do i have to do? edit the PKR_CONFIG_PATH? I googled and found out it FC5 could be the answer but FC5 installatin isw not explained in the cygwin instruction (http://gnuradio.org/trac/wiki/FC5Install) so anybody can give me a hint? I think when you do the install, it installed to /usr/local/lib/pkgconfig. This is noted on the FFTW installation page here: http://gnuradio.org/trac/wiki/FFTWInstall On my Cygwin installation, I have: $ echo $PKG_CONFIG_PATH /usr/lib/pkgconfig:/usr/local/lib/pkgconfig Which allows me to run: $ pkg-config --list-all | grep fft fftw3 FFTW - fast Fourier transform library fftw3fFFTW - fast Fourier transform library thx! Tomek Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem: Package fftw3f was not found in thepkg-config
- Original Message - From: Tomek [EMAIL PROTECTED] To: discuss-gnuradio@gnu.org Sent: Thursday, October 04, 2007 11:59 AM Subject: [Discuss-gnuradio] Problem: Package fftw3f was not found in thepkg-config [...] Now i tried to configure gnuradio 3.0.4 and i get the following message: checking for fftw = 3.0... Package fftw3f was not found in the pkg-config search path. Perhaps you should add the directory containing 'fftw3f.pc' to the PKG_CONFIG_PATH enviroment variable No package 'fftw3f' found configure: error: Libary requirements (fftw3f = 3.0) not met; consider adjusting the PKG_CONFIG_PATH enviroment variable if you libaries are in a nonstander prefix so pkg-config can find tham. ls /usr/local/lib/pkgconfig should list fftw3f.pc among the known packages. PKG_CONFIG_PATH=/usr/local/lib/pkgconfig pkg-config --list-all should also list fftw3f.pc among the known packages. echo $PKG_CONFIG_PATH should show that PKG_CONFIG_PATH is not defined. If it is defined as anything other than /usr/local/lib/pkgconfig you have a problem; try resetting it with PKG_CONFIG_PATH= -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] About Latency
Hi all: I have two questions about Gnuradio latency: 1. In transmit path, the USB delay is constant due to the 32KB buffer between signal source output and USB. If the sampling rate is 1MS/s and each sample is complex 16 bits( sample size=4bytes), we can get the USB latency = 8ms. But how do we estimate the delay of signal processing by processor and USRP? I think these delays are variable depending on how complex the signal is and how fast the processor is. But are there any ways to determine what is the range of these delays? 2. fusb_options define two parameters of fusb_nblocks and fusb_block_size. This function should be used to decrease the delay of USB. But, if we choose any value of number of blocks and block size, say, nblock=8 and block_size =2048, does that mean we need to have larger time to pass through the 8*2048 Bytes packet than the smallest allowed 512 Bytes? So, in this logic, the latency of usb will increase although the throughput is increased. Am I correct? If not, what's wrong with my thought? Thanks for ur reply advance!! KC Huang ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] About Latency
KC Huang- I have two questions about Gnuradio latency: 1. In transmit path, the USB delay is constant due to the 32KB buffer between signal source output and USB. If the sampling rate is 1MS/s and each sample is complex 16 bits( sample size=4bytes), we can get the USB latency = 8ms. But how do we estimate the delay of signal processing by processor and USRP? I think these delays are variable depending on how complex the signal is and how fast the processor is. But are there any ways to determine what is the range of these delays? Compared to PC data transfer, FPGA logic delays should be negligible. For example, FIR filtering in FPGA logic contributes at least one clock cycle per sample to latency (64 MHz clock). It could be more than one clock per, but I don't know the FPGA code and the Cyclone (which is an old FPGA) well enough to say whether Matt was able to implement single-cycle MAC. To get some idea of comparison, depending on how it's implemented, a 16-tap FIR filter might add from 250 nsec to a few usec. -Jeff 2. fusb_options define two parameters of fusb_nblocks and fusb_block_size. This function should be used to decrease the delay of USB. But, if we choose any value of number of blocks and block size, say, nblock=8 and block_size =2048, does that mean we need to have larger time to pass through the 8*2048 Bytes packet than the smallest allowed 512 Bytes? So, in this logic, the latency of usb will increase although the throughput is increased. Am I correct? If not, what's wrong with my thought? Thanks for ur reply advance!! KC Huang ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: About Latency
On Thu, Oct 04, 2007 at 03:22:40PM -0400, KC Huang wrote: Hi all: I have two questions about Gnuradio latency: 1. In transmit path, the USB delay is constant due to the 32KB buffer between signal source output and USB. You misunderstand how things work. Please take a look at Thomas Schmid's paper http://nesl.ee.ucla.edu/document/show/242 and then if you've still got questions, please post again. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: About Latency
Hi Eric: I have already read that paper before. As that paper mentions, the USB delay is according to the equation f(512, fusb_block_size*fusb_nblock) - fs*sample_size , which f(x,y) is at least x and at most y So, does that mean if u have large product of fusb_block_size and fusb_nblock, then the theometical maximum delay will be increased? Therefore, I think that the range of USB latency is also increased. Please correct me if I am wrong. Thanks! KC - Original Message - From: Eric Blossom [EMAIL PROTECTED] To: KC Huang [EMAIL PROTECTED] Cc: Discuss-gnuradio@gnu.org Sent: Friday, October 05, 2007 8:29 AM Subject: Re: About Latency On Thu, Oct 04, 2007 at 03:22:40PM -0400, KC Huang wrote: Hi all: I have two questions about Gnuradio latency: 1. In transmit path, the USB delay is constant due to the 32KB buffer between signal source output and USB. You misunderstand how things work. Please take a look at Thomas Schmid's paper http://nesl.ee.ucla.edu/document/show/242 and then if you've still got questions, please post again. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Decimation Rates
I'm using a USRP and the usrp_rx_cfile program to record data for later processing. When I graph the recorded data, it looks choppy as if I need to sample at a higher rate. I have done a few runs at various decimation rates and I'm confused by the resulting file sizes. When I set the decimation rate to 4, 8, or 16 for a constant period, the resulting recordings are approximately the same size. At decimation rates of 32 or higher, the recording sizes reduce dramatically. I would expect the recording sizes to increase inversely and proportionally to the decimation rate. The fact that this isn't happening makes me suspicious of whether changing the decimation rate is really doing anything. I thought it might be that the USB throughput was the limiting factor when decimation rates we low, but I tried recording shorts rather than floats to reduce bandwidth usage, but I saw the same results. What am I missing? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: About Latency
On Thu, Oct 04, 2007 at 09:46:36PM +0800, KC Huang wrote: Hi Eric: I have already read that paper before. As that paper mentions, the USB delay is according to the equation f(512, fusb_block_size*fusb_nblock) - fs*sample_size , which f(x,y) is at least x and at most y So, does that mean if u have large product of fusb_block_size and fusb_nblock, then the theometical maximum delay will be increased? Therefore, I think that the range of USB latency is also increased. Please correct me if I am wrong. Thanks! KC Yes that is true. If you're trying to minimize latency you want the smallest values that work reliably (no over/underruns) and with acceptable overhead. If you enable real time scheduling, you can reliably use smaller values. Try fusb_block_size 2048 and fusb_nblock 4 or 8. You may be able to run with fusb_block_size 1024. It depends on your data rate across the USB. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Decimation Rates
On Thu, Oct 04, 2007 at 10:52:17PM -0400, Andrew Buck wrote: I'm using a USRP and the usrp_rx_cfile program to record data for later processing. When I graph the recorded data, it looks choppy as if I need to sample at a higher rate. I have done a few runs at various decimation rates and I'm confused by the resulting file sizes. When I set the decimation rate to 4, 8, or 16 for a constant period, the resulting recordings are approximately the same size. At decimation rates of 32 or higher, the recording sizes reduce dramatically. I would expect the recording sizes to increase inversely and proportionally to the decimation rate. The fact that this isn't happening makes me suspicious of whether changing the decimation rate is really doing anything. I thought it might be that the USB throughput was the limiting factor when decimation rates we low, but I tried recording shorts rather than floats to reduce bandwidth usage, but I saw the same results. What am I missing? It it reporting overruns? Do you see uOuOuO... on stdout? If so, you're not keeping up and are dropping samples. If you're running decim = 8, you're producing data at 8 MS/s (32MB/s across the USB, and to disk if you're storing as shorts). You may be running into filesystem or disk throughput problems. If you're writing data to an ext3 filesystem (the default under Linux), edit /etc/fstab so that it's mounted as ext2 instead of ext3 and reboot. The ext3 file systems don't stream continuously well because they go dead while they post their journals. Also, when you say a constant period are you referring to watching the clock, or are you specifying the -N nsamples command line argument. Use the -N argument. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
