Re: [Discuss-gnuradio] pipes for today
Eric, Have you made any progress with this? I'm having a problem that may be related. The blocks are layed out like this. USRP Rx -> ... -> pipe gr_sig_source -> ... -> USRP Tx When running in gdb: 1. I wait for it to lockup 2. hit Ctrl-Z (to get into gdb) 3. type continue 4. more data is processed with a bunch of uU printed 5. software lockups again 6. goto 2 When I hit Ctrl-Z the Tx thread always seems to be in ioctl in _reap. Is this normal? Attached is a file with bt's for each of the threads Thread 1 is Python/Wx, which seems to lockup Thread 2 seems to be the USRP Tx graph Thread 3 seems to be the USRP Rx graph Thread 4 is my pipe monitoring thread, which does not lockup Quoting Eric Blossom: > On Fri, Apr 08, 2005 at 04:10:20PM -0400, cswiger wrote: > > This is a curious behavior: if > > > > 1) Use a vector source at the head and the USRP at the tail all is OK > > > > 2) Use the pipe fd source at the head and a file sink at the tail all is > > OK > > > > but if > > > > 3) Use a pipe fd source at the head and the USRP (with a parallel file > > sink to monitor) at the tail data very slowly trickles into the file, > > much slower than the 1.6Msps that it should - UNTIL I close the process > > feeding the pipe, THEN it goes full blast and processes the backed up > > pipe A-OK. > > > > very interesting ;) > > Chuck, if you send me the code to test example (3), I'll take a look at it. > > Eric (gdb) info threads 4 Thread 1148025776 (LWP 28678) 0x401324e7 in select () from /lib/tls/libc.so.6 3 Thread 1139637168 (LWP 28677) 0x40031d0b in [EMAIL PROTECTED] () from /lib/tls/libpthread.so.0 * 2 Thread 1131248560 (LWP 28676) 0x40131bd4 in ioctl () from /lib/tls/libc.so.6 1 Thread 1075400832 (LWP 28671) 0x4012ffe3 in poll () from /lib/tls/libc.so.6 (gdb) thread 1 [Switching to thread 1 (Thread 1075400832 (LWP 28671))]#0 0x4012ffe3 in poll () from /lib/tls/libc.so.6 (gdb) bt #0 0x4012ffe3 in poll () from /lib/tls/libc.so.6 #1 0x407c8896 in wxApp::WakeUpIdle () from /usr/lib/libwx_gtk2u_core-2.5.so.3 #2 0x410ab226 in g_main_loop_get_context () from /usr/lib/libglib-2.0.so.0 #3 0x410aa820 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #4 0x410aae43 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #5 0x40d9a8f3 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #6 0x407e3208 in wxEventLoop::Run () from /usr/lib/libwx_gtk2u_core-2.5.so.3 #7 0x40874233 in wxAppBase::MainLoop () from /usr/lib/libwx_gtk2u_core-2.5.so.3 #8 0x4046c2d2 in wxPyApp::MainLoop () from /usr/lib/python2.3/site-packages/wx-2.5.3-gtk2-unicode/wx/_core_.so #9 0x404a67dd in wxGridBagSizer_Add () from /usr/lib/python2.3/site-packages/wx-2.5.3-gtk2-unicode/wx/_core_.so #10 0x080fdede in PyCFunction_Call () #11 0x0805b989 in PyObject_Call () #12 0x080abcd4 in PyEval_CallObjectWithKeywords () #13 0x080aa028 in Py_MakePendingCalls () #14 0x080aa77c in PyEval_EvalCodeEx () #15 0x080fd9b7 in PyStaticMethod_New () #16 0x0805b989 in PyObject_Call () #17 0x080623d8 in PyMethod_Fini () #18 0x0805b989 in PyObject_Call () #19 0x080aba52 in PyEval_CallObjectWithKeywords () #20 0x080ab6b9 in PyEval_CallObjectWithKeywords () #21 0x080a9bee in Py_MakePendingCalls () #22 0x080ab96d in PyEval_CallObjectWithKeywords () #23 0x080ab72c in PyEval_CallObjectWithKeywords () #24 0x080a9bee in Py_MakePendingCalls () #25 0x080ab96d in PyEval_CallObjectWithKeywords () #26 0x080ab72c in PyEval_CallObjectWithKeywords () #27 0x080a9bee in Py_MakePendingCalls () #28 0x080aa77c in PyEval_EvalCodeEx () #29 0x080acf79 in PyEval_EvalCode () #30 0x080d90db in PyRun_FileExFlags () #31 0x080d85de in PyRun_InteractiveOneFlags () #32 0x080d83d3 in PyRun_InteractiveLoopFlags () #33 0x080d9a02 in PyRun_AnyFileExFlags () #34 0x08054e95 in Py_Main () #35 0x080549eb in main () (gdb) thread 2 [Switching to thread 2 (Thread 1131248560 (LWP 28676))]#0 0x40131bd4 in ioctl () from /lib/tls/libc.so.6 (gdb) bt #0 0x40131bd4 in ioctl () from /lib/tls/libc.so.6 #1 0x4211ce38 in fusb_devhandle_linux::_reap (this=0x85bb958, ok_to_block_p=true) at fusb_linux.cc:274 #2 0x4211dd1c in fusb_ephandle_linux::get_write_work_in_progress (this=0x85bcb30) at fusb_linux.cc:470 #3 0x4211dc3b in fusb_ephandle_linux::write (this=0x85bcb30, buffer=0x436d2cf0, nbytes=16384) at fusb_linux.cc:429 #4 0x421176ff in usrp_basic_tx::write (this=0x85bcad0, buf=0xfffc, len=1074025740, underrun=0x436d2ce7) at usrp_basic.cc:780 #5 0x4218c8b1 in usrp1_sink_base::work (this=0x85bb8c8, noutput_items=8192, [EMAIL PROTECTED], [EMAIL PROTECTED]) at usrp1_sink_base.cc:94 #6 0x41eb7f9a in gr_sync_block::general_work (this=0x85bb8c8, noutput_items=-4, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]) at gr_sync_block.cc:52 #7 0x41ed8631 in gr_single_threaded_scheduler::main_loop (this=0x85b4178) at gr_single_threaded_scheduler.cc:258 #8 0x41ed7b53 in gr_single_threaded_scheduler::run (this=0xfffc) at gr_single_threaded_scheduler.cc:62 #9 0x41c01d7f
[Discuss-gnuradio] Built most of gr-*
I don't have any hardware for the highspeed conversions, and have not set up to use 'sound cards' etc. for low speed testing. However, I have been able to get gnuradio-core, as well as several other gr-* packages to compile. The most problem seemed to be centered on having 1) a somewhat large set of additional packages that don't seem to have much to do with signal processing, such as various cpp pre-preprocessing tools, or the like. If the intent was to have a package that was 'portable', then having a large number of ancillary packages, which have not only interdependencies, but also mutual exlucusions for an existing system configuration, seems to go counter to that goal. Since I don't have much (like absolutely none) of anything based on an existing installed python environment, the fact that a number of libraries and packages where 'installed' to get things for gnuradio to compile correctly, it is of no real great difficulty, other than just which ones, and what upstream package requirements are needed. Moving on... Since I don't have hardware at the moment, are there some examples of using simulated signal generators or the like in the existing cvs packages, or out on the net. Also, the gnuradio web site has some pictures of oscope, or fft output, are those buried some where in the gr-* set of code. Perhaps next week I'll have the time to see if I can set this up on a NetBSD machine, but in the mean time I'd like test things on the linux box I have at the moment. Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] _gnuradio_swig_python import error on Mac OS X
ImportError: No module named _gnuradio_swig_python I fixed it. On Mac OS X, the build creates _gnuradio_swig_python.dylib. But python's import statement will only import files ending in .py, .pyc, and .so (I found this by trying "python -vv"). I just put made a symbolic link _gnuradio_swig_python.so and pointed it at _gnuradio_swig_python.dylib in the same directory. That worked! So now I've got an (apparently) working gnuradio-core-2.5 on Mac OS X. I'll post a writeup of everything I had to do soon, after I've cleaned up some loose ends. Can someone explain where in the build (which Makefile or whatever is relevant) is _gnuradio_swig_python built? Perhaps I can figure out where and how to change some switch so it builds an .so not a .dylib on Mac OS X. I feel a little guilty about just faking it with a link ... Jon Jacky PS. There is a patch for Python that gets it to import .dylib files also, but it's a source patch, so I didn't bother. http://mail.python.org/pipermail/patches/2004-June/014925.html https://sourceforge.net/tracker/?func=detail&atid=305470&aid=641685&group_id=5470 PPS. I didn't have this problem when I built gnuradio 2.3 in January. Sure enough, I find I have a _gnuradio_swig_python.so there. The only thing I have changed since then besides gnuradio itself is SWIG, I moved from 1.3.22 to 1.3.24 as advised. I've also installed a few OS and security updates but I wouldn't think they changed the toolchain. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] make check errors, innocuous (?), gnuradio-core-2.5, Mac OS X
I got few error messages from "make check" with gnuradio-core-2.5 on Mac OS X. I think they're innocuous. Please confirm. .Testing gr_vmcircbuf_sysv_shm_factory... gr_vmcircbuf_sysv_shm: shmat (1): Too many open files gr_vmcircbuf_sysv_shm: shmget (1): Invalid argument gr_vmcircbuf_sysv_shm: shmat (1): Too many open files ... gr_vmcircbuf_sysv_shm_factory: Doesn't work This message appeared in 2.3 also. I was told here it was nothing to worry about. FAIL: test_001_filter_delay_one_input (__main__.qa_filter_delay_fc) ... (traceback omitted) AssertionError: (-0.95105588436126709-0.30904296040534973j) != (-0.95105570554733276-0.3090435266494751j) within 6 places ... FAIL: test_002_filter_delay_two_inputs (__main__.qa_filter_delay_fc) ... (traceback omitted) AssertionError: (-0.95105588436126709-0.30904296040534973j) != (-0.95105570554733276-0.3090435266494751j) within 6 places These messages are new with 2.5. It looks like the agreement is still quite close. I expect the difference is from executing the test on a different architecture (PPC not x86). I assume it is nothing to worry about. Jon Jacky ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Built most of gr-*
John, I have a set of Over-The-Air captures of a wide variety of signals for download: http://www.kd7lmo.net/ground_gnuradio_ota.html As well as sample GNU radio code to demod and process them: http://www.kd7lmo.net/ground_gnuradio_software.html Hope that helps and gets you started. On Wed, 20 Apr 2005, John Clark wrote: > I don't have any hardware for the highspeed conversions, and have not > set up to use 'sound cards' etc. for > low speed testing. > > However, I have been able to get gnuradio-core, as well as several other > gr-* packages to compile. > The most problem seemed to be centered on having 1) a somewhat large set > of additional packages > that don't seem to have much to do with signal processing, such as > various cpp pre-preprocessing > tools, or the like. If the intent was to have a package that was > 'portable', then having a large number > of ancillary packages, which have not only interdependencies, but also > mutual exlucusions for an > existing system configuration, seems to go counter to that goal. > > Since I don't have much (like absolutely none) of anything based on an > existing installed python > environment, the fact that a number of libraries and packages where > 'installed' to get things for > gnuradio to compile correctly, it is of no real great difficulty, other > than just which ones, and what > upstream package requirements are needed. > > Moving on... Since I don't have hardware at the moment, are there some > examples of using simulated > signal generators or the like in the existing cvs packages, or out on > the net. Also, the gnuradio web site > has some pictures of oscope, or fft output, are those buried some where > in the gr-* set of code. > > Perhaps next week I'll have the time to see if I can set this up on a > NetBSD machine, but in the mean > time I'd like test things on the linux box I have at the moment. > > Thanks > > > > > ___ > 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
[Discuss-gnuradio] gr-audio-osx ?
The README in gnuradio-examples-0.4 recommends installing gr-audio-osx, sound card support for OS X. There's no tarball at http://comsec.com/wiki?GnuRadio2.X and Google turns up nothing. Has anyone started on this? Jon Jacky ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Waterfall spectrum display
Has anyone contemplated a "waterfall" type spectrum display? This might best be done when contemplating general data display speedups and UI improvements. Not that I'm volunteering, you understand :-) -- Marcus LeechMail: Dept 1A12, M/S: 04352P16 Security Standards AdvisorPhone: (ESN) 393-9145 +1 613 763 9145 Strategic Standards, CTO Office Nortel Networks [EMAIL PROTECTED] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Waterfall spectrum display
I've been working on one for a while, it works well (and is fast) but its a little rough. I believe that Matt has a fairly recent version of it in CVS. It may also now be a part of gr-wxgui --- I don't know. If you'd like the latest copy send me an email. -David Carr Marcus Leech wrote: > Has anyone contemplated a "waterfall" type spectrum display? > This might best be done when contemplating general data > display speedups and UI improvements. > > Not that I'm volunteering, you understand :-) > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP need antenna?
Eric Blossom wrote: As far as I know nobody has said anything about not needing an antenna. You need something. Try a 3 foot long piece of wire. For the broadcast AM band, longer is better. A cheap "FM dipole" works great for the FM broadcast band. By "FM dipole" I mean those really cheap T-shaped wire antennas that came with your stereo. They're typically available at the local drugstore for about $3. Don't bother trying RadioShack, they don't carry them, only the $20 amplified antennas that you don't need. I tried 2 different antennas. First, tried with FM/UHF tv antenna that has 2 extendable wires and one loop. Had to cut off the input connector of the antenna and just stick the bare coaxial wires in one of the RX A/RX B jacks on the USRP receiver board. I could tune and hear only one FM station among several; and even that one with a lot of noise. Next, tried FM dipole that looks like T shaped tape, the one you hang on wall. This one had 2 parallel inputs, each flat U shaped, I guess they're supposed to be secured between nut and bolt. I cut them off, stuck bare wires in the receiver jacks. Nothing, can't tune to a single AM/FM station. These antennas I assume don't have any gain control. I read on Ettus website the following: - Can I do interesting things with just a USRP and BasicTX/BasicRX, but no RF frontend? Do I need a separate RF front end to capture, say, CW or phone transmissions in the amateur bands? Or can the BasicRX fill that role? For reception you would need to add gain and filtering in front of the BasicRX daughterboard. This can be done pretty easily with MiniCircuits parts, or you can use the 10.7 MHz IF output of common scanners and receivers. The BasicRX board will handle signals up to around 100MHz directly. For higher frequencies you'll need to downconvert. It seems like I need an antenna with gain and filtering... Where do I get those? I'm totally illiterate in harware, electronics areas. Many thanks -suvda ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Waterfall spectrum display
Quite apart from the standard wx GUIs, I've been playing a bit with OpenGL. This one is the first of two open GL displays I've been toying with: http://web.media.mit.edu/~jcooley/gr_experiments/experiments/fft_3d_time/gr_3d_fft_time.htm It's a bit like a combined waterfall and standard fft display and performance is surprisingly good! There's no legend and the scale markers mean nothing at this point, but at least it looks cool ;) Kind of an fft land. -jamie David Carr wrote: I've been working on one for a while, it works well (and is fast) but its a little rough. I believe that Matt has a fairly recent version of it in CVS. It may also now be a part of gr-wxgui --- I don't know. If you'd like the latest copy send me an email. -David Carr Marcus Leech wrote: Has anyone contemplated a "waterfall" type spectrum display? This might best be done when contemplating general data display speedups and UI improvements. Not that I'm volunteering, you understand :-) ___ 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] FFT Baselines curved?
On Tuesday 19 April 2005 10:54, n4hy wrote: > Cascaded Integrator Comb filters are pretty simple filters that are very > fast to compute > but produce those slow roll offs. There are more complex things that > could be done and > hopefully now that the USRP is really flowing out the door, > daughtercards and all, and > as we come up to speed, we can work on these subtleties in the core code. Yeah, we're trying to apply these as spectrometers at PARI, and getting a flat baseline is pretty much required. I personally am working on spec-an stuff for AM broadcast (to do 47CFR73.44 occupied bandwidth measurements, where 12 bit resolution is fine). For the spectrometer project, we don't actually want an FFT. We want a swept filter analyzer instead, for integration purposes. FFT is acceptable, but most radio astronomy spectrometers are swept filter. Getting swept filter in software isn't too hard, either, but pre-filtering with the FPGA would be nice, then set up the software filters as fixed-frequency. The skirts next to signals are quite curved, too, and make the box not as useful as it could be in my application. Straight A/D at a low enough sample rate to get over the USB with no filtering at all I could deal with, but I've not dug into the code deep enough as yet to see how that works. I can choose basically any IF I want, and 10.7MHz is fairly standard in the RA world, which falls in the passband of the USRP nicely. My personal USRP I ordered with a TVRX (plus a BasicTX/RX pair), and I must say the WFM demod is nice for UHF NTSC TV audio. I see the BTSC stereo subcarriers properly, and can even see some hsync leakage in the audio. I may also write an NTSC block; I do enough video work that having a vectorscope and a waveform monitor is required. Currently I drag around an SGI O2 with the analog video card; the SGI diagnostic software for that card has vectorscope and waveform monitor capabilities. Does anyone (Matt?) have a good characterization of the frequency response curves of the BasicRX? If not, I'll take our calibrated noise sources and generators here and produce one; but it will be offset by the curvature already noted. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp_fft.py questions
Dear all,
I guess I should have spent more time experimenting and
studying the examples before asking these questions.
In any case, I have resolved both issues:
As it turns out the ADC's (I guess due to some
hardware mismathces etc) may add a DC term at the output.
This offset can be eliminated easily by adding some
more code in the python script.
The example "tweak_adc_offset.py" can help with this:
so what I did is I left the RX-A and RX-B open and run
tweak_adc_offset.py
The oscope showed the DC values for channels A and B
which have to be compensated. In my case was 322 and 180
for channels A and B, respectively.
Then I run
tweak_adc_offset.py -0 322 -1 180 and the oscope
verified an almost 0 offset for both of the channels.
I added the piece of code in both usrp_fft.py and usrp_oscope.py
to be able to compensate for this offset in all these programs:
parser.add_option ("-0", "--adc-offset-0", type="int", default=0,
help="set adc offset to OFFSET",
metavar="OFFSET")
parser.add_option ("-1", "--adc-offset-1", type="int", default=0,
help="set adc offset to OFFSET",
metavar="OFFSET")
parser.add_option ("-2", "--adc-offset-2", type="int", default=0,
help="set adc offset to OFFSET",
metavar="OFFSET")
parser.add_option ("-3", "--adc-offset-3", type="int", default=0,
help="set adc offset to OFFSET",
metavar="OFFSET")
where the parsing of arguments is taking place and
the following piece of code
# I added this to correct for the DC offset
# Experiments: it seems that 322 and 180 works for my USRP
FR_ADC_OFFSET_3_2 = 2 # hi 16: ADC3, lo 16: ADC2
FR_ADC_OFFSET_1_0 = 3
self.u._write_fpga_reg (FR_ADC_OFFSET_1_0, ((options.adc_offset_1
& 0x) << 16) | (options.adc_offset_0 & 0x))
self.u._write_fpga_reg (FR_ADC_OFFSET_3_2, ((options.adc_offset_3
& 0x) << 16) | (options.adc_offset_2 & 0x))
right after the definition of the usrp source.
I attach the corrected script usrp_fft.py and usrp_oscope.py
It wouldn't be hard to add a piece of code in all usrp-related
scripts that compensates for the DC offset automatically at the
beginning of the program.
All is needed is to measure the average DC term and use some sort of
AGC (I think it is already implemented in gnuradio) to drive the DC offset
close to 0. I might take a crack at it later, but now I am satisfied
with the manual way of compensation.
Best
Achilleas
#!/usr/bin/env python
#
# Copyright 2004 Free Software Foundation, Inc.
#
# This file is part of GNU Radio
#
# GNU Radio is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2, or (at your option)
# any later version.
#
# GNU Radio is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with GNU Radio; see the file COPYING. If not, write to
# the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
# Boston, MA 02111-1307, USA.
#
from gnuradio import gr
from gnuradio import usrp
from gnuradio import eng_notation
from gnuradio.eng_option import eng_option
from gnuradio.wxgui import stdgui, fftsink
from optparse import OptionParser
import wx
class app_flow_graph (stdgui.gui_flow_graph):
def __init__(self, frame, panel, vbox, argv):
stdgui.gui_flow_graph.__init__ (self, frame, panel, vbox, argv)
self.frame = frame
self.panel = panel
parser = OptionParser (option_class=eng_option)
parser.add_option ("-d", "--decim", type="int", default=16,
help="set fgpa decimation rate to DECIM")
parser.add_option ("-c", "--ddc-freq", type="eng_float", default=0,
help="set Rx DDC frequency to FREQ", metavar="FREQ")
parser.add_option ("-m", "--mux", type="intx", default=0x32103210,
help="set fpga FR_RX_MUX register to MUX")
parser.add_option ("-g", "--gain", type="eng_float", default=0,
help="set Rx PGA gain in dB (default 0 dB)")
parser.add_option ("-0", "--adc-offset-0", type="int", default=0,
help="set adc offset to OFFSET", metavar="OFFSET")
parser.add_option ("-1", "--adc-offset-1", type="int", default=0,
help="set adc offset to OFFSET", metavar="OFFSET")
parser.add_option ("-2", "--adc-offset-2", type="int", default=0,
help="set adc offset to OFFSET", metavar="OFFSET")
parser.add_option ("-3", "--adc-offset-3", type="int", default=0,
Re: [Discuss-gnuradio] pipes for today
On Wed, 20 Apr 2005, Rahul Dhar wrote: > On Fri, Apr 08, 2005 at 04:10:20PM -0400, cswiger wrote: > > This is a curious behavior: if > > > > 1) Use a vector source at the head and the USRP at the tail all is OK > > > > 2) Use the pipe fd source at the head and a file sink at the tail all is > > OK > > > > but if > > > > 3) Use a pipe fd source at the head and the USRP (with a parallel file > > sink to monitor) at the tail data very slowly trickles into the file, > > much slower than the 1.6Msps that it should - UNTIL I close the process > > feeding the pipe, THEN it goes full blast and processes the backed up > > pipe A-OK. > > > > Did you figure out the problem? I'm seeing something similar. I have > named pipes in place of the USRP, and nothing seems to go through them. > I'm not sure why. > I tried everything I can think of on the level I can work at but didn't find a solution. Have moved on to other projects (plus work is interfering with research time but that is almost over ;) --Chuck ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Waterfall spectrum display
James Cooley wrote: > > Quite apart from the standard wx GUIs, I've been playing a bit with OpenGL. > > This one is the first of two open GL displays I've been toying with: > > http://web.media.mit.edu/~jcooley/gr_experiments/experiments/fft_3d_time/gr_3d_fft_time.htm > > It's a bit like a combined waterfall and standard fft display and > performance is surprisingly good! There's no legend and the scale > markers mean nothing at this point, but at least it looks cool ;) Kind > of an fft land. > > -jamie > Very, very, spiffulous. Highly reminiscent of some of the [EMAIL PROTECTED] displays. -- Marcus LeechMail: Dept 1A12, M/S: 04352P16 Security Standards AdvisorPhone: (ESN) 393-9145 +1 613 763 9145 Strategic Standards, CTO Office Nortel Networks [EMAIL PROTECTED] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] animations - pulse shaping
Gang - Here's a couple of Blender dataset animations that demonstrate the bandlimiting effect of root-raised-cosine filter on pulses. They're about 2mb each. The first one is an unfiltered pulse with varying duty-cycle just to make things wiggle: http://webpages.charter.net/cswiger/pulse_fft.avi and the next one is the same pulse run thru a rrcf filter with the symbol rate at 1/8 the sample rate: http://webpages.charter.net/cswiger/rrcf_pulse.avi --Chuck ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] pipes for today
Hi,
i think i just hit the same issue
>From this simple code (no display what so ever):
fg = gr.flow_graph ()
u = usrp.source_c (0, 64, 1, 0xf0f0f0f0, 0)
n = gr.null_sink(gr.sizeof_gr_complex);
fg.connect(u, n);
dest = usrp.sink_c (0, 64)
siggen = gr.sig_source_c (dest.dac_freq()/64, gr.GR_SIN_WAVE,100e3, 16e3,0)
fg.connect(siggen, dest)
fg.start ()
raw_input ('Press Enter to quit: ')
fg.stop ()
TX and RX part are working independently... but in the same code, i
have a whole bunch of messages.
* one (length can change)
_reap: usb->status = -108, actual_length = 3584
* a lots of:
_reap: usb->status = -108, actual_length = 0
* And then a lots of:
fusb: (rd status -108) Cannot send after transport endpoint shutdown
with a few Uu and U0 scattered around
Cheers
Damien
On 4/21/05, Krzysztof Kamieniecki <[EMAIL PROTECTED]> wrote:
> Eric,
>
> Have you made any progress with this?
>
> I'm having a problem that may be related. The blocks are layed out like this.
>
> USRP Rx -> ... -> pipe
>
> gr_sig_source -> ... -> USRP Tx
>
> When running in gdb:
> 1. I wait for it to lockup
> 2. hit Ctrl-Z (to get into gdb)
> 3. type continue
> 4. more data is processed with a bunch of uU printed
> 5. software lockups again
> 6. goto 2
>
> When I hit Ctrl-Z the Tx thread always seems to be in ioctl in _reap. Is this
> normal?
>
> Attached is a file with bt's for each of the threads
> Thread 1 is Python/Wx, which seems to lockup
> Thread 2 seems to be the USRP Tx graph
> Thread 3 seems to be the USRP Rx graph
> Thread 4 is my pipe monitoring thread, which does not lockup
>
> Quoting Eric Blossom:
> > On Fri, Apr 08, 2005 at 04:10:20PM -0400, cswiger wrote:
> > > This is a curious behavior: if
> > >
> > > 1) Use a vector source at the head and the USRP at the tail all is OK
> > >
> > > 2) Use the pipe fd source at the head and a file sink at the tail all is
> > > OK
> > >
> > > but if
> > >
> > > 3) Use a pipe fd source at the head and the USRP (with a parallel file
> > > sink to monitor) at the tail data very slowly trickles into the file,
> > > much slower than the 1.6Msps that it should - UNTIL I close the process
> > > feeding the pipe, THEN it goes full blast and processes the backed up
> > > pipe A-OK.
> > >
> > > very interesting ;)
> >
> > Chuck, if you send me the code to test example (3), I'll take a look at it.
> >
> > Eric
>
>
> ___
> 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] USRP need antenna?
Hi, Suvda Myagmar wrote: Eric Blossom wrote: As far as I know nobody has said anything about not needing an antenna. You need something. Try a 3 foot long piece of wire. For the broadcast AM band, longer is better. A cheap "FM dipole" works great for the FM broadcast band. By "FM dipole" I mean those really cheap T-shaped wire antennas that came with your stereo. They're typically available at the local drugstore for about $3. Don't bother trying RadioShack, they don't carry them, only the $20 amplified antennas that you don't need. I tried 2 different antennas. First, tried with FM/UHF tv antenna that has 2 extendable wires and one loop. Had to cut off the input connector of the antenna and just stick the bare coaxial wires in one of the RX A/RX B jacks on the USRP receiver board. I could tune and hear only one FM station among several; and even that one with a lot of noise. Next, tried FM dipole that looks like T shaped tape, the one you hang on wall. This one had 2 parallel inputs, each flat U shaped, I guess they're supposed to be secured between nut and bolt. I cut them off, stuck bare wires in the receiver jacks. Nothing, can't tune to a single AM/FM station. These antennas I assume don't have any gain control. I read on Ettus website the following: - Can I do interesting things with just a USRP and BasicTX/BasicRX, but no RF frontend? Do I need a separate RF front end to capture, say, CW or phone transmissions in the amateur bands? Or can the BasicRX fill that role? For reception you would need to add gain and filtering in front of the BasicRX daughterboard. This can be done pretty easily with MiniCircuits parts, or you can use the 10.7 MHz IF output of common scanners and receivers. The BasicRX board will handle signals up to around 100MHz directly. For higher frequencies you'll need to downconvert. It seems like I need an antenna with gain and filtering... Where do I get those? I'm totally illiterate in harware, electronics areas. Many thanks -suvda Well out of the options there are, you should go with the scanner with IF output. Here is one example: *AOR's **AR8600MKII New Wide Band All-Mode 100KHz to 3GHz Scanner In general you would look for something like this: "The 10.7 MHz IF output can be used with ..." This thing would cost $900-$1000 and you may get away cheaper if you spend some time on the web. What I wonder about now is what the output level is, there is a good chance though that it is what you need. If you have an order of magnitude more money (or a university lab) you can go with a spectrum analyzer IF output at 21.4MHz, cool but expensive. I wonder though, whether there is not a cheaper way like the antenna with an amplifier you mentioned. There is a chance that there are FM antennas with amplifier and filter since amplifier bandwidth can be "costly" (designwise) too. Oh here is one (the first I found with google): http://www.magnumdynalab.com/x_sleuth.htm It says: * signal amplification variable from -10dB thru +30dB (30 times to gain) to bring weak stations to full quieting *** and tame strong, harsh, local signals * full tunability with a "hi Q," 400 KHz bandwidth. This adds some 70dB+ in Spurious Response selectivity * an electronic antenna switching system to bypass the SLEUTH's amplifier when not needed. Also with the SLEUTH's direct "in/out" Antenna Signal switching system, instant A/B comparison is always available * a low profile, cabinet in satin black. 17 3/4", 19" or 19" rackmount available. This seems to have a preselector and even though not electronically controllable should do the trick for you. Still, it seems expensive at $350. This should at most cost $50. The problem is that the cheap stuff never talks about bandwidths. To get a more accurate view of things let me find out what I get from my scanner antenna (SA7000). In the FM range I have a bunch of signals at around -80dBV(rms) my scope tells me. This would mean 282uV P-P over the 50Ohm input. If we assume the AD converter supports a -1V-+1V input range (somebody correct me) the lowest value would be triggered by 488uV(or 488uV/2 ?) this is not enough. Fortunately we have an integrated amplifier (PGA) which gives us +20dB so that the signal at the AD converter will get 2.8mV P-P now at its input (I can hear something now). The additional +30dB will amplify this to 89mV. This will give me a much larger number of stations too. Notice that there is also noise contributed by system internal sources, so my estimate may be optimistic. Maybe you can ask some EE people at your university for help, they may even part with an SMA connector. If not, Froogle is a good source at least for the connector: *SMA* Jack 3PC *Crimp* Style RG-58
Re: [Discuss-gnuradio] pipes for today
Some more information and possible solution (it's been running for about 20 minutes now without any problems and it usually failed in less then a minute). I am transmitting using 4 DACs at 1MS/s and receiving using 4 ADCs at 1MS/s. When the problem occurs: - The USRP Tx thread seems to be running without any problems. - The thread that is processing the USRP Rx graph seems to be stuck in PyThread_acquire_lock () (see line #2 below) Possible cause: I think I was monopolizing the lock needed in PyEval_RestoreThread in the Rx thread by doing a select inside of one of my block's C++ methods in my data monitor thread. Possible solution: When I call select using python in my data monitor thread, but outside of my block, everything seems to behave properly. (gdb) thread 3 [Switching to thread 3 (Thread 1139637168 (LWP 28677))]#0 0x40031d0b in [EMAIL PROTECTED] () from /lib/tls/libpthread.so.0 (gdb) bt #0 0x40031d0b in [EMAIL PROTECTED] () from /lib/tls/libpthread.so.0 #1 0x0004 in ?? () #2 0x080dd0bc in PyThread_acquire_lock () #3 0x080ace61 in PyEval_RestoreThread () #4 0x080d7908 in PyGILState_Ensure () #5 0x080e0b20 in initthread () #6 0x4002db63 in start_thread () from /lib/tls/libpthread.so.0 #7 0x40138c4a in clone () from /lib/tls/libc.so.6 Krzysztof Kamieniecki wrote: Eric, Have you made any progress with this? I'm having a problem that may be related. The blocks are layed out like this. USRP Rx -> ... -> pipe gr_sig_source -> ... -> USRP Tx When running in gdb: 1. I wait for it to lockup 2. hit Ctrl-Z (to get into gdb) 3. type continue 4. more data is processed with a bunch of uU printed 5. software lockups again 6. goto 2 When I hit Ctrl-Z the Tx thread always seems to be in ioctl in _reap. Is this normal? Attached is a file with bt's for each of the threads Thread 1 is Python/Wx, which seems to lockup Thread 2 seems to be the USRP Tx graph Thread 3 seems to be the USRP Rx graph Thread 4 is my pipe monitoring thread, which does not lockup Quoting Eric Blossom: On Fri, Apr 08, 2005 at 04:10:20PM -0400, cswiger wrote: This is a curious behavior: if 1) Use a vector source at the head and the USRP at the tail all is OK 2) Use the pipe fd source at the head and a file sink at the tail all is OK but if 3) Use a pipe fd source at the head and the USRP (with a parallel file sink to monitor) at the tail data very slowly trickles into the file, much slower than the 1.6Msps that it should - UNTIL I close the process feeding the pipe, THEN it goes full blast and processes the backed up pipe A-OK. very interesting ;) Chuck, if you send me the code to test example (3), I'll take a look at it. Eric (gdb) info threads 4 Thread 1148025776 (LWP 28678) 0x401324e7 in select () from /lib/tls/libc.so.6 3 Thread 1139637168 (LWP 28677) 0x40031d0b in [EMAIL PROTECTED] () from /lib/tls/libpthread.so.0 * 2 Thread 1131248560 (LWP 28676) 0x40131bd4 in ioctl () from /lib/tls/libc.so.6 1 Thread 1075400832 (LWP 28671) 0x4012ffe3 in poll () from /lib/tls/libc.so.6 (gdb) thread 1 [Switching to thread 1 (Thread 1075400832 (LWP 28671))]#0 0x4012ffe3 in poll () from /lib/tls/libc.so.6 (gdb) bt #0 0x4012ffe3 in poll () from /lib/tls/libc.so.6 #1 0x407c8896 in wxApp::WakeUpIdle () from /usr/lib/libwx_gtk2u_core-2.5.so.3 #2 0x410ab226 in g_main_loop_get_context () from /usr/lib/libglib-2.0.so.0 #3 0x410aa820 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #4 0x410aae43 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #5 0x40d9a8f3 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #6 0x407e3208 in wxEventLoop::Run () from /usr/lib/libwx_gtk2u_core-2.5.so.3 #7 0x40874233 in wxAppBase::MainLoop () from /usr/lib/libwx_gtk2u_core-2.5.so.3 #8 0x4046c2d2 in wxPyApp::MainLoop () from /usr/lib/python2.3/site-packages/wx-2.5.3-gtk2-unicode/wx/_core_.so #9 0x404a67dd in wxGridBagSizer_Add () from /usr/lib/python2.3/site-packages/wx-2.5.3-gtk2-unicode/wx/_core_.so #10 0x080fdede in PyCFunction_Call () #11 0x0805b989 in PyObject_Call () #12 0x080abcd4 in PyEval_CallObjectWithKeywords () #13 0x080aa028 in Py_MakePendingCalls () #14 0x080aa77c in PyEval_EvalCodeEx () #15 0x080fd9b7 in PyStaticMethod_New () #16 0x0805b989 in PyObject_Call () #17 0x080623d8 in PyMethod_Fini () #18 0x0805b989 in PyObject_Call () #19 0x080aba52 in PyEval_CallObjectWithKeywords () #20 0x080ab6b9 in PyEval_CallObjectWithKeywords () #21 0x080a9bee in Py_MakePendingCalls () #22 0x080ab96d in PyEval_CallObjectWithKeywords () #23 0x080ab72c in PyEval_CallObjectWithKeywords () #24 0x080a9bee in Py_MakePendingCalls () #25 0x080ab96d in PyEval_CallObjectWithKeywords () #26 0x080ab72c in PyEval_CallObjectWithKeywords () #27 0x080a9bee in Py_MakePendingCalls () #28 0x080aa77c in PyEval_EvalCodeEx () #29 0x080acf79 in PyEval_EvalCode () #30 0x080d90db in PyRun_FileExFlags () #31 0x080d85de in PyRun_InteractiveOneFlags () #32 0x080d83d3 in PyRun_Inter
