Re: [Discuss-gnuradio] GnuRadio 3.1.1 and USRP on Fedora 8
On Tue, Feb 12, 2008 at 12:25:04PM -0800, Johnathan Corgan wrote: On 2/12/08, Ed Criscuolo [EMAIL PROTECTED] wrote: Has anyone else seen this? Can you confirm that you are in fact using a USB 2.0 controller? Your symptoms are consistent with what happens when you have USB 1.1. The enumeration is able to successfully occur, so you get the device, etc., but when the host tries to establish a high speed endpoint for data transfer, it fails. You can check this with: $ lsmod | grep ehci ehci_hcd 39117 0 ehci_hcd us the name of the USB 2.0 host driver ohci_hcd and uhci_hcd are the USB 1.1 host drivers. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Planning for the future
I'm currently doing some preliminary planning/budgeting for a significant project involving Gnu Radio: http://tech.groups.yahoo.com/group/sbrac-astronomy/ My current thinking is to run dual polarization at the feedpoint, using USRP2. The idea is that two USRP2s can live in a weatherproof enclosure at the feed, providing signals over GiGE to a pair of happy CPUs in the control room. Still lots of unknowns, but I want to know what I should aim for when I go seeking funding. I'm thinking that with quad-core systems becoming cheaper, perhaps a pair of quad-core signal processing engines (Q6600 or better), along with perhaps 2-4GB of memory on each system. Right now, I'm getting by with a Pentium D 925 doing just fine with 8Mhz input bandwidth driving a sampled spectral display, and a total power display. I wonder at what point the Gnu Radio stack will grow serious multi-threading capability (particularly in blocks like filters and FFTs), making multi-CPU systems a real bonus. I think I recall that the re-write of the signal chain plumbing was partially to make multi-threading easier, yes? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] libusrp installation problem
David - Sounds like libusb isn't in the DYLD load path, wasn't installed correctly, or wasn't part of the linking for libusrp. Can you reply with [off list is probably best; we can summarize results on- list if they're useful]: otool -L /usr/local/lib/libusrp.0.dylib as well as printenv from the shell in which you're running the application trying to access the USRP. - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP Audio Rate versus Sample Rate of Soundcard
Hello! I am current transmitting an audio stream from my sound card (SB Audigy2) to the USRP and it is transmitting at an FM frequency. The problem I am facing is that my sound card supports 44100Hz sample rate however, since the USRP audio rate is an integer factor of 128MS/s When I receive the signal on a regular FM radio it sounds funny depending on the audio rate I set (either sounds high pitched if i set audio rate to high or sounds low pitched and slow if I choose a lower sample rate). If I change the sample rate for the audio_source (sound card) it gives me an error that the sound card requests 44100Hz. I am including the lines I am using to rectrieve the audio data: self.fg = gr.flow_graph() src = audio.source(44100, options.audio_input) fmtx = blks.wfm_tx(self.fg, self.audio_rate, self.usrp_rate) self.fg.connect(src, fmtx, gain, self.u) Thank you for the previous help and Thanks for this one in advance. Omer -- This message was sent on behalf of [EMAIL PROTECTED] at openSubscriber.com http://www.opensubscriber.com/messages/discuss-gnuradio@gnu.org/topic.html ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] minimizing interference with usrp
2. Locate USRP as far as possible from electronic devices (is 5m really the maximum distance, or is there some other trick?) Juha, You might try using a USB media converter. This would make it possible to separate the USRP from the laptop by a much greater distance (cutting down on radiated noise). BB Electronics has them: http://www.bb-elec.com/product_family.asp?FamilyId=148 If you do get one, make sure it supports USB 2.0 ... many do not. --Jim Morash ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] minimizing interference with usrp
Matt Ettus wrote: Juha Vierinen wrote: Hi, I have been doing some radio astronomy experiments with USRP using a 30 MHz dipole antenna (actually it is more of a riometer experiment). I am running into various interference issues. E.g., at one point I noticed that if my laptop power supply is too close to my USRP I get switching power supply harmonics in my signal. At other times I have been pretty sure that the inteference comes through my antenna. I have found huge differences between laptop power supplies from the manufacturer of the laptop (like Lenovo, HP, etc.), and cheap replacement supplies made to look like the originals. Once I was testing something on the USRP while the computer was attached to one of these supplies and I saw a huge mess on the spectrum analyzer. I spent an hour trying to figure out what was happening, only to find that it was there even if there was no USRP hooked up at all -- it was all radiating from the power supply. If you really need low noise, run the laptop off of its internal battery only. What also works is running everything (laptop and USRP) from external batterypacks. The USRP needs 6V, which can be provided by 5 standard NiMH batteries in series (use large D-size cells or put several penlites in parallel) Alternatively you can use non-switching powersupplies. (Just use a LAB power-supply or build your own with a transformer, rectifier, big capacitor and linear regulator) More tips to get rid of RF spuriuos: Put ferrite beads around any power or digital cable. (mains power, DC power, USB, ethernet) Put everything in fully closed metal cases (powersupply, laptop, USRP) Make sure you don't run into heat problems this way. If you do run into heat problems, only use small round holes in the metal casings. 1000 small holes is much better then 10 big holes from a RF point of view. What also helps for laptops is to attach coppertape to the inside or outside of the full casing of the laptop. (We used this to get flatscreen TV's we developed CE complient) Take care this tape doesn't cause any shortcircuits. A low-budget solution is to use aluminium foil. Make sure you use high-quality coax cables for the RF-connections. Make sure to use high-quality USB cables with good shielding. Use a mains filter. Run the USRP powersupply from a different mains group as the laptop. Make sure your antenna is above a big metal plate (several wavelengths big) which is very well grounded. Make sure that your grounding is several meters into the ground well into the groundwaterlevel. Make sure that all digital equipment is below this metal plate If you are really desperate: Add extra 100 nF SMD capacitors between all powersuppply pins of every chip and ground (both USRP and laptop) Make a metal casing for the daughterboards. I hope this helps, Martin Dudok van Heel Matt ___ 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] GnuRadio 3.1.1 and USRP on Fedora 8
On Tue, Feb 12, 2008 at 04:30:00PM -0500, Ed Criscuolo wrote: Johnathan Corgan wrote: Can you confirm that you are in fact using a USB 2.0 controller? Your symptoms are consistent with what happens when you have USB 1.1. The enumeration is able to successfully occur, so you get the device, etc., but when the host tries to establish a high speed endpoint for data transfer, it fails. Arrrgh you hit the nail on the head! USBView reports that the built-in hub is Full-Speed, which is USB-speak for 1.1! Thanks. Any way the error reporting can be improved to explicitly indicate a 1.1 port? It's ticket:90. http://gnuradio.org/trac/ticket/90 It needs somebody willing to work on it. The fix is probably a new function in usrp_prims.cc that fishes out the bcdUSB field from the libusb usb_device_descriptor. See usrp_usrp_p for code that extracts info from the same descriptor. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GnuRadio 3.1.1 and USRP on Fedora 8
Johnathan Corgan wrote: Can you confirm that you are in fact using a USB 2.0 controller? Your symptoms are consistent with what happens when you have USB 1.1. The enumeration is able to successfully occur, so you get the device, etc., but when the host tries to establish a high speed endpoint for data transfer, it fails. Arrrgh you hit the nail on the head! USBView reports that the built-in hub is Full-Speed, which is USB-speak for 1.1! Thanks. Any way the error reporting can be improved to explicitly indicate a 1.1 port? @(^.^)@ Ed ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GnuRadio 3.1.1 and USRP on Fedora 8
On 2/12/08, Ed Criscuolo [EMAIL PROTECTED] wrote: Has anyone else seen this? Can you confirm that you are in fact using a USB 2.0 controller? Your symptoms are consistent with what happens when you have USB 1.1. The enumeration is able to successfully occur, so you get the device, etc., but when the host tries to establish a high speed endpoint for data transfer, it fails. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GnuRadio 3.1.1 and USRP on Fedora 8
After many successful Gnu Radio projects with GR 3.1.1 under both Fedora 4 and Fedora 6, I tried to install it on a Fedora 8 32-bit system, but am having a problem. The build was successful, 'make check' passed all tests, and the install was successful. The modification to the udev config worked, and an 'ls -lR /dev/bus/usb' showed a new dev file with permissions of 'crw-rw' and an owner/group of 'root/usrp' was created when the usrp was plugged in. Executing a 'groups' command under my user account shows I am in the 'usrp' group. Whenever I try to execute any app that uses the usrp as a receiver, such as test_usrp_standard_rx, or the usrp diagnostic in GRC, I get the error: usrp_open_interface::usb_claim_interface: failed interface 2 could not claim interface 2: No such file or directory The error even occurs when I run as root. The same thing happens when trying to use a transmitter, but the interface number changes to 1. I dug into the host-side usrp code, and found that the 'usb_claim_interface call (in usrp_prims.cc) occurs AFTER a successful call to usb_open, so it MUST be able to find the device, contrary to the error message. In fact, the only two error codes that usb_claim_interface can return are -EBUSY or -ENOMEM. Has anyone else seen this? Did something in the USB handling change for Fedora core 8? Could some automounter be grabbing the interface before me? Any help would be greatly appreciated! Here's my relevant version info: Gnu RadioRel 3.1.1 Fedora Core 8 kernel 2.6.23.14-115-fc8 libusb 0.1.12-10.fc8.i386 libusb-devel 0.1.12-10.fc8.i386 usrp Rev 4 (as reported by usbview) @(^.^)@ Ed ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Realtime scheduling with Linux kernel 2.6.24
Hello! To enable realtime scheduling the requesting process needs CAP_SYS_NICE. Until now this meat running as root (and probably dropping all other capabilities), either as root user, via a wrapper or with sudo [1]. running as root initially is not preferable, but probably the most used practice. With Linux kernel 2.6.24, file capabilities were enabled [2]. This means you can run your apps with predefined capabilities without unleashing the whole set powers at any time. I manged to run ping without suid bit, and to run a minimal GNU Radio script that simply enables realtime scheduling, but only with adding the cabability to the python interpreter. I did not manage to assign the CAP_SYS_NICE capability to a script and run it so that enablig realtime scheduling was successful. It seems that I got the capability inheritance wrong or maybe it is not working at all and scripts can not be granted capabilities. Did anyone have success until now with capabilities? I hope this will be working out, as it would get us rid of running scripts as root. Patrick [1] [EMAIL PROTECTED] http://thread.gmane.org/gmane.comp.gnu.radio.general/9789 [2] http://www.friedhoff.org/fscaps.html -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser patrick dot strasser at tugraz dot at Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] libusrp installation problem
All - I'm trying to set up libusrp on a G4 PowerBook under OS 10.5.1. We installed gnuradio 3.1.1 and installed all of the supporting packages with macports. When I try to access the USRP I get this: dyld: Symbol not found: _usb_error_str Referenced from: /usr/local/lib/libusrp.0.dylib Expected in: flat namespace Trace/BPT Any advice would be greatly appreciated. Or if anyone just has a set of libusrp binaries for this system, that would be great, too. Every new installation seems to take two full days, but this one has been particularly brutal. -- David David A. Burgess Kestrel Signal Processing, Inc. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
