[Discuss-gnuradio] Urgent
Hi I'm in a hurry writing this mail. I had a trip to Nigeria visiting the Tinapa opening ceremony. Unfortunately all my money has been stolen at the hotel where I stayed, by some armed robbers and since then I've been without any money and I'm even owing money to the hotel here. So I have only access to my emails,my mobile phone can't work here so I didn't bother bringing it along. Please can you lend me $2,500 so I can return back and settle the hotel bills I will return it back to you as soon as i get home.You can have it sent through western union. I have already spoken to the hotel manager, please let me hear from you so i can collect his full name and address where you can send the money tomorrow please or if possible today. I am waiting for your reply Thanks, Jared _ Make every e-mail and IM count. Join the i’m Initiative from Microsoft. http://im.live.com/Messenger/IM/Join/Default.aspx?source=EML_WL_ MakeCount___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] DV Dongle - AMBE USB Device
speex is nice. I've used it as well as the AMBE2000/2020. I wasn't in love with the AMBE. We ended up doing lots of hacking to make the DVSI AMBE 2000/2020 pair of DSPs work in our application. Specs were light and idiosyncrasies were numerous. j0j > Date: Wed, 19 Mar 2008 09:02:46 -0700 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Subject: Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device > CC: discuss-gnuradio@gnu.org > > On Wed, Mar 19, 2008 at 07:02:08AM -0600, Jeff Brower wrote: > > Rick- > > > > > > I am also thinking of writing a APCO P25 Voice to AMBE2000 frame > > > > converter and see > > > > if the device can decode P25 as well. This may be a general IMBE and > > > > AMBE codec. > > > > > > > > > > I hope so. I looked at this a while back. What concerned me most was the > > > AMBE2000/2020 documentation seemed to omit P25 style IMBE compatibility. > > > Compare the docs to another DVSI product - the VC55 - to see what I mean. > > > > If you're looking at low bitrate codecs for GNU radio, why use a hardware > > (dongle) > > dependent solution? You might look at MELPe, which provides 600, 1200, and > > 2400 bps, > > and can be implemented as a software solution. MELPe is a US/NATO standard > > (STANAG > > 4591). Common applications are HF radio and L band satellite apps where > > bandwidth is > > very limited. > > > > -Jeff > > Unless something has changed, MELP is also encumbered. How about a > free codec, such as speex? http://www.speex.org/ > > Eric > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio _ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Big bugs out of nowhere...
As Root, the effects are the same. I'd been trying it as root since you mentioned the groups Eric. BUT, George, thanks for the idea. I have 2 USRPs. I switched the power supplies (DC converters) and it's golden now. I tested the voltage on the first power supply with a Fluke and it was sagging down to around 3 Volts with no load on it. I think the process of flashing the FPGA and starting to run it was pulling it down to ground or something close, and basically turning off the USRP. It makes sense now too, because I'd hear the fan turn off sometimes while doing this. Anyway, power supply #2 works, and I have lots of DC converters, so I'm back up and running. Thanks for the help. :) j0j > Date: Mon, 17 Mar 2008 12:41:36 -0400 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > CC: [EMAIL PROTECTED]; discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] Big bugs out of nowhere... > > Have you changed anything on the USB bus? For example, adding another > device that is USB intensive or adding a hub? I received this error > once and narrowed it down to my webcam on the same bus sucking up > bandwidth, causing the USRP to have a hard time initializing. Once I > disconnected the webcam, it went away. > > - George > > > Eric Blossom wrote: > > On Mon, Mar 17, 2008 at 05:50:03AM -0400, Jared Jensen wrote: > > > >> Yes. I double checked just to make sure. I have a usrp group. I'm > >> in it. My 10-usrp.rules file is verbatim from the site. In the > >> past, I had no trouble accessing the usrp as non-root... but I > >> triple-checked, and the group is setup correctly. > > > > Let me ask the question a different way. > > > > If you run as root, does it work? > > > > Eric > > > > > >> I restarted, and I still get the same behavior. > >> > >> j0j > >> > >>> Date: Fri, 14 Mar 2008 10:54:42 -0700 > >>> From: [EMAIL PROTECTED] > >>> To: [EMAIL PROTECTED] > >>> CC: discuss-gnuradio@gnu.org > >>> Subject: Re: [Discuss-gnuradio] Big bugs out of nowhere... > >>> > >>> On Fri, Mar 14, 2008 at 10:48:29AM -0400, Jared Jensen wrote: > >>>> I haven't been using my usrp for a little while. I've been porting > >>>> my code to a TI C64x+. I came back to my usrp today and tried to > >>>> run just a basic receive for test data for my TI DSP. I got the > >>>> following error. In usbview I see a "USRP Rev4" under my ehci > >>>> controller. I thought it might be the board, so I grabbed my other > >>>> usrp, and the exact same thing happened. (This is with > >>>> gnuradio-3.1.1 ) So I tried my older gnuradio install, and tried to > >>>> run usrp_fft.py... and the same things happened. I checked > >>>> /usr/local/share/usrp. It has all of the rbf (see below). Has > >>>> anyone encountered this before? It was just a few months back > >>>> everything was great... I didn't touch gr for a while... came back > >>>> and BOOM. :( No joy. > >>> > >>> Have you followed the instructions for ensuring that you can access > >>> the USRP w/o being root? > >>> > >>> http://gnuradio.org/trac/wiki/UdevConfig > >>> > >>> Eric > >>> > >>> > >>>> usb_control_msg failed: error sending control message: Protocol error > >>>> usb_control_msg failed: error sending control message: Protocol error > >>>> usb_control_msg failed: error sending control message: Protocol error > >>>> usrp: failed to load fpga bitstream > >>>> /usr/local/share/usrp/rev4/std_2rxhb_2tx.rbf. > >>>> > >>>> File "/usr/local/lib/python2.5/site-packages/gnuradio/usrp1.py", line > >>>> 1232, in source_c > >>>> return _usrp1.source_c(*args) > >>>> RuntimeError: can't open usrp1 > > > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > _ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Big bugs out of nowhere...
Yes. I double checked just to make sure. I have a usrp group. I'm in it. My 10-usrp.rules file is verbatim from the site. In the past, I had no trouble accessing the usrp as non-root... but I triple-checked, and the group is setup correctly. I restarted, and I still get the same behavior. j0j > Date: Fri, 14 Mar 2008 10:54:42 -0700 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > CC: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] Big bugs out of nowhere... > > On Fri, Mar 14, 2008 at 10:48:29AM -0400, Jared Jensen wrote: > > > > > I haven't been using my usrp for a little while. I've been porting > > my code to a TI C64x+. I came back to my usrp today and tried to > > run just a basic receive for test data for my TI DSP. I got the > > following error. In usbview I see a "USRP Rev4" under my ehci > > controller. I thought it might be the board, so I grabbed my other > > usrp, and the exact same thing happened. (This is with > > gnuradio-3.1.1 ) So I tried my older gnuradio install, and tried to > > run usrp_fft.py... and the same things happened. I checked > > /usr/local/share/usrp. It has all of the rbf (see below). Has > > anyone encountered this before? It was just a few months back > > everything was great... I didn't touch gr for a while... came back > > and BOOM. :( No joy. > > > Have you followed the instructions for ensuring that you can access > the USRP w/o being root? > > http://gnuradio.org/trac/wiki/UdevConfig > > Eric > > > > usb_control_msg failed: error sending control message: Protocol error > > usb_control_msg failed: error sending control message: Protocol error > > usb_control_msg failed: error sending control message: Protocol error > > usrp: failed to load fpga bitstream > > /usr/local/share/usrp/rev4/std_2rxhb_2tx.rbf. > > > > File "/usr/local/lib/python2.5/site-packages/gnuradio/usrp1.py", line > > 1232, in source_c > > return _usrp1.source_c(*args) > > RuntimeError: can't open usrp1 > _ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Big bugs out of nowhere...
I haven't been using my usrp for a little while. I've been porting my code to a TI C64x+. I came back to my usrp today and tried to run just a basic receive for test data for my TI DSP. I got the following error. In usbview I see a "USRP Rev4" under my ehci controller. I thought it might be the board, so I grabbed my other usrp, and the exact same thing happened. (This is with gnuradio-3.1.1 ) So I tried my older gnuradio install, and tried to run usrp_fft.py... and the same things happened. I checked /usr/local/share/usrp. It has all of the rbf (see below). Has anyone encountered this before? It was just a few months back everything was great... I didn't touch gr for a while... came back and BOOM. :( No joy. usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usrp: failed to load fpga bitstream /usr/local/share/usrp/rev4/std_2rxhb_2tx.rbf. Traceback (most recent call last): File "./usrp_wfm_rcv.py", line 289, in app = stdgui2.stdapp (wfm_rx_block, "USRP WFM RX") File "/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 36, in __init__ wx.App.__init__ (self, redirect=False) File "/usr/lib/python2.5/site-packages/wx-2.6-gtk2-unicode/wx/_core.py", line 7700, in __init__ self._BootstrapApp() File "/usr/lib/python2.5/site-packages/wx-2.6-gtk2-unicode/wx/_core.py", line 7352, in _BootstrapApp return _core_.PyApp__BootstrapApp(*args, **kwargs) File "/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 39, in OnInit frame = stdframe (self.top_block_maker, self.title, self._nstatus) File "/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 60, in __init__ self.panel = stdpanel (self, self, top_block_maker) File "/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 81, in __init__ self.top_block = top_block_maker (frame, self, vbox, sys.argv) File "./usrp_wfm_rcv.py", line 79, in __init__ self.u = usrp.source_c()# usrp is data source File "/usr/local/lib/python2.5/site-packages/gnuradio/usrp.py", line 248, in __init__ fpga_filename, firmware_filename) File "/usr/local/lib/python2.5/site-packages/gnuradio/usrp1.py", line 1232, in source_c return _usrp1.source_c(*args) RuntimeError: can't open usrp1 :/proc$ cd /usr/local/share/usrp/rev4/ total 840k drwxr-xr-x 2 root root 4.1k 2007-11-12 11:57 ./ drwxr-xr-x 4 root root 4.1k 2007-08-20 20:45 ../ -rw-r--r-- 1 root root 181k 2007-11-12 11:56 multi_2rxhb_2tx.rbf -rw-r--r-- 1 root root 181k 2007-11-12 11:56 std_2rxhb_2tx.rbf -rw-r--r-- 1 root root 182k 2007-11-12 11:56 std_4rx_0tx.rbf -rw-r--r-- 1 root root 18k 2007-11-12 11:56 std.ihx -rw-r--r-- 1 root root 123k 2007-11-12 11:57 usrp_radar_mono.rbf -rw-r--r-- 1 root root 114k 2007-11-12 11:57 usrp_sounder.rbf j0j _ Need to know the score, the latest news, or you need your Hotmail®-get your "fix". http://www.msnmobilefix.com/Default.aspx___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Broken 3.1.1 install on Ubuntu Gutsy??? (7.10)
I downloaded the 3.1.1. tar ball today and tried to install. For background info, I already had gr3.0rc1 installed and running fine. I untarred, cd'd to gnuradio-3.1.1 and did a... > sudo make install Everything went fine, but when I try to run anything, I get the following... Traceback (most recent call last): File "./usrp_fft.py", line 23, in from gnuradio import gr, gru File "/usr/local/lib/python2.5/site-packages/gnuradio/gr/__init__.py", line 27, in from gnuradio_swig_python import * File "/usr/local/lib/python2.5/site-packages/gnuradio/gr/gnuradio_swig_python.py", line 23, in from gnuradio_swig_py_runtime import * File "/usr/local/lib/python2.5/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py", line 6, in import _gnuradio_swig_py_runtime ImportError: libgromnithread.so.0: cannot open shared object file: No such file or directory I did a ... > make check to see if anything was wrong and I got this... make[4]: Leaving directory `.../gnuradio-3.1.1/gr-audio-oss/src' make[3]: Leaving directory `.../gnuradio-3.1.1/gr-audio-oss/src' make[2]: Leaving directory `.../gnuradio-3.1.1/gr-audio-oss/src' make[2]: Entering directory `.../gnuradio-3.1.1/gr-audio-oss' make[2]: Nothing to be done for `check-am'. make[2]: Leaving directory `.../gnuradio-3.1.1/gr-audio-oss' make[1]: Leaving directory `.../gnuradio-3.1.1/gr-audio-oss' Making check in gr-atsc make[1]: Entering directory `.../gnuradio-3.1.1/gr-atsc' Making check in src make[2]: Entering directory `.../gnuradio-3.1.1/gr-atsc/src' Making check in lib make[3]: Entering directory `.../gnuradio-3.1.1/gr-atsc/src/lib' make check-am make[4]: Entering directory `.../gnuradio-3.1.1/gr-atsc/src/lib' make check-TESTS make[5]: Entering directory `.../gnuradio-3.1.1/gr-atsc/src/lib' /usr/bin/ld: cannot open output file .../gnuradio-3.1.1/gr-atsc/src/lib/.libs/7836-lt-test_atsci: Permission denied collect2: ld returned 1 exit status FAIL: test_atsci === 1 of 1 tests failed === make[5]: *** [check-TESTS] Error 1 make[5]: Leaving directory `.../gnuradio-3.1.1/gr-atsc/src/lib' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `.../gnuradio-3.1.1/gr-atsc/src/lib' make[3]: *** [check] Error 2 make[3]: Leaving directory `.../gnuradio-3.1.1/gr-atsc/src/lib' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `.../gnuradio-3.1.1/gr-atsc/src' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `.../gnuradio-3.1.1/gr-atsc' make: *** [check-recursive] Error 1 Are there some new dependencies I should be aware of? Thanks. Jared _ Climb to the top of the charts! Play Star Shuffle: the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_oct ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Still not working with 2 DBSRX... :(
HA! REFCLK_REG = 43 for RXB, and 41 for RXA. I had hard-coded 41. Thank you! I had looked at db_base.py a long time ago when I got one board working, but I completely forgot about it until your e-mail. Thanks a lot. Now the data looks good. :D I'll tell our accountant to send you a consulting check. ;) Jared > Date: Wed, 24 Oct 2007 12:21:28 -0700 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > CC: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] Still not working with 2 DBSRX... :( > > On Wed, Oct 24, 2007 at 12:16:53PM -0700, Eric Blossom wrote: > > On Wed, Oct 24, 2007 at 02:29:31PM -0400, Jared Jensen wrote: > > > > > I'm brainstorming and I wonder if I setup RXB correctly, but haven't > > > sent some command to gate the data through. Or if there is an > > > additional step when using 2 channels that isn't documented. Any > > > ideas of things I could look at? > > > > No magic that isn't contained in db_dbs_rx.py > > > > You're looked at the code in db_base.py too, right? > > Eric _ Help yourself to FREE treats served up daily at the Messenger Café. Stop by today. http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=TXT_TAGLM_OctWLtagline___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Still not working with 2 DBSRX... :(
Wow. I'm still not able to get data out of my 2nd DBSRX. I have verified the board is good. I modified multi-antenna/multi-fft.py to use 2 DBSRX board and the 2rx 2tx fpga build. It works, and I can point the boards at different frequencies and see good data. So I know the hardware is working. Ergo, the problem is with my code, and I'm not sure what to do next. I've debugged this ad nauseum. I've verified that I setup r, n, gc1, gc2... all correctly. I rebuilt usrp_standard.cc with debugging info as well as db_dbs_rx.py. My code does the same things in setup. I think I'm setting up each dbsrx correctly. They return success on tune, and return successfully from all of the write_i2c commands. I'm using I2C_ADDR 0x67 for subdev A, and I2C_ADDR 0x65 for subdev B. I've changed those randomly and found that it correctly fails. So I'm fairly confident that the commands are getting down to the DBSRXs. When I call usrp_standard_rx::make(0, decim=64, nchannels=2, mux=0x32103210, fpga_mode=0x00, fusb_block_size=0, fusb_nblocks=0, "std_2rxhb_2tx.rbf", "std.ihx") it returns a valid usrp device, and when I query the number of channels, it says 2. But when I do a dev->start(); followed by nRead = dev->read(arr, buf_size, &bOverrun); and fwrite(arr,1,nRead, USRPfid); I get perfect data for channel 0 (RXA) , but channel 1 (RXB) is just the noise floor. Loading it into Matlab and looking at the fft shows RXA is doing perfectly, while RXB has no signal magnitude. (This is when I point it at two known frequencies where both are looking at signals with good power... and even when I point them at the same frequency.) Using ASCII art... FFT_RXA is like | ||| __|___ and FFT_RXB is just _. I'm brainstorming and I wonder if I setup RXB correctly, but haven't sent some command to gate the data through. Or if there is an additional step when using 2 channels that isn't documented. Any ideas of things I could look at? Like I said, gnuradio is able to talk to both boards and get good data, but my C++ code isn't. I can only get good data from RXA. RXB is flat. (Well... there's low magnitude white noise, but no significant power.) Am I missing a step? All was well until I added a second DBSRX to the system, and now I can't get data from that new board. Save me Eric/Matt/anyone better at this than I! Jared _ Windows Live Hotmail and Microsoft Office Outlook – together at last. Get it now. http://office.microsoft.com/en-us/outlook/HA102225181033.aspx?pid=CL100626971033___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Mux settings...
Thanks. That means I have issues. :) I am trying to use 2 channels, with a mux setting of 0x32103210. I have a DBSRX on RXA and another one on RXB. I have no TX. When I do a... nRead = myDev->read(arr, USB_BUF_SIZE, &bOverrun); I get perfect data from one channel. (i.e. I_a = arr[0], Q_a = arr[1], I_a = arr[4], Q_a = arr[5] and so on.) But I get complete junk on the second channel. (I_a = arr[2], Q_a = arr[3], I_a = arr[6], Q_a = arr[7]). I've swapped the boards (slot A to slot B and vice versa), and they both seem to work fine. I've run usrp_fft.py -R B and -R A and it works in both cases, but I can't find anything to test both at once. But regardless, I don't think it's the USRP's fault. It think it's mine unfortunately. I'm just out of ideas where to look. I've been debugging this for a couple of days now. Ugh. :) Any thoughts? Jared > Date: Mon, 22 Oct 2007 17:15:08 -0700 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > CC: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] Mux settings... > > On Mon, Oct 22, 2007 at 05:13:33PM -0400, Jared Jensen wrote: > > > > > What are the proper mux settings for one DBSRX in RXA and one DBSRX > > in RXB? When I used a single DBSRX in RXA 0x0010 worked well. > > But now I want Channel 0 to be RXA, and Channel 1 to be RXB both of > > which are I and Q, and not swapped. > > > > So far anything other than 0x32103210 or 0x0010 produces dirty > > output with random-looking noise in the data. > > > > Jared > > If you're using a single channel, usrp.determine_rx_mux_value will get you > the right answer, regardless of the type of daughterboard. > > On the DBSRX, 0x3210 (or for that matter 0x32103210) will set you > up with side A routed to channel 0 and side B routed to channel 1. > > See http://gnuradio.org/trac/wiki/UsrpRfxDiagrams > and http://gnuradio.org/doc/doxygen/classusrp__standard__rx.html > > Eric > _ Help yourself to FREE treats served up daily at the Messenger Café. Stop by today. http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=TXT_TAGLM_OctWLtagline___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Mux settings...
What are the proper mux settings for one DBSRX in RXA and one DBSRX in RXB? When I used a single DBSRX in RXA 0x0010 worked well. But now I want Channel 0 to be RXA, and Channel 1 to be RXB both of which are I and Q, and not swapped. So far anything other than 0x32103210 or 0x0010 produces dirty output with random-looking noise in the data. Jared _ Peek-a-boo FREE Tricks & Treats for You! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Multi-channel I/Q buffer format...
I'm getting some strange behavior when I use two DBSRX boards with my USRP. I just wanted to vet some of my assumptions as I'm debugging. I'm assuming that the data comes across the USB bus as follows I_A/Q_A/I_B/Q_B/I_A/Q_A/ Is that correct? i.e. do we get I/Q of one board followed by I/Q of the other board? And they come across as 2-byte samples for each I and 2-byte samples for each Q? So... I_A_16bits/Q_A_16bits/I_B_16bits/Q_B_16bits/... and so on? Again, I'm just trying to make sure I don't waste time debugging elsewhere. Thanks Jared _ Peek-a-boo FREE Tricks & Treats for You! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] fusb::_reap: Interrupted System Call
That's an idea. I do call usleep() occasionally in my other thread when I know I won't be processing for a while. (Like when I want to let my buffer recover a little while after I run up to the end of it.) Maybe the super high priority read thread is executing when a usleep() should return and I get this error. I'll look into it. Thanks for taking the time to look at it. I'm not using any signaling between the two threads. I just have that callback. So hopefully it's just the usleep issue. Thanks again. Jared > Date: Tue, 16 Oct 2007 10:07:17 -0700 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > CC: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] fusb::_reap: Interrupted System Call > > On Tue, Oct 16, 2007 at 12:47:59PM -0400, Jared Jensen wrote: > > > > Eric, > > > > Ubuntu, Feisty. 2.6.20-16-generic. HP dv2000 > > laptop, Core 2 Duo, 1.6 GHz. 2 GB RAM, 160GB HDD 5400 RPM (But I'm not > > doing much disk I/O at all). > > > > I get the error message > > every 10-15 seconds or so. Sometimes I won't see it for minutes at a > > time, and other times, I'll see it often; like multiple times in a few > > seconds. Like I said, no data is missing (as far as I can tell), but > > this pops up frequently; apparently from the libusb driver. I don't > > get overruns, just this. Also, as I said, I can't see any missing > > data, but I also can't 100% guarantee that I'm not losing some data, so > > it concerns me a little. > > Without chasing through more code than I just did, I can't say with > certainty if you're losing data or not, but I suspect that you're not. > > I would guess that you're using some kind of time keeping alarm that's > setting a periodic interrupt, and that's what you're seeing (E.g., > sleep or alarm). Are you expecting to be getting a SIG* in this > thread? If not, you may want to take a look at pthread_sigmask. > Using threads and signals together is a bit of a black art. > > Eric _ Boo! Scare away worms, viruses and so much more! Try Windows Live OneCare! http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=wl_hotmailnews___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] fusb::_reap: Interrupted System Call
Eric,
Ubuntu, Feisty. 2.6.20-16-generic. HP dv2000
laptop, Core 2 Duo, 1.6 GHz. 2 GB RAM, 160GB HDD 5400 RPM (But I'm not
doing much disk I/O at all).
I get the error message
every 10-15 seconds or so. Sometimes I won't see it for minutes at a
time, and other times, I'll see it often; like multiple times in a few
seconds. Like I said, no data is missing (as far as I can tell), but
this pops up frequently; apparently from the libusb driver. I don't
get overruns, just this. Also, as I said, I can't see any missing
data, but I also can't 100% guarantee that I'm not losing some data, so
it concerns me a little.
To reproduce it, I just run my
code. :) I've written some custom code to do MSK. It's all in C++,
since management wasn't down with Python, and I had to interface to our
existing C++ protocol libraries. (And other complications...) So I
ported the DBSRX tuning code over to C++, and implemented a read
thread. Then my consumer thread just takes the data and handles it.
The read thread is really brief. It's just a while(1) loop
while(!bThreadStop){
// Toggling the ping pong buffers
(!bWhichBuf) ? arr = &array1[0] : arr = &array2[0];
// The read
nRead = myDev->read(arr,sizeof(array1),&bOverrun);
// The resampler method just hands the data to my processing thread.
// The processing thread then handles the polyphase rational resampler.
if(bUseRationalResampler){
myDSP->rational(arr,nRead/sizeof(short));
}
else{ // Or just copy it out and do nothing with it. (This still
produces the error message.) I did this to debug if maybe something
// was lacking CPU time, or resources. But it seems
like the error is independent of processing load.
myDSP->CopyData(arr,nRead/sizeof(short));
}
// Keeping track of the amount of data
nData += nRead/sizeof(short)/2 & ( INDEX_MAX - 1 );
if(bOverrun){
fprintf(stderr,"DISASTEROUS ERROR : Overrun! (%ld)\n",nData);
if(bLogDebugging)
fprintf(logfileFID,"DISASTEROUS ERROR : Overrun!
(%ld)\n",nData);
}
// Switch buffers
bWhichBuf = !bWhichBuf;
}
So
that's the only code that reads the USRP. My read thread is MAX
PRIORITY, and it spends most of its time blocked. My other thread
takes about 15% of the CPU on my machine. I know that the read thread
resides on one core of my CPU, while the processing is on the other
core. (Processor affinity from Intel's ICC compiler.) It always seems
like both threads have more than enough resources though. But again,
I'd be open to any suggestions/tips/tricks. It seems like nothing I do
changes it, so let me know if you have any insight and I'll give it a
try.
Also, everything runs well and processes well. So I'm
talking to the USRP correctly and to the DBSRX correctly as well.
(Have been for a couple of months now.) Again, there may be some
subtlety I'm missing, but as for functionality, things appear to work.
Thanks for the help.
Jared
> Date: Mon, 15 Oct 2007 12:38:28 -0700
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> CC: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] fusb::_reap: Interrupted System Call
>
> On Thu, Oct 11, 2007 at 03:54:56PM -0400, Jared Jensen wrote:
> >
> > Does anyone know why I get "fusb::_reap: Interrupted System Call" fairly
> > frequently? There are no overruns, and my data seems good, but I keep
> > getting this error. If it's meaningless, is there a way to suppress it?
> >
> > Jared
>
> I've never seen it.
>
> Can you tell me how you reproduce it?
> What OS, distribution, etc?
>
> Eric
_
Peek-a-boo FREE Tricks & Treats for You!
http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] fusb::_reap: Interrupted System Call
Does anyone know why I get "fusb::_reap: Interrupted System Call" fairly frequently? There are no overruns, and my data seems good, but I keep getting this error. If it's meaningless, is there a way to suppress it? Jared _ Boo! Scare away worms, viruses and so much more! Try Windows Live OneCare! http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=wl_hotmailnews___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] more issues with read_i2c
D'oh! Typo. I'm actually on Side A, not B, and am using 0x67. Since posting this, I started debugging and put in some debug statements in usrp_prims.cc and rebuilt with make && make install. The issue was just byte-ordering in the data buffer. I had guessed wrong as to how python marshals data to/from C strings. Thanks for the help. j0j From: Eric Blossom <[EMAIL PROTECTED]> To: Jared Jensen <[EMAIL PROTECTED]> CC: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] more issues with read_i2c Date: Mon, 30 Jul 2007 15:44:13 -0700 On Mon, Jul 30, 2007 at 12:44:11PM -0400, Jared Jensen wrote: > I've been having some issues with read_i2c. I noticed several posts dealt > with this, and their particular solutions didn't resolve the issue, so here > it goes. > > I ported bd_bds_rx.py and bd_basic.py to C++, along with usrp.py so I could > include it all in my C++ signal processing app. Things in general work, > but read_i2c doesn't. I'm using a dbsrx on side B and using I2C_ADDR = > 0x67. I called _write_oe(0,0x0001,0x0001) and not write_io(...). class db_dbs_rx (db_base.db_base): def __init__ (self, usrp, which): """ Control DBS receiver based USRP daughterboard. @param usrp: instance of usrp.source_c @param which: which side: 0 or 1 corresponding to RX_A or RX_B respectively @type which: int """ # sets _u and _which db_base.db_base.__init__(self, usrp, which) self._u._write_oe(self._which,0x0001,0x0001) self.i2c_addr = (0x67, 0x65)[self._which] 0x65 is the i2c_address for a DBSRX on the B side. FWIW, 0x67 is for the A side. Eric _ http://liveearth.msn.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] more issues with read_i2c
I've been having some issues with read_i2c. I noticed several posts dealt
with this, and their particular solutions didn't resolve the issue, so here
it goes.
I ported bd_bds_rx.py and bd_basic.py to C++, along with usrp.py so I could
include it all in my C++ signal processing app. Things in general work, but
read_i2c doesn't. I'm using a dbsrx on side B and using I2C_ADDR = 0x67. I
called _write_oe(0,0x0001,0x0001) and not write_io(...).
When I read_i2c I get 0x00 in the first byte and either 0x00, 0x02, or 0x04
in the second byte. I cast each byte to an int for us in the set_freq
function. (See code below.)
bool DBSRX::read_status(){
std::string retbuf = USRP_dev->read_i2c(I2C_ADDR,2);
if(retbuf.length() != 2){
printf("ERROR : read_status returned length
%d\n",retbuf.length());
return false;
}
nStatus[0] = (int)retbuf[0];
nStatus[1] = (int)retbuf[1];
printf("READ_STATUS read_i2c result : [0x%x,
0x%x]\n",retbuf[0],retbuf[1]);
return true;
}
I've been pouring through the python code trying to find some initialization
I've missed, or some setup or something, but I can't spot anything. Any
clues on what may be causing this? Is there any documentation on what the
actual data returned by read_i2c actually represents? I see that
db_dbs_rx.py shifts the lower byte down by 2 and calls it "adc_val". Any
more info on that? What adc property does that represent? Also, is the
second byte ever useful? I don't see it used anywhere, but it usually
contains some data when I do a read_i2c. Thanks for any help.
Jared
_
Local listings, incredible imagery, and driving directions - all in one
place! http://maps.live.com/?wip=69&FORM=MGAC01
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
