Re: [Discuss-gnuradio] Re: Ubuntu and make check (weird results)
On Sun, 2006-12-03 at 01:08 -0600, Shravan Rayanchu wrote: > Is it because of the 'make check' failure? > > FAIL: test_cc_2 (__main__.test_feval) > > -- > > Traceback (most recent call last): > > File "./qa_feval.py", line 94, in test_cc_2 > > self.assertEqual(expected_result, actual_result) > > AssertionError: ((2-1j), (4+1j), (6+3j), (8+5j)) != (0j, 0j, 0j, 0j) This is a known issue with the trunk code and SWIG versions < 1.3.31. There is no fix other than to upgrade your SWIG and recompile. Ubuntu 6.10 only comes with 1.3.28 so you'll have to do a source installation from swig.org. It's pretty painless. -- Johnathan Corgan, AE6HO Corgan Enterprises LLC [EMAIL PROTECTED] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Ubuntu and make check (weird results)
Hi everyone, It turns out there are problems with the install. I get wierd results. I have a gentoo box and a ubuntu box both of which have gnuradio installed. The ubuntu box however failed some make checks (my mail below). When I run "./usrp_spectrum_sense.py 2412M 2444M" with gentoo box, the center frequencies are printed out fine. However, when I do that with the ubuntu installation, I get "0.0" as the center frequency !! I dont get a "failed to set frequency" message. Infact, when I run the 802.11 BBN code (./bbn_80211b_rx.py -d 8 -f 2412e6 -b), I am able to capture packets. So u.tune actually works and the frequency is set I don't understand what is wrong with the installation .. Is it because of the 'make check' failure? --Shravan On 12/3/06, Shravan Rayanchu <[EMAIL PROTECTED]> wrote: Hi all, When I do a 'make check' on ubuntu, I get an error. This seems to be a fairly common problem (I tried searching on the lists, there were some references to seg fault, but not the exact error I get). I am using gcc 4.0.1, cppunit 1.10.2, and here is what I get: == FAIL: test_cc_2 (__main__.test_feval) -- Traceback (most recent call last): File "./qa_feval.py", line 94, in test_cc_2 self.assertEqual(expected_result, actual_result) AssertionError: ((2-1j), (4+1j), (6+3j), (8+5j)) != (0j, 0j, 0j, 0j) I get some errors similar to the above and then this one: -- Ran 8 tests in 0.002s FAILED (failures=4) ..>>> gr_fir_ccc: using SSE -- Is this something to worry about? (make install worked fine). I appreciate the help. Thanks! Shravan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Ubuntu and make check
Hi all, When I do a 'make check' on ubuntu, I get an error. This seems to be a fairly common problem (I tried searching on the lists, there were some references to seg fault, but not the exact error I get). I am using gcc 4.0.1, cppunit 1.10.2, and here is what I get: == FAIL: test_cc_2 (__main__.test_feval) -- Traceback (most recent call last): File "./qa_feval.py", line 94, in test_cc_2 self.assertEqual(expected_result, actual_result) AssertionError: ((2-1j), (4+1j), (6+3j), (8+5j)) != (0j, 0j, 0j, 0j) I get some errors similar to the above and then this one: -- Ran 8 tests in 0.002s FAILED (failures=4) ..>>> gr_fir_ccc: using SSE -- Is this something to worry about? (make install worked fine). I appreciate the help. Thanks! Shravan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Transmit Frequencies
> -Original Message- > Thomas Schmid > Sent: Friday, December 01, 2006 1:48 PM > To: Scott Meuleners > Cc: discuss-gnuradio > Subject: Re: [Discuss-gnuradio] Transmit Frequencies > > >From Ettus Inc.'s FAQ you can read that the BasicTX goes only up to > about 50MHz because the DACs in the USRP run at 128MS/s. You would > need some other hardware to upsample your output to 70MHz. > > Thomas > > On 12/1/06, Scott Meuleners <[EMAIL PROTECTED]> wrote: > > > > I am working on a project for a class, and we have been using the FM > > transmit functions included with the examples, and we've run into a > problem > > where we are unable to transmit on frequencies from about 40 to 80 MHz, > the > > problem is that we would like to transmit at 72MHz. The errors amount > to > > something like "cannot tune frequency", etc... Does anyone have any > > suggestions as to how we might get this to work? We are using the USRP > with > > the Basic TX daughterboard. > > Scott, Thomas' email is correct, using the BasicTX boards, you can only transmit up to 44 MHz and because of the 128 Msps DAC, you can only get up to 64 MHz from a comms. perspective. However, you can cheat (sort of) by using the sampling process of the system. When you sample the original frequency, you get images around the sampling frequencies, in this case 128 Msps. Out of the BasicTX, you get three fairly strong signals: one at the specified center frequency (fc), one at 128 MHz + fc, and one at 128 MHz - fc. You won't be able to hit your target of 72 MHz this way, though (128 - 44 = 84 MHz), but I point it out in case it helps. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NetBSD
usb_control_msg failed: error sending control message: Input/output
error
I haven't tracked this down, but I'd be interested in fixing it. I
suspect it's either something missing in NetBSD or some OS-dependent
code that isn't properly abstracted. I think it might be coming from
libusb, but I really don't know - the error message is a bit lame. If
you can figure out the call chain that results in the error (perhaps
with ktrace on the simplest program that provokes it), that would be
helpful.
Ok, I put a few printfs in there. You're right: the error message comes
from libusb, but the "usb_control_msg" part comes from
usrp/host/lib/usrp_prims.cc in the function write_cmd() and the args are
rType=8 val=87 index=0 len=1 and so that's VRQ_I2C_WRITE so i'm gonna
guess that this is the usrp_eeprom_write() call that includes this code:
// The simplest thing that could possibly work:
// all writes are single byte writes.
//
// We could speed this up using the page write feature,
// but we write so infrequently, why bother...
while (len-- > 0){
cmd[0] = eeprom_offset++;
cmd[1] = *p++;
bool r = usrp_i2c_write (udh, i2c_addr, cmd, sizeof (cmd));
mdelay (10);// delay 10ms worst case write time
if (!r)
return false;
}
That's a single byte write ...
Now: why this is failing and the rest of everything still works, that's
up to someone else ...
/jordan
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NetBSD
Everytime I run a (v3.0.2) gnuradio program (on NetBSD 3.1), I get the following message: usb_control_msg failed: error sending control message: Input/output error I haven't tracked this down, but I'd be interested in fixing it. I suspect it's either something missing in NetBSD or some OS-dependent code that isn't properly abstracted. I think it might be coming from libusb, but I really don't know - the error message is a bit lame. If you can figure out the call chain that results in the error (perhaps with ktrace on the simplest program that provokes it), that would be helpful. BTW if you run -current instead of 3.1, the USRP should do 16 MB/s each way instead of 4 MB/s that you probably get on 3.1. The improvements were committed sometime this summer. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NetBSD
On Sunday 03 December 2006 07:42, Jordan Hayes wrote: > Everytime I run a (v3.0.2) gnuradio program (on NetBSD 3.1), I get the > following message: > > usb_control_msg failed: error sending control message: Input/output > error > > It doesn't seem to stop the program from running, but it's a little > annoying. > > Anyone know what it means? This was raised previously in following thread http://www.nabble.com/USRP-on-NetBSD-p1964955.html No fix has surfaced since then. cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] NetBSD
Everytime I run a (v3.0.2) gnuradio program (on NetBSD 3.1), I get the following message: usb_control_msg failed: error sending control message: Input/output error It doesn't seem to stop the program from running, but it's a little annoying. Anyone know what it means? Thanks, /jordan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] audio sampling rate problem after Ubuntu 6.06 downgrade...
Yep, that worked. Thanks! On 12/2/06, Berndt Josef Wulf <[EMAIL PROTECTED]> wrote: On Sunday 03 December 2006 06:26, Dave hartzell wrote: > After a failed attempt to upgrade to Ubuntu 6.10, I reformatted and > re-installed 6.06. I had heard of problems to 6.10 (broken X), but > didn't listen > > I'm back to normal (at least with Gnu Radio) and now I'm having an > audio card sample rate problem that was NOT there with my initial > install of 6.06. > > This can be fixed with the "-O plughw:0,0" runtime CLI option, but > anyone have any clues as to why this is required now? No hardware was > changed in the install process...maybe I should upgrade from the > on-board sound... G'day, You may want to create a directory such as mkdir ~/.gnuradio Then create a file called "config.conf" containing your default settings (below are those of mine): [audio] audio_module = audio_oss [audio_oss] default_input_device = /dev/audio default_output_device = /dev/audio latency = 0.005 This should do the trick. cheerio Berndt -- "Truth and technology will triumph over bullsh*t and bureaucracy!" - Rene Anselmo. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] audio sampling rate problem after Ubuntu 6.06 downgrade...
On Sunday 03 December 2006 06:26, Dave hartzell wrote: > After a failed attempt to upgrade to Ubuntu 6.10, I reformatted and > re-installed 6.06. I had heard of problems to 6.10 (broken X), but > didn't listen > > I'm back to normal (at least with Gnu Radio) and now I'm having an > audio card sample rate problem that was NOT there with my initial > install of 6.06. > > This can be fixed with the "-O plughw:0,0" runtime CLI option, but > anyone have any clues as to why this is required now? No hardware was > changed in the install process...maybe I should upgrade from the > on-board sound... G'day, You may want to create a directory such as mkdir ~/.gnuradio Then create a file called "config.conf" containing your default settings (below are those of mine): [audio] audio_module = audio_oss [audio_oss] default_input_device = /dev/audio default_output_device = /dev/audio latency = 0.005 This should do the trick. cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] audio sampling rate problem after Ubuntu 6.06 downgrade...
After a failed attempt to upgrade to Ubuntu 6.10, I reformatted and re-installed 6.06. I had heard of problems to 6.10 (broken X), but didn't listen I'm back to normal (at least with Gnu Radio) and now I'm having an audio card sample rate problem that was NOT there with my initial install of 6.06. This can be fixed with the "-O plughw:0,0" runtime CLI option, but anyone have any clues as to why this is required now? No hardware was changed in the install process...maybe I should upgrade from the on-board sound... Thanks, Dave ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fft sink x-axis units
On Fri, Dec 01, 2006 at 08:04:52PM -0500, Eric Hill Matlis wrote: > Thanks for the response. I guess my question is: where is that > information carried? Is it in the definition of the source? The > two definitions of the sinks look virtually identical to me: > > am_rcv.py: > pre_demod = fftsink.fft_sink_c (self, panel, > title="Pre-Demodulation", fft_size=1024, sample_rate=if_rate) > self.connect (src, pre_demod) > vbox.Add (pre_demod.win, 1, wx.EXPAND) > > usrp_wfm_rcv_pll.py: > self.src_fft = fftsink.fft_sink_c (self, self.panel, > title="Data from USRP",fft_size=512, sample_rate=usrp_rate) > self.connect (self.u, self.src_fft) > vbox.Add (self.src_fft.win, 4, wx.EXPAND) > > eric def update_status_bar (self): msg = "Volume:%r Setting:%s" % (self.vol, self.state) self._set_status_msg(msg, 1) self.src_fft.set_baseband_freq(self.freq) <<< LOOK HERE <<< ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
