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
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 mea
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.d
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
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 comb
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
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 e
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,
> daughte
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
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-s
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 a
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 A
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 mail
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 W
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:
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
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 se
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 pro
18 matches
Mail list logo
