discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] Re: Dead USRP


From: David
Subject: [Discuss-gnuradio] Re: Dead USRP
Date: Tue, 06 Nov 2007 18:10:11 -0500
User-agent: Thunderbird 2.0.0.5 (X11/20070727)

Keith,
I just had the same thing happen about a month ago. Pretty much the same error messages you report. I ended up sending it in to Matt. I would email him directly to see if this is a possibility. On a bright note: I just got it back and it works great. Matt was very straight about the possibility that he wouldn't be able to fix it though. It was the USB chip controller.

Hope that helps.
Dave

address@hidden wrote:
Send Discuss-gnuradio mailing list submissions to
        address@hidden

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
or, via email, send a message with subject or body 'help' to
        address@hidden

You can reach the person managing the list at
        address@hidden

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."


Today's Topics:

   1. test_usrp_inband_tx crash (sanmi)
   2. Re: test_usrp_inband_tx crash (George Nychis)
   3. introduction + question re: optimal demod for     audio stream
      analysis (m. cera)
   4. undefined symbol: _Z20gr_make_io_signatureiii (Tomek)
   5. Re: undefined symbol: _Z20gr_make_io_signatureiii
      (Johnathan Corgan)
   6. Dead USRP  (Keith)
   7. Re: I and Q samples out of FPGA receive chain (Johnathan Corgan)


----------------------------------------------------------------------

Message: 1
Date: Sun, 4 Nov 2007 17:22:18 -0600
From: "sanmi" <address@hidden>
Subject: [Discuss-gnuradio] test_usrp_inband_tx crash
To: <address@hidden>,     "'George Nychis'" <address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain;       charset="us-ascii"

Hi,

While using the inband code, I tried to test <test_usrp_inband_tx> in the
apps-inband folder, I noticed that the test crashes after 20 packets. I am
currently trying to debug this problem. I traced the crash to
<fusb_linux.cc>
in the legacy folder.

1) I noticed that rf-freq in <test_usrp_inband_tx> is set to 10 Mhz. Is this
the
RF-Frequency used on the hardware? We are using a 400Mhz daughtercard. What
happens if the frequencies don't match?

2) Do you observe the same crash? How can we fix this?

BTW, I understand that the inband code is in development, I am still
interested
in experimenting with it.

Hardware: USRP with 400Mhhz daughtercards, Intel p4
Software: gnuradio from <root/gnuradio/branches/developers/gnychis/inband>,
ubuntu gutsy gibbon

Thanks
Sanmi






------------------------------

Message: 2
Date: Sun, 04 Nov 2007 18:41:27 -0500
From: George Nychis <address@hidden>
Subject: [Discuss-gnuradio] Re: test_usrp_inband_tx crash
To: sanmi <address@hidden>
Cc: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi Sanmi,

1) We are not supporting the code until release, seriously :) There is no daughterboard support yet.

2) You haven't really given us enough information about the crash, however we have found and patched a bug in fusb_linux.cc as of version 6647.

- George


sanmi wrote:
Hi,

While using the inband code, I tried to test <test_usrp_inband_tx> in the
apps-inband folder, I noticed that the test crashes after 20 packets. I am
currently trying to debug this problem. I traced the crash to
<fusb_linux.cc>
in the legacy folder.

1) I noticed that rf-freq in <test_usrp_inband_tx> is set to 10 Mhz. Is this
the
RF-Frequency used on the hardware? We are using a 400Mhz daughtercard. What
happens if the frequencies don't match?

2) Do you observe the same crash? How can we fix this?

BTW, I understand that the inband code is in development, I am still
interested
in experimenting with it.

Hardware: USRP with 400Mhhz daughtercards, Intel p4
Software: gnuradio from <root/gnuradio/branches/developers/gnychis/inband>,
ubuntu gutsy gibbon

Thanks
Sanmi







------------------------------

Message: 3
Date: Mon, 5 Nov 2007 02:25:49 -0500
From: "m. cera" <address@hidden>
Subject: [Discuss-gnuradio] introduction + question re: optimal demod
        for     audio stream analysis
To: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

hi all,
just wanted to say hello & offer a quick introduction...
i'm a sound / media artist, currently enrolled in the digital + media mfa program at the rhode island school of design; for my thesis work, i'm developing a system with which i will sonify / visualize data (primarily density levels) from cellular networks (i.e. gsm) to create realtime performances and audiovisual installations using the usrp + gnu radio.

i'm running gnu radio (3.0.4) on fc7 w/ the planet ccrma kernel,
and have been successful receiving data using the usrp with AM / FM / WFM demodulation, and sending it out via alsa to another machine running supercollider 3 for analysis / resynthesis.
ultimately, i am planning on sending the data to supercollider via jack,
then onto max/msp/jitter on the other machine via open sound control
for 3d visualization using its implementation of openGL.

the audio stream generated from usrp_rx_nogui.py using AM demodulation
is fairly reliable in terms of spectral analysis: the cell traffic is generally pretty discernible, and while the noise floor is decently high, it could be compensated for somehow. but it seems like it might make more sense to be using GMSK demodulation... (FM / WFM have lower noise floors, but seem to require too tight of a radius to be useful)

however, i'm hitting a brick wall when it comes to trying to rectify the differences between the demodulation methods in usrp_rx_nogui.py and benchmark_rx.py / rx_voice.py... i also noticed that, in gmsk.py, the comments for the GMSK demodulator block say that the output is a stream of bits packed in the LSB of each byte it streams out.

but of course, a stream of bits in the LSBs of a bunch of bites does not a great audio signal make... and while i'd originally thought i'd be streaming out data files, then using that data to drive a synthesis engine written in supercollider, it seems to makes more sense to keep it all in an audio stream, as it is conveniently packaged for my needs,
and the latency is much lower than would be the case otherwise.

and since i'm not trying to transmit or receive specific data, just trying to analyze the level of activity in specific ranges of the spectrum in a given location, maybe it doesn't make sense to bother with GMSK. at any rate, any insight or advice you might have regarding optimal strategies for demodulation
in regards to this project would be greatly appreciated.

thanks in advance,
--mark

--
m. cera | c3ra.com





------------------------------

Message: 4
Date: Mon, 05 Nov 2007 14:02:50 +0100
From: "Tomek" <address@hidden>
Subject: [Discuss-gnuradio] undefined symbol:
        _Z20gr_make_io_signatureiii
To: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset="us-ascii"

Hey!

I installed gnuradio like described here: 
http://gnuradio.org/trac/wiki/UbuntuInstall and everything worked fine. Now I 
try to run the benchmark and i get this:

sudo ./usrp_fft.py Traceback (most recent call last):
  File "./usrp_fft.py", line 23, in <module>
    from gnuradio import gr, gru
  File "/usr/local/lib/python2.5/site-packages/gnuradio/gr/__init__.py", line 27, in 
<module>
    from gnuradio_swig_python import *
  File "/usr/local/lib/python2.5/site-packages/gnuradio/gr/gnuradio_swig_python.py", 
line 23, in <module>
    from gnuradio_swig_py_runtime import *
  File 
"/usr/local/lib/python2.5/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py", 
line 6, in <module>
    import _gnuradio_swig_py_runtime
ImportError: 
/usr/local/lib/python2.5/site-packages/gnuradio/gr/_gnuradio_swig_py_runtime.so:
 undefined symbol: _Z20gr_make_io_signatureiii

I tried to find answers in the history here but was not successful, can anybody give me a hint? I get the same error with usrp_benchmark_usb.py
thanks!
Tomek

--
http://www.qsl.net/n1yvv
***********************************
****I'm not dead, yet!************
*********************************** Dave Ocame, WS1ETI Awards Chair
The SETILeague, Inc
www.setileague.org

Stony Creek Observatory FN31og -72.834 longitude 41.272 latitude Member: The SETILeague, Inc. and, The Society for Amateur Radio Astronomy (SARA) and,
The Planetary Society





reply via email to

[Prev in Thread] Current Thread [Next in Thread]