Re: [Discuss-gnuradio] IRQ Conflicts
I wouldn't worry too much about trying to get the ehci_hcd it's owninterrupt. On one of my systems it shares with two gig-ethernet cardsand a video card with no porblem. --Thanks Eric. I feel safe now that I know its not a big issue :-) In PCI systems, IRQs are assigned by slot; try changing what slot theUSB2 card is in. --Mine is a non-pci system. Good suggestion though ! Thanks Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] interpolation and output level
Hello ppl, I understand that the interpolation factor changes the amplitudes of the signals. The default usrp_siggen.py works fine and I can admire 16mV and 100 K on the scope. But if I use the default intrp of 64 in the example usrp_siggen.py and try to change the amplitude levels using -a option, the signals still come down. Any guesses why ? Also, When I first boot my USRP and try an example, it fails for the first time. For instance, I tried tx_check.py and i had a runtime error. However, it works fine the second time. Is this because, it takes its time to load firmware into the FX2 and the FPGA or am I missing something here ? Any help is appreciated :-) Javs >This is also why most systems like this only allow power of 2 ratios.Quoting Matt Ettus <[EMAIL PROTECTED]>:> Quoting Chuck Swiger <[EMAIL PROTECTED]>:>> > Hi - Just curious whats the mechanism behind this: using a usrp xmit> > interpolation of 64 we get max signal level, and it drops off a lot if> > changed, say to> > 40 or 80. With interp=64, sample rate of 200, sig ampl of 6000, center> > at 14000e3 and freq of 72e3 my output is 3v peak (external amps).> > Change it to interp=80, sample rate of 160 it drops way down to .6v> peak> > (-14db). Try 50, 320 and get .5v peak out. Even stranger using> interp=60> > gets 2.7v peak but 68 it's down to .6v.>>> This happens both with the interpolator and decimator. It is due to a> simplification I made to save space in the FPGA. I will be fixing it in the> near future.>> Basically, if you interp/decimate by a power of 2 you get full amplitude> signals. If you use a non-power of 2, you will get lower amplitudes. Using> a> value just greater than a power of 2 will have the worst effect. A value> just> less than a power of 2 should be less noticeable. This is why 68 is so much> lower than 60 in your example above.>> Matt Do you Yahoo!? Make Yahoo! your home page ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] interpolation and output level
Hey Eric, I tried various values for the amplitude and looks like it works fine anywhere between 1 and 35000, giving me ~= 10mV and 35mV respectively. But anywhere below or beyond its behaving erratic. Is this the boundary ? And here is what I get when I boot my usrp and run the tx_check.py the first time. [EMAIL PROTECTED] usrp]$ ./tx_check.py usrp: found usrp rev2 usrp_open_interface: usb_claim_interface: failed conf 0 could not set config 1: Operation not permitted open_nth_cmd_interface: open_cmd_interface failed Traceback (most recent call last): File "./tx_check.py", line 78, in ? main () File "./tx_check.py", line 70, in main sg = siggen () File "./tx_check.py", line 17, in __init__ self._instantiate_blocks () File "./tx_check.py", line 53, in _instantiate_blocks self.usrp = usrp.sink_c (0, self.interp) File "/usr/local/lib/python2.3/site-packages/gnuradio/usrp1.py", line 692, in sink_c return _usrp1.sink_c(*args) RuntimeError: std::runtime_error - Thanks for looking into it. Javs --- Eric Blossom <[EMAIL PROTECTED]> wrote: > On Fri, Mar 18, 2005 at 02:05:24PM -0800, Javs > wrote: > > > > Hello ppl, > > > > > I understand that the interpolation factor changes > the amplitudes of > > the signals. The default usrp_siggen.py works fine > and I can admire > > 16mV and 100 K on the scope. But if I use the > default intrp of 64 in > > the example usrp_siggen.py and try to change the > amplitude levels > > using -a option, the signals still come down. Any > guesses why ? > > What value's are you trying with the -a option? > Keep them <= 16000. > > > Also, When I first boot my USRP and try an > example, it fails for the > > first time. For instance, I tried tx_check.py and > i had a runtime > > error. However, it works fine the second time. Is > this because, it > > takes its time to load firmware into the FX2 and > the FPGA or am I > > missing something here ? > > What's the error? > > Eric > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] interpolation and output level + missing Tx_check
Greetings, I updated my code from CVS yesterday and the tx_check.py was missing in the gnuradio-examples. Was this removed ? I am still wresting with the issues below. This time I tried usrp_siggen.py and it fails the first time giving: [EMAIL PROTECTED] usrp]$ ./usrp_siggen.py usrp: found usrp rev2 usrp_open_interface: usb_claim_interface: failed conf 0 could not set config 1: Operation not permitted open_nth_cmd_interface: open_cmd_interface failed Traceback (most recent call last): File "./usrp_siggen.py", line 144, in ? main () File "./usrp_siggen.py", line 128, in main sg = siggen () File "./usrp_siggen.py", line 21, in __init__ self._instantiate_blocks () File "./usrp_siggen.py", line 68, in _instantiate_blocks self.usrp = usrp.sink_c (0, self.interp) File "/usr/local/lib/python2.3/site-packages/gnuradio/usrp1.py", line 740, in sink_c return _usrp1.sink_c(*args) RuntimeError: std::runtime_error --- Any suggestions ? Thanks in advance. Javs --- Javs <[EMAIL PROTECTED]> wrote: > Hey Eric, > > I tried various values for the amplitude and looks > like it works fine anywhere between 1 and > 35000, > giving me ~= 10mV and 35mV respectively. But > anywhere > below or beyond its behaving erratic. Is this the > boundary ? > > And here is what I get when I boot my usrp and run > the > tx_check.py the first time. > > [EMAIL PROTECTED] usrp]$ ./tx_check.py usrp: found usrp > rev2 > usrp_open_interface: usb_claim_interface: failed > conf > 0 > could not set config 1: Operation not permitted > open_nth_cmd_interface: open_cmd_interface failed > Traceback (most recent call last): > File "./tx_check.py", line 78, in ? > main () > File "./tx_check.py", line 70, in main > sg = siggen () > File "./tx_check.py", line 17, in __init__ > self._instantiate_blocks () > File "./tx_check.py", line 53, in > _instantiate_blocks > self.usrp = usrp.sink_c (0, self.interp) > File > "/usr/local/lib/python2.3/site-packages/gnuradio/usrp1.py", > line 692, in sink_c > return _usrp1.sink_c(*args) > RuntimeError: std::runtime_error > > - > > Thanks for looking into it. > > Javs > > --- Eric Blossom <[EMAIL PROTECTED]> wrote: > > On Fri, Mar 18, 2005 at 02:05:24PM -0800, Javs > > wrote: > > > > > > Hello ppl, > > > > > > > > I understand that the interpolation factor > changes > > the amplitudes of > > > the signals. The default usrp_siggen.py works > fine > > and I can admire > > > 16mV and 100 K on the scope. But if I use the > > default intrp of 64 in > > > the example usrp_siggen.py and try to change the > > amplitude levels > > > using -a option, the signals still come down. > Any > > guesses why ? > > > > What value's are you trying with the -a option? > > Keep them <= 16000. > > > > > Also, When I first boot my USRP and try an > > example, it fails for the > > > first time. For instance, I tried tx_check.py > and > > i had a runtime > > > error. However, it works fine the second time. > Is > > this because, it > > > takes its time to load firmware into the FX2 and > > the FPGA or am I > > > missing something here ? > > > > What's the error? > > > > Eric > > > > __ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam > protection around > http://mail.yahoo.com > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: interpolation and output level + missing Tx_check
Note: forwarded message attached. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- Begin Message --- Sure. I am running Redhat 4.0 on a linux machine with a VIA EBC-C3 733MHz MMX compatible processor and 512MB of PCI133 SDRAM. I added a USB 2.0 host controller(NEC uPD720101) over the existing slow USB. Other Features: VIA 733 MHz low power C3 processor EBX-compliant board - 32 to 512MB of system PC133 SDRAM supported in a 168-pin DIMM socket - Socket for up to 1GB bootable DiskOnChip® or 512KB SRAM or 1MB EPROM - Type I and II Compact Flash (CF) cards supported - PC-compatible supports Linux,Windows CE.NET and XPe, plus other x86-compatible RTOS - High resolution video controller supports - Color panels supported with up to 36-bits/pixel - Supports resolutions up to 1920 x 1440 - Simultaneous CRT and LCD operation - 4X AGP local bus for high speed operation - LVDS supported - Dual 10/100 Mbps Intel PCI Ethernet controllers - 4 RS-232 serial ports with FIFO, COM1 & COM2 with RS-422/485 support - Bi-directional LPT port supports EPP/ECP - 48 bi-directional TTL digital I/O lines with 24 capable of event sense interrupt generation - Four USB ports onboard - Two, dual Ultra DMA 33/66/100 EIDE connectors - Floppy disk controller supports 1 or 2 drives - AC97 Audio supported - PC/104 and PC/104-Plus expansion connectors - AT keyboard controller and PS/2 mouse support - Activity LEDs onboard for visual status - Two interrupt controllers and 7 DMA channels - Three, 16-bit counter/timers - +5 volt only operation - Upgrade for WinSystems' EBC-LP and EBC-BX - Real Time Clock,WDT and power fail reset - Small size: 5.75" x 8.0" (146 mm x 203 mm) Thanks Javs Eric Blossom <[EMAIL PROTECTED]> wrote: On Tue, Mar 22, 2005 at 07:04:13AM -0800, Javs wrote:> Greetings,> > I updated my code from CVS yesterday and the> tx_check.py was missing in the gnuradio-examples. Was> this removed ? Yep. Try usrp_siggen.py instead.> I am still wresting with the issues below. This time I> tried usrp_siggen.py and it fails the first time> giving: > > [EMAIL PROTECTED] usrp]$ ./usrp_siggen.py> usrp: found usrp rev2> usrp_open_interface: usb_claim_interface: failed conf> 0> could not set config 1: Operation not permitted> open_nth_cmd_interface: open_cmd_interface failed> Traceback (most recent call last):> File "./usrp_siggen.py", line 144, in ?> main ()> File "./usrp_siggen.py", line 128, in main> sg = siggen ()> File "./usrp_siggen.py", line 21, in __init__> self._instantiate_blocks ()> File "./usrp_siggen.py", line 68, in> _instantiate_blocks> self.usrp = usrp.sink_c (0, self.interp)> File> "/usr/local/lib/python2.3/site-packages/gnuradio/usrp1.py",> line 740, in sink_c> return _usrp1.sink_c(*args)> RuntimeError: std::runtime_error> > ---> > Any suggestions ? > > Thanks in advance.> > JavsCan you please provide additional platform info such as:OS, version, distribution, hardware architecture, etc.Eric__Do You Yahoo!?Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- End Message --- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Where do Gnuradio and USRP meet?
Hey all, I was looking at the build codes(.h, .cc., .c, .i, .py) for the USRP and the Gnuradio Docs seperately and I am not sure where exactly these two meet. I was guessing that the fusb would be calling both the headers from usrp and gnuradio, but doesn't seem like it. Can anyone please point me to core files in which one calls the other. Thanks. Javs Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP heating up !
Dear all, The Analog Device chips on my USRP (and to some extent the FPGA) seem to be heating more than usual now. On a touch basis, I observed that they are much heated (burning sensation) than they were before. I've been using it for about 40 days now. I haven't done anything unusual with it. However, it seems to be running the software perfectly the way it should. Am I the only one who is experiencing this ? I am thinking of a fan to cool the chips to avoid burning them. Any suggestions ? Thanks, Javs Do you Yahoo!? Better first dates. More second dates. Yahoo! Personals ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP heating up !
Matt, I tried the following and observed this: >During normal operation, the AD chips can get pretty warm. Try >this: >1 - Take off all daughterboards. >2 - Plug in the the USRP. Do not run any software. Leave it for a >few minutes. > Every chip other than the power supply on there should be at room temp. The LED should be flashing about 2-3 times per second. Power supply and the Cypress chip(?) are a little higher than room temperature. LED at 3Hz. >3 - Run some of the examples, and quit them normally (no ctrl-C). >A few minutes later the FPGA and AD chips should be back to room >temp. The LED should be flashing slower. FPGA is warm. AD chips get warmer and so does the cypress chip. LED at 1hz. And they do NOT get back to normal temp. >4 - Run a receive program (like usrp_fft). After a few minutes, >the AD chip should be just slightly warm. Yes it is ! >5 - Leave the receive program running. In another window start up >a transmit program (like usrp_siggen). The codec chips should get >pretty hot, but not painfully hot. The FPGA should only show the >slightest hint of warmness. At this stage when I run simultaneous Tx (siggen) and Rx (usrp_fft) programs, the Codecs get pretty hot. To the extent that I cannot lay my fingure and rest it for about 3-5 secs (burning sensation). The FPGA is slightly warm and the FX2 stays somewhere between the codecs and FPGA. >6 - Quit the receive program. The chips shoul get much cooler now. >7 - quit the transmit program. Everything should return to room >temp. The temperature drops down a bit, but still hot(definitely NOT at room temperature). I am concerned if there are any hidden processes going on in the codecs even after I close the programs which are causing this heat? I understand that I am not using specific numbers to pinpoint the degree of heat, but I hope I gave the picture. Thanks in advance. Javs Do you Yahoo!? Make Yahoo! your home page ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP heating up !
Thanks Eric. Looking forward for the code. JavsEric Blossom <[EMAIL PROTECTED]> wrote: Hi Javs,Thanks for all the data.I've made a bunch of power measurements and Matt and I have beendiscussing some ways to ameliorate the problem. I expect to have afew of them coded up over the next couple of days.Eric__Do You Yahoo!?Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP seems to work...but
Hey Achilleas, > Also, wfm_rcv.py and wfm_rcv_gui.py > seem to be different in the way they access the RF > front end: > the former does it explicitely (and gives me errors) > while the latter has this part commented out. I believe that part in latter code was commented out because wfm_rcv_gui.py does not require the RF front end. You should be able to listen to FM with a SMA connector and a piece of wire. Also, try to connect the Rx on the 'A' side with your basic Rx daughter board. It is just an example and would work only on the basic A Rx brd side. Check the old post at http://lists.gnu.org/archive/html/discuss-gnuradio/2005-02/msg00313.html Good luck - Javs __ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP heating up !
Hi all, I tried the experiment again today and I think I answered my question. I first ran the am_rcv.py example which pops a GUI, a very tiny one since the pre_demod, post_demod and post_filt blocks were commented. And this was hiding on the top left corner of my screen (I missed it). Assuming, there was no GUI for this code, I used Cntrl C to kill it. Although I wrongly assumed it was ended it actually was not destroyed and was running its internal processes, thereby heating the codecs. I think the way the 'Destroy' destructor for the GUI's is written is applicable only if we gracefully exit the GUI (i.e. through File->exit on the GUI). It seems to me that Cntrl C does not totally kill the internal processes in the codecs and they continuosly receive the power. Lesson learnt : Avoid using Cntrl C to close your GUI's. I still am not sure of one thing though. When I run the example 'wfm_rcv_gui.py' with my basic d'board on the A side, the codec on the B side heats up. It seems like when I receive on A side the Codec on the other side has no job . If this is true, I think a better way to cut power to the unused codec would be to use the 'which_side' logic. Or this is probably what Eric was inkling at when he mentioned about ways to ameliorate the problem. Thanks for all your help. Javs --- Eric Blossom <[EMAIL PROTECTED]> wrote: > On Mon, Apr 11, 2005 at 10:38:39PM -0700, Eric > Blossom wrote: > > > > I've made a bunch of power measurements and Matt > and I have been > > discussing some ways to ameliorate the problem. I > expect to have a > > few of them coded up over the next couple of days. > > Following up on my own post, I wanted to make clear > that the power > measurements I made indicate that the power > consumption is within > spec. We've been talking about ways to lower the > power consumption by > turning off parts of the AD9862 when they are not > required. > > Eric > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP MUX questions
> According to usrp_wfm_gui.py the correct MUX seting > for listening to > FM is0x f0 f0 f0 f2. Could you please point me to this file ? Im not able to locate it in my code. Or did you mean wfm_rcv_gui.py ? Javs __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP MUX questions
I am a new user to this group and I am beginning to understanding the bridge between the software and usrp. Let me attempt to answer atleast on of your questions here. The gurus can correct me if I am wrong :-) > Are the connections from the daughterboards to the > ADC's > hardwired in the USRP the way it is shown in the > figure, > ie, RX-A to ADC-0, RX-B to ADC-1 and the IF output > of the > TV-RX to both ADC-2 and ADC-3 ? I think this is the default wiring: RxA (Jumper 19 )-ADC 0 RxB (Jumper 18 )-ADC 1 TvRx-Real - ADC 2 TvRx-Imaginary-ADC 3 However,you can change these setting using software muxes documented in usrp_standard.h and usrp_basic.h >Why is there a need for 4 DDC implemented in the FPGA? I was thinking about it for some time too. But in a different way. Why not use four DDC's (real A, cmplx A, real B,cmplx B)with just one input and one output? Haven't delved deeply into it but i think the answer lies in the architecture of the AD9862, or the way the FPGA code was designed. Quoting Matt here: "The way the USRP FPGA code is designed, samples sent over the USB bus are always complex. This is not inconsistent with using real samples on the IF, since you downconvert to 0 IF in the FPGA, and so you need both I and Q." > According to usrp_wfm_gui.py the correct MUX seting > for listening to > FM is0x f0 f0 f0 f2. > To start with, why are we zeroing all Q > channels? If this is done then we should be getting > always a complex number with zero imaginary part... Thats the intention. To receive only the real samples and provide a zero for all the imaginary samples. HTH, Javs __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] mt4937di5.sym was not found in any component library
Hi all, I just downloaded the TvRx schematics and layouts and am using the gEDA rpms for Fedora Core 3 on my new 64 bit AMD machine. I am using gschem to read the schematic of the tvrx.sch. The schematic pops up with the following status: - gEDA/gschem version 20050313 gEDA/gschem comes with ABSOLUTELY NO WARRANTY; see COPYING for more details. This is free software, and you are welcome to redistribute it under certain conditions; please see the COPYING file for more details. Read system-gafrc file [/usr/share/gEDA/system-gafrc] Did not find optional ~/.gEDA/gafrc file [/home/tester/.gEDA] Did not find optional local gafrc file [/home/tester/USRP_download/tvrx/gafrc] Read system-gschemrc file [/usr/share/gEDA/system-gschemrc] Did not find optional ~/.gEDA/gschemrc file [/home/tester/.gEDA] Read local gschemrc file [/home/tester/USRP_download/tvrx/gschemrc] Read init scm file [/usr/share/gEDA/scheme/gschem.scm] Did not find specified /home/tester/USRP_download/tvrx/gafrc file [/home/tester/USRP_download/tvrx/gafrc] Read an old format sym/sch file! Please run g[sym|sch]update on: [/home/tester/USRP_download/sym/pmc64.sym] Component [mt4937di5.sym] was not found in any component library Component library was not found or specified Component [nmos-sot23.sym] was not found in any component library Component library was not found or specified Component [nmos-sot23.sym] was not found in any component library Component library was not found or specified WARNING: Symbol version mismatch on refdes U4 (dual-opamp-1.sym): Symbol in library is newer than instantiated symbol Minor version change (file 0.100, instantiated 0.000) WARNING: Symbol version mismatch on refdes U4 (dual-opamp-1.sym): Symbol in library is newer than instantiated symbol Minor version change (file 0.100, instantiated 0.000) Component [lm2940imp.sym] was not found in any component library Component library was not found or specified Opened file [/home/tester/USRP_download/tvrx/tvrx.sch] I did not create the .gEDA in my home and the missing of optional rc files make sense to me but the other warnings are much of a bother. I linked the elements-dir in the tvrx.prj file to the in my usr/share/pcb/newlib. When that gave me the same error message I linked to the USRP_download/pkg/newlib/ created by matt. It didn't work either. Two things Im not sure about. 1. Did not find specified /home/tester/USRP_download/tvrx/gafrc file [/home/tester/USRP_download/tvrx/gafrc]. Do i need a gafrc file here in the first place if i have gschemrc and gnetlistrc with path to the component libraries ? If so, who is specifying this gafrc file ? 2. Missing components: mt4937di5.sym, nmos-sot23.sym. I did not find any of these symbols in the downloaded 'sym' directory. I created the symbols with the sources using the 'make_symbols' file. There is a mt4936py5.sym however and no trace of nmos-sot.sym. Do i have to create these symbols or am I missing something blatantly obvious here? Thanks in advance. Javs __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] mt4937di5.sym was not found in any component library
Following up on my own post: I created a gafrc file in the tvrx directory linking it to all the symbols. And I got rid of the first error. Still baffled about the missing components... Javs --- Javs <[EMAIL PROTECTED]> wrote: > Hi all, > > I just downloaded the TvRx schematics and layouts > and > am using the gEDA rpms for Fedora Core 3 on my new > 64 > bit AMD machine. > > I am using gschem to read the schematic of the > tvrx.sch. The schematic pops up with the following > status: > > - > gEDA/gschem version 20050313 > gEDA/gschem comes with ABSOLUTELY NO WARRANTY; see > COPYING for more details. > This is free software, and you are welcome to > redistribute it under certain > conditions; please see the COPYING file for more > details. > > Read system-gafrc file > [/usr/share/gEDA/system-gafrc] > Did not find optional ~/.gEDA/gafrc file > [/home/tester/.gEDA] > Did not find optional local gafrc file > [/home/tester/USRP_download/tvrx/gafrc] > Read system-gschemrc file > [/usr/share/gEDA/system-gschemrc] > Did not find optional ~/.gEDA/gschemrc file > [/home/tester/.gEDA] > Read local gschemrc file > [/home/tester/USRP_download/tvrx/gschemrc] > Read init scm file > [/usr/share/gEDA/scheme/gschem.scm] > Did not find specified > /home/tester/USRP_download/tvrx/gafrc file > [/home/tester/USRP_download/tvrx/gafrc] > Read an old format sym/sch file! > Please run g[sym|sch]update on: > [/home/tester/USRP_download/sym/pmc64.sym] > Component [mt4937di5.sym] was not found in any > component library > Component library was not found or specified > Component [nmos-sot23.sym] was not found in any > component library > Component library was not found or specified > Component [nmos-sot23.sym] was not found in any > component library > Component library was not found or specified > WARNING: Symbol version mismatch on refdes U4 > (dual-opamp-1.sym): > Symbol in library is newer than instantiated symbol > Minor version change (file 0.100, instantiated > 0.000) > WARNING: Symbol version mismatch on refdes U4 > (dual-opamp-1.sym): > Symbol in library is newer than instantiated symbol > Minor version change (file 0.100, instantiated > 0.000) > Component [lm2940imp.sym] was not found in any > component library > Component library was not found or specified > Opened file > [/home/tester/USRP_download/tvrx/tvrx.sch] > > > > I did not create the .gEDA in my home and the > missing > of optional rc files make sense to me but the other > warnings are much of a bother. > > I linked the elements-dir in the tvrx.prj file to > the > in my usr/share/pcb/newlib. When that gave me the > same > error message I linked to the > USRP_download/pkg/newlib/ created by matt. It didn't > work either. > > Two things Im not sure about. > 1. Did not find specified > /home/tester/USRP_download/tvrx/gafrc file > [/home/tester/USRP_download/tvrx/gafrc]. Do i need a > gafrc file here in the first place if i have > gschemrc > and gnetlistrc with path to the component libraries > ? > If so, who is specifying this gafrc file ? > > 2. Missing components: mt4937di5.sym, > nmos-sot23.sym. > I did not find any of these symbols in the > downloaded > 'sym' directory. I created the symbols with the > sources using the 'make_symbols' file. There is a > mt4936py5.sym however and no trace of nmos-sot.sym. > Do > i have to create these symbols or am I missing > something blatantly obvious here? > > Thanks in advance. > > Javs > > > __ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam > protection around > http://mail.yahoo.com > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] mt4937di5.sym was not found in any component library
Thanks Matt ! Looks perfect now. Javs --- Matt Ettus <[EMAIL PROTECTED]> wrote: > > I have put the updated parts package on the download > page at ettus.com You can > find all the parts you need there. > > Matt > > > Quoting Javs <[EMAIL PROTECTED]>: > > > Following up on my own post: > > > > I created a gafrc file in the tvrx directory > linking > > it to all the symbols. And I got rid of the first > > error. > > > > Still baffled about the missing components... > > > > Javs > > > > --- Javs <[EMAIL PROTECTED]> wrote: > > > Hi all, > > > > > > I just downloaded the TvRx schematics and > layouts > > > and > > > am using the gEDA rpms for Fedora Core 3 on my > new > > > 64 > > > bit AMD machine. > > > > > > I am using gschem to read the schematic of the > > > tvrx.sch. The schematic pops up with the > following > > > status: > > > > > > - > > > gEDA/gschem version 20050313 > > > gEDA/gschem comes with ABSOLUTELY NO WARRANTY; > see > > > COPYING for more details. > > > This is free software, and you are welcome to > > > redistribute it under certain > > > conditions; please see the COPYING file for more > > > details. > > > > > > Read system-gafrc file > > > [/usr/share/gEDA/system-gafrc] > > > Did not find optional ~/.gEDA/gafrc file > > > [/home/tester/.gEDA] > > > Did not find optional local gafrc file > > > [/home/tester/USRP_download/tvrx/gafrc] > > > Read system-gschemrc file > > > [/usr/share/gEDA/system-gschemrc] > > > Did not find optional ~/.gEDA/gschemrc file > > > [/home/tester/.gEDA] > > > Read local gschemrc file > > > [/home/tester/USRP_download/tvrx/gschemrc] > > > Read init scm file > > > [/usr/share/gEDA/scheme/gschem.scm] > > > Did not find specified > > > /home/tester/USRP_download/tvrx/gafrc file > > > [/home/tester/USRP_download/tvrx/gafrc] > > > Read an old format sym/sch file! > > > Please run g[sym|sch]update on: > > > [/home/tester/USRP_download/sym/pmc64.sym] > > > Component [mt4937di5.sym] was not found in any > > > component library > > > Component library was not found or specified > > > Component [nmos-sot23.sym] was not found in any > > > component library > > > Component library was not found or specified > > > Component [nmos-sot23.sym] was not found in any > > > component library > > > Component library was not found or specified > > > WARNING: Symbol version mismatch on refdes U4 > > > (dual-opamp-1.sym): > > > Symbol in library is newer than instantiated > symbol > > > Minor version change (file 0.100, instantiated > > > 0.000) > > > WARNING: Symbol version mismatch on refdes U4 > > > (dual-opamp-1.sym): > > > Symbol in library is newer than instantiated > symbol > > > Minor version change (file 0.100, instantiated > > > 0.000) > > > Component [lm2940imp.sym] was not found in any > > > component library > > > Component library was not found or specified > > > Opened file > > > [/home/tester/USRP_download/tvrx/tvrx.sch] > > > > > > > > > > > > I did not create the .gEDA in my home and the > > > missing > > > of optional rc files make sense to me but the > other > > > warnings are much of a bother. > > > > > > I linked the elements-dir in the tvrx.prj file > to > > > the > > > in my usr/share/pcb/newlib. When that gave me > the > > > same > > > error message I linked to the > > > USRP_download/pkg/newlib/ created by matt. It > didn't > > > work either. > > > > > > Two things Im not sure about. > > > 1. Did not find specified > > > /home/tester/USRP_download/tvrx/gafrc file > > > [/home/tester/USRP_download/tvrx/gafrc]. Do i > need a > > > gafrc file here in the first place if i have > > > gschemrc > > > and gnetlistrc with path to the component > libraries > > > ? > > > If so, who is specifying this gafrc file ? > > > > > > 2. Missing components: mt4937di5.sym, > > > nmos-sot23.sym. > > > I did not find any of these symbols in the > > > downloaded > > > 'sym' directory. I created
Re: [Discuss-gnuradio] how to pronounce gnuradio?
Eric had already answered this, but I thought to add
another pointer from the old GNU's bulletin.
Clip - "Specifically, we are putting together a
complete, integrated software system named "GNU"
("GNU's Not Unix", pronounced "guh-new") that will be
upwardly compatible with Unix."
http://www.cs.utah.edu/dept/old/texinfo/gnu-bull-jun-94.html
-Javs
--- Clark Pope <[EMAIL PROTECTED]> wrote:
> Dumb question: is it ga-new-radio or new-radio, i.e.
> is the g silent?
>
> Thanks,
> Clark
>
>
_
> Express yourself instantly with MSN Messenger!
> Download today - it's FREE!
>
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
>
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
__
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] usb_claim_interface error
Group, I am having problems to establish the initial communication with the USRP with any example in the code. The first time I run any code (test_usrp_standard_tx in this case), it fails giving me the following error : --- [EMAIL PROTECTED] apps]$ ./test_usrp_standard_tx en_interface: usb_claim_interface: failed conf 0 could not set config 1: Operation not permitted open_nth_cmd_interface: open_cmd_interface failed die: lt-test_usrp_standard_tx: usrp_standard_tx::make --- However, the second time I run the same code, it runs perfectly. Same is the case with any of the examples. I tried a few random experiments to figure out where exactly the problem is : 1.I removed the power cable and reconnected it(USB remains plugged, at this point LED is at faster rate). Then if i try the "test_usrp_standard_tx", it gives me the above error (now LED slown down). After the LED slows down, things are normal. the slowing down of LED is a sign that the firmware is loaded, but my concern is why does it not execute the code ? 2. Now when things are normal, this time I removed the USB and replugged to usrp(power remains plugged and LED remains at slower rate). "test_usrp_standard_tx" will run now with no errors. I guess this time it remembered the USB association as the eeprom was alive with power. 3. Following upon the usrp install doc, I tried to reconnect the power and usb and this time tryin the same code as root. Works fine with no errors. So looked to me like its a USB permissions error for other users. I then checked the 'usrp' and 'usrp.usermap' files at stc/hotplug/usb. They seem to be intact as described in http://comsec.com/wiki?UsrpInstall The 'usbview' positively recognises the USB connect as a 'unknown' device when plugged in ;and as a 'USRP Rev 2' when the code is run the first time. I checked my 'fstab' file (attached) and added the following line --- /mnt/usb /proc/bus/USB usbfs defaults0 0 --- I suspect this to be the culprit and i am investigating more on this. Javs __ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/LABEL=/1/ ext2 defaults1 1 LABEL=/boot1/boot ext3 defaults1 2 none/dev/ptsdevpts gid=5,mode=620 0 0 none/dev/shmtmpfs defaults0 0 LABEL=/home /home ext3 defaults1 2 LABEL=/opt /optext3 defaults1 2 none/proc proc defaults0 0 none/syssysfs defaults0 0 LABEL=/usr /usrext3 defaults1 2 LABEL=/var /varext3 defaults1 2 LABEL=SWAP-hda5 swapswap defaults0 0 /mnt/usb/proc/bus/USB usbfs defaults0 0 /dev/hdb/media/cdromauto pamconsole,exec,noauto,managed 0 0 /dev/fd0/media/floppy auto pamconsole,exec,noauto,managed 0 0___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usb_claim_interface error
> What distribution and version of linux are you > running, with which kernel? I am running the Redhat enterprise linux 4 on a 2.6.9 kernel. Tried chmoding all subdirectories and files under /proc/bus/usb. Still doesn't work. __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usb_claim_interface error
> No clue. Is there anything interesting in the > kernel logs? Nothing going on in the logs when i run the code. But the usb allocates a new address to the usb (old adress+1) upon reconnecting the power cable. Here are a few more observations i made: When i do a 'lsusb' upon system restart, I get the usrp on Bus 1 and device 2 after i force the bitstream. Now, when i disconnect and reconnect the power, the device changes to 3 with default permissions of '-rw-rw-r--' and the device address increments upon further reconnects. As a test, here i forced the bitstream (so that the examples work) and then changed the permission by 'chmod 000 -R /proc/bus/usb/001/*'. After this, no usrp found as expected. Changed back to 'chmod 777 -R /proc/bus/usb/001/*' and it works again. So, look like it does not stabilize on the device address after power reconnect. The changing of permissions (777) is not effected as it is creating a new mount with a new address at each reconnect with default permissions(664). Still experimenting ! -Javs __ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usb_claim_interface error
I found the permissions error in my strace when i run
the 'test_usrp_standard_tx'. Similar error was
previously observed by Larry, but I am not sure if
this was solved. I don't have the usbtest loaded.
Also, i observe that when i run any code the first
time as 'root', the other LED (LED1) glows for a
second or two and shuts off. This does not happen when
i do the same test as 'user'. Is this related to the
USB access?
Still trying to figure out whats going on.
Anyway, Here is the clip of the strace, very similar
to the one from Larry.
Javs
clip:
--
getdents64(3, /* 0 entries */, 4096)= 0
close(3)= 0
access("/usr/local/share/usrp/rev2/usrp_fpga.rbf",
R_OK) = 0
open("/proc/bus/usb/001/060", O_RDWR) = -1 EACCES
(Permission denied)
open("/proc/bus/usb/001/060", O_RDONLY) = 3
ioctl(3, USBDEVFS_SETCONFIGURATION, 0xbfffacd4) = -1
EPERM (Operation not permitted)
write(2, "usrp_open_interface: usb_claim_i"...,
56usrp_open_interface: usb_claim_interface: failed
conf 0
) = 56
write(2, "could not set config 1: Operatio"...,
48could not set config 1: Operation not permitted
) = 48
close(3)= 0
write(2, "open_nth_cmd_interface: open_cmd"...,
50open_nth_cmd_interface: open_cmd_interface failed
) = 50
write(2, "die: lt-test_usrp_standard_tx: u"..., 54die:
lt-test_usrp_standard_tx: usrp_standard_tx::make
) = 54
exit_group(1) = ?
---
--- Eric Blossom <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 18, 2005 at 07:11:21AM -0700, Javs
> wrote:
> >
> > > What distribution and version of linux are you
> > > running, with which kernel?
> >
> > I am running the Redhat enterprise linux 4 on a
> 2.6.9
> > kernel.
> >
> > Tried chmoding all subdirectories and files under
> > /proc/bus/usb. Still doesn't work.
> >
>
> No clue. Is there anything interesting in the
> kernel logs?
>
> Eric
>
__
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] setgid directories / usb permissions
Me too. I created a new mount point at /proc/bus/usb
with usbfs for a regular 'user'account and now I am
able to talk to the usrp with the very first command.
Ahh..such a relief ! Thanks for all your pointers.
Javs
--- Eric Blossom <[EMAIL PROTECTED]> wrote:
> On Fri, Oct 28, 2005 at 10:01:42AM -0600,
> Robitaille, Michael wrote:
> > Finally got GNU Radio compiled and working with
> the USRP so I am out of the
> > wood for now.
>
> Great!
>
> > I installed it in the 'standard' location,
> unfortunately I could do that
> > only as the root and I can only run GnuRadio as
> root. I can't even use
> > 'sudo' to run usrp_oscope.py.
>
> Please remind me which distribution you're using.
> FC4?
>
> Generally speaking, having to run as root reflects a
> permission problem
> on /proc/bus/usb/ and files below. The fix is
> distribution
> dependent. I've generally had success by adding
> myself to group "usb"
> and then making sure that "usb" was the group for
> all those files.
> The stuff under /proc/bus/usb is created by the
> usbfs kernel module,
> and there are mount time options that set the gid
> and perms for those
> files. Look under /etc/rc.d and find out where
> usbfs is mounted.
>
> [EMAIL PROTECTED] init.d]$ grep usbfs *
> usb:action "Mount USB filesystem" mount -t
> usbfs -o devmode=0664,devgid=43 none /proc/bus/usb
>
> [EMAIL PROTECTED] eb]$ grep 43 /etc/group
> usb:x:43:eb
>
> The magic usbfs mount options are defined in the
> kernel source in
> linux/drivers/usb/core/inode.c (Yes, I know you
> shouldn't have to
> look at kernel source to figure this stuff out, but
> hey, at least we
> *do* have the source available.)
>
> static match_table_t tokens = {
> {Opt_devuid, "devuid=%u"},
> {Opt_devgid, "devgid=%u"},
> {Opt_devmode, "devmode=%o"},
> {Opt_busuid, "busuid=%u"},
> {Opt_busgid, "busgid=%u"},
> {Opt_busmode, "busmode=%o"},
> {Opt_listuid, "listuid=%u"},
> {Opt_listgid, "listgid=%u"},
> {Opt_listmode, "listmode=%o"},
> {Opt_err, NULL}
> };
>
> They probably ought to be documented in
> linux/Documentation/filesystems
> along with the rest of the filesystems and have a
> man page.
>
>
> > Eric wrote:
> > > > Depends on your setup. I don't install with
> sudo (being generally
> > > > paranoid), and have arranged things so that
> I'm in a group that has
> > > > write access to everything under /usr/local.
> Judicious use of
> > >
> > > > chmod g+s on directories under there is
> useful.
> >
> > > Shell programming 101:
> >
> > > $ find /usr/local/ -type d -print0 | xargs -0
> chgrp
> > > $ find /usr/local/ -type d -print0 | xargs -0
> chmod g+rwxs
> >
> > > Figuring out what the setgid bit on a directory
> does is left as an
> > exercise ;)
> >
> > Sid not - exercise;
> >
> > Per my old Unix book;
> >
> > Unless the set group ID (sgid) permission of an
> executable file are set, the
> > process created is assigned your uid and gid at
> its real and effective uid
> > and real and effective gid, respectively. File
> access for a process is
> > determined by its effective uid and effective gid.
>
> Note that we are setting the setgid bit on a
> directory, *not* a
> regular file. What it does is ensure that all files
> and directories
> created in the that directory have their group set
> to the group of
> parent directory.
>
>
> Here's what my setup looks like:
>
> [EMAIL PROTECTED] eb]$ id
> uid=502(eb) gid=502(eb)
> groups=10(wheel),43(usb),502(eb)
>
> Note that my gid is 502(eb), but that I'm also a
> member of
> wheel and usb.
>
> [EMAIL PROTECTED] eb]$ ls -ld /usr/local/bin
> drwxrwsr-x 2 root wheel 4096 Oct 24 18:24
> /usr/local/bin
>
> Given this setup, I can write files into
> /usr/local/bin, and even
> though my gid is 502(eb), the installed files end up
> with group 10(wheel).
>
> E.g.,
>
> [EMAIL PROTECTED] eb]$ ls -ld /usr/local/bin
> drwxrwsr-x 2 root wheel 4096 Oct 24 18:24
> /usr/local/bin
> [EMAIL PROTECTED] eb]$ touch /usr/local/bin/foo
> [EMAIL PROTECTED] eb]$ ls -l /usr/local/bin/foo
> -rw-rw-r-- 1 eb wheel 0 Oct 28 09:41
> /usr/local/bin/foo
> [EMAIL PROTECTED] eb]$ rm /usr/local/bin/foo
>
>
> > After m
Re: [Discuss-gnuradio] usb_claim_interface Invalid argument error
I had a similar problem with the USB failing to get USRP access. It was a USB permissions issue at my host. Can you try to run the usrper command as a root and check if it loads without error? If it does load without errors, then it might be about setting your rights in the 'fstab' for the usb mount. HTH, Javs > > Running usrper load_standard_bits gives this output: > > debian:/home/ward/usrp-0.8/host/apps# usrper > load_standard_bits > usrper: found unconfigured usrp; needs firmware. > usrp_open_interface: usb_claim_interface: failed > conf 0 > could not set config 1: Invalid argument > open_nth_cmd_interface: open_cmd_interface failed > usrper: failed > > Why would I start getting the "Invalid argument" > between application runs? Any help regarding what > to look for would be appreciated. > > Thanks, > Ward > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > __ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
