Re: [Discuss-gnuradio] increasing output power from lftx with resistor mod gives saturated output
According to the AD8047 datasheet, the output voltage range is +/- 3 volts into a 150 ohm load. That works out I believe to 30 milli-watts of output. So it should be able to sink sufficient current to do better than what I'm observing... On Wednesday, July 30, 2014 4:22 PM, Marcus D. Leech wrote: On 07/30/2014 04:14 PM, emat...@yahoo.com wrote: > Hello- > > I have attempted to increase the output power from my Rev 2.2 LFTX as per > instructions from Matt Ettus on this list dated Aug 3 2013 in which he > suggests reducing the values of resistors R3 and R5, but I am seeing a > clipped output at peak values much less than expected. > > Using the ettus.com LFTX schematic as a guide, I left the resistors on the > board untouched, but soldered wires to either side of R3 and R5 to add > additional resistors in parallel. My first attempt was with resistors of > value 220 ohms; I figured this would about halve the value at R3 and R5 which > are originally 225 ohms. I do see some increase in output power, but very > minimal. Specifically, whereas before I was observing 1 V P-P, or about 2.5 > milli-watts on an oscilloscope that is 50-ohm DC coupled, I am now seeing > 1.34 V P-P, or about 4.6 milli-watts with a 1 kHz sine-wave. To obtain this > without clipping I had to reduce the amplitude on the USRP sink block from 1 > to about .77, othwerwise the tops of the sinusoids flatten anywhere above the > 1.34 V P-P level. So I appear to be saturated. > > I am using a USRP1 Rev. 3. I verified that the LFTX output op-amp in > question is supplied with +/- 3.3 volts, so I don't see why it is clipping at > half of this. > > I am hoping to use the LFTX in an HF Ham radio application. I have > mini-circuits ZHL-1A TX pre-amplifier for this purpose, but was hoping to > obtain a little more output from the LFTX than I am currently getting to > drive the ZHL-1A. Any thoughts? > > Thanks! > > Eric > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio I would look at the datasheet for the driver amp. But +6dBm is pretty-close to the max output of the DAC as I recall, so you might be better to just put an interstitial amplifier in place. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] increasing output power from lftx with resistor mod gives saturated output
Hello- I have attempted to increase the output power from my Rev 2.2 LFTX as per instructions from Matt Ettus on this list dated Aug 3 2013 in which he suggests reducing the values of resistors R3 and R5, but I am seeing a clipped output at peak values much less than expected. Using the ettus.com LFTX schematic as a guide, I left the resistors on the board untouched, but soldered wires to either side of R3 and R5 to add additional resistors in parallel. My first attempt was with resistors of value 220 ohms; I figured this would about halve the value at R3 and R5 which are originally 225 ohms. I do see some increase in output power, but very minimal. Specifically, whereas before I was observing 1 V P-P, or about 2.5 milli-watts on an oscilloscope that is 50-ohm DC coupled, I am now seeing 1.34 V P-P, or about 4.6 milli-watts with a 1 kHz sine-wave. To obtain this without clipping I had to reduce the amplitude on the USRP sink block from 1 to about .77, othwerwise the tops of the sinusoids flatten anywhere above the 1.34 V P-P level. So I appear to be saturated. I am using a USRP1 Rev. 3. I verified that the LFTX output op-amp in question is supplied with +/- 3.3 volts, so I don't see why it is clipping at half of this. I am hoping to use the LFTX in an HF Ham radio application. I have mini-circuits ZHL-1A TX pre-amplifier for this purpose, but was hoping to obtain a little more output from the LFTX than I am currently getting to drive the ZHL-1A. Any thoughts? Thanks! Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] increasing output power from lftx with resistor mod gives saturated output
Hello- I have attempted to increase the output power from my Rev 2.2 LFTX as per instructions from Matt Ettus on this list dated Aug 3 2013 in which he suggests reducing the values of resistors R3 and R5, but I am seeing a clipped output at peak values much less than expected. Using the ettus.com LFTX schematic as a guide, I left the resistors on the board untouched, but soldered wires to either side of R3 and R5 to add additional resistors in parallel. My first attempt was with resistors of value 220 ohms; I figured this would about halve the value at R3 and R5 which are originally 225 ohms. I do see some increase in output power, but very minimal. Specifically, whereas before I was observing 1 V P-P, or about 2.5 milli-watts on an oscilloscope that is 50-ohm DC coupled, I am now seeing 1.34 V P-P, or about 4.6 milli-watts with a 1 kHz sine-wave. To obtain this without clipping I had to reduce the amplitude on the USRP sink block from 1 to about .77, othwerwise the tops of the sinusoids flatten anywhere above the 1.34 V P-P level. So I appear to be saturated. I am using a USRP1 Rev. 3. I verified that the LFTX output op-amp in question is supplied with +/- 3.3 volts, so I don't see why it is clipping at half of this. I am hoping to use the LFTX in an HF Ham radio application. I have mini-circuits ZHL-1A TX pre-amplifier for this purpose, but was hoping to obtain a little more output from the LFTX than I am currently getting to drive the ZHL-1A. Any thoughts? Thanks! Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] missing internal callbacks
Hello- when creating a flowgraph in GRC there are times I would like to change the decimation on-the-fly with a gui slider. However, this does not work because the decimation factor in blocks such as the AM Demod or Decimating Fir Filter does not have an internal callback (as I understand it). My main purpose is to be able to dynamically change the sampling rate to re-scale the x-axis in a gui fft sink while the flowgraph is operating. Is there a way around this? Is this a necessary limitation, or just something nobody has gotten around to implementing? Thanks! Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] filename using time-stamp in GRC
Alexandru- I thought I would revisit the "dynamic file creation" issue under GRC. The last suggestion was to simply code this up as a GRC custom block. I was hoping to get some help from you on this, since my GRC/python programming skills are very limited. I have modified a simple GRC-created python code by hand to implement your dynamic filename creation capability. It seems to work- a new file is created each time I click the button, but as I said it is hand-generated in python. Any chance you could try to implement this as a GRC block? I've attached the code, and annotated the relevant sections with the words "File Recording". I really think this would be a great addition to GRC. Any help would be appreciated. Thanks, eric --- On Thu, 1/20/11, Alexandru Csete wrote: > From: Alexandru Csete > Subject: Re: [Discuss-gnuradio] filename using time-stamp in GRC > To: discuss-gnuradio@gnu.org > Date: Thursday, January 20, 2011, 11:41 AM > On Thu, Jan 20, 2011 at 5:41 > PM, > wrote: > > > ... > > Following up on this, I found this site that had some > useful suggestions:http://www.oz9aec.net/index.php/gnu-radio/grc-examples > > > > A grc example is provided that implements a dynamic > time stamp, but NOT a button to control it. So I am trying > to use a Variable Chooser to select between "/dev/null" and > the filename that is based on the time-stamp. However, > nothing is generated. In particular, I have: > > > > A file sink with File: recfile > > A Variable with ID prefix with Value "./" > > A Variable Chooser with ID: recfile, Default Value: > "/dev/null" and > > Choices of "/dev/null" or "prefix + > datetime.now().strftime("%Y.%m.%d.%H.%M.%S") + ".bin" > > > > I was hoping this would dynamically create a file with > the current time stamp for the name, but no files are > actually being generated. Could this be and issue related > to a bug that is described in the link below? > > > > http://lists.gnu.org/archive/html/discuss-gnuradio/2011-01/msg00080.html > > > > If so, will this approach work if I upgrade via git? > > > > Hi Eric, > > The problem with this simple example is that the variable > containing > > "prefix + datetime.now().strftime("%Y.%m.%d.%H.%M.%S") + > ".bin" > > is evaluated when you start the script, so it will only > work for a > single file per execution. I believe it is for the same > reason that > you see no file with your modification: The file sink is > initialized > with /dev/null as filename and it can not change the file > name during > runtime because the required code for "close file, set new > file name, > open new file" is not generated by GRC - I am not exactly > sure about > this but it should be obvious if you look in the generated > code. I > would try to do as Josh said in the other mail, implement > the required > code yourself and embed it as a custom block. > > Alex > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > dynamic_file_prototype.py Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] grc amplitude demodulation questions
Getting back to my question about adjusting decimation on the fly, and having the FFT sink adjust to show the spectrum correctly, I have an example of what I am doing on my site at: www.nd.edu/~ematlis/z.gnuradio There's a jpg and the grc file there. If anybody would care to take a look and comment, that would be great. Basically, I want to dynamically adjust the software decimation going on in the AM Demod block, and have the result shown correctly in the FFT sink. What I am seeing is the x-axis of the FFT changes, but not the position of the spectrum. A variable slider is used to control the decimation value in the AM Demod block, and the Sample Rate in the FFT sink is dependent on the same variable, but something is not correct. Thanks, eric --- On Fri, 1/14/11, Josh Blum wrote: > From: Josh Blum > Subject: Re: [Discuss-gnuradio] grc amplitude demodulation questions > To: discuss-gnuradio@gnu.org > Date: Friday, January 14, 2011, 2:14 PM > > > I believe the code is already doing this. Here > are code segments for > > 2 fft guis. The first shows the fft of the raw > output of the USRP2. > > This gui responds correctly. Notice the line: > > "sample_rate=100e6/usrp2_decim", so I assume that as I > dynamically > > adjust usrp2_decim, this value is being updated. > However, with the > > second fft, while there is a similar line: > > "sample_rate=100e6/usrp2_decim/sw_decim" that includes > the software > > decimation value, this fft gui does not correct the > position of the > > fft when I dynamically change sw_decim. The > x-axis DOES change, but > > the peaks in the spectrum just stay fixed in their > relative > > positions. Any thoughts? > > > > Where else is sw_decim used? Is it used in a parameter that > can be > changed at runtime? Look at the generated source code, see > set_sw_decim > > -Josh > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] filename using time-stamp in GRC
--- On Thu, 1/20/11, Alexandru Csete wrote: > From: Alexandru Csete > Subject: Re: [Discuss-gnuradio] filename using time-stamp in GRC > To: discuss-gnuradio@gnu.org > Date: Thursday, January 20, 2011, 11:41 AM > On Thu, Jan 20, 2011 at 5:41 > PM, > wrote: > > > ... > > Following up on this, I found this site that had some > useful suggestions:http://www.oz9aec.net/index.php/gnu-radio/grc-examples > > > > A grc example is provided that implements a dynamic > time stamp, but NOT a button to control it. So I am trying > to use a Variable Chooser to select between "/dev/null" and > the filename that is based on the time-stamp. However, > nothing is generated. In particular, I have: > > > > A file sink with File: recfile > > A Variable with ID prefix with Value "./" > > A Variable Chooser with ID: recfile, Default Value: > "/dev/null" and > > Choices of "/dev/null" or "prefix + > datetime.now().strftime("%Y.%m.%d.%H.%M.%S") + ".bin" > > > > I was hoping this would dynamically create a file with > the current time stamp for the name, but no files are > actually being generated. Could this be and issue related > to a bug that is described in the link below? > > > > http://lists.gnu.org/archive/html/discuss-gnuradio/2011-01/msg00080.html > > > > If so, will this approach work if I upgrade via git? > > > > Hi Eric, > > The problem with this simple example is that the variable > containing > > "prefix + datetime.now().strftime("%Y.%m.%d.%H.%M.%S") + > ".bin" > > is evaluated when you start the script, so it will only > work for a > single file per execution. I believe it is for the same > reason that > you see no file with your modification: The file sink is > initialized > with /dev/null as filename and it can not change the file > name during > runtime because the required code for "close file, set new > file name, > open new file" is not generated by GRC - I am not exactly > sure about > this but it should be obvious if you look in the generated > code. I > would try to do as Josh said in the other mail, implement > the required > code yourself and embed it as a custom block. > > Alex > Thank you all. Eric > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] filename using time-stamp in GRC
--- On Wed, 1/19/11, emat...@yahoo.com wrote: > From: emat...@yahoo.com > Subject: [Discuss-gnuradio] filename using time-stamp in GRC > To: discuss-gnuradio@gnu.org > Date: Wednesday, January 19, 2011, 12:47 PM > He all- > > is there a way to implement a button controlling a > record-to-file function where the filename is generated > instantly from the current time stamp? I can do this > manually in python as follows (taken from a previously > existing gnuradio code): > > # > # Recording file, in case we > ever need to record baseband data > # > self.recording = > gr.file_sink(gr.sizeof_float, "/dev/null") > self.recording_state = False > # Filename prefix for recording > file > self.prefix = options.prefix > > # We come up with recording > turned off, but the user may > # request recording later > on > self.recording.close() > > . > . > . > > self.connect (self.source, > self.recording) > > . > . > . > > # Data recording control > buttonbox = > wx.BoxSizer(wx.HORIZONTAL) > self.record_control = > form.button_with_callback(self.panel, > > label="Recording Data: Off > > > > ", > > callback=self.toggle_recording) > > > buttonbox.Add(self.record_control, 0, wx.CENTER) > > . > . > . > > # > # Turn recording on/off > # Called-back by "Recording" button > # > def toggle_recording(self): > # Pick up localtime, for > generating filenames > timestamp = time.localtime() > > # Generate filenames for both > data and header file > filename = > "%04d_%02d_%02d_%02d:%02d:%02d.dat" % (timestamp.tm_year, > timestamp.tm_mon, > timestamp.tm_mday, > timestamp.tm_hour, timestamp.tm_min,timestamp.tm_sec) > > # Current recording? Flip > state > if (self.recording_state == > True): > self.recording_state = > False > > self.record_control.SetLabel("Recording Data: Off > > > > ") > self.recording.close() > # Not recording? > else: > self.recording_state = > True > > self.record_control.SetLabel("Recording Data to: > "+filename) > > # Cause gr_file_sink > object to accept new filename > # note > use of self.prefix--filename prefix from > > # command line (defaults to ./) > # > self.recording.open > (self.prefix+filename) > > > Thanks! > eric > Following up on this, I found this site that had some useful suggestions:http://www.oz9aec.net/index.php/gnu-radio/grc-examples A grc example is provided that implements a dynamic time stamp, but NOT a button to control it. So I am trying to use a Variable Chooser to select between "/dev/null" and the filename that is based on the time-stamp. However, nothing is generated. In particular, I have: A file sink with File: recfile A Variable with ID prefix with Value "./" A Variable Chooser with ID: recfile, Default Value: "/dev/null" and Choices of "/dev/null" or "prefix + datetime.now().strftime("%Y.%m.%d.%H.%M.%S") + ".bin" I was hoping this would dynamically create a file with the current time stamp for the name, but no files are actually being generated. Could this be and issue related to a bug that is described in the link below? http://lists.gnu.org/archive/html/discuss-gnuradio/2011-01/msg00080.html If so, will this approach work if I upgrade via git? Thanks! eric > > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] filename using time-stamp in GRC
He all- is there a way to implement a button controlling a record-to-file function where the filename is generated instantly from the current time stamp? I can do this manually in python as follows (taken from a previously existing gnuradio code): # # Recording file, in case we ever need to record baseband data # self.recording = gr.file_sink(gr.sizeof_float, "/dev/null") self.recording_state = False # Filename prefix for recording file self.prefix = options.prefix # We come up with recording turned off, but the user may # request recording later on self.recording.close() . . . self.connect (self.source, self.recording) . . . # Data recording control buttonbox = wx.BoxSizer(wx.HORIZONTAL) self.record_control = form.button_with_callback(self.panel, label="Recording Data: Off ", callback=self.toggle_recording) buttonbox.Add(self.record_control, 0, wx.CENTER) . . . # # Turn recording on/off # Called-back by "Recording" button # def toggle_recording(self): # Pick up localtime, for generating filenames timestamp = time.localtime() # Generate filenames for both data and header file filename = "%04d_%02d_%02d_%02d:%02d:%02d.dat" % (timestamp.tm_year, timestamp.tm_mon, timestamp.tm_mday, timestamp.tm_hour, timestamp.tm_min,timestamp.tm_sec) # Current recording? Flip state if (self.recording_state == True): self.recording_state = False self.record_control.SetLabel("Recording Data: Off ") self.recording.close() # Not recording? else: self.recording_state = True self.record_control.SetLabel("Recording Data to: "+filename) # Cause gr_file_sink object to accept new filename # note use of self.prefix--filename prefix from # command line (defaults to ./) # self.recording.open (self.prefix+filename) Thanks! eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] grc amplitude demodulation questions
--- On Fri, 1/14/11, Josh Blum wrote: > From: Josh Blum > Subject: Re: [Discuss-gnuradio] grc amplitude demodulation questions > To: discuss-gnuradio@gnu.org > Date: Friday, January 14, 2011, 2:14 PM > > > I believe the code is already doing this. Here > are code segments for > > 2 fft guis. The first shows the fft of the raw > output of the USRP2. > > This gui responds correctly. Notice the line: > > "sample_rate=100e6/usrp2_decim", so I assume that as I > dynamically > > adjust usrp2_decim, this value is being updated. > However, with the > > second fft, while there is a similar line: > > "sample_rate=100e6/usrp2_decim/sw_decim" that includes > the software > > decimation value, this fft gui does not correct the > position of the > > fft when I dynamically change sw_decim. The > x-axis DOES change, but > > the peaks in the spectrum just stay fixed in their > relative > > positions. Any thoughts? > > > > Where else is sw_decim used? Is it used in a parameter that > can be > changed at runtime? Look at the generated source code, see > set_sw_decim > > -Josh Josh- here are the two definitions generated by GRC, one to set the USRP2 decimation (via a variable slider), the second to set the "audio decimation" used in the AM Demod block: def set_usrp2_decim(self, usrp2_decim): self.usrp2_decim = usrp2_decim self.wxgui_fftsink2_0.set_sample_rate(100e6/self.usrp2_decim) self.wxgui_scopesink2_0.set_sample_rate(100e6/self.usrp2_decim) self.usrp2_source__0.set_decim(self.usrp2_decim) self._usrp2_decim_slider.set_value(self.usrp2_decim) self._usrp2_decim_text_box.set_value(self.usrp2_decim) self.wxgui_scopesink2_0_0.set_sample_rate(100e6/self.usrp2_decim/self.sw_decim) self.wxgui_fftsink2_1.set_sample_rate(100e6/self.usrp2_decim/self.sw_decim) self.high_pass_filter_0.set_taps(firdes.high_pass(1, 100e6/self.usrp2_decim/self.sw_decim, 100, 20, firdes.WIN_HAMMING, 6.76)) def set_sw_decim(self, sw_decim): self.sw_decim = sw_decim self._sw_decim_slider.set_value(self.sw_decim) self._sw_decim_text_box.set_value(self.sw_decim) self.wxgui_scopesink2_0_0.set_sample_rate(100e6/self.usrp2_decim/self.sw_decim) self.wxgui_fftsink2_1.set_sample_rate(100e6/self.usrp2_decim/self.sw_decim) self.high_pass_filter_0.set_taps(firdes.high_pass(1, 100e6/self.usrp2_decim/self.sw_decim, 100, 20, firdes.WIN_HAMMING, 6.76)) > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] grc amplitude demodulation questions
Martin, thanks for responding. See my follow ups below: --- On Thu, 1/13/11, Marcus D. Leech wrote: > From: Marcus D. Leech > Subject: Re: [Discuss-gnuradio] grc amplitude demodulation questions > To: discuss-gnuradio@gnu.org > Date: Thursday, January 13, 2011, 4:26 PM > > Hello- > > > > I am using GRC 3.3 to create a flow graph using the > USRP2 and a LFRX to do amplitude demodulation. I have > a few questions. > > > > 1) What are good values for "Audio Pass" and "Audio > Stop" within the "AM Demod" block? > > > > 2) I observe a DC offset at the output of the > demodulation. Is this expected, and what is the best > way to remove it? I am currently using a high-pass > filter. My incoming signal is a 27 kHz sine modulated > at 1 kHz. > There will always be a certain amount of DC offset in an AM > demodulator, since it's just a power detector, and since the > RF chain always > produces at least *some* noise, the detected version > of that noise results in a small residual DC offset. You can > null it out with an > an "ADD" block. I've tried an ADD block, but I noticed that if my decimation is not a power of 2, the offset changes. > > > 3) I am sending the result to an FFT sink. I > instituted a variable slider to control the decimation > within the AM Demod block, but when I change that > decimation, the displayed fft trace does not adjust > correctly to the new sample rate. In fact, the fft > trace remains in a fixed position; the only thing that > changes in the plot is the x-axis, ie frequency. I > have a second slider for the usrp2 decimation which does > change the displayed spectrum correctly, so that the peaks > move to the correct position. Any thoughts? > The FFT sink isn't psychic. It needs to be told what > the current sample rate is, so if you change decimation on > the fly, you'll need to > arrange for the FFT sink to know about the new > sample rate. I believe the code is already doing this. Here are code segments for 2 fft guis. The first shows the fft of the raw output of the USRP2. This gui responds correctly. Notice the line: "sample_rate=100e6/usrp2_decim", so I assume that as I dynamically adjust usrp2_decim, this value is being updated. However, with the second fft, while there is a similar line: "sample_rate=100e6/usrp2_decim/sw_decim" that includes the software decimation value, this fft gui does not correct the position of the fft when I dynamically change sw_decim. The x-axis DOES change, but the peaks in the spectrum just stay fixed in their relative positions. Any thoughts? 1st FFT:self.wxgui_fftsink2_0 = fftsink2.fft_sink_c( self.notebook_0.GetPage(1).GetWin(), baseband_freq=0, y_per_div=20, y_divs=10, ref_level=10, ref_scale=2.0, sample_rate=100e6/usrp2_decim, fft_size=1024, fft_rate=10, average=False, avg_alpha=None, title="Total Signal FFT", peak_hold=False, ) 2nd FFT:self.wxgui_fftsink2_1 = fftsink2.fft_sink_f( self.notebook_0.GetPage(3).GetWin(), baseband_freq=0, y_per_div=20, y_divs=10, ref_level=10, ref_scale=2.0, sample_rate=100e6/usrp2_decim/sw_decim, fft_size=1024, fft_rate=10, average=False, avg_alpha=None, title="Demodulated FFT Plot", peak_hold=False, > > > -- Marcus Leech > Principal Investigator > Shirleys Bay Radio Astronomy Consortium > http://www.sbrac.org > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] grc amplitude demodulation questions
Hello- I am using GRC 3.3 to create a flow graph using the USRP2 and a LFRX to do amplitude demodulation. I have a few questions. 1) What are good values for "Audio Pass" and "Audio Stop" within the "AM Demod" block? 2) I observe a DC offset at the output of the demodulation. Is this expected, and what is the best way to remove it? I am currently using a high-pass filter. My incoming signal is a 27 kHz sine modulated at 1 kHz. 3) I am sending the result to an FFT sink. I instituted a variable slider to control the decimation within the AM Demod block, but when I change that decimation, the displayed fft trace does not adjust correctly to the new sample rate. In fact, the fft trace remains in a fixed position; the only thing that changes in the plot is the x-axis, ie frequency. I have a second slider for the usrp2 decimation which does change the displayed spectrum correctly, so that the peaks move to the correct position. Any thoughts? 4) Related to the above- I thought I'd mention that if I move the usrp2 decimation slider bar too quickly, the fft plot then fails to adjust the fft trace correctly - I have to move the bar slowly. 5) Occasionally I am seeing a random error which causes the flowgraph to freeze: Executing: "/home/matlis/Downloads/top_block.py" Error: failed to enable realtime scheduling. >>> gr_fir_fff: using SSE Traceback (most recent call last): File "/usr/local/lib64/python2.6/site-packages/gnuradio/wxgui/plotter/plotter_base.py", line 187, in _on_paint for fcn in self._draw_fcns: fcn[1]() File "/usr/local/lib64/python2.6/site-packages/gnuradio/wxgui/plotter/plotter_base.py", line 59, in draw self._draw() File "/usr/local/lib64/python2.6/site-packages/gnuradio/wxgui/plotter/grid_plotter_base.py", line 395, in _draw_p oint_label label_str = self._populate_point_label(x_val, y_val) File "/usr/local/lib64/python2.6/site-packages/gnuradio/wxgui/plotter/channel_plotter.py", line 149, in _populate _point_label y_value = (samples[x_index_high] - samples[x_index_low])*scale + samples[x_index_low] IndexError: index out of bounds >>> Done Thanks for any suggestions! eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] am antenna
Hello all- can anyone suggest a source for an am-band antenna for the usrp? I need to acquire signals in the frequency band between roughly 1 to 2 MHz. Something small and compact would be nice. Thanks, eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] determining rms of AM carrier
Hello- I am interested in determining the rms strength of the carrier of an AM modulated waveform, and displaying it in realtime, perhaps as a windowed average value. I am using the LFRX boards on the USRP. This question probably comes up a lot in the SNR and RSSI related posts, but perhaps not specifically for my application. Are there currently tools available in the gnuradio libs for this? If not, I would appreciate a run-down of what technique is needed to do this, and if there are any related codes that can be used as a guide. In principle it would seem to me that just measuring the rms of the I or Q stream would be sufficient if the modulation index is low (which it is). If not, then perhaps dividing the I or Q stream with the modulation (obtained with gr.complex_to_mag())? Thanks, eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp usb problem with Mandriva 2010.1
--- On Wed, 8/11/10, Thomas Tsou wrote: > From: Thomas Tsou > Subject: Re: [Discuss-gnuradio] usrp usb problem with Mandriva 2010.1 > To: emat...@yahoo.com > Cc: discuss-gnuradio@gnu.org > Date: Wednesday, August 11, 2010, 1:52 PM > On Wed, Aug 11, 2010 at 11:07 > AM, > wrote: > > Hello- > > > > I am having a usb/USRP issue under x86_64 Mandriva > 2010.1 with gnuradio-3.3.0. > > > > I compiled and installed using the default procedure: > > ./configure > > make > > sudo make install > > > > When I try to use usrp_fft.py, I get many errors (see > below). The gui pops up, but no data is displayed: > > > > [mat...@localhost z.gnuradio]$ usrp_fft.py > > fusb::_submit_urb: Bad file descriptor > > _submit_urb failed > > fusb::_submit_urb: Bad file descriptor > > _submit_urb failed > > fusb::_submit_urb: Bad file descriptor > > I'm guessing that this is the result of an attempt to > extract the file > descriptor out of a libusb-1.0 handle. The presence of the > libusb > compatibility layer - which is incompatible - may have > allowed you to > get through configure. Try building with the following > option. > > ./configure --with-fusb-tech=libusb1 > > > I believe this is a distribution-specific error, as I > was not able to duplicate the issue on a different x86_64 > Fedora 12 computer using exactly the same installation > procedure and USRP hardware. > > > > The recent Mandriva releases are among distributions (SUSE > may be > another) that drop native support for the older version of > libusb, > which gnuradio uses by default. To date, Fedora and Ubuntu > have not > made this change. > > Thomas > Thomas- thanks so much, that fixed the problem. eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] usrp usb problem with Mandriva 2010.1
Hello- I am having a usb/USRP issue under x86_64 Mandriva 2010.1 with gnuradio-3.3.0. I compiled and installed using the default procedure: ./configure make sudo make install When I try to use usrp_fft.py, I get many errors (see below). The gui pops up, but no data is displayed: [mat...@localhost z.gnuradio]$ usrp_fft.py fusb::_submit_urb: Bad file descriptor _submit_urb failed fusb::_submit_urb: Bad file descriptor _submit_urb failed fusb::_submit_urb: Bad file descriptor . . many copies of the error above, then... . fusb::_submit_urb: Bad file descriptor _submit_urb failed fusb::_submit_urb: Bad file descriptor _submit_urb failed fusb::_reap: Bad file descriptor fusb::_reap: Bad file descriptor I believe this is a distribution-specific error, as I was not able to duplicate the issue on a different x86_64 Fedora 12 computer using exactly the same installation procedure and USRP hardware. Incidentally, I had to modify the udev rules a bit to get it to work under Mandriva: [mat...@localhost z.gnuradio]$ more 10-usrp.rules ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="fffe", ATTRS{idProduct}=="0002", GROUP:="usrp", MODE:="0660" ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="077d", ATTRS{idProduct}=="0410", GROUP:="usrp", MODE:="0660" (email formatting broke up what where 2 lines originally) Any thoughts? thanks, eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP with Basic_RX
> From: Marcus D. Leech > Subject: Re: [Discuss-gnuradio] USRP with Basic_RX > To: "Johnathan Corgan" , > Discuss-gnuradio@gnu.org > Date: Tuesday, June 1, 2010, 2:32 PM > On 06/01/2010 03:15 PM, Johnathan > Corgan wrote: > > > > I think he's using a USRP2. Isn't the dual > source USRP1 only? > > > > What he's asking for is a dual, coherent DDC for the I > and Q inputs of > > a BasicRX in a USRP2. This is a common enough > request that I think it > > would be useful to put into the stock FPGA > functionality of UHD, using > > VRT to separate the samples into two separate > streams. > > > > Johnathan > > > > > Yes, that's precisely what I want. I want to be able > to treat the two > inputs of a Basic_RX as > real-sampled data that are largely independant, but > they're both tuned > to the same frequency. > > This is for precision radiometry, with a "outside world" > channel and a > "reference" channel. > > There are a couple of approaches--one using a reference > channel, and the > other switching the > entire gain chain between "outside world" and > "reference". I want to > explore both options. > The switching option would use a single input, with > the input switched. > > > > -- > Principal Investigator > Shirleys Bay Radio Astronomy Consortium > http://www.sbrac.org > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > If there is going to be a discussion on adding more functionality to the USRP2, then I would like to endorse the development of another independent DDC in the FPGA of the USRP2. I currently use 2 LFRX daughter cards in the USRP1 to obtain 4 independent real channels; I would love to be able to do the same with 2 USRP2's connected via a MIMO cable. Thanks, eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] compile errors with gcc-4.4
On Tue, 9 Jun 2009, emat...@nd.edu wrote: On Tue, 9 Jun 2009, emat...@nd.edu wrote: Hi all- I just installed Fedora 11 x86_64 which features gcc-4.4. I get compile errors such as: "gr_fft_filter_ccc.cc: In member function ‘void gr_fft_filter_ccc::compute_sizes(int)’: gr_fft_filter_ccc.cc:133: error: ‘stderr’ was not declared in this scope gr_fft_filter_ccc.cc:134: error: ‘fprintf’ was not declared in this scope" I found this post online at http://osdir.com/ml/debian-bugs-dist/2009-04/msg09184.html "Your package fails to build with GCC 4.4, which has cleaned up some more C++ headers. You always have to #include headers directly and cannot rely for things to be included indirectly." The patch to fix the problem was to explicitly add cstdio include statements. Taking that as a clue, I found that if I add "#include " to gr_fft_filter_ccc.cc that fixes the problem, however there are other files which also appear to need the same fix. Perhaps somebody can look into this? The problem appears on subversions 10991 and 11181. thanks, eric Eric H. Matlis, Ph.D. Aerospace & Mechanical Engineering Dept. 121 Hessert Center for Aerospace Research University of Notre Dame Notre Dame, IN 46556-5684 Phone: (574) 631-6054 Fax: (574) 631-8355 Updating this post- after fixing quite a few files, I ran into this different problem on svn 10991: Making all in usrp2 make[5]: Entering directory `/home/matlis/z.downloads/z.gnuradio/gnuradio_10991/usrp/firmware/src/usrp2' test -f `basename 'eeprom_boot.a51'` || ln -s 'eeprom_boot.a51' . test -f ../common/`basename 'eeprom_boot.a51'` -o \ \! -f `dirname 'eeprom_boot.a51'`/../common/`basename 'eeprom_boot.a51'` \ || ln -s `dirname 'eeprom_boot.a51'`/../common/`basename 'eeprom_boot.a51'` ../common/`basename 'eeprom_boot.a51'` asx8051 -plosgff `basename 'eeprom_boot.a51'` sdcc -mmcs51 --no-xinit-opt -I../../../../usrp/firmware/include -I../../../../usrp/firmware/src/usrp2 -I../../../../usrp/firmware/src/common -I../../../../usrp/firmware/src/common -DHAVE_USRP2 \ -c -o eeprom_init.rel `test -f 'eeprom_init.c' || echo './'`eeprom_init.c test -f `basename '_startup.a51'` || ln -s '_startup.a51' . test -f ../common/`basename '_startup.a51'` -o \ \! -f `dirname '_startup.a51'`/../common/`basename '_startup.a51'` \ || ln -s `dirname '_startup.a51'`/../common/`basename '_startup.a51'` ../common/`basename '_startup.a51'` asx8051 -plosgff `basename '_startup.a51'` sdcc -mmcs51 --no-xinit-opt --code-loc 0x --code-size 0x1800 --xram-loc 0x1800 --xram-size 0x0800 -Wl '-b USBDESCSEG = 0xE000' -L ../../lib libfx2.lib -o eeprom_boot.ihx eeprom_boot.rel eeprom_init.rel _startup.rel *** glibc detected *** /usr/libexec/sdcc/aslink: double free or corruption (fasttop): 0x01e009a0 *** === Backtrace: = /lib64/libc.so.6[0x3c14875a26] /usr/libexec/sdcc/aslink[0x40c490] /usr/libexec/sdcc/aslink[0x402d27] /lib64/libc.so.6(__libc_start_main+0xfd)[0x3c1481ea2d] /usr/libexec/sdcc/aslink[0x401219] === Memory map: 0040-00413000 r-xp 08:08 142876 /usr/libexec/sdcc/aslink 00613000-00617000 rw-p 00013000 08:08 142876 /usr/libexec/sdcc/aslink 00617000-00b1b000 rw-p 00617000 00:00 0 00c16000-00c17000 rw-p 00016000 08:08 142876 /usr/libexec/sdcc/aslink 01dff000-01e41000 rw-p 01dff000 00:00 0 [heap] 3c1420-3c1421f000 r-xp 08:08 261633 /lib64/ld-2.10.1.so 3c1441e000-3c1441f000 r--p 0001e000 08:08 261633 /lib64/ld-2.10.1.so 3c1441f000-3c1442 rw-p 0001f000 08:08 261633 /lib64/ld-2.10.1.so 3c1480-3c14964000 r-xp 08:08 261636 /lib64/libc-2.10.1.so 3c14964000-3c14b64000 ---p 00164000 08:08 261636 /lib64/libc-2.10.1.so 3c14b64000-3c14b68000 r--p 00164000 08:08 261636 /lib64/libc-2.10.1.so 3c14b68000-3c14b69000 rw-p 00168000 08:08 261636 /lib64/libc-2.10.1.so 3c14b69000-3c14b6e000 rw-p 3c14b69000 00:00 0 3c1ee0-3c1ee19000 r-xp 08:08 10872 /lib64/libgcc_s-4.4.0-20090506.so.1 3c1ee19000-3c1f019000 ---p 00019000 08:08 10872 /lib64/libgcc_s-4.4.0-20090506.so.1 3c1f019000-3c1f01a000 rw-p 00019000 08:08 10872 /lib64/libgcc_s-4.4.0-20090506.so.1 7fee10215000-7fee10217000 rw-p 7fee10215000 00:00 0 7fee1022b000-7fee1022c000 rw-p 7fee1022b000 00:00 0 7fee1022f000-7fee10232000 rw-p 7fee1022f000 00:00 0 7fff1821c000-7fff18231000 rw-p 7ffea000 00:00 0 [stack] 7fff183fe000-7fff183ff000 r-xp 7fff183fe000 00:00 0 [vdso] ff60-ff601000 r-xp 00:00 0 [vsyscall] make[5]: *** [eeprom_boot.ihx] Error 1 make[5]: Leaving directory `/home/matlis/z.downloads/z.gnuradio/gnuradio_10991/usrp/firmware/src/usrp2' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/home/matlis/z.downloads/z.gnuradio/gnuradio_10991/usrp/firmware/src' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/matlis/z.downloads/z.gnuradio/gnuradio_10991/usrp/firmware' make[2]: *** [all-recursive]
Re: [Discuss-gnuradio] compile errors with gcc-4.4
On Tue, 9 Jun 2009, emat...@nd.edu wrote: Hi all- I just installed Fedora 11 x86_64 which features gcc-4.4. I get compile errors such as: "gr_fft_filter_ccc.cc: In member function ‘void gr_fft_filter_ccc::compute_sizes(int)’: gr_fft_filter_ccc.cc:133: error: ‘stderr’ was not declared in this scope gr_fft_filter_ccc.cc:134: error: ‘fprintf’ was not declared in this scope" I found this post online at http://osdir.com/ml/debian-bugs-dist/2009-04/msg09184.html "Your package fails to build with GCC 4.4, which has cleaned up some more C++ headers. You always have to #include headers directly and cannot rely for things to be included indirectly." The patch to fix the problem was to explicitly add cstdio include statements. Taking that as a clue, I found that if I add "#include " to gr_fft_filter_ccc.cc that fixes the problem, however there are other files which also appear to need the same fix. Perhaps somebody can look into this? The problem appears on subversions 10991 and 11181. thanks, eric Eric H. Matlis, Ph.D. Aerospace & Mechanical Engineering Dept. 121 Hessert Center for Aerospace Research University of Notre Dame Notre Dame, IN 46556-5684 Phone: (574) 631-6054 Fax: (574) 631-8355 Updating this post- after fixing quite a few files, I ran into this different problem on svn 10991: Making all in usrp2 make[5]: Entering directory `/home/matlis/z.downloads/z.gnuradio/gnuradio_10991/usrp/firmware/src/usrp2' test -f `basename 'eeprom_boot.a51'` || ln -s 'eeprom_boot.a51' . test -f ../common/`basename 'eeprom_boot.a51'` -o \ \! -f `dirname 'eeprom_boot.a51'`/../common/`basename 'eeprom_boot.a51'` \ || ln -s `dirname 'eeprom_boot.a51'`/../common/`basename 'eeprom_boot.a51'` ../common/`basename 'eeprom_boot.a51'` asx8051 -plosgff `basename 'eeprom_boot.a51'` sdcc -mmcs51 --no-xinit-opt -I../../../../usrp/firmware/include -I../../../../usrp/firmware/src/usrp2 -I../../../../usrp/firmware/src/common -I../../../../usrp/firmware/src/common -DHAVE_USRP2 \ -c -o eeprom_init.rel `test -f 'eeprom_init.c' || echo './'`eeprom_init.c test -f `basename '_startup.a51'` || ln -s '_startup.a51' . test -f ../common/`basename '_startup.a51'` -o \ \! -f `dirname '_startup.a51'`/../common/`basename '_startup.a51'` \ || ln -s `dirname '_startup.a51'`/../common/`basename '_startup.a51'` ../common/`basename '_startup.a51'` asx8051 -plosgff `basename '_startup.a51'` sdcc -mmcs51 --no-xinit-opt --code-loc 0x --code-size 0x1800 --xram-loc 0x1800 --xram-size 0x0800 -Wl '-b USBDESCSEG = 0xE000' -L ../../lib libfx2.lib -o eeprom_boot.ihx eeprom_boot.rel eeprom_init.rel _startup.rel *** glibc detected *** /usr/libexec/sdcc/aslink: double free or corruption (fasttop): 0x01e009a0 *** === Backtrace: = /lib64/libc.so.6[0x3c14875a26] /usr/libexec/sdcc/aslink[0x40c490] /usr/libexec/sdcc/aslink[0x402d27] /lib64/libc.so.6(__libc_start_main+0xfd)[0x3c1481ea2d] /usr/libexec/sdcc/aslink[0x401219] === Memory map: 0040-00413000 r-xp 08:08 142876 /usr/libexec/sdcc/aslink 00613000-00617000 rw-p 00013000 08:08 142876 /usr/libexec/sdcc/aslink 00617000-00b1b000 rw-p 00617000 00:00 0 00c16000-00c17000 rw-p 00016000 08:08 142876 /usr/libexec/sdcc/aslink 01dff000-01e41000 rw-p 01dff000 00:00 0 [heap] 3c1420-3c1421f000 r-xp 08:08 261633 /lib64/ld-2.10.1.so 3c1441e000-3c1441f000 r--p 0001e000 08:08 261633 /lib64/ld-2.10.1.so 3c1441f000-3c1442 rw-p 0001f000 08:08 261633 /lib64/ld-2.10.1.so 3c1480-3c14964000 r-xp 08:08 261636 /lib64/libc-2.10.1.so 3c14964000-3c14b64000 ---p 00164000 08:08 261636 /lib64/libc-2.10.1.so 3c14b64000-3c14b68000 r--p 00164000 08:08 261636 /lib64/libc-2.10.1.so 3c14b68000-3c14b69000 rw-p 00168000 08:08 261636 /lib64/libc-2.10.1.so 3c14b69000-3c14b6e000 rw-p 3c14b69000 00:00 0 3c1ee0-3c1ee19000 r-xp 08:08 10872 /lib64/libgcc_s-4.4.0-20090506.so.1 3c1ee19000-3c1f019000 ---p 00019000 08:08 10872 /lib64/libgcc_s-4.4.0-20090506.so.1 3c1f019000-3c1f01a000 rw-p 00019000 08:08 10872 /lib64/libgcc_s-4.4.0-20090506.so.1 7fee10215000-7fee10217000 rw-p 7fee10215000 00:00 0 7fee1022b000-7fee1022c000 rw-p 7fee1022b000 00:00 0 7fee1022f000-7fee10232000 rw-p 7fee1022f000 00:00 0 7fff1821c000-7fff18231000 rw-p 7ffea000 00:00 0 [stack] 7fff183fe000-7fff183ff000 r-xp 7fff183fe000 00:00 0 [vdso] ff60-ff601000 r-xp 00:00 0 [vsyscall] make[5]: *** [eeprom_boot.ihx] Error 1 make[5]: Leaving directory `/home/matlis/z.downloads/z.gnuradio/gnuradio_10991/usrp/firmware/src/usrp2' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/home/matlis/z.downloads/z.gnuradio/gnuradio_10991/usrp/firmware/src' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/matlis/z.downloads/z.gnuradio/gnuradio_10991/usrp/firmware' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/matlis/z.downloads/z.gnu
[Discuss-gnuradio] compile errors with gcc-4.4
Hi all- I just installed Fedora 11 x86_64 which features gcc-4.4. I get compile errors such as: "gr_fft_filter_ccc.cc: In member function ‘void gr_fft_filter_ccc::compute_sizes(int)’: gr_fft_filter_ccc.cc:133: error: ‘stderr’ was not declared in this scope gr_fft_filter_ccc.cc:134: error: ‘fprintf’ was not declared in this scope" I found this post online at http://osdir.com/ml/debian-bugs-dist/2009-04/msg09184.html "Your package fails to build with GCC 4.4, which has cleaned up some more C++ headers. You always have to #include headers directly and cannot rely for things to be included indirectly." The patch to fix the problem was to explicitly add cstdio include statements. Taking that as a clue, I found that if I add "#include " to gr_fft_filter_ccc.cc that fixes the problem, however there are other files which also appear to need the same fix. Perhaps somebody can look into this? The problem appears on subversions 10991 and 11181. thanks, eric Eric H. Matlis, Ph.D. Aerospace & Mechanical Engineering Dept. 121 Hessert Center for Aerospace Research University of Notre Dame Notre Dame, IN 46556-5684 Phone: (574) 631-6054 Fax: (574) 631-8355___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] subdevice selection in USRP2
Hi all- as part of my on-going efforts to acquire 2 channels (two independent signals) on my USRP2 with an LFRX board, I would like to know if there is an equivalent to the subdevice setup code that exists for the USRP1. For example: if not self.u.set_nchannels(nchan): sys.stderr.write('set_nchannels(%d) failed\n' % (nchan,)) raise SystemExit self.subdev = self.u.db[0] + self.u.db[1] self.u.set_mux(gru.hexint(0xf0f0f1f0)) I already understand from a previous response on this list that there is only a single DDC in the USRP2 fpga image, and I can at least verify that set_nchannels, db, or set_mux is not defined for the USRP2. Are there equivalents with different syntax for the USPR2? Without them or their equivalents, is it even possible to acquire two channels with the USRP2 currently? My thought was I could get arround the existence of only 1 DDC by tuning to the midpoint of my two signals and shifting them independently to baseband in the host pc, but it seems to me I need more than this to properly setup the two signal paths. thanks, eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 2-channel AM demodulation on USRP2
Some progress with my USRP2- I am able to demodulate 1 channel while using the translating filters which I was unable to do previously. However, I don't seem to be capturing from the second channel of my LFRX. What makes me think this is that when I introduce a deinterleave block to sequence the second channel, I am seeing the frequency of the demodulated result increase by a factor of two. In other words, it seems to be deinterleaving just one stream of data so I am affectively doubling the frequency of the signal. What code do I need to implement to tell the USRP2 to capture two channels, one from each input of the LFRX? thanks, eric ematlis wrote: > > Hi all- > > I have a USRP2 with a LFRX daughterboard. I'm trying to acquire two > channels each at a separate frequency where Ch0 is amplitude modulated and > Ch1 is not. As per suggestions made to me from this list, to capture two > channels at separate frequencies I was advised to tune the USRP2 to an > average frequency and then use translating filters to capture the band > around each frequency separately. Typically the AM carrier on Ch0 is at > about 1 MHz, and the signal on Ch1 is about 5 kHz. For both channels I'm > interested in no more than 5 kHz of bandwidth. > > I'm using svn 10991 with the SD card updated to the latest fpga and > firmware images on a Fedora 10 x86_64 machine. I don't think I'm doing > this correctly since my spectra is all wrong; perhaps somebody can help me > out. First let me post my USRP1 code that does this, as this was my > starting point: > > USRP1: options.decim = 128 > > usrp_decim=options.decim > self.u = usrp.source_c(0, usrp_decim) > self.u.set_dc_offset_cl_enable(int(0),int(15)) # dc removal off > adc_rate = self.u.adc_rate()# 64 MS/s > > # Set the decimation in the FPGA > usrp_rate = adc_rate / usrp_decim # 500 kS/s > > #set the decimation in software on the host PC > sw_decim = 10 > demod_rate = usrp_rate / sw_decim # 50 kS/s > > if not self.u.set_nchannels(nchan): #nchan = 2 > sys.stderr.write('set_nchannels(%d) failed\n' % (nchan,)) > raise SystemExit > > self.subdev = self.u.db(0) + self.u.db(1) > > if (len(self.subdev) != 6 or > self.u.db(0,0).dbid() != usrp_dbid.LF_RX): > sys.stderr.write('This code requires a Basic Rx board on Side > A\n') > sys.exit(1) > > self.u.set_mux(gru.hexint(0xf0f0f1f0)) > > # deinterleave two channels from FPGA > self.di = gr.deinterleave(gr.sizeof_gr_complex) > > # Channelize the signal of interest. > lpf_coeffs = gr.firdes.low_pass (1, # gain > usrp_rate, # sampling rate > demod_rate/2, # passband > cutoff > 500, # width of > transition band > gr.firdes.WIN_HANN) > > self.lpf_0 = gr.fir_filter_fff (sw_decim,lpf_coeffs) > self.lpf_1 = gr.fir_filter_fff (sw_decim,lpf_coeffs) > > # Demodulate with classic sqrt (I*I + Q*Q) > self.magblock_0 = gr.complex_to_mag() > > # Get real part of Ch1 > self.splitter_1 = gr.complex_to_float() > > # now wire it all together > self.connect (self.u, self.di) > > # Ch 0 > self.connect ((self.di,0), self.magblock_0) > self.connect (self.magblock_0, self.lpf_0) > > # Ch 1 > self.connect ((self.di,1), self.splitter_1) > self.connect ((self.splitter_1,0),self.lpf_1) > etc > > Then I define two set_freq functions, one for each subdevice. Ch0 is > tuned to the carrier frequency of the AM signal, Ch1 is tuned to 0 Hz. > > Now, on the USRP2- since I have only one ddc, I can only tune to one > frequency: > > options.decim = 128 > freq = 1.e6 > > self.u = usrp2.source_32fc(options.interface, options.mac_addr) > self.u.set_decim(options.decim) > > adc_rate = self.u.adc_rate()# 100 MS/s > > #set the decimation in the FPGA > input_rate = self.u.adc_rate() / self.u.decim()# 781.25 kS/s > > #set the decimation in software on the host PC > sw_decim = 16 > demod_rate = input_rate / sw_decim # 48.828 kS/s > > # deinterleave four channels from FPGA > self.di = gr.deinterleave(gr.sizeof_gr_complex
Re: [Discuss-gnuradio] 2-channel AM demodulation on USRP2
On Sun, 10 May 2009, davek wrote: have you had success with your translating filters ? dave Dave- thanks much for responding. I have not yet succeeded in making my application work. Let me just review what I am trying to do. I want to capture with the USRP2 two signals; one AM with a carrier at 1 MHz and a modulation at 5 kHz. The other unmodulated at 5 kHz. I did realize after my last posting that my decimation in the FPGA was too high (sampling rate too low) to capture the bandwidth I was interested in, which is (at first anyway) 1 MHz (since my two center frequencies are separated by about that much). So I decreased the decimation to give an effective sampling rate in the FPGA of just over 2 MHz, which should be sufficient to capture (just barely) the 1 MHz AM signal and the regular one at 5 kHz. However, I still did not see what I expected. The only thing I am seeing (in addition to a random spectra in my fft sinks) is "S" printed to the screen. I'm not sure what this is exactly but it's probably an under-run error of some kind analogous to the Uu in the USRP1. For completeness, my new decimation rates are: 48 instead of 128 in the FPGA (gives a sampling rate of 2.083 MHz instead of 781.25 kHz) and 42 instead of 16 in software on the host PC to give a final acquisition rate of 49.6 kHz, which is about what I had previously (I'm interested ultimately in resolving a 5 kHz signal, so I wanted to oversample by a factor of 10). Anyway, I'll continue to look at my code and see if I can figure out what's going on. I was just hoping that writing out my approach in detail would reveal (to myself or to someone on the list) the stupid error that I was previously overlooking! Thanks, eric On Fri, May 8, 2009 at 3:02 PM, wrote: Hi all- I have a USRP2 with a LFRX daughterboard. I'm trying to acquire two channels each at a separate frequency where Ch0 is amplitude modulated and Ch1 is not. As per suggestions made to me from this list, to capture two channels at separate frequencies I was advised to tune the USRP2 to an average frequency and then use translating filters to capture the band around each frequency separately. Typically the AM carrier on Ch0 is at about 1 MHz, and the signal on Ch1 is about 5 kHz. For both channels I'm interested in no more than 5 kHz of bandwidth. I'm using svn 10991 with the SD card updated to the latest fpga and firmware images on a Fedora 10 x86_64 machine. I don't think I'm doing this correctly since my spectra is all wrong; perhaps somebody can help me out. First let me post my USRP1 code that does this, as this was my starting point: USRP1: options.decim = 128 usrp_decim=options.decim self.u = usrp.source_c(0, usrp_decim) self.u.set_dc_offset_cl_enable(int(0),int(15)) # dc removal off adc_rate = self.u.adc_rate() # 64 MS/s # Set the decimation in the FPGA usrp_rate = adc_rate / usrp_decim # 500 kS/s #set the decimation in software on the host PC sw_decim = 10 demod_rate = usrp_rate / sw_decim # 50 kS/s if not self.u.set_nchannels(nchan): #nchan = 2 sys.stderr.write('set_nchannels(%d) failed\n' % (nchan,)) raise SystemExit self.subdev = self.u.db(0) + self.u.db(1) if (len(self.subdev) != 6 or self.u.db(0,0).dbid() != usrp_dbid.LF_RX): sys.stderr.write('This code requires a Basic Rx board on Side A\n') sys.exit(1) self.u.set_mux(gru.hexint(0xf0f0f1f0)) # deinterleave two channels from FPGA self.di = gr.deinterleave(gr.sizeof_gr_complex) # Channelize the signal of interest. lpf_coeffs = gr.firdes.low_pass (1, # gain usrp_rate, # sampling rate demod_rate/2, # passband cutoff 500, # width of transition band gr.firdes.WIN_HANN) self.lpf_0 = gr.fir_filter_fff (sw_decim,lpf_coeffs) self.lpf_1 = gr.fir_filter_fff (sw_decim,lpf_coeffs) # Demodulate with classic sqrt (I*I + Q*Q) self.magblock_0 = gr.complex_to_mag() # Get real part of Ch1 self.splitter_1 = gr.complex_to_float() # now wire it all together self.connect (self.u, self.di) # Ch 0 self.connect ((self.di,0), self.magblock_0) self.connect (self.magblock_0, self.lpf_0) # Ch 1 self.connect ((self.di,1), self.splitter_1) self.connect ((self.splitter_1,0),self.lpf_1) etc
[Discuss-gnuradio] modified scopesink
I'm not sure if my email got sent out, so I'm re-posting Hi all- I have attached a modified scopesink that I believe fixes some sizing bugs. The issue is that the scope window would intrude on the controls below when sizes other than the default 640 by 240 is specified in the scopesink code. The credit goes to Michael Dickens, who provided these fixes to me a while back in a personal communication. I have been updating the various versions of scopesink for my own use and have done so for the current (as of svn 10991) implementation of scopesink_nongl.py which I provide here, with the hopes that somebody more knowledgeable in creating patches can provide a formal one to fix this issue. The fixes are very simple; other than resizing the defaults window sizes to a smaller value suitable for a smaller resolution screen (such as for a laptop), the changes are either lines that have "size=size" or "| wx.EXPAND)" added to them. All the lines with changes have the note "#mdickens" after them to aid in identification. I would be happy to provide any other information; please let me know. thanks, eric#!/usr/bin/env python # # Copyright 2003,2004,2006,2007 Free Software Foundation, Inc. # # This file is part of GNU Radio # # GNU Radio is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 3, or (at your option) # any later version. # # GNU Radio is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with GNU Radio; see the file COPYING. If not, write to # the Free Software Foundation, Inc., 51 Franklin Street, # Boston, MA 02110-1301, USA. # from gnuradio import gr, gru, eng_notation from gnuradio.wxgui import stdgui2 import wx import gnuradio.wxgui.plot as plot import numpy import threading import struct default_scopesink_size = (200, 100) #from 640 240 by mdickens default_v_scale = 1000 default_frame_decim = gr.prefs().get_long('wxgui', 'frame_decim', 1) class scope_sink_f(gr.hier_block2): def __init__(self, parent, title='', sample_rate=1, size=default_scopesink_size, frame_decim=default_frame_decim, v_scale=default_v_scale, t_scale=None, num_inputs=1, **kwargs): gr.hier_block2.__init__(self, "scope_sink_f", gr.io_signature(num_inputs, num_inputs, gr.sizeof_float), gr.io_signature(0,0,0)) msgq = gr.msg_queue(2) # message queue that holds at most 2 messages self.guts = gr.oscope_sink_f(sample_rate, msgq) for i in range(num_inputs): self.connect((self, i), (self.guts, i)) self.win = scope_window(win_info (msgq, sample_rate, frame_decim, v_scale, t_scale, self.guts, title), parent, size=size) #mdickens added size=size def set_sample_rate(self, sample_rate): self.guts.set_sample_rate(sample_rate) self.win.info.set_sample_rate(sample_rate) class scope_sink_c(gr.hier_block2): def __init__(self, parent, title='', sample_rate=1, size=default_scopesink_size, frame_decim=default_frame_decim, v_scale=default_v_scale, t_scale=None, num_inputs=1, **kwargs): gr.hier_block2.__init__(self, "scope_sink_c", gr.io_signature(num_inputs, num_inputs, gr.sizeof_gr_complex), gr.io_signature(0,0,0)) msgq = gr.msg_queue(2) # message queue that holds at most 2 messages self.guts = gr.oscope_sink_f(sample_rate, msgq) for i in range(num_inputs): c2f = gr.complex_to_float() self.connect((self, i), c2f) self.connect((c2f, 0), (self.guts, 2*i+0)) self.connect((c2f, 1), (self.guts, 2*i+1)) self.win = scope_window(win_info(msgq, sample_rate, frame_decim, v_scale, t_scale, self.guts, title), parent, size=size) #mdickens added size=size def set_sample_rate(self, sample_rate): self.guts.set_sample_rate(sample_rate) self.win.info.set_sample_rate(sample_rate) class constellation_sink(scope_sink_c): def __init__(self, parent, title='Constellation', sample_rate=1, size=default_scopesink_size, frame_decim=default_frame_decim): scope_sink_c.__init__(self, parent=parent, title=title, sample_rate=sample_rate, size=size, frame_decim=frame_decim) self.win.info.xy = True #constellation mode # time_base_
[Discuss-gnuradio] 2-channel AM demodulation on USRP2
Hi all- I have a USRP2 with a LFRX daughterboard. I'm trying to acquire two channels each at a separate frequency where Ch0 is amplitude modulated and Ch1 is not. As per suggestions made to me from this list, to capture two channels at separate frequencies I was advised to tune the USRP2 to an average frequency and then use translating filters to capture the band around each frequency separately. Typically the AM carrier on Ch0 is at about 1 MHz, and the signal on Ch1 is about 5 kHz. For both channels I'm interested in no more than 5 kHz of bandwidth. I'm using svn 10991 with the SD card updated to the latest fpga and firmware images on a Fedora 10 x86_64 machine. I don't think I'm doing this correctly since my spectra is all wrong; perhaps somebody can help me out. First let me post my USRP1 code that does this, as this was my starting point: USRP1: options.decim = 128 usrp_decim=options.decim self.u = usrp.source_c(0, usrp_decim) self.u.set_dc_offset_cl_enable(int(0),int(15)) # dc removal off adc_rate = self.u.adc_rate()# 64 MS/s # Set the decimation in the FPGA usrp_rate = adc_rate / usrp_decim # 500 kS/s #set the decimation in software on the host PC sw_decim = 10 demod_rate = usrp_rate / sw_decim # 50 kS/s if not self.u.set_nchannels(nchan): #nchan = 2 sys.stderr.write('set_nchannels(%d) failed\n' % (nchan,)) raise SystemExit self.subdev = self.u.db(0) + self.u.db(1) if (len(self.subdev) != 6 or self.u.db(0,0).dbid() != usrp_dbid.LF_RX): sys.stderr.write('This code requires a Basic Rx board on Side A\n') sys.exit(1) self.u.set_mux(gru.hexint(0xf0f0f1f0)) # deinterleave two channels from FPGA self.di = gr.deinterleave(gr.sizeof_gr_complex) # Channelize the signal of interest. lpf_coeffs = gr.firdes.low_pass (1, # gain usrp_rate, # sampling rate demod_rate/2, # passband cutoff 500, # width of transition band gr.firdes.WIN_HANN) self.lpf_0 = gr.fir_filter_fff (sw_decim,lpf_coeffs) self.lpf_1 = gr.fir_filter_fff (sw_decim,lpf_coeffs) # Demodulate with classic sqrt (I*I + Q*Q) self.magblock_0 = gr.complex_to_mag() # Get real part of Ch1 self.splitter_1 = gr.complex_to_float() # now wire it all together self.connect (self.u, self.di) # Ch 0 self.connect ((self.di,0), self.magblock_0) self.connect (self.magblock_0, self.lpf_0) # Ch 1 self.connect ((self.di,1), self.splitter_1) self.connect ((self.splitter_1,0),self.lpf_1) etc Then I define two set_freq functions, one for each subdevice. Ch0 is tuned to the carrier frequency of the AM signal, Ch1 is tuned to 0 Hz. Now, on the USRP2- since I have only one ddc, I can only tune to one frequency: options.decim = 128 freq = 1.e6 self.u = usrp2.source_32fc(options.interface, options.mac_addr) self.u.set_decim(options.decim) adc_rate = self.u.adc_rate()# 100 MS/s #set the decimation in the FPGA input_rate = self.u.adc_rate() / self.u.decim()# 781.25 kS/s #set the decimation in software on the host PC sw_decim = 16 demod_rate = input_rate / sw_decim # 48.828 kS/s # deinterleave four channels from FPGA self.di = gr.deinterleave(gr.sizeof_gr_complex) # Channelize the signal of interest. lpf_coeffs = gr.firdes.low_pass (1, # gain input_rate, # sampling rate demod_rate/2, # passband cutoff 500, # width of transition band gr.firdes.WIN_HANN) self.freq_xlating_lpf_0 = gr.freq_xlating_fir_filter_ccf (sw_decim,lpf_coeffs, freq/2., input_rate) self.freq_xlating_lpf_1 = gr.freq_xlating_fir_filter_ccf (sw_decim,lpf_coeffs, -freq/2., input_rate) self.magblock_0 = gr.complex_to_mag() self.splitter_1 = gr.complex_to_float() # Ch 0 self.connect ((self.di,0), self.freq_xlating_lpf_0,self.magblock_0,self.gain_correction_0) # Ch 1 self.connect ((self.di,1), self.freq_xlating_lpf_1, (self.splitter_1,0),self.gain_correction_1) etc I then tune the USRP2 to half of my desired frequency, ie 500 kHz. The other half of the shifting is down in software. I would suspect any problem to be in my definition of the gr.freq_xlating_fir_filter_ccf blocks. I assume the sampling frequency is set to the sampling rate going in to the filter
Re: [Discuss-gnuradio] usrp2 tune two different frequencies
On Mon, 20 Apr 2009, Matt Ettus wrote: emat...@nd.edu wrote: On Mon, 20 Apr 2009, Johnathan Corgan wrote: On Mon, Apr 20, 2009 at 7:59 AM, wrote: Is there any reason why the situation could not be the same as with the USPR1, with which I can program 2 DDC's on 1 LFRX daughterboard (with the appropriate mux) to tune in two separate frequencies? Yes, the USRP2 only has one DDC in the FPGA code. Johnathan I guess I was just curious why there is only one DDC in the FPGA, and if it's possible in future that more than one will be made available. It wouldn't be hard at all to put a second one in there, along with a second DUC. Everything is set up to hold it, and there is enough space. We just haven't had a need yet, since the USRP2 only holds one daughterboard. If, however, you want to RX or transmit 2 different signals on the same daughterboard, or are using a BasicRX/TX with dual independent real signals at IF, then it would make sense. Matt I'm in a position only to say, yes please! I do actually use the BasicRX/LFRX daughterboards with 2 real channels. thanks, eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp2 tune two different frequencies
On Mon, 20 Apr 2009, Johnathan Corgan wrote: On Mon, Apr 20, 2009 at 7:59 AM, wrote: Is there any reason why the situation could not be the same as with the USPR1, with which I can program 2 DDC's on 1 LFRX daughterboard (with the appropriate mux) to tune in two separate frequencies? Yes, the USRP2 only has one DDC in the FPGA code. Johnathan I guess I was just curious why there is only one DDC in the FPGA, and if it's possible in future that more than one will be made available. thanks, eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp2 tune two different frequencies
On Mon, 20 Apr 2009, Johnathan Corgan wrote: On Mon, Apr 20, 2009 at 7:44 AM, Johnathan Corgan wrote: The USRP has one receive daughterboard and one baseband DDC, so no, you can only tune to one center frequency. I of course meant the USRP2 here. Johnathan Is there any reason why the situation could not be the same as with the USPR1, with which I can program 2 DDC's on 1 LFRX daughterboard (with the appropriate mux) to tune in two separate frequencies? thanks, eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp2 tune two different frequencies
On Mon, 20 Apr 2009, Johnathan Corgan wrote: On Mon, Apr 20, 2009 at 7:33 AM, wrote: is it possible to tune the USRP2 to two different frequencies? I can do this with the USRP1 and a LFRX daughterboard using usrp.tune twice: The USRP has one receive daughterboard and one baseband DDC, so no, you can only tune to one center frequency. However, if your signals of interest are close enough, you can set the center frequency to the mid-point between them, set the decimation rate to that which would give you a frequency band that contains both signals, then separate them on the host inside your GNU Radio flowgraph using two DDC blocks. Johnathan I see, thanks for the help. eric___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] usrp2 tune two different frequencies
Hi all- is it possible to tune the USRP2 to two different frequencies? I can do this with the USRP1 and a LFRX daughterboard using usrp.tune twice: # Ch 0 r = usrp.tune(self.u, 0, self.subdev[0], target_freq1) # Ch 1 r = usrp.tune(self.u, 1, self.subdev[1], target_freq2) to tune each DDC to a separate frequency. However, it's not clear to me how to do this with the USRP2 since in the examples I saw there is no explicit mention of which subdevice is being tuned: r = self.u.set_center_freq(target_freq1) thanks for any suggestions. eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bad usrp followup 2
Thanks! eric On Wed, 18 Mar 2009, Eric Blossom wrote: On Wed, Mar 18, 2009 at 06:12:22PM -0400, emat...@nd.edu wrote: I discovered that F501 is measuring as an open; I take it that this is a fuse, and probably it has blown. Can anybody supply me with the part specification so I can replace it? The BOM data sheet doesn't seem to specify it. 3 Amp 0603. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] bad usrp followup 2
I discovered that F501 is measuring as an open; I take it that this is a fuse, and probably it has blown. Can anybody supply me with the part specification so I can replace it? The BOM data sheet doesn't seem to specify it. Thanks! eric Eric H. Matlis, Ph.D. Aerospace & Mechanical Engineering Dept. 121 Hessert Center for Aerospace Research University of Notre Dame Notre Dame, IN 46556-5684 Phone: (574) 631-6054 Fax: (574) 631-8355 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] bad usrp follow up
I was going to mention that there is no consistent voltage on the input of the LT1085 either; it's near zero but not exactly; it seems to vary. thanks, eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] usrp1 not responding
Hi all- I have a problem with my USRP. The device is not detected by the pc OS, and the led's do not flash or come on. I checked the power supply; I can find 6.33 V on the board when powered up, but not 3.3V. I checked the voltage on the LT1085, and there is 0 V on the output pin. Is it likely the LT1085 regulator has gone bad? Or could there be some other explanation? thanks! eric Eric H. Matlis, Ph.D. Aerospace & Mechanical Engineering Dept. 121 Hessert Center for Aerospace Research University of Notre Dame Notre Dame, IN 46556-5684 Phone: (574) 631-6054 Fax: (574) 631-8355 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gnuradio mentioned in cnet article on phone snooping
Gnuradio was recently mentioned in this article on the technology of phone snooping: http://news.cnet.com/8301-13739_3-10159055-46.html ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Usrp2 and Agere ET131x compatibility
I downloaded it from here: http://sourceforge.net/projects/et131x I use dkms to auto compile; here is my dkms.conf: - PACKAGE_NAME="et131x" BUILT_MODULE_NAME[0]="$PACKAGE_NAME" DEST_MODULE_LOCATION[0]="/kernel/3rdparty/$PACKAGE_NAME/" AUTOINSTALL=yes -- Incidentally, a motherboard with the built-in Agere card seemed to work, but not the pciexpress card. eric Eric H. Matlis, Ph.D. Assistant Research Professor Aerospace & Mechanical Engineering Dept. 121 Hessert Center for Aerospace Research University of Notre Dame Notre Dame, IN 46556-5684 Phone: (574) 631-6054 Fax: (574) 631-8355 On Wed, 11 Feb 2009, Matt Ettus wrote: Yc Park wrote: Hi, guys I have two questions: - My laptop has AgereET131x chipset but it works perfect on Ubuntu8.10. Then, wonder why I fail to find USRP2 by the 'find_usrps' command? (I see the chipset 'bad' here(http://gnuradio.org/trac/wiki/USRP2GigEReports), but it looks like that the linux and ET131 have some problems, not USRP2 and ET131) - Granted that the compatibility issue exists, do we have any progress on the latest source code of GR or on the USRP2 firmware? I went out and bought a card based on this chipset so that I could figure out the problem. Unfortunately, I can't even get a driver compiled for it, since the driver seems to not be in the mainline kernel. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] add-on pci-express GigE card compatibility
Hi all- I just wanted to report that a PCI-express card with the Agere ET131x chipset (StarTech ST1000BTPEX from Newegg) doesn't seem to work (as eth1) with the USRP2, but an Intel-based card with the 82572EI chipset does. Maybe there is some option during compilation of the Agere kernel driver that I didn't see, but with the default "make" compilation the find_usrps command failed on the Agere. I'm using a 10099 svn version of GnuRadio and the default firmware that came with the USRP2, purchased about 3 weeks ago. thanks, eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] non root access to usrp2 on Fedora 10
Update- making sudo chmod u+s /usr/local/bin/usrp2_socket_opener allows usrp2_fft.py to work (also as suid) by a normal user. thanks! I would be interested in trying the sudo approach, but as I mentioned in my previous post there are some issues perhaps with sudo not knowing about the path or other environment variables. eric Eric H. Matlis, Ph.D. Aerospace & Mechanical Engineering Dept. 121 Hessert Center for Aerospace Research University of Notre Dame Notre Dame, IN 46556-5684 Phone: (574) 631-6054 Fax: (574) 631-8355 On Wed, 3 Dec 2008, Michael Ossmann wrote: The libraries don't need to be suid, the executable (usrp2_fft.py) does. Personally I think it would be easier to use sudo than to go around making lots of different executables suid root, but the suid method might be easier if you have a small list of executables that doesn't change much. On Wed, Dec 03, 2008 at 10:58:26AM -0500, [EMAIL PROTECTED] wrote: If I want to run the example program usrp2_fft.py, which routines (python and/or c++) need to be made suid? thanks, eric On Tue, 2 Dec 2008, Michael Ossmann wrote: find_usrps and any other front-end programs would need to be suid (have the suid bit set and be owned by root). On Tue, Dec 02, 2008 at 07:10:36PM -0500, [EMAIL PROTECTED] wrote: Thank you very much for your response. If I wanted to provide access through suid, which file should be set suid? On Tue, 2 Dec 2008, Michael Ossmann wrote: On Tue, Dec 02, 2008 at 03:41:35PM -0500, [EMAIL PROTECTED] wrote: Hi all, I looked over the wiki and the mailing list but could not find mention of how to access the usrp2 as a non-root user on Fedora 10. As root, I get the following response from "find_usrps": 00:50:c2:85:30:68 hw_rev = 0x0300 but as a user, I get: socket(PF_PACKET, SOCK_RAW, htons(0xBEEF)): Operation not permitted eth0: socket: No such file or directory No USRP2 found. The code that talks to the USRP2 uses raw socket access (SOCK_RAW) on the ethernet port. This allows the use of a custom ethertype rather than building on a higher level protocol like IP or UDP. The kernel does not allow anyone but root to use raw sockets. This is unlikely to change any time soon. There has been some discussion/experimentation over the last few years on various means of providing ACLs to allow non-root raw socket access, but I don't believe there is anything stable. Other tools that use raw sockets must also be run as root or are suid (like ping). It is possible that the USRP2 could be modified in the future to use a higher level protocol that would permit non-root access. I believe this has been discussed, but I don't know if anyone is working on it. Such a modification would come at the cost of additional packet header overhead and would also require quite a bit more networking code running on the USRP2 (I presume in the FPGA). For the foreseeable future, all USRP2 access must run as root. You could use suid (dangerous) or sudo (maybe a little less dangerous) to allow non-root users to execute stuff as root, but it is always a security risk to allow non-root users to execute unstable/development code as root. Another option might be to use some sort of virtualization to give root access only on a virtual machine and not the host OS; I believe that would work in vmware with a bridged ethernet interface, but I'm not sure about other virtualization tools. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] non root access to usrp2 on Fedora 10
In terms of using sudo, there is some issue with the environment variables not being passed: [EMAIL PROTECTED] ~]$ sudo usrp2_fft.py [sudo] password for matlis: sudo: usrp2_fft.py: command not found [EMAIL PROTECTED] ~]$ sudo /usr/local/bin/usrp2_fft.py execlp: couldn't exec usrp2_socket_opener: No such file or directory eth0: socket: Bad file descriptor Traceback (most recent call last): File "/usr/local/bin/usrp2_fft.py", line 267, in main () File "/usr/local/bin/usrp2_fft.py", line 263, in main app = stdgui2.stdapp(app_top_block, "USRP2 FFT", nstatus=1) File "/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 36, in __init__ wx.App.__init__ (self, redirect=False) File "/usr/lib64/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 7935, in __init__ self._BootstrapApp() File "/usr/lib64/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 7509, in _BootstrapApp return _core_.PyApp__BootstrapApp(*args, **kwargs) File "/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 39, in OnInit frame = stdframe (self.top_block_maker, self.title, self._nstatus) File "/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 60, in __init__ self.panel = stdpanel (self, self, top_block_maker) File "/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 81, in __init__ self.top_block = top_block_maker (frame, self, vbox, sys.argv) File "/usr/local/bin/usrp2_fft.py", line 68, in __init__ self.u = usrp2.source_32fc(options.interface, options.mac_addr) File "/usr/local/lib64/python2.5/site-packages/gnuradio/usrp2.py", line 449, in source_32fc return _usrp2.source_32fc(*args) RuntimeError: No USRPs found on interface eth0 eth0: socket: Operation not permitted Traceback (most recent call last): File "/usr/local/bin/usrp2_fft.py", line 267, in main () File "/usr/local/bin/usrp2_fft.py", line 263, in main app = stdgui2.stdapp(app_top_block, "USRP2 FFT", nstatus=1) File "/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 36, in __init__ wx.App.__init__ (self, redirect=False) File "/usr/lib64/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 7935, in __init__ self._BootstrapApp() File "/usr/lib64/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 7509, in _BootstrapApp return _core_.PyApp__BootstrapApp(*args, **kwargs) File "/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 39, in OnInit frame = stdframe (self.top_block_maker, self.title, self._nstatus) File "/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 60, in __init__ self.panel = stdpanel (self, self, top_block_maker) File "/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 81, in __init__ self.top_block = top_block_maker (frame, self, vbox, sys.argv) File "/usr/local/bin/usrp2_fft.py", line 68, in __init__ self.u = usrp2.source_32fc(options.interface, options.mac_addr) File "/usr/local/lib64/python2.5/site-packages/gnuradio/usrp2.py", line 449, in source_32fc return _usrp2.source_32fc(*args) RuntimeError: No USRPs found on interface eth0 eric On Wed, 3 Dec 2008, Michael Ossmann wrote: The libraries don't need to be suid, the executable (usrp2_fft.py) does. Personally I think it would be easier to use sudo than to go around making lots of different executables suid root, but the suid method might be easier if you have a small list of executables that doesn't change much. On Wed, Dec 03, 2008 at 10:58:26AM -0500, [EMAIL PROTECTED] wrote: If I want to run the example program usrp2_fft.py, which routines (python and/or c++) need to be made suid? thanks, eric On Tue, 2 Dec 2008, Michael Ossmann wrote: find_usrps and any other front-end programs would need to be suid (have the suid bit set and be owned by root). On Tue, Dec 02, 2008 at 07:10:36PM -0500, [EMAIL PROTECTED] wrote: Thank you very much for your response. If I wanted to provide access through suid, which file should be set suid? On Tue, 2 Dec 2008, Michael Ossmann wrote: On Tue, Dec 02, 2008 at 03:41:35PM -0500, [EMAIL PROTECTED] wrote: Hi all, I looked over the wiki and the mailing list but could not find mention of how to access the usrp2 as a non-root user on Fedora 10. As root, I get the following response from "find_usrps": 00:50:c2:85:30:68 hw_rev = 0x0300 but as a user, I get: socket(PF_PACKET, SOCK_RAW, htons(0xBEEF)): Operation not permitted eth0: socket: No such file or directory No USRP2 found. The code that talks to the USRP2 uses raw socket access (SOCK_RAW) on the ethernet port. This allows the use of a custom ethertype rather than building on a higher level protocol like IP or UDP. The kernel does not allow anyone but root to use raw sockets. This is unlikely to change any time soon. There
Re: [Discuss-gnuradio] non root access to usrp2 on Fedora 10
Michael- I found that setting usrp2_fft.py suid doesn't work: [EMAIL PROTECTED] z.research]$ ls -l /usr/local/bin/usrp2_fft.py -rwsr-xr-x 1 root root 9915 2008-12-02 19:03 /usr/local/bin/usrp2_fft.py This is the same permissions as ping, so I thought it would work: [EMAIL PROTECTED] ~]$ ls -l /bin/ping -rwsr-xr-x 1 root root 41784 2008-09-26 02:02 /bin/ping when I run usrp2_fft.py however, I get the following error: [EMAIL PROTECTED] ~]$ usrp2_fft.py socket(PF_PACKET, SOCK_RAW, htons(0xBEEF)): Operation not permitted eth0: socket: No such file or directory Traceback (most recent call last): File "/usr/local/bin/usrp2_fft.py", line 267, in main () File "/usr/local/bin/usrp2_fft.py", line 263, in main app = stdgui2.stdapp(app_top_block, "USRP2 FFT", nstatus=1) File "/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 36, in __init__ wx.App.__init__ (self, redirect=False) File "/usr/lib64/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 7935, in __init__ self._BootstrapApp() File "/usr/lib64/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 7509, in _BootstrapApp return _core_.PyApp__BootstrapApp(*args, **kwargs) File "/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 39, in OnInit frame = stdframe (self.top_block_maker, self.title, self._nstatus) File "/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 60, in __init__ self.panel = stdpanel (self, self, top_block_maker) File "/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 81, in __init__ self.top_block = top_block_maker (frame, self, vbox, sys.argv) File "/usr/local/bin/usrp2_fft.py", line 68, in __init__ self.u = usrp2.source_32fc(options.interface, options.mac_addr) File "/usr/local/lib64/python2.5/site-packages/gnuradio/usrp2.py", line 449, in source_32fc return _usrp2.source_32fc(*args) RuntimeError: No USRPs found on interface eth0 so does this mean some other component must be made suid as well? thanks, eric On Wed, 3 Dec 2008, Michael Ossmann wrote: The libraries don't need to be suid, the executable (usrp2_fft.py) does. Personally I think it would be easier to use sudo than to go around making lots of different executables suid root, but the suid method might be easier if you have a small list of executables that doesn't change much. On Wed, Dec 03, 2008 at 10:58:26AM -0500, [EMAIL PROTECTED] wrote: If I want to run the example program usrp2_fft.py, which routines (python and/or c++) need to be made suid? thanks, eric On Tue, 2 Dec 2008, Michael Ossmann wrote: find_usrps and any other front-end programs would need to be suid (have the suid bit set and be owned by root). On Tue, Dec 02, 2008 at 07:10:36PM -0500, [EMAIL PROTECTED] wrote: Thank you very much for your response. If I wanted to provide access through suid, which file should be set suid? On Tue, 2 Dec 2008, Michael Ossmann wrote: On Tue, Dec 02, 2008 at 03:41:35PM -0500, [EMAIL PROTECTED] wrote: Hi all, I looked over the wiki and the mailing list but could not find mention of how to access the usrp2 as a non-root user on Fedora 10. As root, I get the following response from "find_usrps": 00:50:c2:85:30:68 hw_rev = 0x0300 but as a user, I get: socket(PF_PACKET, SOCK_RAW, htons(0xBEEF)): Operation not permitted eth0: socket: No such file or directory No USRP2 found. The code that talks to the USRP2 uses raw socket access (SOCK_RAW) on the ethernet port. This allows the use of a custom ethertype rather than building on a higher level protocol like IP or UDP. The kernel does not allow anyone but root to use raw sockets. This is unlikely to change any time soon. There has been some discussion/experimentation over the last few years on various means of providing ACLs to allow non-root raw socket access, but I don't believe there is anything stable. Other tools that use raw sockets must also be run as root or are suid (like ping). It is possible that the USRP2 could be modified in the future to use a higher level protocol that would permit non-root access. I believe this has been discussed, but I don't know if anyone is working on it. Such a modification would come at the cost of additional packet header overhead and would also require quite a bit more networking code running on the USRP2 (I presume in the FPGA). For the foreseeable future, all USRP2 access must run as root. You could use suid (dangerous) or sudo (maybe a little less dangerous) to allow non-root users to execute stuff as root, but it is always a security risk to allow non-root users to execute unstable/development code as root. Another option might be to use some sort of virtualization to give root access only on a virtual machine and not the host OS; I believe that would work in vmware with a bridged ethernet interface, but I'm not sure about other virtualization tools. ___
Re: [Discuss-gnuradio] non root access to usrp2 on Fedora 10
If I want to run the example program usrp2_fft.py, which routines (python and/or c++) need to be made suid? thanks, eric On Tue, 2 Dec 2008, Michael Ossmann wrote: find_usrps and any other front-end programs would need to be suid (have the suid bit set and be owned by root). On Tue, Dec 02, 2008 at 07:10:36PM -0500, [EMAIL PROTECTED] wrote: Thank you very much for your response. If I wanted to provide access through suid, which file should be set suid? On Tue, 2 Dec 2008, Michael Ossmann wrote: On Tue, Dec 02, 2008 at 03:41:35PM -0500, [EMAIL PROTECTED] wrote: Hi all, I looked over the wiki and the mailing list but could not find mention of how to access the usrp2 as a non-root user on Fedora 10. As root, I get the following response from "find_usrps": 00:50:c2:85:30:68 hw_rev = 0x0300 but as a user, I get: socket(PF_PACKET, SOCK_RAW, htons(0xBEEF)): Operation not permitted eth0: socket: No such file or directory No USRP2 found. The code that talks to the USRP2 uses raw socket access (SOCK_RAW) on the ethernet port. This allows the use of a custom ethertype rather than building on a higher level protocol like IP or UDP. The kernel does not allow anyone but root to use raw sockets. This is unlikely to change any time soon. There has been some discussion/experimentation over the last few years on various means of providing ACLs to allow non-root raw socket access, but I don't believe there is anything stable. Other tools that use raw sockets must also be run as root or are suid (like ping). It is possible that the USRP2 could be modified in the future to use a higher level protocol that would permit non-root access. I believe this has been discussed, but I don't know if anyone is working on it. Such a modification would come at the cost of additional packet header overhead and would also require quite a bit more networking code running on the USRP2 (I presume in the FPGA). For the foreseeable future, all USRP2 access must run as root. You could use suid (dangerous) or sudo (maybe a little less dangerous) to allow non-root users to execute stuff as root, but it is always a security risk to allow non-root users to execute unstable/development code as root. Another option might be to use some sort of virtualization to give root access only on a virtual machine and not the host OS; I believe that would work in vmware with a bridged ethernet interface, but I'm not sure about other virtualization tools. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] non root access to usrp2 on Fedora 10
Thank you very much for your response. If I wanted to provide access through suid, which file should be set suid? On Tue, 2 Dec 2008, Michael Ossmann wrote: On Tue, Dec 02, 2008 at 03:41:35PM -0500, [EMAIL PROTECTED] wrote: Hi all, I looked over the wiki and the mailing list but could not find mention of how to access the usrp2 as a non-root user on Fedora 10. As root, I get the following response from "find_usrps": 00:50:c2:85:30:68 hw_rev = 0x0300 but as a user, I get: socket(PF_PACKET, SOCK_RAW, htons(0xBEEF)): Operation not permitted eth0: socket: No such file or directory No USRP2 found. The code that talks to the USRP2 uses raw socket access (SOCK_RAW) on the ethernet port. This allows the use of a custom ethertype rather than building on a higher level protocol like IP or UDP. The kernel does not allow anyone but root to use raw sockets. This is unlikely to change any time soon. There has been some discussion/experimentation over the last few years on various means of providing ACLs to allow non-root raw socket access, but I don't believe there is anything stable. Other tools that use raw sockets must also be run as root or are suid (like ping). It is possible that the USRP2 could be modified in the future to use a higher level protocol that would permit non-root access. I believe this has been discussed, but I don't know if anyone is working on it. Such a modification would come at the cost of additional packet header overhead and would also require quite a bit more networking code running on the USRP2 (I presume in the FPGA). For the foreseeable future, all USRP2 access must run as root. You could use suid (dangerous) or sudo (maybe a little less dangerous) to allow non-root users to execute stuff as root, but it is always a security risk to allow non-root users to execute unstable/development code as root. Another option might be to use some sort of virtualization to give root access only on a virtual machine and not the host OS; I believe that would work in vmware with a bridged ethernet interface, but I'm not sure about other virtualization tools. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] non root access to usrp2 on Fedora 10
Hi all, I looked over the wiki and the mailing list but could not find mention of how to access the usrp2 as a non-root user on Fedora 10. As root, I get the following response from "find_usrps": 00:50:c2:85:30:68 hw_rev = 0x0300 but as a user, I get: socket(PF_PACKET, SOCK_RAW, htons(0xBEEF)): Operation not permitted eth0: socket: No such file or directory No USRP2 found. I'm using svn checkout 10025. Any suggestions? thanks! eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] simultaneous receive/transmit with LFRX/TX
Hi all- I looked over the mailing list, and I think I see that what I want to do is possible, but I want to verify before I order the parts: I want to receive an AM modulated waveform using an LFRX, demodulate it, and simultaneously and in a phase-locked way send out the demodulated waveform at baseband from an LFTX so that it can be acquired by a scope or secondary acquisition system. Basically, the gnuradio device would serve as an intermediary block which demodulates the signal in question so that it can be acquired. The process needs to be phase locked because I am correlating the input signal with a second signal (a position encoder), both of which will be acquired by the second acquisition system. If anybody can let me know why I can't do this, I would appreciate it. Suggestions also welcome. thanks, eric Eric H. Matlis, Ph.D. Aerospace & Mechanical Engineering Dept. 120 Hessert Center for Aerospace Research University of Notre Dame Notre Dame, IN 46556-5684 Phone: (574) 631-6054 Fax: (574) 631-8355 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] corrupt points follow up
It just occurred to me that perhaps the explanation for the "corrupt" points I described in my AM demodulation script is due to the mechanics of how the Hilbert Transform works; it produces a copy of the waveform that's delayed, and this would affect the first set of points. Can anybody expand on that? How is the duration of the time delay set (just curious)? thanks, eric Eric H. Matlis, Ph.D. Aerospace & Mechanical Engineering Dept. 120 Hessert Center for Aerospace Research University of Notre Dame Notre Dame, IN 46556-5684 Phone: (574) 631-6054 Fax: (574) 631-8355 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] corrupted points when writing to file
Hi- I have a python app which seems to corrupt points when I use it to demodulate a data stream stored in a file and write the de-modulated result back to a file. I've attached the python code, and an image of the problem can be seen at www.nd.edu/~ematlis/z.gnuradio/waveform.jpg The modulated waveform is shown in the top plot and the demodulated output in the bottom plot. The signal was acquired with a Lecroy digital oscilloscope; it's a 100 kHz sine AM modulated at 10 kHz. As you can see from the image, while the original modulated data shows no corruption in 10002 points, the demodulated data has the first 875-900 points incorrectly set to close to zero. This is repeatable. Could it have anything to do with the fact that I'm generating a gui? Could the time it takes to generate the gui window interfere with the operation of the demodulation? If I were to make this just a script, ie with no scope or fft sink, and no gui box, would it affect things? (And p.s., how would I do that?) thanks, eric Eric H. Matlis, Ph.D. Aerospace & Mechanical Engineering Dept. 120 Hessert Center for Aerospace Research University of Notre Dame Notre Dame, IN 46556-5684 Phone: (574) 631-6054 Fax: (574) 631-8355#!/usr/bin/env python from gnuradio import gr, gru from gnuradio.wxgui import stdgui, fftsink, scopesink, form, slider from gnuradio.eng_option import eng_option from optparse import OptionParser import sys import os import wx import scopesink_mod as scopesink plot1 = 0 plot2 = 0 plot3 = 0 record = 1 class app_flow_graph (stdgui.gui_flow_graph): def __init__(self, frame, panel, vbox, argv): stdgui.gui_flow_graph.__init__ (self, frame, panel, vbox, argv) usage = "usage: %prog filename \n Demodulates AM from filename " parser = OptionParser (option_class=eng_option, usage=usage) parser.add_option("-N", "--nsamples", type="eng_float", default=2000, help="number of samples to collect [default=+inf]") (options, args) = parser.parse_args () if len (args) != 1: parser.print_help () sys.exit (1) FILENAME = args[0] SHOW = True sampling_freq = 5e6 filename = argv[1] lpf_coeffs = gr.firdes.low_pass (1, # gain sampling_freq, # sampling rate 150e3,# passband cutoff 10e3, # width of transition band gr.firdes.WIN_HANN) self.lpf = gr.fir_filter_fff (1,lpf_coeffs) # file is our source. self.src = gr.file_source (gr.sizeof_float, filename, 1) self.throttle = gr.throttle(gr.sizeof_float,sampling_freq) self.head = gr.head(gr.sizeof_float, int(options.nsamples)) self.recording = gr.file_sink(gr.sizeof_float, "test.bin") if plot1: self.pre_demod = fftsink.fft_sink_f (self, panel, title="Source Spectrum", fft_size=8192, sample_rate=sampling_freq, size=(50,100)) self.connect (self.src, self.pre_demod) vbox.Add (self.pre_demod.win, 1, wx.EXPAND) # demodulate AM self.hilb_filt = gr.firdes_hilbert (201, gr.firdes.WIN_BLACKMAN) self.hilb_delay = gr.filter_delay_fc (self.hilb_filt) self.mag = gr.complex_to_mag () self.connect (self.src, (self.hilb_delay,0)) self.connect ((self.hilb_delay,0),self.mag) self.connect (self.mag, self.lpf) if record: self.connect (self.lpf,self.head,self.recording) #self.connect (self.lpf,self.recording) #self.connect (self.mag,self.head,self.recording) if plot2: self.src_fft = fftsink.fft_sink_f (self, panel, title="FFT", fft_size=4096,sample_rate=sampling_freq, size=(50,100)) self.connect (self.lpf, self.src_fft) vbox.Add (self.src_fft.win, 1, wx.EXPAND) if plot3: self.scope = scopesink.scope_sink_f(self, panel, title="Time Series", sample_rate=sampling_freq, size=(50,100), t_scale=1.0e-3, v_scale=None) self.connect(self.lpf, self.scope) vbox.Add (self.scope.win, 1, wx.EXPAND) def main (): app = stdgui.stdapp(app_flow_graph, "Plasma Probe Spectrum", nstatus=1) app.MainLoop() if __name__ == '__main__': main () ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] control time or number of points acquired
Thanks Eric, Juha, and Michael- to get 3 helpful responses within an hour of sending a post is truly amazing, particularly considering the time of the year. I should have elaborated in my post. I tried the gr.head approach, but I'm not sure it works in my application- I'm using the approach of the astronomy guys, with a control button that turns on and off from /dev/null to a file descriptor. So if I use gr.head, correct me if I'm wrong, but I believe it immediately sends the number of samples specified to /dev/null. I don't think that way is compatible with the approach I'm using, which I ripped off from usrp_psr_receiver.py. So you know what I'm doing, I'm using the USRP as a pseudo digital oscilloscope with a capture to file option. When I see something I like in the scope, I hit the "capture to file" button. It works great, but currently I have to look at my watch to capture comparably sized samples. Perhaps there's a way of incorporating a timed capture (or fixed number of samples to this model? thanks again so much. eric Eric H. Matlis, Ph.D. Aerospace & Mechanical Engineering Dept. 120 Hessert Center for Aerospace Research University of Notre Dame Notre Dame, IN 46556-5684 Phone: (574) 631-6054 Fax: (574) 631-8355 On Sat, 22 Dec 2007, Eric Blossom wrote: On Sat, Dec 22, 2007 at 06:04:50PM -0500, [EMAIL PROTECTED] wrote: Hi all- has anybody implemented a control whereby the user can limit how long or how many points gets acquired by a gnuradio application? If so I'd appreciate any pointers! I've got an app where I'm storing samples to file and I'd like to control how many points go into each data file. thanks, eric Hi Eric, We generally use gr.head for this. See gr-utils/src/python/usrp_rx_cfile.py Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] control time or number of points acquired
Hi all- has anybody implemented a control whereby the user can limit how long or how many points gets acquired by a gnuradio application? If so I'd appreciate any pointers! I've got an app where I'm storing samples to file and I'd like to control how many points go into each data file. thanks, eric Eric H. Matlis, Ph.D. Aerospace & Mechanical Engineering Dept. 120 Hessert Center for Aerospace Research University of Notre Dame Notre Dame, IN 46556-5684 Phone: (574) 631-6054 Fax: (574) 631-8355 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] saturation with multi_fft.py
Thanks! eric Eric H. Matlis, Ph.D. Aerospace & Mechanical Engineering Dept. 120 Hessert Center for Aerospace Research University of Notre Dame Notre Dame, IN 46556-5684 Phone: (574) 631-6054 Fax: (574) 631-8355 On Thu, 11 Oct 2007, Martin Dvh wrote: [EMAIL PROTECTED] wrote: I'm sure you are right about the gui taking the majority of the cycles, but it's the real-time feedback that makes gnuradio so attractive. Ideally one would beable to switch them on and off as needed during operation of the program, which it is my understanding will be possible with the implementation of mblocks. As things stand now, is there a "refresh rate" control that I can modify, so that the scope sinks use less cycles? Yes, you can set the following parameters. sinkparam default less cycles Function oscope frame_decim 1 >1 keep one block in every "frame_decim" fft fft_rate15.0<15.0refresh rate of fft_display so for less GUI cycles set frame_decim to 10 or even 100 set fft_rate to 5.0 or even 1.0 I wished that fft_rate was set to 5.0 default because allmost allways 15.0 is too much a load on my machines. Greetings, Martin thanks, eric On Wed, 10 Oct 2007, Eric Blossom wrote: On Wed, Oct 10, 2007 at 06:07:04PM -0400, [EMAIL PROTECTED] wrote: Ok, that works in principle, but I'm finding that I cannot sustain the same data rate as before on a fast dual core machine. I'm acquiring all 4 channels, and I'm doing both low-pass and high-pass filtering on all of them. I am also displaying 5 sinks simultaneously; 1 fft and 4 scopes. You'll most likely find that the bulk of your cycles are spent in the gui. Try disabling it. So, in the long term it would help to have this sorted out in the fpga if that's possible; is that impossible as things stand now, or is there sufficient space in the 4rx no hb fpga? IIRC, the std_4rx_0tx.rbf configuration uses about 86% of the FPGA. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] saturation with multi_fft.py
I'm sure you are right about the gui taking the majority of the cycles, but it's the real-time feedback that makes gnuradio so attractive. Ideally one would beable to switch them on and off as needed during operation of the program, which it is my understanding will be possible with the implementation of mblocks. As things stand now, is there a "refresh rate" control that I can modify, so that the scope sinks use less cycles? thanks, eric On Wed, 10 Oct 2007, Eric Blossom wrote: On Wed, Oct 10, 2007 at 06:07:04PM -0400, [EMAIL PROTECTED] wrote: Ok, that works in principle, but I'm finding that I cannot sustain the same data rate as before on a fast dual core machine. I'm acquiring all 4 channels, and I'm doing both low-pass and high-pass filtering on all of them. I am also displaying 5 sinks simultaneously; 1 fft and 4 scopes. You'll most likely find that the bulk of your cycles are spent in the gui. Try disabling it. So, in the long term it would help to have this sorted out in the fpga if that's possible; is that impossible as things stand now, or is there sufficient space in the 4rx no hb fpga? IIRC, the std_4rx_0tx.rbf configuration uses about 86% of the FPGA. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] saturation with multi_fft.py
Ok, that works in principle, but I'm finding that I cannot sustain the same data rate as before on a fast dual core machine. I'm acquiring all 4 channels, and I'm doing both low-pass and high-pass filtering on all of them. I am also displaying 5 sinks simultaneously; 1 fft and 4 scopes. I set the decimation in the fpga to 128, and in the host to a further 10 for an effective data sampling rate of 50 kHz, and while the gain problem is gone I'm seeing some uO errors. With the decimation set to 250 in the fpga, as I was doing previously, I can sustain data rates of 128 kHz without a problem while having all 5 sinks going, albeit with the gain problem. So, in the long term it would help to have this sorted out in the fpga if that's possible; is that impossible as things stand now, or is there sufficient space in the 4rx no hb fpga? thanks, eric On Wed, 10 Oct 2007, Eric Blossom wrote: On Wed, Oct 10, 2007 at 04:54:10PM -0400, [EMAIL PROTECTED] wrote: Well, this seems logical, and if so then we've finally stumbled on the point of the matter. So what's the fix? Is it a simple matter of extending the "definitions" to other decimations in the file Brian cites? thanks Brian and Eric, eric Also- this fix you are proposing- is it a simple scaling of gain that would be independent of decimation? Because as you can see from the following figure, the amplitudes scale directly with the decimation for values above 128 on the 4 rcv rbf. www.nd.edu/~ematlis/z.gnuradio/Amplitude_vs_decimation.jpg Both rbf's produce a flat response below 128 decimation; greater than this is where the change occurs. The standard half-band rbf does have a couple of dips but is basically flat. OK. In the interest of expediency, use the decimation values that work, then complete the decimation in the host. The reason that there's a version that DOESN'T have the halfband is to save space. Making anything bigger (e.g., width of CIC) is contraindicated ;) Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] saturation with multi_fft.py
Well, this seems logical, and if so then we've finally stumbled on the point of the matter. So what's the fix? Is it a simple matter of extending the "definitions" to other decimations in the file Brian cites? thanks Brian and Eric, eric On Wed, 10 Oct 2007, Brian Padalino wrote: On 10/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Can you give me an example? I've never worked with verilog code before. Also- this fix you are proposing- is it a simple scaling of gain that would be independent of decimation? Because as you can see from the following figure, the amplitudes scale directly with the decimation for values above 128 on the 4 rcv rbf. www.nd.edu/~ematlis/z.gnuradio/Amplitude_vs_decimation.jpg Both rbf's produce a flat response below 128 decimation; greater than this is where the change occurs. The standard half-band rbf does have a couple of dips but is basically flat. A question I can answer! If you would take a look here: http://www.gnuradio.org/trac/browser/gnuradio/trunk/usrp/fpga/sdr_lib/cic_dec_shifter.v The CIC filter has some bit-growth associated based on your decimation rate. This growth is deifned for decimations up to 128 in that file. It basically takes a different "slice" of the CIC "comb" section at the end. The reason it might be happening in the FPGA that doesn't have the halfband filter is because the halfband filter also decimates by 2 - so you would need 1/2 the decimation by the CIC. So for cases where you would normally decimate by 192, the CIC is decimating by 96 and the halfband by 2. In the case where there is no halfband, the CIC takes on all the responsibility and the extra growth is not accounted for. If this was defined for values larger than 128, then the growth wouldn't happen and it could all be alleviated in the FPGA. Hopefully this makes sense to everyone. Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] saturation with multi_fft.py
Can you give me an example? I've never worked with verilog code before. Also- this fix you are proposing- is it a simple scaling of gain that would be independent of decimation? Because as you can see from the following figure, the amplitudes scale directly with the decimation for values above 128 on the 4 rcv rbf. www.nd.edu/~ematlis/z.gnuradio/Amplitude_vs_decimation.jpg Both rbf's produce a flat response below 128 decimation; greater than this is where the change occurs. The standard half-band rbf does have a couple of dips but is basically flat. thanks, eric On Wed, 10 Oct 2007, Eric Blossom wrote: On Wed, Oct 10, 2007 at 03:14:21PM -0400, [EMAIL PROTECTED] wrote: The figures I showed you previously used std_4rx_0tx.rbf. To test with the standard std_2rxhb_2tx.rbf, I use the usrp_fft.py (with -S). I tested two cases, both with decimation 180, 1 kHz input, tuned to 0 Hz with 0 db gain. The first is with the voltage level of 1.4 V P-P (which cuases the clipping on the std_4rx_0tx.rbf), the second figure is at the full scale voltage of 2 V P-P. Neither show clipping. The clipping is clearly dependent on which rbf file is used. www.nd.edu/~ematlis/z.gnuradio/usrp_fft_180dec_1.4V_1khz.jpg www.nd.edu/~ematlis/z.gnuradio/usrp_fft_180dec_2.0V_1khz.jpg hope this helps clarify the situation thanks, eric OK. So it looks like the non-halfband case needs some adjustment to reduce the gain so that it matches (more closely) the halfband case. We don't have any multipliers. What power of 2 would you like? The fix goes on lines 83 and 102 of rx_chain.v. Just change which bits of hb_in_i are assigned to i_out and likewise for Q. Send a patch when you're happy ;) Eric On Wed, 10 Oct 2007, Eric Blossom wrote: On Wed, Oct 10, 2007 at 12:50:35PM -0400, [EMAIL PROTECTED] wrote: Eric- using -d 160 the problem goes away with this latest build, but remains for higher decimation values. For example, at decimation of 180, I can reproduce the problem. As a picture is worth a thousand words, I've put two jpg's up online at: www.nd.edu/~ematlis/z.gnuradio/multi_scope_180dec_1.3V.jpg www.nd.edu/~ematlis/z.gnuradio/multi_scope_180dec_1.4V.jpg The input signal is again a 10 kHz sine wave. In the first image, the voltage level is 1.3 V p-p. In the second, 1.4 V p-p. In both cases I have zero db of gain and decimation of 180, with the LF_RX tuned to 0 Hz. As you can see, at 1.3 V P-P the result is perfect. However at 1.4 V P-P, the signal is seriously corrupted and jagged. The second one is showing clipping. Note how the peaks are folded in on top of themselves. Which rbf are you using for these? std_2rxhb_2tx.rbf (the default), or std_4rx_0tx.rbf (the one without the halfband). Can you run the same experiment using the other rbf and post those pictures too? The graphs are great. Thanks for posting the links. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] saturation with multi_fft.py
The figures I showed you previously used std_4rx_0tx.rbf. To test with the standard std_2rxhb_2tx.rbf, I use the usrp_fft.py (with -S). I tested two cases, both with decimation 180, 1 kHz input, tuned to 0 Hz with 0 db gain. The first is with the voltage level of 1.4 V P-P (which cuases the clipping on the std_4rx_0tx.rbf), the second figure is at the full scale voltage of 2 V P-P. Neither show clipping. The clipping is clearly dependent on which rbf file is used. www.nd.edu/~ematlis/z.gnuradio/usrp_fft_180dec_1.4V_1khz.jpg www.nd.edu/~ematlis/z.gnuradio/usrp_fft_180dec_2.0V_1khz.jpg hope this helps clarify the situation thanks, eric On Wed, 10 Oct 2007, Eric Blossom wrote: On Wed, Oct 10, 2007 at 12:50:35PM -0400, [EMAIL PROTECTED] wrote: Eric- using -d 160 the problem goes away with this latest build, but remains for higher decimation values. For example, at decimation of 180, I can reproduce the problem. As a picture is worth a thousand words, I've put two jpg's up online at: www.nd.edu/~ematlis/z.gnuradio/multi_scope_180dec_1.3V.jpg www.nd.edu/~ematlis/z.gnuradio/multi_scope_180dec_1.4V.jpg The input signal is again a 10 kHz sine wave. In the first image, the voltage level is 1.3 V p-p. In the second, 1.4 V p-p. In both cases I have zero db of gain and decimation of 180, with the LF_RX tuned to 0 Hz. As you can see, at 1.3 V P-P the result is perfect. However at 1.4 V P-P, the signal is seriously corrupted and jagged. The second one is showing clipping. Note how the peaks are folded in on top of themselves. Which rbf are you using for these? std_2rxhb_2tx.rbf (the default), or std_4rx_0tx.rbf (the one without the halfband). Can you run the same experiment using the other rbf and post those pictures too? The graphs are great. Thanks for posting the links. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] saturation with multi_fft.py
Eric- using -d 160 the problem goes away with this latest build, but remains for higher decimation values. For example, at decimation of 180, I can reproduce the problem. As a picture is worth a thousand words, I've put two jpg's up online at: www.nd.edu/~ematlis/z.gnuradio/multi_scope_180dec_1.3V.jpg www.nd.edu/~ematlis/z.gnuradio/multi_scope_180dec_1.4V.jpg The input signal is again a 10 kHz sine wave. In the first image, the voltage level is 1.3 V p-p. In the second, 1.4 V p-p. In both cases I have zero db of gain and decimation of 180, with the LF_RX tuned to 0 Hz. As you can see, at 1.3 V P-P the result is perfect. However at 1.4 V P-P, the signal is seriously corrupted and jagged. The criteria you indicated, ie acquisition rate at 4x bandwidth, seems not to be the issue; I am measuring a 10 kHz sine wave at an effective sampling rate of 355 kHz and the problem remains. In fact, the problem seems to be independent of the frequency of the incoming sine wave, as I get the same thing with a frequency of 1 kHz as opposed to 10 kHz: www.nd.edu/~ematlis/z.gnuradio/multi_scope_180dec_1.4V_1khz.jpg Any thoughts? thanks, eric On Tue, 9 Oct 2007, Eric Blossom wrote: On Tue, Oct 09, 2007 at 05:11:52PM -0400, [EMAIL PROTECTED] wrote: Thanks- I just downloaded, compiled and installed this latest revision. When I test multi_scope.py in the mutli-antenna examples directory with this release I get the same issue. Please note, I have the LF_RX daughterboards, so I change the daughterboard ID from BASIC to LF in the python code. I also eliminate the second factor of 4 decimation in the host (sw_decim = 4) by setting it to 1. I then run with the following command: multi-antenna]$ ./multi_scope.py -f0 -d250 -g0 while acquiring a 10 kHz 0.3 V p-p signal. The max value shown in the waveform on the gui is just over 25,000, which is way too much compared to the standard usrp_fft.py, which by the way is no longer in the examples directory; I used one from a previous release. If I increase the input voltage level to 0.4 V p-p, I get a jagged waveform with sharp discontinuities. So, my problem remains. Any ideas? What's your test signal? Is it your 100kHz wide signal? Can you try it with -d 400 as described below? Eric On Tue, 9 Oct 2007, Eric Blossom wrote: With the halfbands, it's flat to about 70% of the passband. decim = 320 gives 200kS/s complex baseband, a bit more than you'll need. Without the halfbands, I'd use about 4x the bandwidth of interest, then filter and decimate in the host for the final channel selection. In your case, I'd use decim = 160 giving 400kS/s. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] saturation with multi_fft.py
I don't have a chance to test your suggestion at the moment, but no, my test signal was an un-modulated 10 kHz signal. eric On Tue, Oct 09, 2007 at 05:11:52PM -0400, [EMAIL PROTECTED] wrote: Thanks- I just downloaded, compiled and installed this latest revision. When I test multi_scope.py in the mutli-antenna examples directory with this release I get the same issue. Please note, I have the LF_RX daughterboards, so I change the daughterboard ID from BASIC to LF in the python code. I also eliminate the second factor of 4 decimation in the host (sw_decim = 4) by setting it to 1. I then run with the following command: multi-antenna]$ ./multi_scope.py -f0 -d250 -g0 while acquiring a 10 kHz 0.3 V p-p signal. The max value shown in the waveform on the gui is just over 25,000, which is way too much compared to the standard usrp_fft.py, which by the way is no longer in the examples directory; I used one from a previous release. If I increase the input voltage level to 0.4 V p-p, I get a jagged waveform with sharp discontinuities. So, my problem remains. Any ideas? What's your test signal? Is it your 100kHz wide signal? Can you try it with -d 400 as described below? Eric On Tue, 9 Oct 2007, Eric Blossom wrote: With the halfbands, it's flat to about 70% of the passband. decim = 320 gives 200kS/s complex baseband, a bit more than you'll need. Without the halfbands, I'd use about 4x the bandwidth of interest, then filter and decimate in the host for the final channel selection. In your case, I'd use decim = 160 giving 400kS/s. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] saturation with multi_fft.py
Thanks- I just downloaded, compiled and installed this latest revision. When I test multi_scope.py in the mutli-antenna examples directory with this release I get the same issue. Please note, I have the LF_RX daughterboards, so I change the daughterboard ID from BASIC to LF in the python code. I also eliminate the second factor of 4 decimation in the host (sw_decim = 4) by setting it to 1. I then run with the following command: multi-antenna]$ ./multi_scope.py -f0 -d250 -g0 while acquiring a 10 kHz 0.3 V p-p signal. The max value shown in the waveform on the gui is just over 25,000, which is way too much compared to the standard usrp_fft.py, which by the way is no longer in the examples directory; I used one from a previous release. If I increase the input voltage level to 0.4 V p-p, I get a jagged waveform with sharp discontinuities. So, my problem remains. Any ideas? thanks, eric On Tue, 9 Oct 2007, Eric Blossom wrote: On Tue, Oct 09, 2007 at 03:02:33PM -0400, [EMAIL PROTECTED] wrote: Thanks so much for clarifying that! I see now that config.vh controls how the code is configured. FYI, I've committed new rbfs to the trunk. They were built with Quartus II Web Edition, version 7.1 SP1 Regarding the loss of the half-band filters in the multi-antenna fpga configuration; what is the recommendation to avoid aliasing? Say for the case of a 2 MHz carrier AM waveform with modulation out to 100 kHz. What kind of filtering would I need to avoid aliasing? thanks again, eric With the halfbands, it's flat to about 70% of the passband. decim = 320 gives 200kS/s complex baseband, a bit more than you'll need. Without the halfbands, I'd use about 4x the bandwidth of interest, then filter and decimate in the host for the final channel selection. In your case, I'd use decim = 160 giving 400kS/s. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] saturation with multi_fft.py
Thanks so much for clarifying that! I see now that config.vh controls how the code is configured. Regarding the loss of the half-band filters in the multi-antenna fpga configuration; what is the recommendation to avoid aliasing? Say for the case of a 2 MHz carrier AM waveform with modulation out to 100 kHz. What kind of filtering would I need to avoid aliasing? thanks again, eric On Tue, 9 Oct 2007, Eric Blossom wrote: On Tue, Oct 09, 2007 at 01:02:18PM -0400, [EMAIL PROTECTED] wrote: So there is no difference in the fpga code between the standard usrp_fft.py and multi_fft.py found in the multi-antenna directory? Then why does the latter specify std_4rx_0tx.rbf? Because it wants 4 digital downconverters (it's a 4 antenna example). We generate two standard FPGA configurations: std_2rxhb_2tx.rbf # 2 DDCs w/ halfband filters and 2 Tx paths std_4rx_0tx.rbf # 4 DDCs w/o halfband filters and 0 Tx paths And to reiterate my original concern, the multi-antenna versions of the code will not accept more than between .3-.4 V p-p for decimation rates greater than 128; greater than .4 V p-p and the result acts as if the A/D chips are clipping. It's not a hardware issue with my USRP because the usrp_fft.py codes correctly measure up to 2 V p-p. To avoid confusion, let's make sure we've got our terminology straight. There is no "multi-antenna" version of the FPGA code, only the two configurations described above. They are built from the same source, and vary only in which of the .vh files is included. However, taking a look at the modification dates on the .rbfs in: http://gnuradio.org/trac/browser/gnuradio/trunk/usrp/fpga/rbf/rev2 It appears that the std_2rxhb_2tx.rbf was updated 3 months ago, but that the std_4rx_0tx.rbf was updated 6 months ago. They should have both been generated and updated at the same time. [A makefile to handle this would be a good idea.] I will rebuild them both and update the rbf's in svn. I'll post a note when this is done. thanks for your help, eric You're welcome, Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] saturation with multi_fft.py
So there is no difference in the fpga code between the standard usrp_fft.py and multi_fft.py found in the multi-antenna directory? Then why does the latter specify std_4rx_0tx.rbf? And to reiterate my original concern, the multi-antenna versions of the code will not accept more than between .3-.4 V p-p for decimation rates greater than 128; greater than .4 V p-p and the result acts as if the A/D chips are clipping. It's not a hardware issue with my USRP because the usrp_fft.py codes correctly measure up to 2 V p-p. thanks for your help, eric On Tue, 9 Oct 2007, Eric Blossom wrote: On Tue, Oct 09, 2007 at 09:11:31AM -0400, [EMAIL PROTECTED] wrote: Actually no, I want the code that enables a single usrp to receive signals on two daughterboards. Sorry about the confusion on that; I assumed the "multi" in the filenames was referring to multiple daughterboards, I had forgotten there's a multi-usrp capability as well. The standard host and fpga code support multiple daughterboards as long as they are sharing the same interp and decim rates. For examples of this please take a look at gnuradio-examples/python/multi-antenna/* So, with that cleared up, can you verify which file specifically I should load into Quartus? There is only one usrp_std.qpf project file in usrp/fpga/toplevel/usrp_std so it is unclear to me how to compile for the two-daughter board case as opposed to the single. Do I need to configure something in the project file for the two-daughterboard case? There is nothing for you to do. The standard code supports two daughterboards. On the fpga it's handled via the muxes implemented in the FPGA. See http://gnuradio.org/trac/wiki/UsrpRfxDiagrams thanks, eric p.s.- on a positive note, at least my efforts to date have revealed what updates the multi_usrp.qsf file needs to compile! Thanks! Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] saturation with multi_fft.py
Actually no, I want the code that enables a single usrp to receive signals on two daughterboards. Sorry about the confusion on that; I assumed the "multi" in the filenames was referring to multiple daughterboards, I had forgotten there's a multi-usrp capability as well. So, with that cleared up, can you verify which file specifically I should load into Quartus? There is only one usrp_std.qpf project file in usrp/fpga/toplevel/usrp_std so it is unclear to me how to compile for the two-daughter board case as opposed to the single. Do I need to configure something in the project file for the two-daughterboard case? thanks, eric p.s.- on a positive note, at least my efforts to date have revealed what updates the multi_usrp.qsf file needs to compile! On Mon, 8 Oct 2007, Eric Blossom wrote: On Tue, Oct 09, 2007 at 12:05:08AM -0400, [EMAIL PROTECTED] wrote: Your suggestion worked to fix the compilation problem, along with the addition of a line for atr_delay.v, however, I'm not able to load the newly compiled rbf file into the usrp, and the error leads me to believe I need to take a step back and make sure I'm working with the right files. When I copied the newly compiled usrp_multi.rbf to share/usrp/rev2/, I get the following error with the verbose environment variable turned on: usrp: firmware ...share/usrp/rev2/std.ihx loaded successfully. Can't find fpga bitstream: multi_usrp_test.rbf even though I specified the name "multi_usrp_test.rbf" in the python code. So on a hunch I changed the name of the rbf file to std_4rx_0tx.rbf, adjusted my python code appropriatly, and now it loads but I get the following: usrp: firmware .../share/usrp/rev2/std.ihx loaded successfully. usrp: fpga bitstream ...share/usrp/rev2/std_4rx_0tx.rbf loaded successfully. This code requires an FPGA build with 4 DDCs. This FPGA has only 2. This would indicate that you didn't build what you think you did (or that the code that initializes that register value is hosed). The host reads back a register from the FPGA image to get the answer to number DDCs and DUCs. I suspect that you may have copied the wrong rbf to the wrong place, or something similar. So now my question is, to test the multiple receive capability of the usrp, Just to be clear, I think that you mean that you want to use multiple USRPs to receive multiple signals, NOT a single USRP with two daughterboards to receive multiple signals. Do I understand you correctly? exactly which project file (in which directory) do I need to load into Quartus, do I need to modify it to enable 4 receive ddc's, and once it compiles, what do I do with it? Where do I put it and how do I name it? Why does it need to be named exactly one way and not another? The project file for the multi-usrp stuff is in usrp/fpga/toplevel/usrp_multi You need to copy the resulting .rbf file into .../share/usrp/rev{2,4}/multi_4rx_0tx.rbf (or whatever you want to call it) Then you need to ensure that you are specifying that filename in the USRP constructor. E.g., u = usrp.source_c(0, decim, fpga_firmware="multi_4rx_0tx.rbf") I'm assuming that you have looked at the code in gnuradio-examples/python/multi_usrp/* I'm not exactly sure of that status of that code. Martin DVH would be the one to ask. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] saturation with multi_fft.py
Your suggestion worked to fix the compilation problem, along with the addition of a line for atr_delay.v, however, I'm not able to load the newly compiled rbf file into the usrp, and the error leads me to believe I need to take a step back and make sure I'm working with the right files. When I copied the newly compiled usrp_multi.rbf to share/usrp/rev2/, I get the following error with the verbose environment variable turned on: usrp: firmware ...share/usrp/rev2/std.ihx loaded successfully. Can't find fpga bitstream: multi_usrp_test.rbf even though I specified the name "multi_usrp_test.rbf" in the python code. So on a hunch I changed the name of the rbf file to std_4rx_0tx.rbf, adjusted my python code appropriatly, and now it loads but I get the following: usrp: firmware .../share/usrp/rev2/std.ihx loaded successfully. usrp: fpga bitstream ...share/usrp/rev2/std_4rx_0tx.rbf loaded successfully. This code requires an FPGA build with 4 DDCs. This FPGA has only 2. So now my question is, to test the multiple receive capability of the usrp, exactly which project file (in which directory) do I need to load into Quartus, do I need to modify it to enable 4 receive ddc's, and once it compiles, what do I do with it? Where do I put it and how do I name it? Why does it need to be named exactly one way and not another? thanks, eric On Mon, 8 Oct 2007, Eric Blossom wrote: On Mon, Oct 08, 2007 at 08:08:20PM -0400, [EMAIL PROTECTED] wrote: Just as an update, I downloaded revision 6599 and tried again, no change in the result. I then tried to compile usrp_std.qpf, and that did work; it produced 11,496 total logic elements for a utilization of 95%, so I think the Quartus software is working correctly. From this it would appear that usrp_multi needs to be updated? Sounds that way. I may just be missing a verilog file from the project file usrp_multi.qsf. Try adding the line below: [EMAIL PROTECTED] usrp_std]$ grep cic_dec_shifter * usrp_std.qsf:set_global_assignment -name VERILOG_FILE ../../sdr_lib/cic_dec_shifter.v Eric On Mon, 8 Oct 2007, [EMAIL PROTECTED] wrote: Ok, I installed the latest Quartus II ver. 7.2 software onto a virtualized WinXP guest hosted by a Linux x86_64 system running kvm/qemu. I downloaded a recent revision of gnuradio (revision 6595) onto the host. I started Quartus, and using a samba connection between the virtual guest and the Linux host I opened the usrp_multi.qpf project file in: usrp/fpga/toplevel/usrp_multi Not knowing anything about Quartus, I took a guess and hit "Start Compilation" under the Processing menu. The compilation begins, a lot of green and blue lines go by including many "Elaborating entity...", but after a short while the compilation fails with an error: "Error: Node instance "cic_dec_shifter" instantiates undefined entity "cic_dec_shifter" The line just before this, says: "Info: Elaborating entity "sign_extend" for hierarchy "rx_chain:rx_chain_0|cic_decim:cic_decim_i_0|sign_extend:ext_input" Not sure what to do at this point thanks, eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] saturation with multi_fft.py
Just as an update, I downloaded revision 6599 and tried again, no change in the result. I then tried to compile usrp_std.qpf, and that did work; it produced 11,496 total logic elements for a utilization of 95%, so I think the Quartus software is working correctly. From this it would appear that usrp_multi needs to be updated? eric On Mon, 8 Oct 2007, [EMAIL PROTECTED] wrote: Ok, I installed the latest Quartus II ver. 7.2 software onto a virtualized WinXP guest hosted by a Linux x86_64 system running kvm/qemu. I downloaded a recent revision of gnuradio (revision 6595) onto the host. I started Quartus, and using a samba connection between the virtual guest and the Linux host I opened the usrp_multi.qpf project file in: usrp/fpga/toplevel/usrp_multi Not knowing anything about Quartus, I took a guess and hit "Start Compilation" under the Processing menu. The compilation begins, a lot of green and blue lines go by including many "Elaborating entity...", but after a short while the compilation fails with an error: "Error: Node instance "cic_dec_shifter" instantiates undefined entity "cic_dec_shifter" The line just before this, says: "Info: Elaborating entity "sign_extend" for hierarchy "rx_chain:rx_chain_0|cic_decim:cic_decim_i_0|sign_extend:ext_input" Not sure what to do at this point thanks, eric On Sun, 7 Oct 2007, Eric Blossom wrote: On Fri, Oct 05, 2007 at 05:19:38PM -0400, [EMAIL PROTECTED] wrote: Can anybody tell me why the multi_* versions of the fft and scope applications (found in the multi-antenna directory) seem to have such a large gain on the input signal for high decimation values (eg 250), relative to the non-multi versions (at same -g gain setting) of the fft and scope aps? I'm saturating the inputs for anything above .3 V p-p using a function generator, whereas the non-multi versions work fine up to the 2 V p-p limit of the A/D. I'm putting in frequencies of 10 kHz and tuning to 0 Hz. I also noticed that the magnitudes of the values displayed by the multi_* programs is dependent on the decimation. At lower decimation values the magnitudes are much less. This variation is not as pronounced on the non-multi versions, although there is a 'dip' in the response. To give you some idea of the magnitude difference: for a .3 V p-p 10 kHz sine-wave input, here are the peak values: decimation usrp_fft.py (with -S) multi_scope.py 64 1750 1750 1281750 1750 1441750 2900 1881000 8000 2001200 1 2501750 25000 So for decimations greater than 128 the mult_* applications cannot take 2 V p-p. Any ideas? thanks, eric The FPGA rbf's checked into the trunk are probably not up to date for the multi_scope case. I'm not in the habit of building multi-board versions since I'm not sure how to test them. If you've got the free (beer) Quartus tools installed, you can rebuild the rbf's and check. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] saturation with multi_fft.py
Ok, I installed the latest Quartus II ver. 7.2 software onto a virtualized WinXP guest hosted by a Linux x86_64 system running kvm/qemu. I downloaded a recent revision of gnuradio (revision 6595) onto the host. I started Quartus, and using a samba connection between the virtual guest and the Linux host I opened the usrp_multi.qpf project file in: usrp/fpga/toplevel/usrp_multi Not knowing anything about Quartus, I took a guess and hit "Start Compilation" under the Processing menu. The compilation begins, a lot of green and blue lines go by including many "Elaborating entity...", but after a short while the compilation fails with an error: "Error: Node instance "cic_dec_shifter" instantiates undefined entity "cic_dec_shifter" The line just before this, says: "Info: Elaborating entity "sign_extend" for hierarchy "rx_chain:rx_chain_0|cic_decim:cic_decim_i_0|sign_extend:ext_input" Not sure what to do at this point thanks, eric On Sun, 7 Oct 2007, Eric Blossom wrote: On Fri, Oct 05, 2007 at 05:19:38PM -0400, [EMAIL PROTECTED] wrote: Can anybody tell me why the multi_* versions of the fft and scope applications (found in the multi-antenna directory) seem to have such a large gain on the input signal for high decimation values (eg 250), relative to the non-multi versions (at same -g gain setting) of the fft and scope aps? I'm saturating the inputs for anything above .3 V p-p using a function generator, whereas the non-multi versions work fine up to the 2 V p-p limit of the A/D. I'm putting in frequencies of 10 kHz and tuning to 0 Hz. I also noticed that the magnitudes of the values displayed by the multi_* programs is dependent on the decimation. At lower decimation values the magnitudes are much less. This variation is not as pronounced on the non-multi versions, although there is a 'dip' in the response. To give you some idea of the magnitude difference: for a .3 V p-p 10 kHz sine-wave input, here are the peak values: decimation usrp_fft.py (with -S) multi_scope.py 64 1750 1750 1281750 1750 1441750 2900 1881000 8000 2001200 1 2501750 25000 So for decimations greater than 128 the mult_* applications cannot take 2 V p-p. Any ideas? thanks, eric The FPGA rbf's checked into the trunk are probably not up to date for the multi_scope case. I'm not in the habit of building multi-board versions since I'm not sure how to test them. If you've got the free (beer) Quartus tools installed, you can rebuild the rbf's and check. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] saturation with multi_fft.py
Can anybody tell me why the multi_* versions of the fft and scope applications (found in the multi-antenna directory) seem to have such a large gain on the input signal for high decimation values (eg 250), relative to the non-multi versions (at same -g gain setting) of the fft and scope aps? I'm saturating the inputs for anything above .3 V p-p using a function generator, whereas the non-multi versions work fine up to the 2 V p-p limit of the A/D. I'm putting in frequencies of 10 kHz and tuning to 0 Hz. I also noticed that the magnitudes of the values displayed by the multi_* programs is dependent on the decimation. At lower decimation values the magnitudes are much less. This variation is not as pronounced on the non-multi versions, although there is a 'dip' in the response. To give you some idea of the magnitude difference: for a .3 V p-p 10 kHz sine-wave input, here are the peak values: decimation usrp_fft.py (with -S) multi_scope.py 64 1750 1750 1281750 1750 1441750 2900 1881000 8000 2001200 1 2501750 25000 So for decimations greater than 128 the mult_* applications cannot take 2 V p-p. Any ideas? thanks, eric Eric H. Matlis, Ph.D. Aerospace & Mechanical Engineering Dept. 120 Hessert Center for Aerospace Research University of Notre Dame Notre Dame, IN 46556-5684 Phone: (574) 631-6054 Fax: (574) 631-8355 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ATSC
Here it is: www.nd.edu/~ematlis/z.gnuradio/gr-atsc.tar.gz eric Eric H. Matlis, Ph.D. Aerospace & Mechanical Engineering Dept. 120 Hessert Center for Aerospace Research University of Notre Dame Notre Dame, IN 46556-5684 Phone: (574) 631-6054 Fax: (574) 631-8355 On Fri, 5 Oct 2007, Meiners, Jason wrote: Could someone send me a zipped file of the gr-atsc directory in trunk? I have had zero luck getting svc to work properly. Thanks for your help. Jason [EMAIL PROTECTED] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] low frequency oscope
Yes, it's 10 Hz. And a 50 Hz high-pass; I originally didn't have that in place, thinking it would filter off the 4 Hz, but in fact it doesn't seem to, although it does remove most of the DC. Could this problem be an aliasing problem? Or could it be related to the frequency resolution of the local oscillator? thanks, eric On Thu, 13 Sep 2007, Eric Blossom wrote: On Thu, Sep 13, 2007 at 12:53:35PM -0400, [EMAIL PROTECTED] wrote: Hi all- I'm trying to understand the behavior of the USRP/LFRX when used as a low frequency oscilloscope. I am trying to measure a AM modulated waveform with carrier frequency 34 kHz, modulated at 4 Hz. The decimation in the FPGA is 250, with a 10 Hz low-pass fir filter with a decimation factor of Do you really mean 10 Hz low-pass filter, or is this a typo? 64 giving an effective sampling rate of 4 kHz, and a high-pass filter at 50 Hz to remove the 0 Hz (DC) component created by the demodulation. I am using the std_4rx_0tx.rbf firmware to enable 4 channel reception. Contrary to my expectations, I can tune to USRP off the 34 kHz and still pickup the 4 Hz; in fact, it's better if I do tune away from 34 kHz! I can tune anywhere between 0 and 34.98 and I get a nice waveform. I I tune to exactly 34 kHz, I get a low frequency modulation at roughly 1.67 Hz on top of the 4 Hz I'm trying to measure. Here's a snippet of my (psuedo) code for the first channel: usrp --> dinterleaver --> (dinterleaver_ch0)magblock --> lpf --> hpf --> scope. Any thoughts? thanks! eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] low frequency oscope
Hi all- I'm trying to understand the behavior of the USRP/LFRX when used as a low frequency oscilloscope. I am trying to measure a AM modulated waveform with carrier frequency 34 kHz, modulated at 4 Hz. The decimation in the FPGA is 250, with a 10 Hz low-pass fir filter with a decimation factor of 64 giving an effective sampling rate of 4 kHz, and a high-pass filter at 50 Hz to remove the 0 Hz (DC) component created by the demodulation. I am using the std_4rx_0tx.rbf firmware to enable 4 channel reception. Contrary to my expectations, I can tune to USRP off the 34 kHz and still pickup the 4 Hz; in fact, it's better if I do tune away from 34 kHz! I can tune anywhere between 0 and 34.98 and I get a nice waveform. I I tune to exactly 34 kHz, I get a low frequency modulation at roughly 1.67 Hz on top of the 4 Hz I'm trying to measure. Here's a snippet of my (psuedo) code for the first channel: usrp --> dinterleaver --> (dinterleaver_ch0)magblock --> lpf --> hpf --> scope. Any thoughts? thanks! eric Eric H. Matlis, Ph.D. Aerospace & Mechanical Engineering Dept. 120 Hessert Center for Aerospace Research University of Notre Dame Notre Dame, IN 46556-5684 Phone: (574) 631-6054 Fax: (574) 631-8355 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] driver for ueidaq boards
I put their latest driver and a pdf user guide on my website. These are freely available from them. They are at: www.nd.edu/~ematlis/z.gnuradio/powerdaq_linux_full_3.6.18.tgz and www.nd.edu/~ematlis/z.gnuradio/PDAQ-MAN-MFX-601.pdf The tar file contains the driver and there is a manual of the API in the doc section. How difficult do you think it would be to write the interface, based on the information I link to above? Is there a template I could use to look into writing it? eric Eric H. Matlis, Ph.D. Aerospace & Mechanical Engineering Dept. 120 Hessert Center for Aerospace Research University of Notre Dame Notre Dame, IN 46556-5684 Phone: (574) 631-6054 Fax: (574) 631-8355 On Mon, 23 Jul 2007, Johnathan Corgan wrote: [EMAIL PROTECTED] wrote: I was curious what would be involved in getting gnuradio to run on any given data acquistion board that already has a linux kernel driver, such as the United Electronic Industry's Powerdaq boards: http://ueidaq.com/products/pci-data-acquisition/pd2-mfs/ We have a number of these in the lab, and I would be interested in using them in a gnuradio-based oscilloscope type fashion. These boards are capable of streaming data using the Linux drivers. On the face of it there doesn't seem to be any reason you couldn't write a C++ GNU Radio source block that interfaces with the Linux driver. But there was no software driver spec available on the page you linked to really say. The complexity of the GNU Radio block is in direct proportion to how complicated they make their streaming interface. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] driver for ueidaq boards
Hi all- I was curious what would be involved in getting gnuradio to run on any given data acquistion board that already has a linux kernel driver, such as the United Electronic Industry's Powerdaq boards: http://ueidaq.com/products/pci-data-acquisition/pd2-mfs/ We have a number of these in the lab, and I would be interested in using them in a gnuradio-based oscilloscope type fashion. These boards are capable of streaming data using the Linux drivers. thanks, eric Eric H. Matlis, Ph.D. Aerospace & Mechanical Engineering Dept. 120 Hessert Center for Aerospace Research University of Notre Dame Notre Dame, IN 46556-5684 Phone: (574) 631-6054 Fax: (574) 631-8355 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] offset at input of LF_RX
Thank you! eric On Fri, 22 Jun 2007, Roshan Baliga wrote: You want the full schematics, which I believe are in the subversion repository. You can get them with this command (once you've installed the subversion client, of course): svn co http://gnuradio.org/svn/usrp-hw/trunk usrp-hw -Roshan [EMAIL PROTECTED] wrote: I would like to see this schematic that Don mentions; I look at ettus.com but all I could find is the 1-page basic description of the daughterboard. Is there something more detailed that shows the layout of the 8132 as well as the ADC? thanks, eric p.s.- the USRP performed beautifully for my demo, suitable impressing what might prove to be the next generation of aerospace engineers! On Fri, 22 Jun 2007, Matt Ettus wrote: Don Ward wrote: That's not what I get. With the input open, I measure 108 mV on the SMA connector and a DC component from the ADC (detected using the RSSI register, to avoid the DC offset filter in the FPGA). If I short the input to ground, I get a negative DC component from the ADC. To get zero from the ADC I need to ground the input through a 50 ohm (approximately) resistance; in this case I measure 62 mV at the input to the LFRX board. My conclusion (confirmed by inspection of the schematic) is that the LFRX needs to be driven by a source resistance of 50 ohms *at DC* to be correctly biased. I am sorry. You guys are both right. If you connect a 50 ohm resistor across the SMA, you do indeed get 62mV at the connector, but 0V at the ADC, which is what we really care about. If you leave the SMA open, you do get a small voltage being read at the ADC. So yes, the LFRX does have DC bias on its input, but as long as you drive it with a 50 ohm load, you get the right answer at the ADC. The LFRX wasn't designed for measuring DC voltages, although it can as long as you have a 50 ohm source. And if your source is not 50 ohms, you can do the calculations necessary to scale the gain. Also, please note that the amp is inverting, so if you put 1V through 50 ohms into the SMA, the ADC will tell you that it is -1V. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] offset at input of LF_RX
I would like to see this schematic that Don mentions; I look at ettus.com but all I could find is the 1-page basic description of the daughterboard. Is there something more detailed that shows the layout of the 8132 as well as the ADC? thanks, eric p.s.- the USRP performed beautifully for my demo, suitable impressing what might prove to be the next generation of aerospace engineers! On Fri, 22 Jun 2007, Matt Ettus wrote: Don Ward wrote: That's not what I get. With the input open, I measure 108 mV on the SMA connector and a DC component from the ADC (detected using the RSSI register, to avoid the DC offset filter in the FPGA). If I short the input to ground, I get a negative DC component from the ADC. To get zero from the ADC I need to ground the input through a 50 ohm (approximately) resistance; in this case I measure 62 mV at the input to the LFRX board. My conclusion (confirmed by inspection of the schematic) is that the LFRX needs to be driven by a source resistance of 50 ohms *at DC* to be correctly biased. I am sorry. You guys are both right. If you connect a 50 ohm resistor across the SMA, you do indeed get 62mV at the connector, but 0V at the ADC, which is what we really care about. If you leave the SMA open, you do get a small voltage being read at the ADC. So yes, the LFRX does have DC bias on its input, but as long as you drive it with a 50 ohm load, you get the right answer at the ADC. The LFRX wasn't designed for measuring DC voltages, although it can as long as you have a 50 ohm source. And if your source is not 50 ohms, you can do the calculations necessary to scale the gain. Also, please note that the amp is inverting, so if you put 1V through 50 ohms into the SMA, the ADC will tell you that it is -1V. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] offset at input of LF_RX
On Fri, 22 Jun 2007, Matt Ettus wrote: [EMAIL PROTECTED] wrote: On Thu, 21 Jun 2007, Matt Ettus wrote: If there is no dc-removing capacitor in the circuitry , then should I not expect that for a board using a single (positive) supply, that the signal is always above zero? No, you can put a negative voltage in, as long as it doesn't go below -3.33V. You need to look at the schematics -- the 8132 is a differential opamp with a common mode output set at 3.3V/2. I meant that if you operate single supply, a negative input would be mapped to a voltage referenced to the common mode output, not to zero. So -.1 V would become 3.3/2 -.1 = 1.55 V. That's what the data sheet seems to indicate if I read it correctly. Am I reading it correctly? If you put 0V in, both outputs of the amp should be at 3.3/2. If you put in a positive voltage V, the + output should go up by V/2 and the negative output should go down by V/2. The reverse happens for negative voltages. Basically, the differential amps will clip if you go outside the range of -3.3V to +3.3V. You will also damage the differential amp if you go below -3.3V. The ADC will clip if you go outside the range -2V to +2V when set for minimum gain. Back to the subject of what your signal generator is doing, I don't know. If you measure the voltage on the sma connector with nothing connected, you will see that it is 0. If you connect a 1 V source through a 50 ohm resistor, you will see that there is 0.5V at the connector. If you connect -1 V through a 50 ohm resistor, you will see -0.5V at the connector. I do not. In fact, with no voltage applied to a powered up USRP, I actually see +.109 V! So when I apply a -.1 (through a 50 ohm resistor) I see just above zero. I see the behavior you describe only if I unpower the USRP/LF-RX. What gives? Sounds broken. The LFRX has 2 inputs. Does the other one behave the same way? I am measuring at the output connector of the LF-RX, which is of course the input to the 8132. I wasn't measuring at the outputs of that chip on the circuit board. Is that what you intended me to do? And I have 2 LFRX's and all 4 inputs behave the same way. Matt I'm actually giving a demo with the USRP in a couple of minutes to some visiting students, so I'll have to wait to open up my case and make those measurements... I'll get back to you asap though. thanks, eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] offset at input of LF_RX
On Thu, 21 Jun 2007, Matt Ettus wrote: If there is no dc-removing capacitor in the circuitry , then should I not expect that for a board using a single (positive) supply, that the signal is always above zero? No, you can put a negative voltage in, as long as it doesn't go below -3.33V. You need to look at the schematics -- the 8132 is a differential opamp with a common mode output set at 3.3V/2. I meant that if you operate single supply, a negative input would be mapped to a voltage referenced to the common mode output, not to zero. So -.1 V would become 3.3/2 -.1 = 1.55 V. That's what the data sheet seems to indicate if I read it correctly. Am I reading it correctly? Basically, the differential amps will clip if you go outside the range of -3.3V to +3.3V. You will also damage the differential amp if you go below -3.3V. The ADC will clip if you go outside the range -2V to +2V when set for minimum gain. Back to the subject of what your signal generator is doing, I don't know. If you measure the voltage on the sma connector with nothing connected, you will see that it is 0. If you connect a 1 V source through a 50 ohm resistor, you will see that there is 0.5V at the connector. If you connect -1 V through a 50 ohm resistor, you will see -0.5V at the connector. I do not. In fact, with no voltage applied to a powered up USRP, I actually see +.109 V! So when I apply a -.1 (through a 50 ohm resistor) I see just above zero. I see the behavior you describe only if I unpower the USRP/LF-RX. What gives? Matt thanks, eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] offset at input of LF_RX
gnuradio.org appears to be down. Where can I find that flag, and how do I disable it? However, my surmise of the last post seems to be correct. When I substitute a regular Basic RX for the LF RX unit, the upwards shift goes away. This is I'm guessing because, as I hinted to in my previous post, the the LF-RX is dc-coupled to the input signal, and because the USRP board is single supply no negative voltages can be represented. The Basic RX, however, is AC-coupled through an input tranformer and as such any dc bias is automatically removed. At least, that's my theory. Any takers care to correct me on that one? thanks all. eric On Thu, 21 Jun 2007, Brian Padalino wrote: On 6/21/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Is there a software flag in the code I can switch off? If so, where? http://gnuradio.org/trac/wiki/UsrpFPGA Under "Common Registers": 15 FR_DC_OFFSET_CL_EN DC offset control loop enable Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] offset at input of LF_RX
On Thu, 21 Jun 2007, Matt Ettus wrote: Oddly enough, usrp_oscope.py doesn't show any DC bias whatsoever, regardless of what offset I put into the function generator. Maybe it's removed inside the flow-graph? DC offset is automatically removed in hardware, but you can turn that feature off. Can you explain that in more detail, please? Do you have a capacitor is series with the signal flow to remove any dc? It is done digitally. If there is no dc-removing capacitor in the circuitry , then should I not expect that for a board using a single (positive) supply, that the signal is always above zero? Matt thanks, eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] offset at input of LF_RX
On Thu, 21 Jun 2007, Matt Ettus wrote: Oddly enough, usrp_oscope.py doesn't show any DC bias whatsoever, regardless of what offset I put into the function generator. Maybe it's removed inside the flow-graph? DC offset is automatically removed in hardware, but you can turn that feature off. Can you explain that in more detail, please? Do you have a capacitor is series with the signal flow to remove any dc? It is done digitally. Is there a software flag in the code I can switch off? If so, where? Matt thanks, eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] offset at input of LF_RX
On Thu, 21 Jun 2007, Don Ward wrote: - Original Message - From: <[EMAIL PROTECTED]> To: Sent: Thursday, June 21, 2007 5:22 PM Subject: [Discuss-gnuradio] offset at input of LF_RX Hi all- can anybody explain why the USRP/ LF_RX would seem to introduce a DC bias or offset to a signal generated by a function generator? I have a function generator configured to produce a 1 kHz .1 V P-P signal into a 50 Ohm load. I have a Lecroy digital oscilloscope configured with the input at high-impedance to monitor the signal. When I connect the signal to the USRP, I see the trace on the Lecroy gets shifted UP by about .06 volts, ie I have to add a -0.06 V offset at the function generator to zero the bias. Oddly enough, usrp_oscope.py doesn't show any DC bias whatsoever, regardless of what offset I put into the function generator. Maybe it's removed inside the flow-graph? Any thoughts on either of these questions? From looking at the schematic, it appears that the LFRX requires a 50 ohm input resistance (at DC) to bias it for zero output. Does your function generator do this? Yes, the function generator has two modes; high impedance output and 50 ohm load output. It's a switch that seems to basically just multiply the setting on the amplitude by a factor of 2 to account for the voltage divider created by the 50 ohm load. -- Don W. thanks, eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] offset at input of LF_RX
On Thu, 21 Jun 2007, Matt Ettus wrote: [EMAIL PROTECTED] wrote: Hi all- can anybody explain why the USRP/ LF_RX would seem to introduce a DC bias or offset to a signal generated by a function generator? I have a function generator configured to produce a 1 kHz .1 V P-P signal into a 50 Ohm load. I have a Lecroy digital oscilloscope configured with the input at high-impedance to monitor the signal. When I connect the signal to the USRP, I see the trace on the Lecroy gets shifted UP by about .06 volts, ie I have to add a -0.06 V offset at the function generator to zero the bias. Are you sure everything is on the same ground? Disconnect everything but leave it powered up, and measure the voltage on the ground of the scope, lfrx, usrp power supply, and sig gen. Then reconnect things and do the same. Using the ground of the USRP power supply as a reference, I saw a maximum of 0.005 volts difference between the grounds of the scope, the function generator, and the inputs to the LF-RX boards. When I check continuity, all the grounds save that of the sig gen are connected (the sig gen has a battery isolation). Obviously, when I connect everything back up those grounds are all on the same plane. So to sum up. With the sig gen configured for .1 V p-p with 50 Ohm impedance, when I connect only the Lecroy (configured for 50 Ohm impedance) the signal is .1 V p-p centered about zero as expected. When I then switch the Lecroy to high impedance and connect the USRP, the signal now is roughly .1 V p-p but centered about roughly 0.06 V, ie shifted up by slightly more than half scale. Just to confirm that the problem is not my function generator, instead of the USRP I connected a second Lecroy configured also with 50 Ohm impedance (the other Lecroy at high impedance) and verified that the signal is as expected, ie .1 V p-p centered about zero. Oddly enough, usrp_oscope.py doesn't show any DC bias whatsoever, regardless of what offset I put into the function generator. Maybe it's removed inside the flow-graph? DC offset is automatically removed in hardware, but you can turn that feature off. Can you explain that in more detail, please? Do you have a capacitor is series with the signal flow to remove any dc? thanks, eric Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] offset at input of LF_RX
Hi all- can anybody explain why the USRP/ LF_RX would seem to introduce a DC bias or offset to a signal generated by a function generator? I have a function generator configured to produce a 1 kHz .1 V P-P signal into a 50 Ohm load. I have a Lecroy digital oscilloscope configured with the input at high-impedance to monitor the signal. When I connect the signal to the USRP, I see the trace on the Lecroy gets shifted UP by about .06 volts, ie I have to add a -0.06 V offset at the function generator to zero the bias. Oddly enough, usrp_oscope.py doesn't show any DC bias whatsoever, regardless of what offset I put into the function generator. Maybe it's removed inside the flow-graph? Any thoughts on either of these questions? thanks. eric Eric H. Matlis, Ph.D. Aerospace & Mechanical Engineering Dept. 120 Hessert Center for Aerospace Research University of Notre Dame Notre Dame, IN 46556-5684 Phone: (574) 631-6054 Fax: (574) 631-8355 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] problem with mult-fft/scope resolved
The problem was in the gain level- I hadn't realized the default gain in the mult_ versions is at 20 compared to midvalue for the standard versions. My signal was saturating the A/D's at this value of gain. Reducing the gain eliminated the problem. eric Eric H. Matlis, Ph.D. Aerospace & Mechanical Engineering Dept. 120 Hessert Center for Aerospace Research University of Notre Dame Notre Dame, IN 46556-5684 Phone: (574) 631-6054 Fax: (574) 631-8355 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] multi scope/fft not working right?
Hi all- I'm trying to build a multi-reciever program modelled on the stuff in the multi_antenna directory, however there seems to be a problem with the multi_fft and multi_scope programs. I have 2 LF daughterboards, and I'm using a function generator to send a 1 kHz sine wave with .1 V p-p levels. I start either the _fft or _scope program with the arguments -d 250 -f 0. What I'm observing is a very distorted signal; the distortion appears to be due to the presence of significant energy in some harmonics away from 0 Hz. I can remove them if I sharpen the default filter, but I have to have a cuttoff very close to my 1 khz to clean it up. What is going on? I have two images, one for the scope and one for the fft at: www.nd.edu/~ematlis/z.gnuradio/multi_scope.jpg www.nd.edu/~ematlis/z.gnuradio/multi_fft.jpg The standard usrp_oscope.py and usrp_fft.py do not show these harmonics and the signal is very clean. Any suggestions? thanks, eric Eric H. Matlis, Ph.D. Aerospace & Mechanical Engineering Dept. 120 Hessert Center for Aerospace Research University of Notre Dame Notre Dame, IN 46556-5684 Phone: (574) 631-6054 Fax: (574) 631-8355 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] noise problem with USRP
Chris- thanks for the suggestions. I may try to add the ferrite toroid. It's just curious that I didn't notice this before. Maybe my power brick is functioning differently, although it is brand new. thanks, eric On Mon, 18 Jun 2007, Chris Albertson wrote: --- [EMAIL PROTECTED] wrote: I'm seeing a strange noise issue with my USRP. I have a simple antenna fashioned out of a spool of wire connected to a LF-DC daughterboard So if (1) antenna is connected and (2) you are using notebook connected to mains then you see 120Hz noise. So I think the noise comes from the power brick and enters via the antenna. Sounds like the notebook power supply or the cables it connects to radiates RF. Not surprizing at all for a switching power supply Try installing some ferrite toroids on both of the cables on the power brick. Use as many turns as you can through the toroid. Another option is to use an antenna that is farther away from the power brick and bring the signal back using a long coax feed line. Use the inverse square law to your advantage. Chris Albertson Home: 310-376-1029 [EMAIL PROTECTED] Office: 310-336-5189 [EMAIL PROTECTED] Shape Yahoo! in your own image. Join our Network Research Panel today! 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] noise problem with USRP
Hello all- I'm seeing a strange noise issue with my USRP. I have a simple antenna fashioned out of a spool of wire connected to a LF-DC daughterboard with no anti-aliasing filters. The USRP is connected to a laptop and powered off it's standard brick power supply. When the laptop is plugged into the mains, my am-demod gui shows a lot of noise in the spectrum and time series; when I disconnect the laptop from the power socket to operate on the battery this noise goes away. I have two images demonstrating the difference at: www.nd.edu/~ematlis/z.gnuradio/usrp_on_mains.jpg www.nd.edu/~ematlis/z.gnuradio/usrp_on_battery.jpg I don't believe I was seeing this in the recent past, however I recently upgraded to Fedora 7, although I don't see how this could be a factor. You can see in the pic that the demodulated time series has a strong content at roughly 120 HZ; this could be a power-supply induced issue (60 Hz supply harmonic). The odd thing is there is no noise at all when I disconnect the antenna, so the noise does not seem to be entirely a function of the power supply alone. I also do not see the noise at all when using a desktop PC. My supposition is there is some kind of interaction between the power supply ripple coming from the laptop power supply and the circuitry of the USRP, but I have no direct evidence. Any thoughts? Has anybody seen this also? thanks, eric Eric H. Matlis, Ph.D. Aerospace & Mechanical Engineering Dept. 120 Hessert Center for Aerospace Research University of Notre Dame Notre Dame, IN 46556-5684 Phone: (574) 631-6054 Fax: (574) 631-8355 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] VIA USB-2 combo card card, not working on linux for usrp
I have an Adaptec DuoConnect AUA-1422 combo card with an NEC USB2 chipset. Using Mandriva 2007 spring on a Dell Latitude C840 with Pentium 4 m 2.6 GHz cpu I only get 16 MB/s transfer as determined by benchmark_usb.py. A little dissapointed, specially as I'm experiencing uO's with my latest 4-channel receiver app. eric Eric H. Matlis, Ph.D. Aerospace & Mechanical Engineering Dept. 120 Hessert Center for Aerospace Research University of Notre Dame Notre Dame, IN 46556-5684 Phone: (574) 631-6054 Fax: (574) 631-8355 On Thu, 7 Jun 2007, Martin Dvh wrote: Hi all, I am using a combo pccard (USB-2 and firewire) with VIA chipset to get USB-2 on my laptop. But using linux I can't get it to work. I get usrp overruns, (uOuOuO) even with decimation factors of 200 when using usrp_rx_cfile.py This is only 320 ksamples/sec with top I see that the CPU is 80 % idle, so that is not the problem. When running benchmark_usb.py I get slightly better performance, 2 MB/sec works and 4 MB/sec works sometimes, all above fail. I don't know why benchmark_usb works better then usrp_rx_cfile. When I run usrp_wfm_rcv_nogui.py I get garbled sound and uO and aU, but this is logical. The script doesn't get enough data from the USRP. On windows usrp_rx_cfile.py just works fine with the same usb-2 card. (This is a much older gnuradio/usrp release though) Does anybody have a clue, what is wrong here. I tried both kernel 2.6.18 and 2.6.20. I also tried noacpi acpi=off apm=off as kernel-boot param. Or does anybody have a suggestion of an USB-2 addon card for a notebook (pccard) that works with the USRP. Greetings, Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] multi_file usrp tuning options
Ok, great. This simplifies things; I was afraid I was going to have to create a modulating circuit to modulate those low-frequency timing signals so they could be captured along with the 2 MHz am-modulated signals using a single tuning frequency. I have some questions about the deinterleaver. Firstly, how does it know how many channels are interleaved? Does it determine this information from the Mux settings, or from the number and type of subdevices detected, or something else? Secondly, in terms of computational efficiency, is there any advantage to performing the deinterleave operation earlier in the flow-graph sequence, or later? For example, I'm doing AM demodulation. So, currently my flow graph consists of the usrp block connected to a low-pass filter, connected to a mag block, connected to a high-pass filter (to remove dc), connected to a block that corrects for gain, connected to a block that factors in a "calibration constant" for the data path, and finally the file-write. I also branch off to some fft sinks. Is it necessary for me to introduce a deinterleave block immediately after the usrp block or can I put it anywhere? Thirdly, if all I was doing was capturing to file, is the deinterleaver strictly necessary? I could write a program to deinterleave the data in the file in post-processing, correct? thanks! eric On Fri, 1 Jun 2007, Eric Blossom wrote: On Fri, Jun 01, 2007 at 09:27:55AM -0400, [EMAIL PROTECTED] wrote: Excellent. Just so I understand how this is done- when one tunes different subdevices to different frequencies, is there one LO on the USRP which is being switched between these frequencies, or is there more than one LO? In general, the tuning is split between an LO on the daughterboard and the DDCs in the the FPGA. In the case of the Basic Rx and LF RX, there is no LO on the daughterboard, so all the tuning is handled by the DDC. When using std_4rx_0tx.rbf, there are 4 DDCs available in the FPGA. u.tune(...) handles adjusting the LO (if any) and the DDCs transparently for the common case. Also- Can I tune all four subdevices independently, or am I restricted to using the same frequency on a given daughterboard? With the Basic and LF Rx everything is independent, since there's no LO on the daughterboard. In the case of daughterboards with LO's, life is a bit more complicated and you'll have to explicitly control the LO on the daughterboard, and then explicitly control the 2 DDCs that are being fed from the given daughterboard. You of course need to ensure that that two frequencies that you want within the IF passband of the daughterboard. To see how this is currently handled, take a look at the implementation of "tune" in gr-usrp/src/usrp.py Finally- I would guess that at a minimum the decimation factor set in the fpga must be the same for all subdevices. Is this correct? Yes, the decimation rate applies to all subdevices. thanks again, eric You're welcome! Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] multi_file usrp tuning options
Hi- I'm developing a 4-channel receiver using 4 rx paths and 2 LFRX daughter boards. I'm basing my code on the multi_* examples in the multi-antenna directory. Two of the channels I want to capture are AM-modulated at roughly 2 MHz carrier frequency, the other two signals are not modulated and are low frequency on the order of 1 kHz. My question is, can I tune each subdevice to a different frequency? I would need to in order to capture both sets of signals simultaneously in a phase-locked fashion (this is important). thanks, eric Eric H. Matlis, Ph.D. Aerospace & Mechanical Engineering Dept. 120 Hessert Center for Aerospace Research University of Notre Dame Notre Dame, IN 46556-5684 Phone: (574) 631-6054 Fax: (574) 631-8355 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] chuck swiger's file utilities
Hi- I've fixed the problem. I can just read the data directly as a float. You can see my c-code if you want to at: www.nd.edu/~ematlis/z.gnuradio/gnuradio_read_binary_float.c thanks for your help. eric On Tue, 29 May 2007, ismail_itee_uq wrote: ematlis wrote: Hi- does anybody know where Chuck Swiger's website went to? His old site seems to be down and I was looking for his c-code based binary read file utilities. I tried plotting with gr_plot_float.py but the result doesn't seem right to me. thanks, eric [snip] Hi eric, Try matplotlib / pylab: http://matplotlib.sourceforge.net/ OR: You can install it (I did it on Ubuntu) with the 'python-matplotlib' package. Then for plotting, simply: import pylab ... pylab.plot(data) Hope this helps, - Ismail PS You might need to install some other packages to get rid of warning messages. -- View this message in context: http://www.nabble.com/chuck-swiger%27s-file-utilities-tf3836373.html#a10865109 Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] chuck swiger's file utilities
Hi- does anybody know where Chuck Swiger's website went to? His old site seems to be down and I was looking for his c-code based binary read file utilities. I tried plotting with gr_plot_float.py but the result doesn't seem right to me. thanks, eric Eric H. Matlis, Ph.D. Aerospace & Mechanical Engineering Dept. 120 Hessert Center for Aerospace Research University of Notre Dame Notre Dame, IN 46556-5684 Phone: (574) 631-6054 Fax: (574) 631-8355 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Sdcc now available in Fedora.
I also have some sdcc rpm's that worked for me in FC5 at: www.nd.edu/~ematlis/z.gnuradio try sdcc-20061124-4482.x86_64.rpm or sdcc-20061124-4482.src.rpm eric On Wed, 2 May 2007, Trond Danielsen wrote: 2007/5/2, Achilleas Anastasopoulos <[EMAIL PROTECTED]>: Trond, I was not able to locate sdcc in the FC5 repos. Could you please verufy what the status of this project is. Ah, I never added it to FC5, and the CVS are closed atm because of the merge between Fedora Core and Fedora Extras, so I cannot commit it now. I will however request a build once it is open again. In the meantime you should be able to download the src.rpm for devel or FC6 (they are identical) and build it your self. Sorry for the inconvenience. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Can't get input from sound card.
I just got the audio_fft.py running, and this is how I did it on a Fedora Core 6 x86_64 machine, in KDE with a set of earphones/microphone: 1) started kmix, went to the "Input" selection and enabled "capture" 2) verified that audio_fft.py was responding by starting it in Oscilloscope mode, ie "./audio_fft.py -S" with Autorange selected and the timescale set to 1ms/div. I can "see" myself typing this email as the microphone picks up the key-clicks. 3) quit audio_fft.py and restarted it without any flags, ie "./audio_fft.py" 4) right-clicked on the gui window, and selected the highest db/div setting, ie 20 db/div. Otherwise, there was no visible activity on the scale. An alternative would be to decrement the reference level, again by right-clicking and selecting "Decr Ref Level" several times until you see graph activity. I can now see the broadband spectrum as I snack on some peanuts, which seems to be centered below 2 kHz. Incidentally, I can't seem to whistle above 2.5 kHz. eric On Mon, 19 Mar 2007, Bahn William L Civ USAFA/DFCS wrote: Subject: Re: [Discuss-gnuradio] Can't get input from sound card. LRK [EMAIL PROTECTED] On Sat, Mar 17, 2007 at 01:15:34AM -0600, Bahn William L Civ USAFA/DFCS wrote: I still can't get any input from the sound card. I have installed GNU Radio on a completely different computer. The dial_tone.py program works. I get a flat line (it bounces around between -8e-5 and +4e-5) when I run audio_fft.py in the oscilloscope mode. In the hopes of perhaps, possibly getting some kind of a response, I'll try to ask very specific questions. 1) Is the signal source for audio_fft.py supposed to default to the sound card microphone? 2) If not, what is the default? 3) If not, can I tell it to use the sound card microphone? 4) If yes, how? I'm running FreeBSD and the sound cards are controlled by the 'mixer' command. There is a similar command in Linux. Maybe 'amixer'? I have to select the input with the 'mixer', either mic or line. I also have a control named 'rec' which sets the input volume level. The latest versions of FreeBSD save the mixer settings across re-boots. I have not found a way to set these from GR and I have some soundcards which do show a 'rec' control and do not work. Best I can tell the soundcard world is a 'black art' and there are no standards. Maybe someone can shed more light on this. Thanks LRK, that helped at least some. In the GNOME GUI I found a mixer under "Preferences-Volume Control". By un-muting the microphone I got it so that the mike is now live (blow into it and you hear it at the speaker) and selected it as the capture device. But the GNUradio apps such as audio_fft.py still show no response. So although I'm half a step closer, I still think I need at least the basic answers to the above questions, namely: 1) Is the signal source for audio_fft.py supposed to default to the sound card microphone? 2) If not, what is the default? 3) If not, can I tell it to use the sound card microphone? 4) If yes, how? Thanks. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] window sizing issue
Michael- I'm trying to "calibrate" the flow-graph of the am_rcv_plasma_mod.py so that the values displayed in the final window represent actual input amplitudes. The first step to do this would be to account for the internal gain; so I need to divide through by a factor of 10^(gain) where gain is in db. To implement this I define: self.gain_correction = gr.divide_ff(math.log10(self.gain)) and later I implement it as follows: self.connect (self.magblock, self.gain_correction) and if plot3: self.scope = scopesink.scope_sink_f(self, self.panel, title="AM Demodulated Time Series", sample_rate=demod_rate, size=(50,100), t_scale=1.0e-3, v_scale=None, vbox=vbox) self.connect(self.gain_correction, self.scope) but I get the error: File "am_rcv_plasma_mod.py", line 95, in __init__ self.gain_correction = gr.divide_ff(math.log10(self.gain)) AttributeError: 'am_plasma_rx_graph' object has no attribute 'gain' How do I "grab" whatever the current value of the gain is and use it to divide through? The gain will be set by either the mouse or the powermate device. Any thoughts? thanks, eric Eric H. Matlis, Ph.D. Aerospace & Mechanical Engineering Dept. 120 Hessert Center for Aerospace Research University of Notre Dame Notre Dame, IN 46556-5684 Phone: (574) 631-6054 Fax: (574) 631-8355 On Fri, 16 Mar 2007, Michael Dickens wrote: On Mar 16, 2007, at 12:01 PM, [EMAIL PROTECTED] wrote: 1) do you happen to know where the default values for the control buttons are set? I'd like to change the time scale from 100us/div to 1ms/div and to set the Autorange to "on" by default. In your "am_..." file, change the "scope_sink_f" call to inside "_build_gui", "if plot3:": self.scope = scopesink.scope_sink_f(self, self.panel, title="AM Demodulated Time Series", sample_rate=demod_rate, size=(50,100), t_scale=1.0e-3, v_scale=None) the last 2 items set the time scale and autorange as you want. 2) do you know how to convert the integer values on the third window (time-series) to actual voltage values as measured by the adc? It must be a function of the internal gain and offset. I need to know these eventually; this application is supposed to measure physical voltages, not just produce sounds. Not sure of this. Maybe whoever wrote the script knows? - MLD#!/usr/bin/env python #import scopesink_mod as scopesink from gnuradio import gr, gru, eng_notation, optfir from gnuradio import audio from gnuradio import usrp from gnuradio import blks from gnuradio.eng_option import eng_option from gnuradio.wxgui import slider, powermate from gnuradio.wxgui import stdgui, form, fftsink from optparse import OptionParser import usrp_dbid import sys import math import wx import wx.lib.evtmgr as em import scopesink_mod as scopesink def pick_subdevice(u): """ The user didn't specify a subdevice on the command line. Try for one of these, in order: TV_RX, BASIC_RX, whatever is on side A. @return a subdev_spec """ return usrp.pick_subdev(u, (usrp_dbid.TV_RX, usrp_dbid.TV_RX_REV_2, usrp_dbid.BASIC_RX)) plot1 = 1 plot2 = 1 plot3 = 1 class am_plasma_rx_graph (stdgui.gui_flow_graph): def __init__(self,frame,panel,vbox,argv): stdgui.gui_flow_graph.__init__ (self,frame,panel,vbox,argv) parser=OptionParser(option_class=eng_option) parser.add_option("-R", "--rx-subdev-spec", type="subdev", default=None, help="select USRP Rx side A or B (default=A)") parser.add_option("-f", "--freq", type="eng_float", default=3e6, help="set frequency to FREQ", metavar="FREQ") parser.add_option("-g", "--gain", type="int", default=10, help="set gain in dB (default is midpoint)") parser.add_option("-O", "--audio-output", type="string", default="", help="pcm device name. E.g., hw:0,0 or surround51 or /dev/dsp") (options, args) = parser.parse_args() if len(args) != 0: parser.print_help() sys.exit(1) self.frame = frame self.panel = panel self.vol = 0 self.state = "FREQ" self.freq = 0 # build graph self.u = usrp.source_c()# usrp is data source adc_rate = self.u.adc_rate()# 64 MS/s usrp_decim = 250 self.u.set_decim_rate(usrp_decim) usrp_rate = adc_rate / usrp_decim # 256 kS/s chanfilt_decim = 16 #chanfilt_decim = 512 demod_rate = usrp_rate / chanfilt_decim # 16 kHz audio_decimation = 1 audio_rate = demod_rate / audio_decimation # 16 kHz if options.rx_subdev_spec is None: options.r
Re: [Discuss-gnuradio] window sizing issue
Ok, I can accept that this device was not intended to be used as a calibrated measurement device, but maybe I can give it a shot. If I keep the decimation constant, and stabilize the temperature, what other considerations do I need to take into account (other than the obvious one, ie gain) for the basic am-demodulation routine I am using? Can I consider the FPGA as a "black box" and just calibrate the output vs the input at the physical connector? thanks, eric On Fri, 16 Mar 2007, Eric Blossom wrote: On Fri, Mar 16, 2007 at 05:30:44PM -0400, [EMAIL PROTECTED] wrote: Thanks- I'm using the DC-30 MHz basic RX board. So by recording the input signal, recording the value displayed on my "time series" window, and knowing the gain (0-20db if memory serves) I can calibrate the hardware so that I can back out the original voltage levels at the input? What impact does the signal processing have on the absolute magnitudes? If there is some magnitude attenuation caused by the FIR filters, is it frequency independent? thanks, eric Not to discourage you, but the USRP was designed as a software radio peripheral, not a precision calibrated measurement device. You will have to calibrate _everything_ in the path, and of course that includes the signal processing in the FPGA as well as anything in the host-based signal processing path. And yes, pretty much all of this varies depending on a large variety of settings. E.g., you'd want to calibrate for each possible FPGA decimation rate that you're interested in. Also, any calibration you make is going to be temperature dependent. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] window sizing issue
Thanks again! That worked great. As for who wrote the script, well, I adapted it (with much help from people on the discussion list) from a pre-existing wfm-based script, if I recall correctly. eric On Fri, 16 Mar 2007, Michael Dickens wrote: On Mar 16, 2007, at 12:01 PM, [EMAIL PROTECTED] wrote: 1) do you happen to know where the default values for the control buttons are set? I'd like to change the time scale from 100us/div to 1ms/div and to set the Autorange to "on" by default. In your "am_..." file, change the "scope_sink_f" call to inside "_build_gui", "if plot3:": self.scope = scopesink.scope_sink_f(self, self.panel, title="AM Demodulated Time Series", sample_rate=demod_rate, size=(50,100), t_scale=1.0e-3, v_scale=None) the last 2 items set the time scale and autorange as you want. 2) do you know how to convert the integer values on the third window (time-series) to actual voltage values as measured by the adc? It must be a function of the internal gain and offset. I need to know these eventually; this application is supposed to measure physical voltages, not just produce sounds. Not sure of this. Maybe whoever wrote the script knows? - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] window sizing issue
Thanks- I'm using the DC-30 MHz basic RX board. So by recording the input signal, recording the value displayed on my "time series" window, and knowing the gain (0-20db if memory serves) I can calibrate the hardware so that I can back out the original voltage levels at the input? What impact does the signal processing have on the absolute magnitudes? If there is some magnitude attenuation caused by the FIR filters, is it frequency independent? thanks, eric On Fri, 16 Mar 2007, Eric Blossom wrote: On Fri, Mar 16, 2007 at 12:43:01PM -0400, Michael Dickens wrote: 2) do you know how to convert the integer values on the third window (time-series) to actual voltage values as measured by the adc? It must be a function of the internal gain and offset. I need to know these eventually; this application is supposed to measure physical voltages, not just produce sounds. Not sure of this. Maybe whoever wrote the script knows? - MLD You would need to calibrate the complete signal path. Of course this is highly dependent on the particular daugtherboard in use as well as any gain setting in effect. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] window sizing issue
Michael- thanks very much for your help! Your changes have fixed the "control buttons covered" issue. I'll have to study what you did; I don't know any wxPython at all and as you've mentioned it's not easy to wade through existing documentation. Two other questions- 1) do you happen to know where the default values for the control buttons are set? I'd like to change the time scale from 100us/div to 1ms/div and to set the Autorange to "on" by default. 2) do you know how to convert the integer values on the third window (time-series) to actual voltage values as measured by the adc? It must be a function of the internal gain and offset. I need to know these eventually; this application is supposed to measure physical voltages, not just produce sounds. thanks again, eric Eric H. Matlis, Ph.D. Aerospace & Mechanical Engineering Dept. 120 Hessert Center for Aerospace Research University of Notre Dame Notre Dame, IN 46556-5684 Phone: (574) 631-6054 Fax: (574) 631-8355 On Thu, 15 Mar 2007, Michael Dickens wrote: On Mar 15, 2007, at 5:15 PM, [EMAIL PROTECTED] wrote: I've got an application with 3 plot windows and a control area in the bottom. Depending on the screen resolution, the control area on the bottom is "covered" by the lowest of the 3 plot windows. The applicatoin works fine at 1600x1200 but less well at 1440x900, and certainly at lower resolutions the control boxes are getting covered. What can I do so that even at lower resolutions I can see the entire application? I've tried adjusting the middle numeric field (vbox.add(self.scope.win, 4, wx.EXPAND)) in the vbox.add entry from 4 to 0, which helps for 1440x900 but this doesn't work for all resolutions and I don't know what this value represents anyway. Is there a recommendation for making my application resolution-independent? I've attached the python-code. Any advice is appreciated! I've been studying GUI design recently, and I can tell you that it's not simple learning WX or wxPython as documentation really isn't very good (IMHO). Does folks have particular references (online tutorial, book, PDF) that they really like? I could use some pointers ... I've seen those provided by the WX and wxPython projects, and Google'd various others, but none really do justice to all the methods and variables for even such "simple" things as a BoxSizer. I think this is correct: The "0" or "4" you're referring to is a "weight" of the particular added object. The "weight" is taking into account when the BoxSizer [0] determines how big an object should be; "0" weight (I think) means to not consider this object in the sizing but rather instead to just allocate its actual size (in pixels). Tweaking this value helps only so much, as objects can get only so small and screens only so large. Each object has a property, something like "minimum size"; some of these are straight forward to set while others seem to be less so if not impossible. In the case of the "fftsink" GUI, the default frame size is (X,Y) = (640, 240), as found in gr-wxgui/src/python/fftsink.py , and you can change this in the call to "fftsink.fft_sink_c" with "size=(50,50)" or whatever you want. Ditto for fftsink2.py. Then you'll want to change the "weight" in the "vbox.Add" call to 1 for each of these. That for "scopesink" is also (640, 240) [gr-wxgui/src/python/scopesink.py], except that this value doesn't actually get used for anything (oops, bug alert). The "scopesink" also has some extra GUI stuff below it that doesn't seem to be set to EXPAND; nor is "size" passed around to any of the classes that actually create the GUI objects. Thus some work needs to be done on the scopesink classes stuff in order to get "size" to work. Once the scopesink is corrected (as appended [1]), then you'll probably want (in your am_rcv_plasma.py) to vbox.Add them with a weight of 1, and everything else with a weight of 0. At least for me, this looks OK at down to around (X,Y) = (750,525) ... nothing special that small, but it does work. [0] The BoxSizer 'vbox' to which you refer is a means for placing objects into a GUI with minimal user defined parameters; this particular one is a "vertical box" only, which means that items are added from the top of a window towards the bottom, in rows. Each row can have a different number of columns, each of which is generally a BoxSizer in its own right (a "horizontal" one). [1] I've appended updated files, with corrections for these issues. Place them in the same directory before trying to execute your "am_.." script since it now depends on the fftsink_mod script being in that same directory. I'll think about what should really be done to scopesink to get it working properly, since this is just a quick fix for an obvious problem but it's not "ideal" I don't believe. ___ Discuss-gnuradio mailing list
[Discuss-gnuradio] window sizing issue
Hi- I've got an application with 3 plot windows and a control area in the bottom. Depending on the screen resolution, the control area on the bottom is "covered" by the lowest of the 3 plot windows. The applicatoin works fine at 1600x1200 but less well at 1440x900, and certainly at lower resolutions the control boxes are getting covered. What can I do so that even at lower resolutions I can see the entire application? I've tried adjusting the middle numeric field (vbox.add(self.scope.win, 4, wx.EXPAND)) in the vbox.add entry from 4 to 0, which helps for 1440x900 but this doesn't work for all resolutions and I don't know what this value represents anyway. Is there a recommendation for making my application resolution-independent? I've attached the python-code. Any advice is appreciated! thanks, eric Eric H. Matlis, Ph.D. Aerospace & Mechanical Engineering Dept. 120 Hessert Center for Aerospace Research University of Notre Dame Notre Dame, IN 46556-5684 Phone: (574) 631-6054 Fax: (574) 631-8355#!/usr/bin/env python from gnuradio import gr, gru, eng_notation, optfir from gnuradio import audio from gnuradio import usrp from gnuradio import blks from gnuradio.eng_option import eng_option from gnuradio.wxgui import slider, powermate from gnuradio.wxgui import stdgui, fftsink, form, scopesink from optparse import OptionParser import usrp_dbid import sys import math import wx import wx.lib.evtmgr as em def pick_subdevice(u): """ The user didn't specify a subdevice on the command line. Try for one of these, in order: TV_RX, BASIC_RX, whatever is on side A. @return a subdev_spec """ return usrp.pick_subdev(u, (usrp_dbid.TV_RX, usrp_dbid.TV_RX_REV_2, usrp_dbid.BASIC_RX)) plot1 = 1 plot2 = 1 plot3 = 1 class am_plasma_rx_graph (stdgui.gui_flow_graph): def __init__(self,frame,panel,vbox,argv): stdgui.gui_flow_graph.__init__ (self,frame,panel,vbox,argv) parser=OptionParser(option_class=eng_option) parser.add_option("-R", "--rx-subdev-spec", type="subdev", default=None, help="select USRP Rx side A or B (default=A)") parser.add_option("-f", "--freq", type="eng_float", default=3e6, help="set frequency to FREQ", metavar="FREQ") parser.add_option("-g", "--gain", type="int", default=10, help="set gain in dB (default is midpoint)") parser.add_option("-O", "--audio-output", type="string", default="", help="pcm device name. E.g., hw:0,0 or surround51 or /dev/dsp") (options, args) = parser.parse_args() if len(args) != 0: parser.print_help() sys.exit(1) self.frame = frame self.panel = panel self.vol = 0 self.state = "FREQ" self.freq = 0 # build graph self.u = usrp.source_c()# usrp is data source adc_rate = self.u.adc_rate()# 64 MS/s usrp_decim = 250 self.u.set_decim_rate(usrp_decim) usrp_rate = adc_rate / usrp_decim # 256 kS/s chanfilt_decim = 16 #chanfilt_decim = 512 demod_rate = usrp_rate / chanfilt_decim # 16 kHz audio_decimation = 1 audio_rate = demod_rate / audio_decimation # 16 kHz if options.rx_subdev_spec is None: options.rx_subdev_spec = pick_subdevice(self.u) # Select USRP channel (0) self.u.set_mux(usrp.determine_rx_mux_value(self.u, options.rx_subdev_spec)) # Tune to the desired IF frequency self.subdev = usrp.selected_subdev(self.u, options.rx_subdev_spec) # Channelize the signal of interest. chan_filt_coeffs = gr.firdes.low_pass (1, # gain usrp_rate, # sampling rate #1000, 6000,# passband cutoff 500, # stopband cutoff gr.firdes.WIN_HANN) self.lpfilter = gr.fir_filter_ccf (chanfilt_decim,chan_filt_coeffs) # Demodulate with classic sqrt (I*I + Q*Q) self.magblock = gr.complex_to_mag() self.volume_control = gr.multiply_const_ff(self.vol) # Deemphasis. Is this necessary on AM? #TAU = 75e-6 # 75us in US, 50us in EUR #fftaps = [ 1 - math.exp(-1/TAU/usrp_rate), 0] #fbtaps= [ 0 , math.exp(-1/TAU/usrp_rate) ] #self.deemph = gr.iir_filter_ffd(fftaps,fbtaps) # sound card as final sink audio_sink = audio.sink (int (audio_rate), options.audio_output, False) # ok_to_block # now wire