Re: [Discuss-gnuradio] Introducing noise/ considerable BER
On Sun, Aug 07, 2011 at 02:47:10PM -0400, Daniel Zeleznikar wrote:
As Marcus pointed out, there will always be packet loss associated with
higher BER in real systems that employ packet switching. The only thing I
could suggest is that you somehow move further upstream in your receive
system to make the BER measurement happen at the bit/symbol level if you
really want it to be accurate. Otherwise you can just collect data for both
packet loss rate, and the BER of obtained packets, since that is the best
thing you have to work with. The packet loss statistic may be important
anyhow.
Suggestions from anyone for moving the BER measurement closer to symbol
level?
It's not quite clear what exactly you're trying to do. Here's some more
suggestions:
- Don't use benchmark_{tx,rx} scripts, but write something that doesn't
do CRC checks on packets. However, you still have to synchronize,
that'll eventually conk out at very low SNR.
- Don't use USRP's at all. If you're running simulations (e.g. to test a
channel coding scheme), do it all in GRC. You can either use the
channel model that comes with GNU Radio to increase SNR, or, of you
want to stick to bits, try the Channel Coding Toolbox from
https://www.cgran.org/wiki/chancoding which includes some elaborate
bit error models.
MB
On Sat, Aug 6, 2011 at 6:54 PM, Marcus D. Leech mle...@ripnet.com wrote:
**
On 08/06/2011 06:27 PM, shantharam balasubramanian wrote:
Hi
I have been working in usrp2 testbed, and I have been modifying the
benchmark_tx and rx programs for my project. There have been situations
where I was supposed to introduce noise to find out BER. I did that by
giving lower transmitter amplitude values. But very low values cause packet
loss along with higher BER values. I just want to know if there Is there
anyway to just cause high BER values, without causing packet loss? Is there
any way I can do that inside the program or should I do it by any other way
e.g.by using some noise producing source?
Well, in real-world radio communications systems, low-SNR *does* cause
packet loss. That's entirely expected. Nature doesn't discriminate
between packet-synchronization data, and the actual payload data.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
Dan Zeleznikar
daniel.zelezni...@gmail.com
zeleznika...@osu.edu
(216) 233-6232
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
Dipl.-Ing. Martin Braun
Research Associate
Kaiserstraße 12
Building 05.01
76131 Karlsruhe
Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu
KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association
pgphtG0ufcvDs.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Bug with USRP2/SBX and UHD when launching the acquisition
2011/8/5 Marcus D. Leech mle...@ripnet.com: On 05/08/2011 10:33 AM, Emmanuel Caillé wrote: Hello all, I have a problem with my USRP2 (with a SBX board) : Most of times when I launch the acquisition, no data are received. For example with uhd_fft.py : $ uhd_fft.py linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.002.001-fc349d3 -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes and the FFT Plotter appear but is empty. Also, what do you get with uhd_usrp_probe --args addr=192.168.10.2 (or whatever you've set the IP addr of the USRP2 to). There are no samples (autoscale don't do anything) and there are no timeout errors. I perfectly ping the device (with 0% packet loss). I don't understand why sometimes it works and at other times it doesn't (without changing any option). $ uhd_usrp_probe linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.002.001-fc349d3 -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes _ / | Device: USRP2 / N-Series Device | _ |/ | | Mboard: USRP2-REV4 | | rev: 1024 | | mac-addr: 00:50:c2:85:3a:a4 | | ip-addr: 10.66.160.164 | | gpsdo: none | | serial: 2724 | | | | Time sources: none, external, _external_, mimo | | Clock sources: internal, external, mimo | | Sensors: mimo_locked, ref_locked | | _ | |/ | | | RX DSP: 0 | | | Freq range: -50.000 to 50.000 Mhz | | _ | |/ | | | RX DSP: 1 | | | Freq range: -50.000 to 50.000 Mhz | | _ | |/ | | | RX Dboard: A | | | ID: SBX (0x0054) | | | Serial: E7R10Y0XS | | | _ | | |/ | | | | RX Subdev: 0 | | | | Name: SBX (0x0054) | | | | Antennas: TX/RX, RX2 | | | | Sensors: lo_locked | | | | Freq range: 68.750 to 4400.000 Mhz | | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB | | | | Connection Type: IQ | | | | Uses LO offset: No | | | _ | | |/ | | | | RX Codec: A | | | | Name: ltc2284 | | | | Gain Elements: None | | _ | |/ | | | TX DSP: 0 | | | Freq range: -250.000 to 250.000 Mhz | | _ | |/ | | | TX Dboard: A | | | ID: SBX (0x0055) | | | Serial: E7R10Y0XS | | | _ | | |/ | | | | TX Subdev: 0 | | | | Name: SBX (0x0055) | | | | Antennas: TX/RX | | | | Sensors: lo_locked | | | | Freq range: 68.750 to 4400.000 Mhz | | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB | | | | Connection Type: QI | | | | Uses LO offset: No | | | _ | | |/ | | | | TX Codec: A | | | | Name: ad9777 | | | | Gain Elements: None (I had the same problem when I used the 192.168.10.2 IP) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Bug with USRP2/SBX and UHD when launching the acquisition
2011/8/8 Emmanuel Caillé emmanuel.cai...@telecom-bretagne.eu: 2011/8/5 Marcus D. Leech mle...@ripnet.com: On 05/08/2011 10:33 AM, Emmanuel Caillé wrote: Hello all, I have a problem with my USRP2 (with a SBX board) : Most of times when I launch the acquisition, no data are received. For example with uhd_fft.py : $ uhd_fft.py linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.002.001-fc349d3 -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes and the FFT Plotter appear but is empty. Also, what do you get with uhd_usrp_probe --args addr=192.168.10.2 (or whatever you've set the IP addr of the USRP2 to). There are no samples (autoscale don't do anything) and there are no timeout errors. I perfectly ping the device (with 0% packet loss). I don't understand why sometimes it works and at other times it doesn't (without changing any option). $ uhd_usrp_probe linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.002.001-fc349d3 -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes _ / | Device: USRP2 / N-Series Device | _ | / | | Mboard: USRP2-REV4 | | rev: 1024 | | mac-addr: 00:50:c2:85:3a:a4 | | ip-addr: 10.66.160.164 | | gpsdo: none | | serial: 2724 | | | | Time sources: none, external, _external_, mimo | | Clock sources: internal, external, mimo | | Sensors: mimo_locked, ref_locked | | _ | | / | | | RX DSP: 0 | | | Freq range: -50.000 to 50.000 Mhz | | _ | | / | | | RX DSP: 1 | | | Freq range: -50.000 to 50.000 Mhz | | _ | | / | | | RX Dboard: A | | | ID: SBX (0x0054) | | | Serial: E7R10Y0XS | | | _ | | | / | | | | RX Subdev: 0 | | | | Name: SBX (0x0054) | | | | Antennas: TX/RX, RX2 | | | | Sensors: lo_locked | | | | Freq range: 68.750 to 4400.000 Mhz | | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB | | | | Connection Type: IQ | | | | Uses LO offset: No | | | _ | | | / | | | | RX Codec: A | | | | Name: ltc2284 | | | | Gain Elements: None | | _ | | / | | | TX DSP: 0 | | | Freq range: -250.000 to 250.000 Mhz | | _ | | / | | | TX Dboard: A | | | ID: SBX (0x0055) | | | Serial: E7R10Y0XS | | | _ | | | / | | | | TX Subdev: 0 | | | | Name: SBX (0x0055) | | | | Antennas: TX/RX | | | | Sensors: lo_locked | | | | Freq range: 68.750 to 4400.000 Mhz | | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB | | | | Connection Type: QI | | | | Uses LO offset: No | | | _ | | | / | | | | TX Codec: A | | | | Name: ad9777 | | | | Gain Elements: None (I had the same problem when I used the 192.168.10.2 IP) I fixed my problem : I replaced my Gigabit Switch with a crossed cable and know everything work fine. Thanks for your advices. -- Emmanuel ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] coerce endpoint - hier block API question with code
On Sat, Aug 06, 2011 at 10:08:19PM +0200, Marius wrote: Hi! I'm creating an integration for the current GNU Radio = 3.4 tree upwards for a 3d FFT display block. I put the code I got there, and added some changes: https://github.com/wishi/gr_3d_fft My probem is: Traceback (most recent call last): File usrp_gl_fft.py, line 81, in module main () File usrp_gl_fft.py, line 77, in main app = stdgui2.stdapp(app_flow_graph, 3d) [not interesting] File /usr/local/lib/python2.6/dist-packages/gnuradio/gr/top_block.py, line 128, in _connect (dst_block, dst_port) = self._coerce_endpoint(dst) File /usr/local/lib/python2.6/dist-packages/gnuradio/gr/top_block.py, line 139, in _coerce_endpoint raise ValueError(unable to coerce endpoint) ValueError: unable to coerce endpoint I know this is related to the hierarchical block API, but I don't know what I have to change. Could someone help me - at least a little? I think there's too much to do left, however I don't find a way to treat this error. If that works I'll do GRC integration and clean up the OpenGL stuff (the code is from the source mentioned in the repository, but GPL). I'm missing this kind of 3d perspective so I tried to create this graphical sink based on the mentioned code. Hi Marius, this usually means something like there's an 'open' connection (it's like leaving that one pin of your µC dangling when it should be grounded :). A quick look at the code suggests your error is in the fft_sink_c class (possibly others). In fact, you've thoroughly misunderstood what a hier_block does. A hier_block works just like any other block (from the outside). You should have a look at some of the examples in gnuradio-core/src/lib/python/gnuradio. Two things immediately stand out: - You're not calling the hier_block constructor. - You pass 'fg' to the block, but it *is* part of the flow graph. - Since this is a sink, you must have something like self.connect(self, ...) As I said, have a look at the examples. Your code can't work in this state. Good luck, MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpUGZLgxzDUG.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] LTE LTE-Advanced using GNU Radio
At least L1, we spent a lot of time on checking the code's compliance with spec. I heard the RRC part is not completed. Lin 2011/8/4 Alexander Chemeris alexander.cheme...@gmail.com Hi Lin, On Wed, Aug 3, 2011 at 06:31, Lin HUANG huanglin.b...@gmail.com wrote: This link is for download. https://twiki.eurecom.fr/twiki/bin/view/OpenAirInterface/GetSources But the username seems not usable. You have to contact the server administrator to get an account. Yes, their approach to open-source is somewhat weird. I downloaded the code. It has most of LTE funcitons, only few bugs and mistakes which are not fully compatible with the LTE specification. Our comment is: this is a very good reference. Do you refer to L1 or L2 or L3 or all of them? -- Regards, Alexander Chemeris. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] LTE LTE-Advanced using GNU Radio
Try this: http://www.openairinterface.org/overview/page1011.en.htm Lin 2011/8/4 Thomas Tsou tt...@vt.edu On Tue, Aug 2, 2011 at 7:31 PM, Lin HUANG huanglin.b...@gmail.com wrote: This link is for download. https://twiki.eurecom.fr/twiki/bin/view/OpenAirInterface/GetSources But the username seems not usable. You have to contact the server administrator to get an account. I couldn't find any contact information for the administrator or anything on getting access. Do you know where I can find that information? Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Introducing noise/ considerable BER
Hello people, Thanks a lot for the reply. So, you are saying that the packet loss at low transmitter amplitude in benchmark_Tx.py and benchmark_Rx.py come from the loss of packet synchronization data, i.e., a part of the packet synchronization data gets lost or degraded due to low SNR. I know that packet loss also occurs if the queue length is not long enough to hold incoming traffic or if the data reaches the receiver after a long time. I want to ensure that these things don't happen. Basically, we are trying to transmit a random binary sequence between two nodes using the benchmark_Tx.py and benchmark_Rx.py programs. Since both these programs use packets, we convert the whole binary sequence into a number of packets and then transmit each packet using the benchmark programs. Let us say, we have 2000 bits in total. We convert it to 20 packets (100 bits/packet) and then transmit 20 packets from one node to the other. We want to calculate the bit error rate for different levels of transmitter amplitude. Based on our objectives, I have the following questions. 1. Is there any upper limit on the no. of binary bits per packet in benchmark_Tx.py program? 2. Overall can I take other steps to get rid of the packet loss scenario ? Adam, can you please describe the generation of long preamble in further details ? Your help and feedback will be highly appreciated. Thanks, shantharam ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] raw input data for those without hardware
On 08/06/2011 05:21 PM, Ben Reynwar wrote: I don't have any hardware and am looking for some raw input data to play with. It doesn't really matter what. Where are good places to find this? I faintly remember people asking this question here before, but haven't come up with the right search terms to bring up those emails. I'm jumping in a couple days late here, but a resource that seems to be disappearing is KD7LMO's over the air captures. His old website[1] is down, and the ANSR mirror[2] has disappeared as well. You can see a listing of what was available on archive.org[3], but I can't pull down the actual captures right now. Maybe somebody else has grabbed the collection at some point and can drop it off somewhere to be re-hosted? [1] http://www.kd7lmo.net [2] http://www.ansr.org/kd7lmo/www.kd7lmo.net/ [3] http://web.archive.org/web/20090418034309/http://www.kd7lmo.net/ground_gnuradio_ota.html -pat ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] uhd digital-bert script !
Hello everyone I am working on USRPN200 with RFX2400. I am trying to make digital-bert scripts to work for uhd devices. I have modified them a bit but i am getting some errors which am unable to debug. If anyone can help me out. Attached are my benchmark_tx and transmit_path scripts. while running the script, it shows me : aravind@COE-CW85V91:~/gnuradio/gnuradio-examples/python/digital-bert$ ./uhd_benchmark_tx.py -f 2500M -g 16 linux; GNU C++ version 4.4.5; Boost_104200; UHD_003.001.002-5239879 gr_fir_ccf: using SSE Modulation: 250k bits/sec TX IF rate: 500k samples/sec USRP interpolation: 256 DAC amplitude: 2000 -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes -- mboard0 is MIMO master UHD Warning: Unable to set the thread priority. Performance may be negatively affected. Please see the general application notes in the manual for instructions. EnvironmentError: OSError: error in pthread_setschedparam Gain d'board: 16 dB Actual center frequency 2.5G Traceback (most recent call last): File ./uhd_benchmark_tx.py, line 109, in module tb = tx_bpsk_block(options) File ./uhd_benchmark_tx.py, line 56, in __init__ self.connect(self._transmitter, self._usrp) File /usr/local/lib/python2.6/dist-packages/gnuradio/gr/top_block.py, line 124, in connect self._connect(points[i-1], points[i]) File /usr/local/lib/python2.6/dist-packages/gnuradio/gr/top_block.py, line 130, in _connect dst_block.to_basic_block(), dst_port) File /usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_core_runtime.py, line 1504, in primitive_connect return _gnuradio_core_runtime.gr_top_block_sptr_primitive_connect(self, *args) ValueError: port number 0 exceeds max of (none) -- Saketh Kumar #!/usr/bin/env python # # Copyright 2008 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, eng_notation, uhd from gnuradio.eng_option import eng_option from optparse import OptionParser from transmit_path import transmit_path import sys _dac_rate = 128e6 n2s = eng_notation.num_to_str class tx_bpsk_block(gr.top_block): def __init__(self,options): gr.top_block.__init__(self) self._transmitter = transmit_path(options.sps, options.excess_bw, options.amplitude) if_rate = options.rate*options.sps interp = int(_dac_rate/if_rate) print Modulation:, n2s(options.rate), bits/sec print TX IF rate:, n2s(if_rate), samples/sec print USRP interpolation:, interp print DAC amplitude:, options.amplitude self._setup_usrp(options.ip, interp, options.gain, options.tx_freq) self.connect(self._transmitter, self._usrp) def _setup_usrp(self,ip,interp, gain, tx_freq): self._usrp = uhd.usrp_source(device_addr=, io_type=uhd.io_type.COMPLEX_FLOAT32, num_channels=1, ) #set Tx Gain self._usrp.set_gain(gain,0) print Gain d'board:,(n2s(gain)),dB #Tune to center frequency tr = self._usrp.set_center_freq(options.tx_freq, 0) if not (tr): print Failed to tune to Tx frequency to %s % (n2s(options.tx_freq)) else: print Actual center frequency,n2s(options.tx_freq) def get_options(): parser = OptionParser(option_class=eng_option) parser.add_option(--ip, --device_addr,type=string,default=addr=192.168.10.2, help=device address[default=%default]) parser.add_option(-g, --gain, type=eng_float, default=None, help=set TX gain (default is midpoint)) parser.add_option(-f, --tx-freq, type=eng_float, default=None, help=set Tx frequency to FREQ, metavar=FREQ) parser.add_option(-a, --amplitude, type=eng_float, default=2000, help=set Tx amplitude (0-32767) (default=%default)) parser.add_option(-r, --rate, type=eng_float, default=250e3,
[Discuss-gnuradio] Periodic averaging
Hi everyone, I'm new to gnuradio and I was wondering if someone could point me in the right direction. I'm using a usrp to read signals in the frequency domain. I've been able to do this successfully using uhd_fft.py which uses fft_sink_c() to display the signal. What I want to do instead of displaying the signal continuously is to display the average of the power spectrum of the signal every minute using all the samples collected in one minute. I can't find a block that simply takes the (boxcar) average of many spectra once every minute. If I can't find a block to do this, I will attempt to write one myself. If I need to, is there a strong need to write this block in C++ or could I write it in python? Thanks in advance for your help, Prachi ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Periodic averaging
On 08/08/2011 12:31 PM, Prachi Parihar wrote: Hi everyone, I'm new to gnuradio and I was wondering if someone could point me in the right direction. I'm using a usrp to read signals in the frequency domain. I've been able to do this successfully using uhd_fft.py which uses fft_sink_c() to display the signal. What I want to do instead of displaying the signal continuously is to display the average of the power spectrum of the signal every minute using all the samples collected in one minute. I can't find a block that simply takes the (boxcar) average of many spectra once every minute. If I can't find a block to do this, I will attempt to write one myself. If I need to, is there a strong need to write this block in C++ or could I write it in python? Thanks in advance for your help, Prachi ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio There's a logPowerFFT hier block in GRC that allows you to set the frame rate and alpha value, and it produces a FLOAT vector that's the length of the FFT. You can then further IIR filter those vectors, and then do a keep one in N to make them dump to a file once per minute. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] uhd digital-bert script !
On Mon, 2011-08-08 at 12:16 -0400, saketh kumar wrote: Hello everyone I am working on USRPN200 with RFX2400. I am trying to make digital-bert scripts to work for uhd devices. I have modified them a bit but i am getting some errors which am unable to debug. If anyone can help me out. Attached are my benchmark_tx and transmit_path scripts. while running the script, it shows me : aravind@COE-CW85V91:~/gnuradio/gnuradio-examples/python/digital-bert $ ./uhd_benchmark_tx.py -f 2500M -g 16 linux; GNU C++ version 4.4.5; Boost_104200; UHD_003.001.002-5239879 gr_fir_ccf: using SSE Modulation: 250k bits/sec TX IF rate: 500k samples/sec USRP interpolation: 256 DAC amplitude: 2000 -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes -- mboard0 is MIMO master UHD Warning: Unable to set the thread priority. Performance may be negatively affected. Please see the general application notes in the manual for instructions. EnvironmentError: OSError: error in pthread_setschedparam Gain d'board: 16 dB Actual center frequency 2.5G Traceback (most recent call last): File ./uhd_benchmark_tx.py, line 109, in module tb = tx_bpsk_block(options) File ./uhd_benchmark_tx.py, line 56, in __init__ self.connect(self._transmitter, self._usrp) File /usr/local/lib/python2.6/dist-packages/gnuradio/gr/top_block.py, line 124, in connect self._connect(points[i-1], points[i]) File /usr/local/lib/python2.6/dist-packages/gnuradio/gr/top_block.py, line 130, in _connect dst_block.to_basic_block(), dst_port) File /usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_core_runtime.py, line 1504, in primitive_connect return _gnuradio_core_runtime.gr_top_block_sptr_primitive_connect(self, *args) ValueError: port number 0 exceeds max of (none) You're connecting a signal source to a USRP source. The source block is the receiver block; it produces samples. The sink block is the transmitter block; it consumes samples. --n -- Saketh Kumar ___ 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] Data Capture Tool
Hi Everyone, I amwondering if there is a data capture tool for the USRP, specifically the N200. I am looking for something where I could specify a center frequency and bandwidth and it would continuously collect the RF and log the timestamps, underflow/overflow, and f_c that I actually got from the device. Does such software exist? Would the labview interface support this? Thanks in advance, Isaac ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] uhd digital-bert script !
I have made that change. After doing that when i run my script it pops up the error aravind@COE-2X85V91:~/gnuradio/gnuradio-examples/python/digital-bert$ ./uhd_benchmark_tx.py -f 2500M -g 32 linux; GNU C++ version 4.4.5; Boost_104200; UHD_003.001.002-ba0e3c8 gr_fir_ccf: using SSE Modulation: 500k bits/sec TX IF rate: 1M samples/sec USRP interpolation: 128 DAC amplitude: 500 -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes UHD Warning: The recv buffer could not be resized sufficiently. Target sock buff size: 5000 bytes. Actual sock buff size: 131071 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.rmem_max=5000 UHD Warning: The recv buffer could not be resized sufficiently. Target sock buff size: 5000 bytes. Actual sock buff size: 131071 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.rmem_max=5000 -- mboard0 is MIMO master UHD Warning: Unable to set the thread priority. Performance may be negatively affected. Please see the general application notes in the manual for instructions. EnvironmentError: OSError: error in pthread_setschedparam Center frequency: 2.5G Gain d'board:32 Uterminate called after throwing an instance of 'boost::exception_detail::clone_implboost::exception_detail::error_info_injectorboost::math::rounding_error ' what(): Error in function boost::math::roundd(d): Value inf can not be represented in the target integer type. Aborted what does actually the error means? what else changes should i be doing in the transmit_path.py script ? Regards Saketh On Mon, Aug 8, 2011 at 12:16 PM, saketh kumar m.sakethku...@gmail.comwrote: Hello everyone I am working on USRPN200 with RFX2400. I am trying to make digital-bert scripts to work for uhd devices. I have modified them a bit but i am getting some errors which am unable to debug. If anyone can help me out. Attached are my benchmark_tx and transmit_path scripts. while running the script, it shows me : aravind@COE-CW85V91:~/gnuradio/gnuradio-examples/python/digital-bert$ ./uhd_benchmark_tx.py -f 2500M -g 16 linux; GNU C++ version 4.4.5; Boost_104200; UHD_003.001.002-5239879 gr_fir_ccf: using SSE Modulation: 250k bits/sec TX IF rate: 500k samples/sec USRP interpolation: 256 DAC amplitude: 2000 -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes -- mboard0 is MIMO master UHD Warning: Unable to set the thread priority. Performance may be negatively affected. Please see the general application notes in the manual for instructions. EnvironmentError: OSError: error in pthread_setschedparam Gain d'board: 16 dB Actual center frequency 2.5G Traceback (most recent call last): File ./uhd_benchmark_tx.py, line 109, in module tb = tx_bpsk_block(options) File ./uhd_benchmark_tx.py, line 56, in __init__ self.connect(self._transmitter, self._usrp) File /usr/local/lib/python2.6/dist-packages/gnuradio/gr/top_block.py, line 124, in connect self._connect(points[i-1], points[i]) File /usr/local/lib/python2.6/dist-packages/gnuradio/gr/top_block.py, line 130, in _connect dst_block.to_basic_block(), dst_port) File /usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_core_runtime.py, line 1504, in primitive_connect return _gnuradio_core_runtime.gr_top_block_sptr_primitive_connect(self, *args) ValueError: port number 0 exceeds max of (none) -- Saketh Kumar -- Saketh Kumar ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] uhd digital-bert script !
On 08/08/2011 2:04 PM, saketh kumar wrote: I have made that change. After doing that when i run my script it pops up the error aravind@COE-2X85V91:~/gnuradio/gnuradio-examples/python/digital-bert$ ./uhd_benchmark_tx.py -f 2500M -g 32 linux; GNU C++ version 4.4.5; Boost_104200; UHD_003.001.002-ba0e3c8 gr_fir_ccf: using SSE Modulation: 500k bits/sec TX IF rate: 1M samples/sec USRP interpolation: 128 DAC amplitude: 500 -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes UHD Warning: The recv buffer could not be resized sufficiently. Target sock buff size: 5000 bytes. Actual sock buff size: 131071 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.rmem_max=5000 UHD Warning: The recv buffer could not be resized sufficiently. Target sock buff size: 5000 bytes. Actual sock buff size: 131071 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.rmem_max=5000 -- mboard0 is MIMO master UHD Warning: Unable to set the thread priority. Performance may be negatively affected. Please see the general application notes in the manual for instructions. EnvironmentError: OSError: error in pthread_setschedparam Center frequency: 2.5G Gain d'board:32 Uterminate called after throwing an instance of 'boost::exception_detail::clone_implboost::exception_detail::error_info_injectorboost::math::rounding_error ' what(): Error in function boost::math::roundd(d): Value inf can not be represented in the target integer type. Aborted Some part of the block chain setup by transmit_path.py is producing floating-point values that cannot be easily scaled into the range required by the (I'm assuming) UHD sink block. The value inf is usually due to a divide-by-zero error somewhere in the chain. what does actually the error means? what else changes should i be doing in the transmit_path.py script ? Regards Saketh On Mon, Aug 8, 2011 at 12:16 PM, saketh kumar m.sakethku...@gmail.com mailto:m.sakethku...@gmail.com wrote: Hello everyone I am working on USRPN200 with RFX2400. I am trying to make digital-bert scripts to work for uhd devices. I have modified them a bit but i am getting some errors which am unable to debug. If anyone can help me out. Attached are my benchmark_tx and transmit_path scripts. while running the script, it shows me : aravind@COE-CW85V91:~/gnuradio/gnuradio-examples/python/digital-bert$ ./uhd_benchmark_tx.py -f 2500M -g 16 linux; GNU C++ version 4.4.5; Boost_104200; UHD_003.001.002-5239879 gr_fir_ccf: using SSE Modulation: 250k bits/sec TX IF rate: 500k samples/sec USRP interpolation: 256 DAC amplitude: 2000 -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes -- mboard0 is MIMO master UHD Warning: Unable to set the thread priority. Performance may be negatively affected. Please see the general application notes in the manual for instructions. EnvironmentError: OSError: error in pthread_setschedparam Gain d'board: 16 dB Actual center frequency 2.5G Traceback (most recent call last): File ./uhd_benchmark_tx.py, line 109, in module tb = tx_bpsk_block(options) File ./uhd_benchmark_tx.py, line 56, in __init__ self.connect(self._transmitter, self._usrp) File /usr/local/lib/python2.6/dist-packages/gnuradio/gr/top_block.py, line 124, in connect self._connect(points[i-1], points[i]) File /usr/local/lib/python2.6/dist-packages/gnuradio/gr/top_block.py, line 130, in _connect dst_block.to_basic_block(), dst_port) File /usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_core_runtime.py, line 1504, in primitive_connect return _gnuradio_core_runtime.gr_top_block_sptr_primitive_connect(self, *args) ValueError: port number 0 exceeds max of (none) -- Saketh Kumar -- Saketh Kumar ___ 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] Creating a new GNU Block
Hello All, I am trying to make a new block for GNU Radio, which uses MATLAB (MCR). When I get to the 'sudo make check' stage, it gives me the following error: /usr/bin/isn/lib/.libs/lt-test_all: error while loading shared libraries: libmwmclmcr.so: cannot open shared object file: No such file or directory libmwmclmcr.so is located in /usr/local/matlab/r2010b/bin/glnxa64, and I _have_ included this in the Makefile.am as follows: MATLAB_ROOT = /usr/local/matlab/r2010b MY_LIB_ROOT=$(HOME)/homedir/gnuradio/Blocks/MI LD_LIBRARY_PATH=$(MATLAB_ROOT)/bin/glnxa64:/usr/lib64:$(MATLAB_ROOT)/runtime/glnxa64:$(MATLAB_ROOT)/bin/glnxa64:$(MATLAB_ROOT)/sys/os/glnxa64:$(MATLAB_ROOT)/sys/java/jre/glnxa64/jre/libamd64/native_threads:$(MATLAB_ROOT)/sys/java/jre/glnxa64/jre/lib/amd64/server:$(MATLAB_ROOT)/sys/java/jre/glnxa64/jre/lib/amd64:$(MY_LIB_ROOT) It is also in my ~/.bashrc file. I can get past this error by copying the libmwmclmcr.so to the folder /usr/lib64/, and then I can get through the entire 'boostrap/configure/make/install' procedure successfully without any errors, but then the actual block does nothing! Could anyone help me out with this please? I have tried everything I could possibly think of.. Thanks, OGLES ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Periodic averaging
Thanks for your response Marcus. I have been working with this block, but unfortunately, I do not want to iir filter the power spectrum. I want each spectrum to be weighed equally. I'd like to compute the arithmetic mean for all the power spectra within a minute (I believe there are 4000 per second) so that means I want to average 240,000 spectra and return a single power spectrum (which is the average) to be displayed. As for the keep one in N file dump, I considered that when I came across moving_average_ff but that calculates the average every time it receives a new spectrum which is very wasteful in my case, since it's computing the average 240,000 times more than I need to. On Mon, Aug 8, 2011 at 12:45 PM, Marcus D. Leech mle...@ripnet.com wrote: On 08/08/2011 12:31 PM, Prachi Parihar wrote: Hi everyone, I'm new to gnuradio and I was wondering if someone could point me in the right direction. I'm using a usrp to read signals in the frequency domain. I've been able to do this successfully using uhd_fft.py which uses fft_sink_c() to display the signal. What I want to do instead of displaying the signal continuously is to display the average of the power spectrum of the signal every minute using all the samples collected in one minute. I can't find a block that simply takes the (boxcar) average of many spectra once every minute. If I can't find a block to do this, I will attempt to write one myself. If I need to, is there a strong need to write this block in C++ or could I write it in python? Thanks in advance for your help, Prachi ___ Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio There's a logPowerFFT hier block in GRC that allows you to set the frame rate and alpha value, and it produces a FLOAT vector that's the length of the FFT. You can then further IIR filter those vectors, and then do a keep one in N to make them dump to a file once per minute. ___ 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
Re: [Discuss-gnuradio] Timestamps USRP N210
Hi Josh, If you want the timestamps, you can use UHD directly (see the examples/rx_timed_samples.cpp). thanks for the quick response. I did not have much time to check out the timed example, but will do that as soon as possible. If you are looking to align multiple channels, the uhd source block will do that automatically when you set it up for multiple channels. I am actually having two USRPs connected via a switch to a single computer. In the flowgraph I have two times the same branch, starting from each of the UHD source blocks. The USRPs should listen to the same stuff and I want to be able to compare their observations (samples), thus they need to should start sampling at the same time (or I have to know their exact offset). Or from gnuradio, you can make a trivial mod to the source block's work function to intercept the RX metadata and create a tag for each timestamp. This tag will get propagated down the chain of processing blocks. This sounds pretty good. I will have a look what I can do with that. Sebastian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gnuradio.org website service outage
The gnuradio.org website hosting provider, Amazon Web Services, has had data center outage on the US East Coast, which has brought our server down. No ETA for service restoration yet, but I'll post information as I get it. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio.org website service outage
On Mon, Aug 8, 2011 at 19:46, Johnathan Corgan jcor...@corganenterprises.com wrote: No ETA for service restoration yet, but I'll post information as I get it. AWS has restored service to their data center and the gnuradio.org website is again in service. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
