[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
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 mle...@ripnet.com 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] 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 oz9...@gmail.com wrote: From: Alexandru Csete oz9...@gmail.com 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, emat...@yahoo.com 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 j...@joshknows.com wrote: From: Josh Blum j...@joshknows.com 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 Wed, 1/19/11, emat...@yahoo.com emat...@yahoo.com wrote: From: emat...@yahoo.com 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
Re: [Discuss-gnuradio] filename using time-stamp in GRC
--- On Thu, 1/20/11, Alexandru Csete oz9...@gmail.com wrote: From: Alexandru Csete oz9...@gmail.com 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, emat...@yahoo.com 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
[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
Martin, thanks for responding. See my follow ups below: --- On Thu, 1/13/11, Marcus D. Leech mle...@ripnet.com wrote: From: Marcus D. Leech mle...@ripnet.com 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
Re: [Discuss-gnuradio] grc amplitude demodulation questions
--- On Fri, 1/14/11, Josh Blum j...@joshknows.com wrote: From: Josh Blum j...@joshknows.com 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
[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 tt...@vt.edu wrote: From: Thomas Tsou tt...@vt.edu 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, emat...@yahoo.com 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
Re: [Discuss-gnuradio] USRP with Basic_RX
From: Marcus D. Leech mle...@ripnet.com Subject: Re: [Discuss-gnuradio] USRP with Basic_RX To: Johnathan Corgan jcor...@corganenterprises.com, 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 cstdio 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]
[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 cstdio 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
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 cstdio 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
[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
[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_list = [
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, emat...@nd.edu 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)
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)
# 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
[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] usrp2 tune two different frequencies
On Mon, 20 Apr 2009, Johnathan Corgan wrote: On Mon, Apr 20, 2009 at 7:44 AM, Johnathan Corgan jcor...@corganenterprises.com 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:59 AM, emat...@nd.edu 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, Matt Ettus wrote: emat...@nd.edu wrote: On Mon, 20 Apr 2009, Johnathan Corgan wrote: On Mon, Apr 20, 2009 at 7:59 AM, emat...@nd.edu 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] 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] 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] 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] 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] 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
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
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 module 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
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 module 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 module 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 has been some
[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
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] 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] 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
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
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
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
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
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
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
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
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
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
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
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
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
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] 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
[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
[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] 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] 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] 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
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
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
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] 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
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
Re: [Discuss-gnuradio] offset at input of LF_RX
On Thu, 21 Jun 2007, Don Ward wrote: - Original Message - From: [EMAIL PROTECTED] To: discuss-gnuradio@gnu.org 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: 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, 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
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
[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
[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
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
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
[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] 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
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] 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.rx_subdev_spec = pick_subdevice(self.u) # Select USRP
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- 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@gnu.org
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
