[Discuss-gnuradio] max and argmax blocks with SIMD instructions
Hi everyone, I've written a couple of blocks for GNU Radio, but am not satisfied with the performance. I am therefore thinking of using SIMD instructions. However, I am not that familiar with x86 assembly instructions, and finding the reference manual on Intel's website was not easy. I know that DSPs such as the Blackfin has special vector instructions that would make this very simple, but I am not sure about x86. I am also going to write a general purpose multiply and accumulate block that would benefit much from SIMD instructions. Any comments are appreciated. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] packets to the usrp and loopback
Brian Padalino wrote: Sounds fun. Are you sure you're ready for a live test? I don't know :) What kind of problem should I expect when trying to go from simulation to reality ? You don't need to do this. Just don't connect up the tx_strobe - doesn't that solve the problem? You shouldn't necessarily have to make a master_control_inband - just feed the rate register into the module and generate it yourself. Yes it solves the problem, and is much simpler. I will do that. I don't necessarily understand why those pins, especially the have_space pin, are no longer relevant. Could you explain this please? I though that because we report all these informations to host in the header of the packets I don't need to use those signals anymore, but I guess I am wrong... :) Brian Thibaud ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] max and argmax blocks with SIMD instructions
On Mon, Apr 23, 2007 at 10:48:58AM +0200, Trond Danielsen wrote:
Hi everyone,
I've written a couple of blocks for GNU Radio, but am not satisfied
with the performance. I am therefore thinking of using SIMD
instructions. However, I am not that familiar with x86 assembly
instructions, and finding the reference manual on Intel's website was
not easy. I know that DSPs such as the Blackfin has special vector
instructions that would make this very simple, but I am not sure about
x86.
I am also going to write a general purpose multiply and accumulate
block that would benefit much from SIMD instructions.
Any comments are appreciated.
--
Trond Danielsen
Hi Trond,
Can you point us at your code? Before diving into SIMD, it would be
good to confirm that there isn't an easier change to make. Have you
run oprofile on your code?
In general when going for a speed up, you want to be packaging enough
cycles in the block to have it make a difference. I.e., I'm not sure
that a general purpose multiple-accumulate (MAC) block is going to
solve your problem. However, if you take a look at the gr_fir_*.cc
code, you'll find that at the bottom of them they call out to SIMD
assembler in {c,}complex_dotprod_*.S that implements the kernel of the
FIR filter. In those cases the equivalent of the MAC function is buried
in an unrolled inner loop.
With SIMD programming, a lot of the complexity is figuring out how to
schedule the loads and stores, since unless you're careful, your
performance is dominated by the memory hierarchy and not the math.
Also, on the x86 architecuture, there are not enough registers
available to hide the load latencies. On the x86-64 it's better,
since you've got twice as many registers. For a comparison, on the
Cell SPE you've got 128 (!) 128-bit registers. No shortage of
registers there ;)
In addition to the IA-32 Archicture Software Developer's Manual (I
suspect that was the one you had trouble finding), you'll want to look
for the microarchitecture-specific optimization manuals. The one I've
got in front of me, Intel Pentium 4 and Intel Xeon Processor
Optimization Reference Manual (Order Number: 248966-04) isn't the
latest, but is an example. I suspect that there's a new one out that
covers the Pentium M, Core, Core Duo, Core 2 Duo, etc. AMD also has
similar manuals. All these are on the vendor web sites, typically in
the developer section somewhere.
Be sure to create meaningful benchmarks to measure the performance of
your code. That's a whole art into into itself.
When all is said and done, algorithmic changes often result in bigger
wins than SIMD assembler. Be sure to look there first. In our
case, the FFT based FIR code is faster than the hand-coded SIMD code
for pretty much all cases where ntaps = 20.
Have fun!
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] packets to the usrp and loopback
On 4/23/07, Thibaud Hottelier [EMAIL PROTECTED] wrote: I don't know :) What kind of problem should I expect when trying to go from simulation to reality ? I'd run more simulations where there are a massive number of packets waiting to be sent, schedule things too close to each other, make the entire thing error out. You really want to test every aspect of the code that you can. Make things happen that seem impossible. Make things happen that you think will have a specific outcome and verify it works. You should have a testbench that pretends it's an FX2 and is trying to write these packets into the FPGA. From the FX2's perspective, the FPGA is just a set of RX and TX FIFOs. I would write a testbench that would read data packets from a file. Maybe output some complex waves at 2 different frequencies within these packets? Talk with George to maybe setup a file sink attached to the message block components to get the packets that would go over USB. Capture a few hundred of them and then use your testbench to write the values into your system. On the output of your simulation, you should be able to view the complex waves. Do you guys think you'll be able to do that? In ModelSim, if you add the I and Q signals to the Wave window, you can right-click on them, change their radix to decimal and change their type to Analog. There is a scale factor associated with it, but you can always just fiddle with that to make it look nice. Yes it solves the problem, and is much simpler. I will do that. Sounds good. Changing less things decreases our chances of completely breaking the entire system. I don't necessarily understand why those pins, especially the have_space pin, are no longer relevant. Could you explain this please? I though that because we report all these informations to host in the header of the packets I don't need to use those signals anymore, but I guess I am wrong... :) The have_space pin is used by the FX2 to know if the FPGA FIFO can store AT LEAST one more packet. This signal is pretty much required as you don't have FIFOs with infinite depth. As for the tx_empty and tx_underrun - those should still be there, otherwise how are you going to know when those things happen? Just because they're being sent up through the message header doesn't mean they get created out of thin air. I think the consensus was to OR all the tx_underruns from all the channels to one pin that would represent that an underrun occured - not necessarily worry about where it occured. I am not sure about tx_empty - that may be required to start stuffing 0's to flush the TX pipe, control automatic TX/RX switching, ramping up/down the output RF power, etc. It's probably still important to other functions - not necessarily the inband stuff. When it comes to this sort of stuff, it is always nicer to be able to have too much information and just not connect those wires than have too little information and try to wing it. I hope this all helps you guys out. You're both doing a bang up job so far. Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] max and argmax blocks with SIMD instructions
If you don't want to use assembly, you can use MMX and SSE intrisics compiler support. These are C functions/macros to allow the use of SSE instructions directly from C/C++. You can start with this introduction: http://www.codeproject.com/cpp/sseintro.asp . For a reference, you can go on MSDN website and search for intrinsic . Even if it's for Windows, it's still valid for GNU. Have a look at this files on your computer (in your system include dir): mmintrin.h - MMX emmintrin.h - SSE2 xmmintrin.h - SSE pmmintrin.h - SSE3 If you use it, don't forget to use compilation macros to offer alternative for processor that don't have these assembly instructions. Pascal PS From a personnal point of view, I don't know if these instructions are as fast as assembly. But they are quite easy to use, which improve my code writing speed ;-) On 4/23/07, Trond Danielsen [EMAIL PROTECTED] wrote: Hi everyone, I've written a couple of blocks for GNU Radio, but am not satisfied with the performance. I am therefore thinking of using SIMD instructions. However, I am not that familiar with x86 assembly instructions, and finding the reference manual on Intel's website was not easy. I know that DSPs such as the Blackfin has special vector instructions that would make this very simple, but I am not sure about x86. I am also going to write a general purpose multiply and accumulate block that would benefit much from SIMD instructions. Any comments are appreciated. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] packets to the usrp and loopback
On Mon, Apr 23, 2007 at 10:43:10AM -0400, Brian Padalino wrote: On 4/23/07, Thibaud Hottelier [EMAIL PROTECTED] wrote: I don't know :) What kind of problem should I expect when trying to go from simulation to reality ? I'd run more simulations where there are a massive number of packets waiting to be sent, schedule things too close to each other, make the entire thing error out. You really want to test every aspect of the code that you can. Make things happen that seem impossible. Make things happen that you think will have a specific outcome and verify it works. That sounds like the voice of experience ;) You should have a testbench that pretends it's an FX2 and is trying to write these packets into the FPGA. From the FX2's perspective, the FPGA is just a set of RX and TX FIFOs. I would write a testbench that would read data packets from a file. Maybe output some complex waves at 2 different frequencies within these packets? Talk with George to maybe setup a file sink attached to the message block components to get the packets that would go over USB. Capture a few hundred of them and then use your testbench to write the values into your system. On the output of your simulation, you should be able to view the complex waves. Do you guys think you'll be able to do that? In ModelSim, if you add the I and Q signals to the Wave window, you can right-click on them, change their radix to decimal and change their type to Analog. There is a scale factor associated with it, but you can always just fiddle with that to make it look nice. Yes it solves the problem, and is much simpler. I will do that. Sounds good. Changing less things decreases our chances of completely breaking the entire system. I don't necessarily understand why those pins, especially the have_space pin, are no longer relevant. Could you explain this please? I though that because we report all these informations to host in the header of the packets I don't need to use those signals anymore, but I guess I am wrong... :) The have_space pin is used by the FX2 to know if the FPGA FIFO can store AT LEAST one more packet. This signal is pretty much required as you don't have FIFOs with infinite depth. As for the tx_empty and tx_underrun - those should still be there, otherwise how are you going to know when those things happen? Just because they're being sent up through the message header doesn't mean they get created out of thin air. I think the consensus was to OR all the tx_underruns from all the channels to one pin that would represent that an underrun occured - not necessarily worry about where it occured. I am not sure about tx_empty - that may be required to start stuffing 0's to flush the TX pipe, control automatic TX/RX switching, ramping up/down the output RF power, etc. It's probably still important to other functions - not necessarily the inband stuff. Correct. When it comes to this sort of stuff, it is always nicer to be able to have too much information and just not connect those wires than have too little information and try to wing it. I hope this all helps you guys out. You're both doing a bang up job so far. Brian Brian, thanks for all your input. George and Thibaud, I think you need to think about how you're going to test the live combination of the host + FPGA a bit. How are you going to know if it's working? What kind of a test can you design that gives you a repeatable yes / no result? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] interfacing DSP and USRP
hey guys , i am doing a wimax module , the baseband is already implemented on DSP using simulink and i am working on The RF stage on the usrp but the problem is how can i interface both of them togther i have 2 ideas : I have 2 ideas: is based mostly on software : using RTDX channels I think I can get the output from the dsp and save it as .dat file (since USRP only handles raw files) Using a Virtual machine like VMware I can operate the linux under windows Using a virtual lan between windows and linux the .dat files can be shared between both The o/p can be saved in sequential files to prevent the loss of an output due to interface delays The o/p rate is 320bits/50 micro seconds is based on hardware : Using McBSP socket of DSP with 64 I/O pins on the USRP to make the interface but i heard that is one is very risky (specially i am so week in HDL ) so what is the best solution for that and the downsides of each? - Ahhh...imagining that irresistible new car smell? Check outnew cars at Yahoo! Autos.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Re: Re: Re: Tx Path
Eric Blossom wrote: On Fri, Apr 20, 2007 at 08:26:25PM +0200, Anmar wrote: explain why this is happening? OK, here goes, one more time: there is state in the AD9862 -- its DUC phase register -- that we can't control from software. Do you understand what that means? Yes Have you looked at the AD9862 data sheet? Yes, and I have red about the Tx moeds and the clock timing. If you cycle power on the USRP _each time_ before you run the experiment, do you get repeatable results? well, today I tried without each time powering on the usrp, and I get repeatable results, but when I load different code like am_tx then there will be a small phase shift, resetting the USRP I get the normal results. I made some pictures :). What daughterboards are you using? I have two basic Tx daughterboards, so each one use different AD9862. I have a question the 2 AD9862 they both get there clock in from the usrp motherboard, and that is the same clock? thanks , anmar -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: [dttsp-linux] Re: Feisty Fawn updates
I have run into my first Feisty Fawn Ubuntu update issue. usbview works perfectly and reveals the USRP 2 as connected to my computer. But running my favorite application that wishes to talk to the USRP seems to have changed behavior with python 2.5. It claims it cannot find USRP #0. Has anyone else run in to this? DttSP seems to be rocking along seamlessly as does jack and portaudio. Bob N4HY Robert McGwier wrote: I remember the first two times I ran into this sun jdk problem, I got irritated and lost my patience and removed it, so don't feel alone! Then, I took ten long breaths, read the message, and it gives explicit instructions for downloading the sun jdk documentation. It tells you to put it into the /tmp directory and then click go. It finishes. Bob -- Robert W. McGwier, Ph.D. Center for Communications Research 805 Bunn Drive Princeton, NJ 08540 (609)-924-4600 (sig required by employer) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: FRS with the FLEX400
Hello again, Thanks for those that emailed me directly with my last request. I have been able to get my transmit code to tune now, but it is still not working. All I am trying to do is fm modulate a sine wave and transmit it at a certain frequency. I have hooked up a vector signal analyzer and I see no output from the USRP. Could I have a dysfunctional daughter card? My newer code is below. Any help would be appreciated. Kevin Rudd Naval Research Laboratory myfm.py -- #!/usr/bin/env python from gnuradio import gr, eng_notation from gnuradio import usrp from gnuradio import audio from gnuradio import blks from gnuradio.eng_option import eng_option import usrp_dbid import sys class my_graph(gr.flow_graph): def __init__(self): gr.flow_graph.__init__ (self) self.u = usrp.sink_c () # the USRP sink (consumes samples) # Setup Constants self.dac_rate = self.u.dac_rate()# 128 MS/s self.usrp_interp = 400 self.u.set_interp_rate(self.usrp_interp) self.usrp_rate = self.dac_rate / self.usrp_interp# 320 kS/s self.sw_interp = 40 self.audio_rate = self.usrp_rate / self.sw_interp# 8 kS/s # Determine the daughterboard subdevice we're using tx_subdev_spec = usrp.pick_tx_subdevice(self.u) m = usrp.determine_tx_mux_value(self.u, tx_subdev_spec) self.u.set_mux(m) self.subdev = usrp.selected_subdev(self.u, tx_subdev_spec) print Using TX d'board %s % (self.subdev.side_and_name(),) # make blocks and connect them src0 = gr.sig_source_f (self.audio_rate, gr.GR_SIN_WAVE, 350, 1) fmtx = blks.nbfm_tx (self, self.audio_rate, self.usrp_rate, max_dev=2.5e3, tau=75e-6) gain = gr.multiply_const_cc (4000.0 ); self.connect (src0,fmtx,gain,self.u) # set gain, tune, and turn on transmitter self.subdev.set_gain(self.subdev.gain_range()[1]) #max Tx gain self.u.tune(self.subdev._which, self.subdev, 462562500) #self.set_freq(462562500) self.subdev.set_enable(True)# enable transmitter if __name__ == '__main__': try: my_graph().run() except KeyboardInterrupt: pass ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: [dttsp-linux] Re: Feisty Fawn updates
Eric Blossom wrote: Is your udev usrp rule still in place? Aha, that's a very good question. I'll be able to check this out yet today myself. Which kernel comes with Feisty Fawn? 2.6.29-15 Frank ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: [dttsp-linux] Re: Feisty Fawn updates
I will profess complete ignorance. What udev rule? ;-). Bob Eric Blossom wrote: On Mon, Apr 23, 2007 at 11:15:40AM -0400, Robert W McGwier wrote: I have run into my first Feisty Fawn Ubuntu update issue. usbview works perfectly and reveals the USRP 2 as connected to my computer. But running my favorite application that wishes to talk to the USRP seems to have changed behavior with python 2.5. It claims it cannot find USRP #0. Has anyone else run in to this? DttSP seems to be rocking along seamlessly as does jack and portaudio. Bob N4HY Bob, Is your udev usrp rule still in place? Which kernel comes with Feisty Fawn? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Robert W. McGwier, Ph.D. Center for Communications Research 805 Bunn Drive Princeton, NJ 08540 (609)-924-4600 (sig required by employer) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: [dttsp-linux] Re: Feisty Fawn updates
/etc/udev/rules.d/10-usrp.rules
which sez
ACTION==add, BUS==usb, SYSFS{idVendor}==fffe,
SYSFS{idProduct}==0002, GROUP:=usrp, MODE:=0660
Frank
On 4/23/07, Bob McGwier [EMAIL PROTECTED] wrote:
I will profess complete ignorance. What udev rule?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] lfrx+loop antenna
( retrying due to dns/email errors ) On Fri, 2007-04-13 at 13:32 -0700, Matt Ettus wrote: konvak wrote: hello all, I am thinking about building loop antenna for 3-6 MHz to receive some DRM stations. As I understand it the loop antenna is parallel I think Chuck Swiger did something with a loop antenna and a USRP a while ago. You might check out his web pages. Im using this loop antenna: http://www.kr1st.com/swlloop.htm The small pickup loop matches to 50 ohm coax for coupling to preamps and the rx boards. --Chuck ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Maximum I/Q signals frequency limit for TX
Hi guys, I'm trying to generate complex I/Q waveforms using this command (for 700 KHz): ./usrp_siggen.py -T A -w 70 -f 0 From the mailing list, I've read that the USRP can transmit up to 44 MHz. Unfortunately I can only transmit clean quadrature I/Q signal only up to 700 kHz. Above the frequency, I'm starting to see two or more waveforms for each generated quadrature I/Q signals. If I increase the frequency further to 1 MHz, USRP only generate one signal from TX_A connector, there is no signal from TX_B connector. Both TX_A and TX_B connectors are on daughter board of 'USRP Tx side A' as indicated by '-T' flag. FYI, I'm using LFTX daughter board not the Basic ones. If I transmit more than 1 MHz, the frequency is still cap at 1 MHz. Any idea what is happening and how to get higher frequency? Thanks, Regards, Shaiful __ 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] Maximum I/Q signals frequency limit for TX
Shaiful wrote: Hi guys, I'm trying to generate complex I/Q waveforms using this command (for 700 KHz): ./usrp_siggen.py -T A -w 70 -f 0 From the mailing list, I've read that the USRP can transmit up to 44 MHz. Unfortunately I can only transmit clean quadrature I/Q signal only up to 700 kHz. Above the frequency, I'm starting to see two or more waveforms for each generated quadrature I/Q signals. If I increase the frequency further to 1 MHz, USRP only generate one signal from TX_A connector, there is no signal from TX_B connector. Both TX_A and TX_B connectors are on daughter board of 'USRP Tx side A' as indicated by '-T' flag. FYI, I'm using LFTX daughter board not the Basic ones. If I transmit more than 1 MHz, the frequency is still cap at 1 MHz. Any idea what is happening and how to get higher frequency? Thanks, From the mailing list, I've read that the USRP can transmit up to 44 MHz. Unfortunately I can only transmit clean quadrature I/Q signal only up to 700 kHz. Above the frequency, I'm starting to see two or more waveforms for each generated quadrature I/Q signals. If I increase the frequency further to 1 MHz, USRP only generate one signal from TX_A connector, there is no signal from TX_B connector. Both TX_A and TX_B connectors are on daughter board of 'USRP Tx side A' as indicated by '-T' flag. FYI, I'm using LFTX daughter board not the Basic ones. If I transmit more than 1 MHz, the frequency is still cap at 1 MHz. Any idea what is happening and how to get higher frequency? Yes. the -w frequency is the baseband frequency. To go higher you need to change the -f frequency which is the carrier frequency, or lower the interpolation rate. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: Re: Re: Re: Tx Path
Anmar wrote: What daughterboards are you using? I have two basic Tx daughterboards, so each one use different AD9862. I have a question the 2 AD9862 they both get there clock in from the usrp motherboard, and that is the same clock? The AD9862s (which are on the motherboard) both get the same clock from AD9513 clock distribution IC. The only difference is that the clock signal goes through separate (but identical) filters on its way to each AD9862. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: [dttsp-linux] Re: Feisty Fawn updates
On Mon, Apr 23, 2007 at 11:32:18AM -0400, Robert W McGwier wrote: I will profess complete ignorance. What udev rule? ;-). Bob This one ;) http://gnuradio.org/trac/wiki/UdevConfig Eric Eric Blossom wrote: On Mon, Apr 23, 2007 at 11:15:40AM -0400, Robert W McGwier wrote: I have run into my first Feisty Fawn Ubuntu update issue. usbview works perfectly and reveals the USRP 2 as connected to my computer. But running my favorite application that wishes to talk to the USRP seems to have changed behavior with python 2.5. It claims it cannot find USRP #0. Has anyone else run in to this? DttSP seems to be rocking along seamlessly as does jack and portaudio. Bob N4HY Bob, Is your udev usrp rule still in place? Which kernel comes with Feisty Fawn? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Maximum I/Q signals frequency limit for TX
On Mon, Apr 23, 2007 at 09:42:46AM -0700, Matt Ettus wrote: Shaiful wrote: Hi guys, I'm trying to generate complex I/Q waveforms using this command (for 700 KHz): ./usrp_siggen.py -T A -w 70 -f 0 From the mailing list, I've read that the USRP can transmit up to 44 MHz. Unfortunately I can only transmit clean quadrature I/Q signal only up to 700 kHz. Above the frequency, I'm starting to see two or more waveforms for each generated quadrature I/Q signals. As Matt mentions below, there are two things you can adjust: the RF center frequency with -f RF_FREQ and the baseband data sample rate. To increase the baseband sample rate, use the -i INTERP option. Try -i 32. That'll give you a baseband sample rate of 128M/32 = 4M samples/s. The defaults give a baseband sample rate of 1MS/s which is consistent with your report. [EMAIL PROTECTED] usrp]$ ./usrp_siggen.py --help usage: usrp_siggen.py [options] options: -h, --helpshow this help message and exit -T TX_SUBDEV_SPEC, --tx-subdev-spec=TX_SUBDEV_SPEC select USRP Tx side A or B -f RF_FREQ, --rf-freq=RF_FREQ set RF center frequency to FREQ -i INTERP, --interp=INTERP set fgpa interpolation rate to INTERP [default=64] --sinegenerate a complex sinusoid [default] --const generate a constant output --gaussiangenerate Gaussian random output --uniform generate Uniform random output -w WAVEFORM_FREQ, --waveform-freq=WAVEFORM_FREQ set waveform frequency to FREQ [default=10.0] -a AMPL, --amplitude=AMPL set waveform amplitude to AMPLITUDE [default=16000.0] -o OFFSET, --offset=OFFSET set waveform offset to OFFSET [default=0] Unfortunately I can only transmit clean quadrature I/Q signal only up to 700 kHz. Above the frequency, I'm starting to see two or more waveforms for each generated quadrature I/Q signals. If I increase the frequency further to 1 MHz, USRP only generate one signal from TX_A connector, there is no signal from TX_B connector. Both TX_A and TX_B connectors are on daughter board of 'USRP Tx side A' as indicated by '-T' flag. FYI, I'm using LFTX daughter board not the Basic ones. If I transmit more than 1 MHz, the frequency is still cap at 1 MHz. Any idea what is happening and how to get higher frequency? Yes. the -w frequency is the baseband frequency. To go higher you need to change the -f frequency which is the carrier frequency, or lower the interpolation rate. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: [dttsp-linux] Re: Feisty Fawn updates
On Mon, Apr 23, 2007 at 03:18:23PM -0400, Robert McGwier wrote: YOU MEAN RTFM? Well, that worked. EVERY step has to be done. I guess that is why there is a manual. We don't have many docs, but we do try to get the ones we have right ;) Glad to hear it's working! Thanks, Bob Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Memory leak in wxgtk
I have been running the usrp wfm stereo receiver for a few hours under Feisty Field Rat from Ubuntu. The memory percentage for the python is absolutely steady at 4.0%. The same with the Xorg process (at 1.9%). It appears the memory leak has been repaired. Bob -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair Taking fun as simply fun and earnestness in earnest shows how thoroughly thou none of the two discernest. - Piet Hine ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Memory leak in wxgtk
On Mon, Apr 23, 2007 at 04:13:06PM -0400, Robert McGwier wrote: I have been running the usrp wfm stereo receiver for a few hours under Feisty Field Rat from Ubuntu. The memory percentage for the python is absolutely steady at 4.0%. The same with the Xorg process (at 1.9%). It appears the memory leak has been repaired. Bob That's good news! I like it when other people fix bugs that we've been tripping over... Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Question on accessing ADC I/Q outputs on RFX2400 debug headers
Hello, I would like access to the I and Q output data (12 bits each) from ADC U601 using the debug headers from two RFX2400 daughterboards and was wondering if someone could assist my understanding and tell me if what I am doing is right or wrong prior to my actually implementing this on the USRP. Specific questions are labelled with a Q in what follows. Based on a couple of mailing list discussions I was able to figure out the following. Output enable all the general purpose i/o pins referred to below: * Each d'board has 16-bits of general purpose i/o. * Setting the bit makes it an output from the FPGA to the d'board. * This register is initialized based on a value stored in the * d'board EEPROM. In general, you shouldn't be using this routine * without a very good reason. Using this method incorrectly will * kill your USRP motherboard and/or daughterboard. */ bool _write_oe (int which_dboard, int value, int mask); u = usrp.sink_c(0, 64) side0 = 0 # side A u._write_oe(side0, 0x, 0x) # set all i/o pins as outputs side1=1 # side B u._write_oe(side1, 0x, 0x) # set all i/o pins as outputs Next output enable the debug pins and enable them as debug outputs. u._write_fpga_reg(FR_DEBUG_EN, ??) -- Q. I am not sure how to safely output enable the debug outputs. Would 0xf do the job? Q. I am also not sure how to assign the 12 I bits and the 12 Q bits from U601 across the daughterboard headers. Would the following in usrp_std.v (master_control) do the trick? .debug_0(rx_a_a[11:4]),.debug_1(rx_a_a[3:0]), .debug_2(rx_b_a[11:4]),.debug_3(rx_b_a[3:0]), ); Q. I was a little confused about the RX Nets beside J24 and TX Nets beside J101 in the 2400 receiver and transmitter schematics, respectively. Can someone please explain? Thanks very much in advance! -Nikhil ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question on accessing ADC I/Q outputs on RFX2400 debug headers
On Mon, Apr 23, 2007 at 11:17:59PM -0400, Nikhil wrote: Hello, I would like access to the I and Q output data (12 bits each) from ADC U601 using the debug headers from two RFX2400 daughterboards and was wondering if someone could assist my understanding and tell me if what I am doing is right or wrong prior to my actually implementing this on the USRP. Specific questions are labelled with a Q in what follows. Based on a couple of mailing list discussions I was able to figure out the following. Output enable all the general purpose i/o pins referred to below: * Each d'board has 16-bits of general purpose i/o. * Setting the bit makes it an output from the FPGA to the d'board. * This register is initialized based on a value stored in the * d'board EEPROM. In general, you shouldn't be using this routine * without a very good reason. Using this method incorrectly will * kill your USRP motherboard and/or daughterboard. */ bool _write_oe (int which_dboard, int value, int mask); u = usrp.sink_c(0, 64) side0 = 0 # side A u._write_oe(side0, 0x, 0x) # set all i/o pins as outputs side1=1 # side B u._write_oe(side1, 0x, 0x) # set all i/o pins as outputs Oops! You've now smoked two RFX-2400 boards and/or the FPGA ;) The daughterboard and the FPGA are both driving at least pin 2. Though the pins are called general purpose i/o, that doesn't mean the user should mess with all of them. Some of them are used by the daugtherboard code to control or read status from parts on the daughterboards. Which pins are safe for the user to mess with depends on the design of the given daughterboard. Hence our scary warning on _write_oe. Step one: Look at the schematics for the RFX-2400 board and figure out which of the 16 i/o pins are actually used by the Tx and Rx halves of the transceiver daughterboard, and which ones are available for your use. See which of the i/o pins actually makes it to the header on the board. Step two: Look again and check your work. Step three: Look at the daughterboard code (db_flexrf.py). See what it's doing to the various output enables and i/o pins. Does this match your understanding of which pins are available for your use? Step four: Confirm again which pins are safe for you to be messing with. (I _believe_ that the high 7-bits are available for your use. It might be 8, but I haven't looked at the schematics in a _long_ time. I'm not kidding when I say _you_ should check the schematics.) Now figure out new values for the calls to u._write_oe(...), that only change the OE values of the pins that make it to the header and aren't used for some other purpose by the code that's controlling the daughterboard. Next output enable the debug pins and enable them as debug outputs. u._write_fpga_reg(FR_DEBUG_EN, ??) -- Q. I am not sure how to safely output enable the debug outputs. Would 0xf do the job? All the output enables are controlled using _write_oe. FR_DEBUG_EN determines whether the debug pins are routed to the i/o pins or whether the normal write_io and auto T/R values make it to the header. See the bottom of master_control.v for the details. Given what you'll find out after you look at the schematics, no value of FR_DEBUG_EN except for 0 is safe when you're using two RFX-2400 boards. Q. I am also not sure how to assign the 12 I bits and the 12 Q bits from U601 across the daughterboard headers. Would the following in usrp_std.v (master_control) do the trick? .debug_0(rx_a_a[11:4]),.debug_1(rx_a_a[3:0]), .debug_2(rx_b_a[11:4]),.debug_3(rx_b_a[3:0]), ); Q. I was a little confused about the RX Nets beside J24 and TX Nets beside J101 in the 2400 receiver and transmitter schematics, respectively. Can someone please explain? Thanks very much in advance! -Nikhil If you can get by with a single RFX-2400, my suggestion is that you put it on the A-side, and then put a Basic Tx and a Basic Rx on the B-side. Then you've got a total of 32 uncommitted i/o pins on the B-side. The FR_DEBUG_EN register wasn't designed to solve every possible problem. It solved the one we had, which was getting debug info out to a Basic Rx and/or Basic Tx ;) Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
