[Discuss-gnuradio] Custom Blocks and FPGA builds
Hi I just wanted clarification on somethings: 1) For creating customs blocks, I wasn't sure on the compiling process. Once you've generated the three files needed for your custom block, and placed them in the correct place, does one simply compile them in their folder using the ./bootstrap - ./configure - etc. process? Is it only the new files that are compiled and integrated? Or does this process re-compile and install the whole gnuradio setup? 2) For custom FPGA builds. So far I've been creating and compiling custom FPGA builds for the rev 2 USRP that I'm using. My fellow students are all using rev 4 boards. I seem to vaguely remember Eric mentioning that one should be cautious about where custom .rbfs are placed for rev 4 boards, and how they are called from python. If the rev 4 users would like to use the rbf's I've made, what is the safe way for them to load it from python? Do I need to recompile my rbf's differently to work with rev 4 boards? Regards Lance Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr_message_sink
I was wondering if someone could perhaps clarify how the gr_message_sink works . I'm trying to make a modified version of the fft_sink. I noticed that the sample stream is turned into a vector streasm and then sent to a message sink. When the data is unpacked from the messages, then it seems there are a varying number of fft frames in each message. How does this happen? Why isn't there only one frame per message? Also, what exactly are msg.arg(1) and msg.arg(2). Are they part of the message payload or part a special frame? Lastly, what does self.msgq.delete_head() do? Regards Lance - Shape Yahoo! in your own image. Join our Network Research Panel today!___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem installing gnu radio 3.0.4
--- Jeffrey Ung [EMAIL PROTECTED] wrote: I ran into a similar problem installing GR. My question to you is, have you checked to make sure that file is actually in that directory? Simply setting the environment to where the file is actually located may help you get past the stage. the command is: env LD_LIBRARY_PATH=/directory where directory is where libgnuradio-core.la is found. - jeff On 7/30/07, seph 004 [EMAIL PROTECTED] wrote: --- Johnathan Corgan [EMAIL PROTECTED] wrote: seph 004 wrote: I'm using autoconf 2.61 automake 1.9.6 libtool 1.5.22 gcc 4.0.4 Can you post your: OS and version (uname -a) ./configure parameters (or none) make parameters (or none) Thanks. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com Thanks for replying. I'm using Debian 2.6.16.9 I did not use any parameters with ./configure or make. I was following the instructions in the README file included with the tarball, and I didn't see any parameters listed there. Should I have included --enable maintainer mode like in the older release? Regards Lance Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=listsid=396545433 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio Thanks for replying. I'll give this a try. The file is in the right place but my LD_LIBRARY_PATH doesn't point there. Adding the install directory to the LD path won't affect the rest of the installation/operation? Regards Lance Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem installing gnu radio 3.0.4
--- Johnathan Corgan [EMAIL PROTECTED] wrote: seph 004 wrote: I'm using autoconf 2.61 automake 1.9.6 libtool 1.5.22 gcc 4.0.4 Can you post your: OS and version (uname -a) ./configure parameters (or none) make parameters (or none) Thanks. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com Thanks for replying. I'm using Debian 2.6.16.9 I did not use any parameters with ./configure or make. I was following the instructions in the README file included with the tarball, and I didn't see any parameters listed there. Should I have included --enable maintainer mode like in the older release? Regards Lance Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=listsid=396545433 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Problem installing gnu radio 3.0.4
I tried installing the new gnu radio 3.04 version tarball but I can't get past the make stage. I get the following error: creating libgnuradio-core-qa.la /bin/sed: can't read Software/gnuradio-3.0.4/gnuradio-core/src/lib/libgnuradio-core.la: No such file or directory libtool: link: `Software/gnuradio-3.0.4/gnuradio-core/src/lib/libgnuradio-core.la' is not a valid libtool archive make[5]: *** [libgnuradio-core-qa.la] Error 1 I'm using autoconf 2.61 automake 1.9.6 libtool 1.5.22 gcc 4.0.4 - Choose the right car based on your needs. Check out Yahoo! Autos new Car Finder tool.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The correct way to receive pulses?
--- Matt Ettus [EMAIL PROTECTED] wrote: seph 004 wrote: My question is about the correct setup to receive pulses. I've managed to get my system to transmit 1 second pulses at 16 ms intervals. I wanted to test how the usrp receives these pulses again by routing the output of the basic TX board, to the input of the basic RX board. This seems to work for continuous wave signals, but when I try to route my pulsed output back, the signal appearing on the host pc appears to be saturated. I end up getting a series of combs that don't seem to be related to the incoming pulse in anyway. The pulses are centred at 40 kHz and have 2 kHz bw. I've set the decimation rate to 250, and used the set_freq method to tune to 40 kHz. I know I can receive a 40 kHz wave as I have done so with a modified version of usrp_siggen. Is there something Ive overlooked in terms of the settings I've used? What daughterboard are you using? Only the LFRX and LFTX go down to 40 kHz. Matt Thanks for replying. I'm using the basic RX daughterboard. I know it's not supposed to be able to pass such low frequency signals, but I have used it to successfully receive signals as low as 40 kHz. Those were continuous waves though. Now that I'm trying to view pulses centered at 40 kHz, I get the behavior I described previously. I made a mistake in my first email. My transmitter is outputting 1 millisecond pulses, not 1 second pulses. Could the behavior I'm seeing be caused by the PRI I'm using? I'm not sure what to try next. Regards Lance Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] The correct way to receive pulses?
My question is about the correct setup to receive pulses. I've managed to get my system to transmit 1 second pulses at 16 ms intervals. I wanted to test how the usrp receives these pulses again by routing the output of the basic TX board, to the input of the basic RX board. This seems to work for continuous wave signals, but when I try to route my pulsed output back, the signal appearing on the host pc appears to be saturated. I end up getting a series of combs that don't seem to be related to the incoming pulse in anyway. The pulses are centred at 40 kHz and have 2 kHz bw. I've set the decimation rate to 250, and used the set_freq method to tune to 40 kHz. I know I can receive a 40 kHz wave as I have done so with a modified version of usrp_siggen. Is there something Ive overlooked in terms of the settings I've used? Regards Lance Get the Yahoo! toolbar and be alerted to new email wherever you're surfing. http://new.toolbar.yahoo.com/toolbar/features/mail/index.php ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] VIA USB-2 combo card
Or does anybody have a suggestion of an USB-2 addon card for a notebook (pccard) that works with the USRP. Jim Perkins recently told me the following: I recently tested an inexpensive Zonet USB 2.0 add-on card. It has the Via VT6212L chipset. The Via based card worked very well. The benchmark_usb.py test returned OK for all speeds including 32 MB/s. Matt I tried using an ALI based Chronos USB 2.0 pc card. It did not work well at all. It could only do USB 1.0 connection to the USRP. It worked with the USRP at first, but after a few days I could not get any attempts at USB2.0 USRP connection to work. I'm not sure if it is the chipset, but perhaps Chronos cards are best avoided. Lance Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] calculated vs observed pulse length
Matt Ettus [EMAIL PROTECTED] wrote: seph 004 wrote: This would mean that to obtain a total rate of 32 Msamples/sec to the DAC, the data rate of the I and Q channels would have to be 16 Msamples/sec each, and thus 128 000 samples/sec each into the txchain modules. This should mean that if I provide a samples set of 128 I samples, and 128 Q samples, I should get 1 msec worth of complex output signal. The bus carrying IQ data to the 9862 TX runs at 64 MHz, so it is 32 MS/s for each. Matt Thanks for the reply. I see what you are saying about the bus. It means that the pulse is longer instead of shorter, which makes more sense. Going with this though, I have done tests with the new numbers and I still get a longer pulse than expected. I thought the problem might have been a delay from the cic shifter or the DAC, but even those should only have added a few microseconds, not over 100 microseconds. From the logic analyser , it seems that the counter I use for advancing the read pointer for the RAM might be running slow, though the Quartus simulator shows it running at the right speed. Would such a problem stem from using an interp rate like 125 within the FPGA? Has anyone who has done USRP FPGA builds that use counters noticed a similar variance? Regards Lance - Choose the right car based on your needs. Check out Yahoo! Autos new Car Finder tool.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] calcualted vs observed pulse length
I've managed to store a sample set on the FPGA and transmit it periodically. The problem I'm experiencing is that the transmitted pulse is shorter than what I expected. I worked out that by setting an interp value of 500 from python, that the FPGA interpolator would basically be set to 125 to go with the AD9860s x4. This would mean that to obtain a total rate of 32 Msamples/sec to the DAC, the data rate of the I and Q channels would have to be 16 Msamples/sec each, and thus 128 000 samples/sec each into the txchain modules. This should mean that if I provide a samples set of 128 I samples, and 128 Q samples, I should get 1 msec worth of complex output signal. Is this correct? I'm not sure if I overlooked something. The result I get when monitoring the output is about 750 microseconds instead of 1 msec. Is there perhaps something I didn't take into account in the calculations? If anyone can assist it would be greatly appreciated. Regards Lance - Don't pick lemons. See all the new 2007 cars at Yahoo! Autos.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Questions about USRP RX
There were just a couple of things I wasn't sure about: If the RX chain is disabled inside the FPGA, but a receive application is still running on the host pc, will samples still arrive on the host pc (like 16 bit zeros)? If wrreq for the FIFO in the RX buffer module is de-asserted, but an application is still running expecting samples, will there still be samples with zero value arriving on the host pc? What is the behaviour of a GNU Radio program when the sample flow is interrupted? Does the program merely idle waiting for samples until it is finished running? Lastly, is it feasible to re-adjust the USRP's RX chain to work with 12-bit samples directly from the ADC instead of 16-bit adjusted samples? I have very little experience in the level of dsp happening in the rx_chain module, but how difficult would it be to modify this and other rx modules to work with 12 bit samples directly from the ADC and still retain their functionality? I was musing about the possibility of a very simple form of inband signalling for the receiver section by processing the 12 bit received samples and then appending 4 bit messages to them to make 16 bit samples to send across the usb to be seperated on the host pc. Regards Lance - TV dinner still cooling? Check out Tonight's Picks on Yahoo! TV.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The shortest pulse length
Thanks for the advice. I don't think that's my only problem though. My vector is currently supposed to produce 2500 samples. This combined with an interpolation factor of 512, should give me 10 msecs of signal. Have I calculated this correctly? Also, I'm using the gr.modulation block to make the signal, but if it is producing complex output, does that mean I'm actually sending 5000 samples? At the moment, sending my 2500 samples produces an output only 1 msec long. Regards Lance - Original Message From: Eric Blossom [EMAIL PROTECTED] To: seph 004 [EMAIL PROTECTED] Cc: David Scaperoth [EMAIL PROTECTED]; discuss-gnuradio@gnu.org Sent: Friday, March 2, 2007 7:06:06 PM Subject: Re: [Discuss-gnuradio] The shortest pulse length On Fri, Mar 02, 2007 at 12:41:40AM -0800, seph 004 wrote: I am only using 1 daughterboard. Sorry about the duc0 = 0 inclusion. It's something I neglected to remove when I was editing the original file. I don't think it should have any effect on what I am seeing though. I set the duc frequency to 0 because I wanted to transmit at baseband. I've already built the signal I want in the gr.vector, I just want the daughterboard to pass it as is. I've managed to do that with usrp_siggen.py. By setting the -f option to 0 and the -w option to some frequency, I get a waveform of the -w frequency at the daughterboard output. I'm pretty sure (0, 0) is TXA, and (1, 0) is TXB. My waveform does appear at the TXB output when I run the script. The problem is the pulse duration I'm seeing is much shorter (about 1/10) than what I expect. Regards Lance Unless the total number of samples comes out to a multiple of 128, some will left in the host buffer and not transmitted across the USB. Try padding your vsource data with zeros to a multiple of 128. Eric - Original Message From: David Scaperoth [EMAIL PROTECTED] To: seph 004 [EMAIL PROTECTED] Cc: discuss-gnuradio@gnu.org Sent: Thursday, March 1, 2007 7:15:36 PM Subject: Re: [Discuss-gnuradio] The shortest pulse length On 3/1/07, seph 004 [EMAIL PROTECTED] wrote: This is what I did: def build_graph (): nchan = 1 interp = 512 duc0 = 0 duc1 = 0 fs = 250e3#2nd sample rate between usb and dac max_dev = 32e3 #1st sample rate divided by 4 (1st = 2nd sample rate) gain = 16e3 k = 2 * math.pi * max_dev / fs vec1 = Numeric.arange (0.624, 0.656, 0.128) vsource = gr.vector_source_f(vec1, False) fmmod = gr.frequency_modulator_fc (k) amp = gr.multiply_const_cc(gain) fg = gr.flow_graph () u = usrp.sink_c (0, interp, nchan) tx_subdev_spec = (1, 0) #usrp.pick_tx_subdevice(u) m = usrp.determine_tx_mux_value(u, tx_subdev_spec) u.set_mux(m) subdev = usrp.selected_subdev(u, tx_subdev_spec) subdev.set_enable(True) sample_rate = u.dac_freq () / interp u.set_tx_freq (0, duc0) u.set_tx_freq (1, duc1) Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The shortest pulse length
Thanks for the reply. I mentioned in my response to David's message that I'm purposefully setting the duc frequency to 0 to transmit at baseband. Is using .tune to do this better than the set_freq method even if I don't want duc to do anything to the signal? Regards Lance - Original Message From: Eric Blossom [EMAIL PROTECTED] To: David Scaperoth [EMAIL PROTECTED] Cc: seph 004 [EMAIL PROTECTED]; discuss-gnuradio@gnu.org Sent: Thursday, March 1, 2007 11:32:45 PM Subject: Re: [Discuss-gnuradio] The shortest pulse length On Thu, Mar 01, 2007 at 12:15:36PM -0500, David Scaperoth wrote: On 3/1/07, seph 004 [EMAIL PROTECTED] wrote: This is what I did: def build_graph (): nchan = 1 interp = 512 duc0 = 0 duc1 = 0 fs = 250e3#2nd sample rate between usb and dac max_dev = 32e3 #1st sample rate divided by 4 (1st = 2nd sample rate) gain = 16e3 k = 2 * math.pi * max_dev / fs vec1 = Numeric.arange (0.624, 0.656, 0.128) vsource = gr.vector_source_f(vec1, False) fmmod = gr.frequency_modulator_fc (k) amp = gr.multiply_const_cc(gain) fg = gr.flow_graph () u = usrp.sink_c (0, interp, nchan) tx_subdev_spec = (1, 0) #usrp.pick_tx_subdevice(u) m = usrp.determine_tx_mux_value(u, tx_subdev_spec) u.set_mux(m) subdev = usrp.selected_subdev(u, tx_subdev_spec) subdev.set_enable(True) sample_rate = u.dac_freq () / interp u.set_tx_freq (0, duc0) u.set_tx_freq (1, duc1) Are you trying to use one daughter boards(nchen=1)? Why did you set duc0 = 0? that means your frequency will not be set at all. You do not need to do set_tx_freq() twice if you are using one daughter board. you only need : u.set_tx_freq (0, duc0) where duc0 is some frequency. Also, if you are using the basic daughterboards, you need to make sure that you have the output connector connect to TXA not TXB (according to your tx_subdev_spec) Hope this helped. David Lance, you really want to be using tune, not set_tx_freq. tune knows about all the daughterboards and does the right thing to split the work between the digital upconverter and the RF front end (if any). Take a look at fm_tx4.py or fm_tx_2_daughterboards.py Eric TV dinner still cooling? Check out Tonight's Picks on Yahoo! TV. http://tv.yahoo.com/___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The shortest pulse length
Well, I have implemented a bit of a strange setup which seems to be working somewhat now. I'm not really trying to view only the first few samples, I'm currently trying to track where I might of made a mistake with trying to generate a defined pulse with a specific length. My aim is to generate a very narrow band chirp to transmit on a little ultrasonic tranducer. I figured out which numerical values to the gr.modulation block produce which frequencies. Using this, I made a vector of the exact number of samples I want with the values to produce the frequencies I want. In my case 39-41 kHz. For some reason these low frequencies still make it through the transformer on the basic TX db, so I'm using them. Initially I was just generating a sine wave, and trying to use gr.head to limit the number of samples, but I've since switched to this approach I figured that if I wanted to produce a wave form lasting 10 msecs, then I would need at least 2500 samples. I got this number from the DAC rate of 128M and the highest interpolation factor of 512. When I test with the scope set to auto store, I spot the waveform, but it is only 1 msec long. So either I've lost a lot of samples somewhere, or my scaling is wrong. I pretty much abandoned using gr.head, as it wasn't producing anything. At least now though I can see a waveform, though my scaling seems to have gone wrong somewhere. When you say you used a looback, do you mean you connected the TX db output and RX db input, and used the gr.oscope block to view your signals? Regards Lance - Original Message From: Lee Patton [EMAIL PROTECTED] To: seph 004 [EMAIL PROTECTED] Cc: discuss-gnuradio@gnu.org Sent: Tuesday, February 27, 2007 12:58:31 AM Subject: Re: [Discuss-gnuradio] The shortest pulse length On Mon, 2007-02-26 at 00:55 -0800, seph 004 wrote: I have a vector source producing a sine wave, and then I'm using gr.head to limit the number of samples sent. I'm sure you checked this, but are you trying to capture the first few samples of sin(x)? I so, sin(x) = x for small angles, and sin(0)=0. So, you won't see anything in the first few samples anyway. From your explanation, I should be ok with even a low number of samples. When I tested my setup, I couldn't catch anything on the scope. There is probably some problem in how I made the app. I saw something mentioned elsewhere in the discussion archives that the usrp dumps the first few samples it receives from the host before transmitting. Is this still something to take note of? I don't know whether or not the USRP dumps the first few samples. I don't think I've ever experienced it though. I can say that there is an unpredictable delay from the generation of the first sample in software until the time it actually reaches the output port. I haven't tried to do what you're doing -- i.e., capture the first few output samples on a scope. How is the scope triggered? (What I did was create a loopback whereby I transmit and receive by reading the bleedover on the daugherboard.) -Lee Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The shortest pulse length
This is what I did: def build_graph (): nchan = 1 interp = 512 duc0 = 0 duc1 = 0 fs = 250e3#2nd sample rate between usb and dac max_dev = 32e3 #1st sample rate divided by 4 (1st = 2nd sample rate) gain = 16e3 k = 2 * math.pi * max_dev / fs vec1 = Numeric.arange (0.624, 0.656, 0.128) vsource = gr.vector_source_f(vec1, False) fmmod = gr.frequency_modulator_fc (k) amp = gr.multiply_const_cc(gain) fg = gr.flow_graph () u = usrp.sink_c (0, interp, nchan) tx_subdev_spec = (1, 0) #usrp.pick_tx_subdevice(u) m = usrp.determine_tx_mux_value(u, tx_subdev_spec) u.set_mux(m) subdev = usrp.selected_subdev(u, tx_subdev_spec) subdev.set_enable(True) sample_rate = u.dac_freq () / interp u.set_tx_freq (0, duc0) u.set_tx_freq (1, duc1) fg.connect (vsource, fmmod, amp, u) return fg I modified a version of siggen_min2.py into the above. Regards Lance - Original Message From: David Scaperoth [EMAIL PROTECTED] To: seph 004 [EMAIL PROTECTED] Cc: Lee Patton [EMAIL PROTECTED]; discuss-gnuradio@gnu.org Sent: Thursday, March 1, 2007 5:59:22 AM Subject: Re: [Discuss-gnuradio] The shortest pulse length On Feb 28, 2007, at 4:29 AM, seph 004 wrote: Well, I have implemented a bit of a strange setup which seems to be working somewhat now. I'm not really trying to view only the first few samples, I'm currently trying to track where I might of made a mistake with trying to generate a defined pulse with a specific length. My aim is to generate a very narrow band chirp to transmit on a little ultrasonic tranducer. I figured out which numerical values to the gr.modulation block produce which frequencies. Using this, I made a vector of the exact number of samples I want with the values to produce the frequencies I want. In my case 39-41 kHz. For some reason these low frequencies still make it through the transformer on the basic TX db, so I'm using them. Initially I was just generating a sine wave, and trying to use gr.head to limit the number of samples, but I've since switched to this approach I figured that if I wanted to produce a wave form lasting 10 msecs, then I would need at least 2500 samples. I got this number from the DAC rate of 128M and the highest interpolation factor of 512. When I test with the scope set to auto store, I spot the waveform, but it is only 1 msec long. So either I've lost a lot of samples somewhere, or my scaling is wrong. How are you creating the flow graph? I pretty much abandoned using gr.head, as it wasn't producing anything. At least now though I can see a waveform, though my scaling seems to have gone wrong somewhere. When you say you used a looback, do you mean you connected the TX db output and RX db input, and used the gr.oscope block to view your signals? Regards Lance - Original Message From: Lee Patton [EMAIL PROTECTED] To: seph 004 [EMAIL PROTECTED] Cc: discuss-gnuradio@gnu.org Sent: Tuesday, February 27, 2007 12:58:31 AM Subject: Re: [Discuss-gnuradio] The shortest pulse length On Mon, 2007-02-26 at 00:55 -0800, seph 004 wrote: I have a vector source producing a sine wave, and then I'm using gr.head to limit the number of samples sent. I'm sure you checked this, but are you trying to capture the first few samples of sin(x)? I so, sin(x) = x for small angles, and sin(0)=0. So, you won't see anything in the first few samples anyway. From your explanation, I should be ok with even a low number of samples. When I tested my setup, I couldn't catch anything on the scope. There is probably some problem in how I made the app. I saw something mentioned elsewhere in the discussion archives that the usrp dumps the first few samples it receives from the host before transmitting. Is this still something to take note of? I don't know whether or not the USRP dumps the first few samples. I don't think I've ever experienced it though. I can say that there is an unpredictable delay from the generation of the first sample in software until the time it actually reaches the output port. I haven't tried to do what you're doing -- i.e., capture the first few output samples on a scope. How is the scope triggered? (What I did was create a loopback whereby I transmit and receive by reading the bleedover on the daugherboard.) -Lee Now that's room service! Choose from over 150,000 hotels in 45,000 destinations on Yahoo! Travel to find your fit.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r
Re: [Discuss-gnuradio] The shortest pulse length
Hi Thanks very much for your explaination. I wasn't so sure what was happening with my setup. I have a vector source producing a sine wave, and then I'm using gr.head to limit the number of samples sent. From your explanation, I should be ok with even a low number of samples. When I tested my setup, I couldn't catch anything on the scope. There is probably some problem in how I made the app. I saw something mentioned elsewhere in the discussion archives that the usrp dumps the first few samples it receives from the host before transmitting. Is this still something to take note of? Regards Lance - Original Message From: Lee Patton [EMAIL PROTECTED] To: seph 004 [EMAIL PROTECTED] Cc: discuss-gnuradio@gnu.org Sent: Friday, February 23, 2007 6:07:45 PM Subject: Re: [Discuss-gnuradio] The shortest pulse length The shortest pulse duration which you can transmit is going to be limited by: a) the sampling rate of the converters b) the USB interface c) the bandwidth of IF/RF components I don't know your exact setup. So, let me provide an example of what I'm doing: I transmit and receive in an always-on fashion using a single USRP in 4 Byte/sample mode (2 for real, 2 for complex) Therefore, for each sample that must be transmitted and received, 8 bytes will traverse the USB (4 for Tx, 4 for Rx). The USRP is limited to 32 MB/s across the USB. Therefore, I can only handle signals 4 MHz wide. Because the USRP does complex sampling, 4 MHz becomes the maximum sampling rate I can use to generate my signal at baseband. (This signal will be interpolated to 128 MHz on the USRP.) Because the fastest I can generate samples is 4 MHz, the smallest interval between samples is 1/4e6 = 250 ns. That is (theoretically) the shortest pulse width. Now, anytime you signal using one sample you will suffer more system distortion than if you used, say, two. This is because the converters will act as a really wide low-pass filter. However, with that said, I am able to do it. I believe the minimum interpolation factor is 16. Therefore, in a transmit-only mode, I believe the minimum pulse width would be 1/8MHz = 125 ns. I haven't had coffee yet to day. So, caveat emptor on these calculations, but I hope they help. -Lee On Fri, 2007-02-23 at 06:08 -0800, seph 004 wrote: Hi Does anyone know what the shortest duration pulse is which the USRP can transmit? I've tried to test it by using gr.head to limit the number of samples to produce a short waveform, but I can't catch anything appearing at the output. Is there a simple test I could do to check? Regards Lance __ TV dinner still cooling? Check out Tonight's Picks on Yahoo! TV. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio Don't pick lemons. See all the new 2007 cars at Yahoo! Autos. http://autos.yahoo.com/new_cars.html ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] The shortest pulse length
Hi Does anyone know what the shortest duration pulse is which the USRP can transmit? I've tried to test it by using gr.head to limit the number of samples to produce a short waveform, but I can't catch anything appearing at the output. Is there a simple test I could do to check? Regards Lance Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Help with verilog: write_count
-- Message: 3 Date: Thu, 16 Nov 2006 12:44:48 -0800 From: Eric Blossom [EMAIL PROTECTED] Subject: Re: [Discuss-gnuradio] Help with Verilog: write_count[8] To: seph 004 [EMAIL PROTECTED] Cc: discuss-gnuradio@gnu.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii On Thu, Nov 16, 2006 at 01:11:15AM -0800, seph 004 wrote: Hi I'm still trying to figure out the problem in my code. I think that along the way I misunderstood the purpose of the write_count register. How does it actually work? WR triggers every time a 16 bit packet is ready from the FX2 doesn't it? write_count counts from 0 to 256, then back to 0. It's at 256 when WR is still asserted but there's really no data to receive. This works around some strange behavior in the FX2 GPIF interface and/or programming. The wreq trigger of the FIFO is triggered by (WR ~write_count[8]). Does this mean that only 256 16 bit samples enter the FIFO before the WR is removed? Why is this? How could I determine exactly when there is an I or Q sample that must be written into the FIFO? .wrreq tells the FIFO when data should be written to the fifo. So, we write when (WR ~write_count[8]). That is, when WR is asserted, but the count does not have 0x100 bit set. As I recall, WR is asserted an extra cycle, and the counter trick works around this. You may want to take a look at the Altera Cyclone documentation. The block called tx_fifo is one of their standard blocks. It's the dual clock version of the fifo, and is used (amongst other things), to bridge between the USB clock domain (.wrclk(usbclk)) and the signal processing clock (.rdclk(txclk)). Eric Hi Thanks for responding. So WR ~write_count[8] should be able to serve as a write enable for a ram block? Also, while testing with one of the unmodified FPGA builds, I found that the have_space control line would sometimes go to zero even though I am only sending small amounts of data (60 bytes for instance). In the original build, have_space would only go to zero temporarily if the FIFO became full. So why then does this happen even when sending small numbers of samples? Shouldn't the 4k FIFO never become full under those circumstances? Regards Lance ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Help with Verilog: write_count[8]
Hi I'm still trying to figure out the problem in my code. I think that along the way I misunderstood the purpose of the write_count register. How does it actually work? WR triggers every time a 16 bit packet is ready from the FX2 doesn't it? The wreq trigger of the FIFO is triggered by (WR ~write_count[8]). Does this mean that only 256 16 bit samples enter the FIFO before the WR is removed? Why is this? How could I determine exactly when there is an I or Q sample that must be written into the FIFO? Regards Lance ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Help with Verilog
From: "Oussama Sekkat" [EMAIL PROTECTED]Subject: Re: [Discuss-gnuradio] Help with VerilogTo: "seph 004" [EMAIL PROTECTED]Cc: discuss-gnuradio@gnu.orgMessage-ID:[EMAIL PROTECTED]Content-Type: text/plain; charset="iso-8859-1"Hi Lance,On 11/7/06, seph 004 [EMAIL PROTECTED] wrote: Hi I've been bashing my head against this problem for a few weeks now, but I can't seem to figure it out. I've been making a few modifications to the verilog code, in particular the
tx_buffer.v module. What I want to do is send a signal from the pc and trap it in the fpga. I've tried doing this by replacing the FIFO module with an ALTSYNCRAM module (generated by quartus). The idea is to capture the incoming signal in the RAM, and only transmit it when an external trigger is received. (for the external signal, I am using a changing register for now). I am using a slightly modified version of the test_usrp_standard_tx program to test my FPGA build. So far though, none of the signals I've tried to send have been transmitted (I have a scope on the daughterboard output). Below is the modified module:Did you make sure that the output debug pins, that your logic analyzer isconnected to, have been enabled?module tx_buffer ( input usbclk, input bus_reset,// Used here for the 257-Hack to fix the FX2
bug input reset,// standard DSP-side reset input ptr_reset, //reset the read pointer to transmit same signal again input [15:0] usbdata, input wire WR, output wire have_space, output wire done, //indicates when the whole waveform has been sent output reg tx_underrun, input wire [3:0] channels, output reg [15:0] tx_i_0, output reg [15:0] tx_q_0, output reg [15:0] tx_i_1, output reg [15:0] tx_q_1, output reg [15:0] tx_i_2, output reg [15:0] tx_q_2, output reg [15:0]
tx_i_3, output reg [15:0] tx_q_3, input txclk, input txstrobe, input clear_status, input start, //start sending the waveform output [15:0] debugbus );reg [8:0] write_count;wire [15:0] ramdata;wire rdreq;reg [11:0] wrptr;//write addressreg [11:0] rdptr;//read addressreg [3:0] load_next;// DAC Side of FIFOassignrdreq = ((load_next != channels) start);assigndone = (rdptr ==
wrptr);always @(posedge txclk)if(reset | ptr_reset)begin {tx_i_0,tx_q_0,tx_i_1,tx_q_1,tx_i_2,tx_q_2,tx_i_3,tx_q_3} = #1 128'h0; load_next = #1 4'd0; rdptr = #1 12'd0;end // (reset |ptr_reset)elseif((load_next != channels) start)begin rdptr = #1 rdptr + 1; load_next = #1 load_next +
4'd1; case(load_next) 4'd0 : tx_i_0 = #1 ramdata; 4'd1 : tx_q_0 = #1 ramdata; 4'd2 : tx_i_1 = #1 ramdata; 4'd3 : tx_q_1 = #1 ramdata; 4'd4 : tx_i_2 = #1 ramdata; 4'd5 : tx_q_2 = #1 ramdata; 4'd6 : tx_i_3 = #1 ramdata; 4'd7 : tx_q_3 = #1 ramdata; endcase //
case(load_next)end // if ((load_next != channels) start)else if(txstrobe (load_next == channels))begin load_next = #1 4'd0;end// USB Side of FIFOassign have_space = 1'b1;//quick fix for now. (wrptr =4000) not functioningalways @(posedge usbclk)if(bus_reset)// Use bus reset because this is on usbclkwrite_count = #1 0;else
if(reset)wrptr = #1 12'd0;else if(WR ~write_count[8])beginwrptr = #1 wrptr + 1;//move to next address to writewrite_count = #1 write_count + 9'd1;endelsewrite_count = #1 WR ? write_count : 9'b0;// Detect Underrunsalways @(posedge txclk)if(reset)tx_underrun = 1'b0;else if(txstrobe
(load_next != channels))tx_underrun = 1'b1;else if(clear_status)tx_underrun = 1'b0;// RAMsignal_ram signal_ram( .data ( usbdata ),.wren ( WR ~write_count[8] ),.wrclock ( usbclk ),.wraddress ( wrptr ),.q ( ramdata ),.rden ( rdreq ),.rdclock ( txclk ),.rdaddress ( rdptr
),.wr_aclr ( reset ),// asynch, so we can use either.rd_aclr ( reset ) );// Debugging Aidsassign debugbus[11:0] = wrptr;assign debugbus[12] = start;assign debugbus[13] = rdreq;assign debugbus[14] = done;assign debugbus[15] = ptr_reset; endmodule // tx_buffer It's probably something simple I've missed, I'm pretty new to verilog. Any help would be greatly appreciated. Regards LanceHiThanks for taking a look. I have made sure to enable my outputs, and I can see the effects of changes to the
verilog. I am still having trouble with the transmitting though. I know what the wave I'm transmitting is supposed to look like on the scope (it's the same as the normal std_2rxhb_2tx.rbf and the test_usrp_standard_tx.) the only difference is my FPGA build will hold the signal in tx_buffer, instead of streaming to the tx_chain module immediately.RegardsLance___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Help with Verilog
HiI've been bashing my head against this problem for a few weeks now, but I can't seem to figure it out. I've been making a few modifications to the verilog code, in particular the tx_buffer.v module. What I want to do is send a signal from the pc and trap it in the fpga. I've tried doing this by replacing the FIFO module with an ALTSYNCRAM module (generated by quartus). The idea is to capture the incoming signal in the RAM, and only transmit it when an external trigger is received. (for the external signal, I am using a changing register for now). I am using a slightly modified version of the test_usrp_standard_tx program to test my FPGA build. So far though, none of the signals I've tried to send have been transmitted (I have a scope on the daughterboard output). Below is the modified
module:module tx_buffer ( input usbclk, input bus_reset, // Used here for the 257-Hack to fix the FX2 bug input reset, // standard DSP-side reset input ptr_reset, //reset the read pointer to transmit same signal again input [15:0] usbdata, input wire WR, output wire have_space, output wire done, //indicates when the whole waveform has been sent output reg tx_underrun, input wire [3:0] channels, output reg [15:0] tx_i_0, output reg [15:0] tx_q_0, output reg [15:0] tx_i_1, output reg [15:0] tx_q_1, output reg [15:0] tx_i_2, output reg [15:0] tx_q_2, output reg [15:0] tx_i_3,
output reg [15:0] tx_q_3, input txclk, input txstrobe, input clear_status, input start, //start sending the waveform output [15:0] debugbus ); reg [8:0] write_count; wire [15:0] ramdata; wire rdreq; reg [11:0] wrptr; //write address reg [11:0] rdptr; //read address reg [3:0] load_next; // DAC Side of FIFO assign rdreq = ((load_next != channels) start); assign done = (rdptr == wrptr); always @(posedge txclk) if(reset | ptr_reset) begin
{tx_i_0,tx_q_0,tx_i_1,tx_q_1,tx_i_2,tx_q_2,tx_i_3,tx_q_3} = #1 128'h0; load_next = #1 4'd0; rdptr = #1 12'd0; end // (reset |ptr_reset) else if((load_next != channels) start) begin rdptr = #1 rdptr + 1; load_next = #1 load_next + 4'd1; case(load_next) 4'd0 : tx_i_0 = #1 ramdata; 4'd1 : tx_q_0 = #1 ramdata; 4'd2 : tx_i_1 = #1 ramdata; 4'd3 : tx_q_1 = #1
ramdata; 4'd4 : tx_i_2 = #1 ramdata; 4'd5 : tx_q_2 = #1 ramdata; 4'd6 : tx_i_3 = #1 ramdata; 4'd7 : tx_q_3 = #1 ramdata; endcase // case(load_next) end // if ((load_next != channels) start) else if(txstrobe (load_next == channels)) begin load_next = #1 4'd0; end // USB Side of FIFO assign have_space = 1'b1; //quick fix for now. (wrptr = 4000) not functioning always @(posedge usbclk)
if(bus_reset) // Use bus reset because this is on usbclk write_count = #1 0; else if(reset) wrptr = #1 12'd0; else if(WR ~write_count[8]) begin wrptr = #1 wrptr + 1; //move to next address to write write_count = #1 write_count + 9'd1; end else write_count = #1 WR ? write_count : 9'b0; // Detect Underruns always @(posedge txclk) if(reset) tx_underrun = 1'b0; else if(txstrobe
(load_next != channels)) tx_underrun = 1'b1; else if(clear_status) tx_underrun = 1'b0; // RAM signal_ram signal_ram ( .data ( usbdata ), .wren ( WR ~write_count[8] ), .wrclock ( usbclk ), .wraddress ( wrptr ), .q ( ramdata ),.rden ( rdreq ), .rdclock ( txclk ), .rdaddress ( rdptr ), .wr_aclr ( reset ), // asynch, so we can use either .rd_aclr (
reset ) ); // Debugging Aids assign debugbus[11:0] = wrptr; assign debugbus[12] = start; assign debugbus[13] = rdreq; assign debugbus[14] = done; assign debugbus[15] = ptr_reset; endmodule // tx_bufferIt's probably something simple I've missed, I'm pretty new to verilog. Any help would be greatly appreciated.RegardsLance___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] reading and writing registers
HiI am having some trouble trying to get register writing and reading from the C++ level to work. I've created two methods:for writingstatic boolwrite_a_reg (usrp_basic *u, int address, int amount){ bool isit = u-_write_fpga_reg (address, amount); return isit;}for reading intread_a_reg (usrp_basic *u, int address){ int val = u-_read_fpga_reg (address); return val;}When I use the write method:bool fine2 = write_a_reg (urx, 78, 60);The returned boolean indicates that the write was successful. If I try to read the same register though:int value = read_a_reg (urx, 78);it always returns zero no matter what I put in. The urx is the handle of a
usrp_standard_rx object, and if I'm not mistaken, register number 78 (`FR_USER_14) shoul be free to use. What am I doing wrong?RegardsLance___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] no trasnmit signal
Hi I am having trouble with transmiting from a Basic TX daughterboard (it's the only one I have for the time being). I've tried connecting an oscilloscope to the output while running siggen.py, but there is no signal coming out. Also, I notice a continuous stream of 'usrp underrun' messages. Has anyone experienced a similar problem, or know what a possible solution may be? Regards Lance___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] c++ programs
HiI recently finished a modified FPGA build and I wanted to compile a C++ program to test it. The program is based on the test_usrp_standard_tx program. I wanted to know how I would go about compiling the program so that all the proper header files are correctly included.Sorry if this is a silly question, c++ isn't really my forte.RegardsLance Do you Yahoo!? Get on board. You're invited to try the new Yahoo! Mail.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] tx_chain
HiI just wanted to confirm something. If the cordic in tx_chain is disabled, how is tuning to the IF frequency acheived? Is it done with only the cordic on the DAC?RegardsLance Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail Beta.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] frequency modulating block.
HiI just had a few questions regarding the frequency modulatig block. The current input sample is used in conjuction with the sensitivity parameter to determine the new phase value. Is this correct? I'm just a bit confused as to how the phase calculations and the sensitivity parameter relate to the instantaneous frequency output.Secondly, I suppose this is a more general question about the vector and file source blocks. At what rate are they producing data? For a non repeating vector source of n values, how can I detemine the exact amount of time it takes for all the values to be used?RegardsLance Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Make Check Failure
HiDuring my installation of gnuradio-core, make check keeps failing with this error:ake[3]: Entering directory `/home/lance/gr-build/gnuradio-core/src/tests'.Testing gr_vmcircbuf_createfilemapping_factory...gr_vmcircbuf_createfilemapping: createfilemapping is not available... gr_vmcircbuf_createfilemapping_factory: Doesn't workTesting gr_vmcircbuf_sysv_shm_factory.. gr_vmcircbuf_sysv_shm_factory: OKTesting gr_vmcircbuf_mmap_shm_open_factory.. gr_vmcircbuf_mmap_shm_open_factory: OKTesting gr_vmcircbuf_mmap_tmpfile_factory.. gr_vmcircbuf_mmap_tmpfile_factory: OK...FAIL: test_all===1 of 1 tests failed===make[3]: *** [check-TESTS] Error 1make[3]: Leaving directory `/home/lance/gr-build/gnuradio-core/src/tests'make[2]: *** [check-am] Error 2make[2]: Leaving directory `/home/lance/gr-build/gnuradio-core/src/tests'make[1]: *** [check-recursive] Error 1make[1]: Leaving directory `/home/lance/gr-build/gnuradio-core/src'make: *** [check-recursive] Error 1While make is running, I notice the following:/usr/bin/ld: warning: libstdc++.so.6, needed by /usr/bin/../lib/libcppunit-1.10.so.2, may conflict with libstdc++.so.5creating test_vmcircbufmake[3]: Leaving directory `/home/lance/gr-build/gnuradio-core/src/tests'Making all in pythonI've gone through the requiments many times now. is there something I've missed?RegardsLance __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] Checkout Problem
Hi I am experiencing some trouble trouble checking out the gnuradio stuff. So far gnuradio-core, gr-usrp, gr-wxgui, gr-audio-portaudio, gr-audio-jack, gr-howto-write-a-block have successfully checked out. However the process breaks down with the following message: svn: PROPFIND request failed on '/svn/usrp/trunk' svn: PROPFIND of '/svn/usrp/trunk': could not connect to server (http://usrp.svnrepository.com) FAILED: svn co http://usrp.svnrepository.com/svn/usrp/trunk usrp Traceback (most recent call last): File "./checkout", line 142, in ? main () File "./checkout", line 138, in main checkout (options.anon, options.user, options.exclude, options.include, options.options) File "./checkout", line 90, in checkout do_svn_checkout(repository, module) File "./checkout", line 63, in do_svn_checkout doit(cmd) File "./checkout", line 69, in doit raise RuntimeError RuntimeError It seems there is only a problem when it's time to get USRP stuff via svn. I just recently installed subversion, so perhaps some of my settings are wrong. I have absolutely no idea where to look though. I would appreciate it if someone could help me out... Regards Lance How low will we go? Check out Yahoo! MessengerÂ’s low PC-to-Phone call rates.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Generating chrip signals
Hi At the moment I would like to see if I can generate a chirp signal. Looking through what gnuradio blocks are available, I assumed I could use the gr_fxpt_nco block to do something like this. I was wondering firstly if it would be possible, and secondly, how this block works and behaves when it's running. Regards Lance New Yahoo! Messenger with Voice. Call regular phones from your PC and save big.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Reinstalling gnuradio
Hi Thanks Patrick, your suggestion worked. Everything seems ok now. Regards Lance __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] USRP usb cable question
Hi My earlier usb problem seems to be related to the cable I was using. I tried my home printer's cable and it began to work. I could load the firmware and the standard tx and rx programs worked perfectly. I tried out the usrp_fft.py script. It worked initially and then I got a stream of usb protocol errors which caused the script to crash. When I tried to reconnect the board I saw that I was back to square one with the USRP failing to connect. I also noticed that even though the script crashed and the was no longer running, the USRP was still drawing just over 1A. My question is: Is there any way or situation where communication between the USRP and the pc could cause the usb cable to be damaged? I haven't tried another cable yet, because I'm uncertain if the same thing would happen again. I did rmmod ehci_hcd and connected the USRP to the same port. I could succesfully connect and load firmware. I assumes this means that the USB2 pci card is working and that the cable can still do USB1.1 connections and that the USRP is fine as well. Is there a very specific kind of USB2 cable I should be using? A shielded type or something? Regards Lance __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] USRP usb cable question
Hi My earlier usb problem seems to be related to the cable I was using. I tried my home printer's cable and it began to work. I could load the firmware and the standard tx and rx programs worked perfectly. I tried out the usrp_fft.py script. It worked initially and then I got a stream of usb protocol errors which caused the script to crash. When I tried to reconnect the board I saw that I was back to square one with the USRP failing to connect. I also noticed that even though the script crashed and the was no longer running, the USRP was still drawing just over 1A. My question is: Is there any way or situation where communication between the USRP and the pc could cause the usb cable to be damaged? I haven't tried another cable yet, because I'm uncertain if the same thing would happen again. I did rmmod ehci_hcd and connected the USRP to the same port. I could succesfully connect and load firmware. I assumes this means that the USB2 pci card is working and that the cable can still do USB1.1 connections and that the USRP is fine as well. Is there a very specific kind of USB2 cable I should be using? A shielded type or something? Regards Lance Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1/min.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Reinstalling gnuradio
Hi I'm trying to reinstall the gnuradio files from cvs. I get all the files and start the ./bootstrap then ./configure procedure. When it comes to executing 'make' however, it keeps breaking down with the following error: make[4]: Entering directory `/home/lance/gr-build/gnuradio-core/src/lib/swig' make[4]: *** No rule to make target `../../../src/lib/general/gr_serial_to_parallel.i', needed by `gnuradio_swig_python.cc'. Stop. make[4]: Leaving directory `/home/lance/gr-build/gnuradio-core/src/lib/swig' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/lance/gr-build/gnuradio-core/src/lib' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/lance/gr-build/gnuradio-core/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/lance/gr-build/gnuradio-core' make: *** [all] Error 2 I've checked and double checked the dependancies, for the gnuradio-core. I've also updated and reinstalled all of them. Can anyone help? Am I missing something obvious? Regards Lance Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1/min.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
