[Discuss-gnuradio] Re: Valve Problem
I tried with throotle block before Valve but same thing happens, flow graph seems to stop working. I think the problem is with Probe Avf Mag^2 block because when i removed this block the valve start working. Now a new thing happens, whenever I make it open using a variable during execution, the scope stops but when I re-enable (close) the valve again an error occurs that is, usrp2::rx_samples() failed usrp2: channel 0 not receiving THere is one more problem when i try to run any flow graph in 64-bit machine. When I enable Realtime Scheduling to ON or when I try to change USRP2 source frequency or decimation value during execution (using a variable) the error occurs Failed to enable Realtime Scheduling Regards, Umair Naeem MSc Communication Engineering Chalmers University ot Technology, Sweden. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] transmit_path.py
Hi allCan somebody tell me what kwards means or where can I find some help, I'm trying to understand how this program works to make one more simple if it is posible.# Get mod_kwargs mod_kwargs = self._modulator_class.extract_kwargs_from_options(options) Simple user manual for Gnuradio is good but I need some examples. Thanks for your help Juan Quiroz ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fedora 12 install
Hi Eric, Typo there in the boost version, the one I got from the F12 yum repo is 1.39.0. Usually I build boost from source and use the ---prefix when configuring but this time I decided to try getting it from the yum repo. In my case buy running 'yum install boost boost-devel' GnuRadio compiled and run. If somebody can also verify my doing it would be useful (make the configure process easier) by adding line 'yum install boost boost-devel' to topic 'GnuRadio from tarball' Patrik (...I know my SWEnglish is terrible.) - Original Message - From: Eric Blossom e...@comsec.com To: Patrik Tast pat...@poes-weather.com Cc: Discuss-gnuradio@gnu.org Sent: Monday, May 10, 2010 6:38 Subject: Re: [Discuss-gnuradio] Fedora 12 install On Sun, May 09, 2010 at 12:28:19AM +0300, Patrik Tast wrote: Hi All, I just reformatted and installed Fedora 12 and did yum update, an hour later, got GnuRadio from git. The only problem I run into was libboost. By doing yum install boost boost-devel all was sorted out in a few minutes and GnuRadio connection to USRP workin' At the moment my boost is 3.9 (and then some) Boost version numbers look something like 1.42.0. I'm not sure what you mean by 3.9 NOTICE: I did not have to fiddle with any paths at this point. The README is very helpful in the gnuradio folder Perhaps for GnuRadio fedora users in the wiki, yum install boost boost-devel could be added? It's been in there since at least 2008: http://gnuradio.org/redmine/wiki/gnuradio/FedoraInstall Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 MIMO setup problem
Hi, Is there any files for using two usrp2 as a receivers not as transmitters? thanks sri ram-2 wrote: Hi all, I am trying to create a two transmitter setup with two USRP2s connected with the MIMO cable. I use the trunk version of GNURadio (Friday, Jan 29,2010) on laptops running Ubuntu 9.04. From previous emails and looking at the code, the relevant code for two transmitter setup seems to be the test_mimo_tx file in usrp2/host/apps. I update the firmware of the master USRP2 with mimo_tx.bin as pointed out in http://gnuradio.org/redmine/wiki/gnuradio/USRP2UserFAQ. sudo ./u2_flash_tool --dev=/dev/sdb -t s/w apps/mimo_tx.bin -w and for the slave USRP2, I use sudo ./u2_flash_tool --dev=/dev/sdb -t s/w apps/mimo_tx_slave.bin -w When I invoke the transmission program at the sender laptop using sudo ./test_mimo_tx -f 2.412G -I a.dat -i 100 -r I observe the following message: usrp2::ctor reset_db failed. The USRP2 freezes after this and the host cannot find it using find_usrps. The archives of the mailing list suggest updating the firmware to solve this issue. But I want to use the MIMO firmware and not the usual txrx.bin. 1. Is there firmware for the MIMO master and slave, which does not have this problem? 2. What modifications need to be incorporated to the current MIMO files to fix this problem? If there is not a solution already, I am thinking of modifying the existing MIMO USRP2 related files. Any pointers on what are to be taken care of, will be very useful. Thanks, Sri ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/USRP2-MIMO-setup-problem-tp27397628p28509343.html 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] could not find device after flashing uhd firmware
I downloaded the image from the website and flashed it into the SD card. With command 'uhd_find_devices' I could not find the USRP2 for most of time(try hundred times find twice). I could not get reply for the ping command neither. I used 1GB card. There is no firewall. And the computer has several ethernet ports(I have tried all of them). What could be reason for this? Thank you! Liang _ 约会说不清地方？来试试微软地图最新msn互动功能！ http://ditu.live.com/?form=TLswm=1___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] svn 9482, usrp2 trunk, host/apps compile
I'm still unable to compile apps for USRP2 due to the following errors on the Boost libraries: gcc -g -O2 -Wall -pg -o .libs/find_usrps find_usrps.o ../lib/.libs/libusrp2.so /usr/local/lib/libgruel.so ../lib/.libs/libusrp2.so: undefined reference to `boost::thread_resource_error::thread_resource_error()' ../lib/.libs/libusrp2.so: undefined reference to `typeinfo for boost::thread_resource_error' ../lib/.libs/libusrp2.so: undefined reference to `boost::thread_resource_error::~thread_resource_error()' collect2: ld returned 1 exit status make[2]: *** [find_usrps] Error 1 So PLEASE, can anyone enlighten me about how can I solve this issue so that I can test my boards and apps too? Eric Blossom wrote: On Tue, Sep 02, 2008 at 01:01:06PM +0200, Mattias Kjellsson wrote: Hi list, I checked out usrp2- trunk svn9482 today, and got some errors when I tried to build it. the following steps was taken: Installed boost-1.36, from source with configure --with-libraries=all option made a symbolic link from /usr/local/include/boost-1.36 to /usr/local/include/boost Downloaded usrp2 trunk, svn co http://www.gnuradio.org/... usrp2 cd usrp2 bootstrap configure --with-warnings --with-gprof --with-gnu-ld Please don't create any symlinks etc. The configure macros assume that boost is installed the way that the boost build system installs it. I strongly suggest that you build boost as described in the README.building-boost with a --prefix of /opt/boost_1_36_0. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/svn-9482%2C-usrp2-trunk%2C-host-apps-compile-tp19268084p28510674.html 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
Re: [Discuss-gnuradio] transmit_path.py
Juan Quiroz wrote: Can somebody tell me what kwards means or where can I find some help, I'm trying to understand how this program works to make one more simple if it is posible. # Get mod_kwargs mod_kwargs = self._modulator_class.extract_kwargs_from_options(options) Simple user manual for Gnuradio is good but I need some examples. I haven't tried that particular one, but I guess it's a dictionary. Try printing it. My reason for guessing that it is a dictionary is that kwargs is a standard name used in Python code for keyword-arguments. Try the vast online tutorial: http://lmgtfy.com/?q=python+kwargs+tutorial Good luck /Mikael Olofsson Universitetslektor (Associate Professor) Linköpings universitet --- E-Mail: mik...@isy.liu.se WWW: http://www.commsys.isy.liu.se/en/staff/mikael Phone: +46 - (0)13 - 28 1343 Telefax: +46 - (0)13 - 13 9282 --- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Problem to set RF filter on DBSRX board
Hi, I'm a new user on this forum I need some help and I hope someone can save me from the madness %-|%-| I used on USRP 1 the DBSRX daughterboard with discrete success to acquire DVB-T signal in 800 MHz band. Now i want to carry on my work on USRP2 to avoid problem with overrun butafter hardware changes at daughterboard it works very well to see the signal but I can't set daughterboard RF filter bandwidth to select a particular DVB- T channel cause in USRP2 there is no method set_bw(). Now...I can modify db_dbsrx.c to add this method that modify registers to set RF frequency bw like the same .cc script for USRP1...but after that? I have to recompile something after that? how can I recall my new method in a python flow graph if the usrp2 class not contain this new method? Please help meand I'm deeply sorry if someone thinks I'm an ignorant :confused: Thanks, Domenico -- View this message in context: http://old.nabble.com/Problem-to-set-RF-filter-on-DBSRX-board-tp28509367p28509367.html 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] USRP2 and python
Hi, Is it true that most of the application and examples for mimo based usrp2, which are created till now are only using c++ not using python?? if there are some mimo usrp2 examples using python, can anybody point me to it? regards, -- View this message in context: http://old.nabble.com/USRP2-and-python-tp28511315p28511315.html 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] Missing critical module: gnuradio.gr.hier_block2
Hello all I'm trying to execute the graphical interface since several days from the command promnt but I get the following error: Missing critical module: gnuradio.gr.hier_block2 Exiting! I tried to import such a file from gnuradio_swig_python but in vain! could someone help me to solve that? Thank you in advance -- View this message in context: http://old.nabble.com/Missing-critical-module%3A-%22gnuradio.gr.hier_block2%22-tp28512271p28512271.html 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
Re: [Discuss-gnuradio] could not find device after flashing uhd firmware
Link for the newest u2 images: http://code.ettus.com/redmine/ettus/projects/public/wiki/U2binaries See notes on networking: http://www.ettus.com/uhd_docs/manual/html/usrp2.html#setup-networking Set a static ip on the interface to 192.168.10.1 For simplicity, no other interfaces should be on 192.168.10.* You should be able to ping 192.168.10.2 Does it work? Once ping works, find devices should work. My best guess is that you did not set the static ip, or did not have the most recent images. You may want to look at the verbose from the serial port on the rear of the usrp2. It will let you know that the usrp2 has booted up normally. I hope that this helps. -Josh On 05/10/2010 01:14 AM, 周亮 wrote: I downloaded the image from the website and flashed it into the SD card. With command 'uhd_find_devices' I could not find the USRP2 for most of time(try hundred times find twice). I could not get reply for the ping command neither. I used 1GB card. There is no firewall. And the computer has several ethernet ports(I have tried all of them). What could be reason for this? Thank you! Liang _ 约会说不清地方？来试试微软地图最新msn互动功能！ http://ditu.live.com/?form=TLswm=1 ___ 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] svn 9482, usrp2 trunk, host/apps compile
On Mon, May 10, 2010 at 04:59:15AM -0700, STErm wrote: I'm still unable to compile apps for USRP2 due to the following errors on the Boost libraries: gcc -g -O2 -Wall -pg -o .libs/find_usrps find_usrps.o ../lib/.libs/libusrp2.so /usr/local/lib/libgruel.so ../lib/.libs/libusrp2.so: undefined reference to `boost::thread_resource_error::thread_resource_error()' ../lib/.libs/libusrp2.so: undefined reference to `typeinfo for boost::thread_resource_error' ../lib/.libs/libusrp2.so: undefined reference to `boost::thread_resource_error::~thread_resource_error()' collect2: ld returned 1 exit status make[2]: *** [find_usrps] Error 1 So PLEASE, can anyone enlighten me about how can I solve this issue so that I can test my boards and apps too? We need more clues from you to be of assistance. Please read this: http://gnuradio.org/redmine/wiki/gnuradio/ReportingErrors and ask again. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PACKET FORMAT error
On Sun, May 9, 2010 at 11:28 PM, zzw.1012 zzw.1...@163.com wrote:
Hi,
I'm studying benchmark_tx.py now. I find that the packet size is not
right (at least I'd like to think so) in the process of making packet, which
can be seen in pkt.py and packet_utils.py. In the packet consist of 2 bytes
packed_preamble, 8 bytes packed_access_code, 4 bytes header, 4 bytes
outband_crc with default 1500 bytes size, padding bytes and endbyte\x55 .
I use default gmsk modulatiom. So, the packet have 2 + 8 + 4 + 1504 + 1 + 1
= 1520bytes.
However, in the function of _npadding_bytes(pkt_bytes_len,
samples_per_symbol, bits_per_symbol) , there have such description:
generate sufficient padding such that each packet ultimately ends up being
a multiple of 512 bytes when sent across the USB, we send 4-byte samples
across the USB (16-bit I and 16-bit Q), thus we want to pad so that after
modulation the resulting packet is a multiple of 128 samples. Also , in the
function int usrp_basic_tx::write(const void *buf, int len, bool
*underrun)in the usrp_basic.cc, there have similar code like if (len 0
|| (len % 512) != 0){fprintf(stderr, usrp_basic_tx::write: invalid length
= %d\n, len}.
they both tell me that the data across the USB must be a multiple of 512
bytes .but in the example of benchmark_tx.py, the packet size is 1520
bytes. what's wrong ?
1520 bytes only refers to the packet size. The transmitted sample
stream at the physical layer includes a number of other factors
including conversion to bits, samples per symbol, and sample size. So
for the default case, a 1520 byte packet using 4 samples per symbol
yields 48640 samples or 194560 bytes, which is a multiple of 512.
Thomas
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Trouble in x86_64 land?
On Sat, May 8, 2010 at 6:09 PM, Marcus D. Leech mle...@ripnet.com wrote: I have a recent (couple of days old) GIT of Gnu Radio, installed on an x86_64 Quad-core QX9770. I have F12 installed on this, with all the updates applied. Any application that uses the wxGui sinks, using gl rendering, dumpeth the core, without even bringing a window up. Changing the rendering to nongl fixes the problem, but gosh, the nongl stuff is ugly, and doesn't have as many working features as the gl stuff. Has anyone else seen this issue? Anything that uses a gl scope type window seems to fail: One of my machines has this issue. I just assumed it was something with the ever changing Nouveau driver, which was included in F12. I haven't bothered with trying to get it to work. Are you running a nVidia card? My other 64-bit boxes are fine. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Quesions on BPSK transceiver
Dear all, I'm trying to build a BPSK transmitter which is modulated with a group of binary sequence of bits by USRP1 with LFTX/RX plugged on. The frequence of the sequence in baseband should be 25kHz, I'm modifying the digital-bert project in gnuradio-example, using the following two line to take the place of the BERT data creation (._bits and ._ scrambler): self._bits = (1,0,0,1, 0,0,0,1, 0,1,1,1, 1,0,1,0, 1,1,1,0, 0,1,0,1, 1,0,1,1, 0,1,0,0, 1,1,1,0, 1,0,1,1, 1,1,0,1, 0,0,0,1, 0,0,1,1, 0,1,0,1, 1,1,0,0, 0,1,0,0, 0,0,1,0, 0,1,0,0, 0,0,1,1, 1,1,1,0, 0,1,1,0, 0,1,1,1, 1,0,1,0, 0,0,1,0, 0,1,0,0, 0,0,1,0, 0,0,1,1, 1,0,1,0, 1,0,0,0, 0,0,0,0, 0,0,0,0, 0,0,0,0) self.in_data = gr.vector_source_b(self._bits, True ) Then the data will map to the same constellation and filtered by the same rrc as BERT data does. To meet the requirement of the baseband frequence, the parameters are set as shown as following: rate: 25e3 sps: 32 if_rate: 800e3 (=rate*sps) interp: 160 (=_dac_rate/if_rate=128e6/800e3) freq:3M amplitude: 128 --excess-bw: 0.35 Are these parameters set correctly? How to decide the amplitude? Will the signal be saturated at the receiver side, if the amplitude is too large but less than 32767? At the receiver side, the received raw signal in baseband will be required to recorded in a data file without frequency recovery and time offset correction. Such that my receiver only tune the signal back to baseband and filter it by a matched filter rrc and sink the data in a data file. My top block for the receiver is: class rx_bpsk_block(gr.top_block): def __init__(self, options): gr.top_block.__init__(self, rx_mpsk) print USRP decimation rate, options.decim_rate # Create a USRP source at desired board, sample rate, frequency, and gain self._setup_usrp(options.which, options.decim_rate, options.rx_subdev_spec, options.freq, options.gain) # Create the receiver if_rate = self._usrp.adc_rate()/options.decim_rate self._sps = int(if_rate/options.rate) # Create RRC with specified excess bandwidth taps = gr.firdes.root_raised_cosine(1.0, # Gain self._sps,# Sampling rate 1.0, # Symbol rate options.excess_bw,# Roll-off factor 11*self._sps) # Number of taps self._rrc = gr.fir_filter_ccf(1, taps) self._c2r = gr.complex_to_real() #sink the data into a file self._sink = gr.file_sink(gr.sizeof_float, options.filename) self.connect(self._usrp, self._agc,self._rrc, self._c2r, self._sink) The parameters are set as: gain: 20 rate: 25e3 decim-rate: 8 freq:3M How to determine the decim-rate? By using octave to plot the data recorded, the received signal I got is like a impulse response of root-raised-cosine filter. What I suppose to get is the signal after tunning back to baseband and filtered by a lowpass filter. What the problem will be? Thank you so much in advance Regards, Yan attachment: ynie3.vcf___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr.and_const_ss Overflow error with values over 0x7FFF?
Hi All, Does anyone have any idea what's happening here? It seems like gr.and_const_ss(short k) wont accept any values of k greater than 0x7fff. It's a bit of a problem for using gr-gpio where the use case would be gr.and_const_ss(0xEFFF) to get only the analog portion of the samples. Executing z = gr.and_const_ss(0x7fff) works fine but z = gr.and_const_ss(0x8000) results in: z = gr.and_const_ss(0x8000) Traceback (most recent call last): File stdin, line 1, in module File /usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_swig_py_gengen.py, line 1636, in and_const_ss return _gnuradio_swig_py_gengen.and_const_ss(*args, **kwargs) OverflowError: in method 'and_const_ss', argument 1 of type 'short' I've git pulled with no improvement and I'm running Ubuntu 10.04 LTS. This issue can be reproduced using either an interactive Python console or by running gnuradio/gr-gpio/src/python/gpio_rx_sfile.py Also multiply_const_ss is doing the same thing. Maybe I need to raise this as an issue? Thanks for any help, Drew ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr.and_const_ss Overflow error with values over 0x7FFF?
On Tue, May 11, 2010 at 09:12:40AM +1200, Drew Read wrote: Hi All, Does anyone have any idea what's happening here? It seems like gr.and_const_ss(short k) wont accept any values of k greater than 0x7fff. It's a bit of a problem for using gr-gpio where the use case would be gr.and_const_ss(0xEFFF) to get only the analog portion of the samples. Executing z = gr.and_const_ss(0x7fff) works fine but z = gr.and_const_ss(0x8000) results in: z = gr.and_const_ss(0x8000) Traceback (most recent call last): File stdin, line 1, in module File /usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_swig_py_gengen.py, line 1636, in and_const_ss return _gnuradio_swig_py_gengen.and_const_ss(*args, **kwargs) OverflowError: in method 'and_const_ss', argument 1 of type 'short' I've git pulled with no improvement and I'm running Ubuntu 10.04 LTS. This issue can be reproduced using either an interactive Python console or by running gnuradio/gr-gpio/src/python/gpio_rx_sfile.py Also multiply_const_ss is doing the same thing. Maybe I need to raise this as an issue? Thanks for any help, Drew It's a side effect of the conversion between Python and C++. I just pushed an update to master that gives you a way to deal with what SWIG thinks are hex values that won't fit in a short. [...@octo ~]$ python Python 2.6.2 (r262:71600, Jan 25 2010, 18:46:47) [GCC 4.4.2 20091222 (Red Hat 4.4.2-20)] on linux2 Type help, copyright, credits or license for more information. from gnuradio import gr, gru z=gr.and_const_ss(gru.hexshort(0x8000)) gru.hexshort(0x8000) -32768 gru.hexshort(0xFFE0) -32 Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Swept FFT needs more tweeking
Well, it looks like my swept FFT program still needs some tweaking. As helpful as Marcus was . I need someone else with a WBX board to test this flow graph. 1)If you set the frequency span to 2300MHz (reasonable for the WBX) the center frequency jumps to 1.27866GHz immediately after you start the sweep. The next center frequency is 1.31699GHz. This is a difference of 38.33MHz. With this decimation the span is only 8MHz, so we have a problem L 2)If you stop the sweep manually, the coarse slider takes on a life of its own and zooms off to the end of the control. Note: The controls on the Setup tab don't do anything yet. Any help would be appreciated . Bill Swept_usrp_fft_Notebook_Rev2.grc Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Swept FFT needs more tweeking
I think that you are being bitten by the gnuradio scheduler. Gnuradio likes to pass around data in big chunks, so you are probably getting a bunch of tune frequencies at once, then a big wait, then another bunch. It sounded good in principal, but trying to generate a nicely incrementing frequency based on sampling the output of a sawtooth is turning out to be very challenging with the current blocks. It would be best to make a custom block in grc that spawns a thread that calls set on the variable, increments the freq, sleeps, repeats. You would need to write a little python. Take a look at the writing custom blocks on the grc wiki page. It would probably look like this: makeNone def do(): while True: self.set_tune_freq(self.tune_freq+incr) time.sleep(yawn) threading.Thread(target=do).start()/make -Josh On 05/10/2010 06:41 PM, William Pretty Security Inc wrote: Well, it looks like my swept FFT program still needs some tweaking. As helpful as Marcus was . I need someone else with a WBX board to test this flow graph. 1)If you set the frequency span to 2300MHz (reasonable for the WBX) the center frequency jumps to 1.27866GHz immediately after you start the sweep. The next center frequency is 1.31699GHz. This is a difference of 38.33MHz. With this decimation the span is only 8MHz, so we have a problem L 2)If you stop the sweep manually, the coarse slider takes on a life of its own and zooms off to the end of the control. Note: The controls on the Setup tab don't do anything yet. Any help would be appreciated . Bill ___ 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] Unexplained out-of-sequence packets...
Hi All I am coming across problems when using USRP2s with certain decimation factors, and these problems are somewhat counterintuitive. For instance, either using our own code while simply waiting for samples to cross a threshold (so very little computation), I find that I am getting SSS, indicating out-of-sequence packets. This was for a decimation factor of 20. However, when I tried a decimation factor of 10, which should have increased both the Ethernet and the computational requirements, I no longer observed out-of-sequence packets. I tried the same sort of thing with usrp2_fft.py, trying decimations of 10, 16, and 20. For decimations 16 and 20, I got out-of-sequence packets within about 10 - 20 seconds, but with decimation factor 10 I saw no out-of-sequence packets even after a few minutes. Can anybody suggest what might be going on here? Thanks Ian. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr.and_const_ss Overflow error with values over 0x7FFF?
On Tue, May 11, 2010 at 09:12:40AM +1200, Drew Read wrote: Hi All, Does anyone have any idea what's happening here? It seems like gr.and_const_ss(short k) wont accept any values of k greater than 0x7fff. It's a bit of a problem for using gr-gpio where the use case would be gr.and_const_ss(0xEFFF) to get only the analog portion of the samples. Executing z = gr.and_const_ss(0x7fff) works fine but z = gr.and_const_ss(0x8000) results in: z = gr.and_const_ss(0x8000) Traceback (most recent call last): File stdin, line 1, in module File /usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_swig_py_gengen.py, line 1636, in and_const_ss return _gnuradio_swig_py_gengen.and_const_ss(*args, **kwargs) OverflowError: in method 'and_const_ss', argument 1 of type 'short' I've git pulled with no improvement and I'm running Ubuntu 10.04 LTS. This issue can be reproduced using either an interactive Python console or by running gnuradio/gr-gpio/src/python/gpio_rx_sfile.py Also multiply_const_ss is doing the same thing. Maybe I need to raise this as an issue? Thanks for any help, Drew ___ 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] Unexplained out-of-sequence packets...
On Tue, May 11, 2010 at 09:24:18AM +0930, Ian Holland wrote: Hi All I am coming across problems when using USRP2s with certain decimation factors, and these problems are somewhat counterintuitive. For instance, either using our own code while simply waiting for samples to cross a threshold (so very little computation), I find that I am getting SSS, indicating out-of-sequence packets. This was for a decimation factor of 20. However, when I tried a decimation factor of 10, which should have increased both the Ethernet and the computational requirements, I no longer observed out-of-sequence packets. I tried the same sort of thing with usrp2_fft.py, trying decimations of 10, 16, and 20. For decimations 16 and 20, I got out-of-sequence packets within about 10 - 20 seconds, but with decimation factor 10 I saw no out-of-sequence packets even after a few minutes. Can anybody suggest what might be going on here? Thanks Ian. What GNU Radio version are you using? git? tarball? What kind of hardware are you running on? How much RAM is in the machine? What OS and distribution are you running? What kernel version are you using? What else is running on the machine? What USRP firmware are you using? What does $ sudo ethtool -a ethN report? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Unexplained out-of-sequence packets...
On 05/10/2010 04:54 PM, Ian Holland wrote: Hi All I am coming across problems when using USRP2s with certain decimation factors, and these problems are somewhat counterintuitive. For instance, either using our own code while simply waiting for samples to cross a threshold (so very little computation), I find that I am getting SSS, indicating out-of-sequence packets. This was for a decimation factor of 20. However, when I tried a decimation factor of 10, which should have increased both the Ethernet and the computational requirements, I no longer observed out-of-sequence packets. I tried the same sort of thing with usrp2_fft.py, trying decimations of 10, 16, and 20. For decimations 16 and 20, I got out-of-sequence packets within about 10 – 20 seconds, but with decimation factor 10 I saw no out-of-sequence packets even after a few minutes. Can anybody suggest what might be going on here? I don't know what exactly is happening here, as I have not seen this behavior, but I just want to clarify a little terminology. The S you are seeing indicates sequence number errors. While getting packets out of sequence would give this error, that isn't that is happening. The sequence number errors really indicate that you are dropping packets because you can't keep up. Typically, if you can't keep up at a slow decimation, going to a faster one would make things worse, not better. The only thing I can think of to explain what you are seeing is that you might be doing a lot more processing at the lower rate. For example, at the lower sample rate, you might be making your filter transition bands very narrow, resulting in very long filters. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Full-duplex WBX
Hi there, Does anybody know how to configure WBX to work in full-duplex mode? By running the usrp2_fft.py, it turned out that both TX/RX port and RX2 port work for receiving. Since TX and RX share the same port, how do we know if the WBX work in half-duplex mode or in full-duplex mode? Thanks. -Evan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Unexplained out-of-sequence packets...
Typically, if you can't keep up at a slow decimation, going to a faster one would make things worse, not better. The only thing I can think of to explain what you are seeing is that you might be doing a lot more processing at the lower rate. For example, at the lower sample rate, you might be making your filter transition bands very narrow, resulting in very long filters. Matt I've run into that problem (in a different context--not with USRP2). If you make your filter transition bandwidth some fraction of the overall bandwidth of the filter, you can end up with longish filters and lower bandwidths. I was used to using an expression like (filter_bandwidth/10) for the transition bands, but that ends up with quite long filters. -- 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
RE: [Discuss-gnuradio] Unexplained out-of-sequence packets...
Hi Eric Please find my answers inline below. Cheers Ian. What GNU Radio version are you using? git? tarball? Git - Taken from trunk on 25 March 2010. What kind of hardware are you running on? HP Intel Core 2 Duo - 2 x 2 GHz CPUs How much RAM is in the machine? 3513M (according to free -mt) What OS and distribution are you running? Ubuntu 9.10 What kernel version are you using? Release: 2.6.31-20-generic Version: #58-Ubuntu SMP Fri Mar 12 05:23:09 UTC 2010 (according to uname -v) What else is running on the machine? Netbeans 6.8, and System Monitor. What USRP firmware are you using? u2_rev3.bin and txrx.bin, which were taken from the latest versions as of 29 January 2010. What does $ sudo ethtool -a ethN report? Pause parameters for eth0: Autonegotiate: on RX:on TX:off ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Unexplained out-of-sequence packets...
Hi Matt and Marcus. I understand it is indicating dropped packets, hence causing later ones to show up out-of-sequence. Re the processing, this occurs even with the usrp2_fft.py script as well. I don't think that does more processing for higher values of decimation factor, though please correct me if I am wrong here. Also, I am not doing any special filtering with my code, simply capturing raw complex samples, and comparing their magnitude to a threshold. Of course, once the threshold is crossed I do more computations, but these S's appear even while I am still listening. On the other hand, when I reduce the decimation factor, then I don't have this problem until I do my other processing, which then leads to lost packets due to excessive computational load. As such, I haven't found a value of decimation factor that I can use. Cheers Ian. -Original Message- From: Matt Ettus [mailto:m...@ettus.com] Sent: Tuesday, 11 May 2010 9:46 AM To: Ian Holland Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Unexplained out-of-sequence packets... On 05/10/2010 04:54 PM, Ian Holland wrote: Hi All I am coming across problems when using USRP2s with certain decimation factors, and these problems are somewhat counterintuitive. For instance, either using our own code while simply waiting for samples to cross a threshold (so very little computation), I find that I am getting SSS, indicating out-of-sequence packets. This was for a decimation factor of 20. However, when I tried a decimation factor of 10, which should have increased both the Ethernet and the computational requirements, I no longer observed out-of-sequence packets. I tried the same sort of thing with usrp2_fft.py, trying decimations of 10, 16, and 20. For decimations 16 and 20, I got out-of-sequence packets within about 10 - 20 seconds, but with decimation factor 10 I saw no out-of-sequence packets even after a few minutes. Can anybody suggest what might be going on here? I don't know what exactly is happening here, as I have not seen this behavior, but I just want to clarify a little terminology. The S you are seeing indicates sequence number errors. While getting packets out of sequence would give this error, that isn't that is happening. The sequence number errors really indicate that you are dropping packets because you can't keep up. Typically, if you can't keep up at a slow decimation, going to a faster one would make things worse, not better. The only thing I can think of to explain what you are seeing is that you might be doing a lot more processing at the lower rate. For example, at the lower sample rate, you might be making your filter transition bands very narrow, resulting in very long filters. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Trouble in x86_64 land?
On Sat, May 8, 2010 at 6:09 PM, Marcus D. Leech mle...@ripnet.com wrote: One of my machines has this issue. I just assumed it was something with the ever changing Nouveau driver, which was included in F12. I haven't bothered with trying to get it to work. Are you running a nVidia card? My other 64-bit boxes are fine. Thomas Well, I just turned gl rendering back on, but displayed via an SSH tunnel back to a different machine with a different video card. Works just fine. So, some badness in GL I spoze. Not much that Gnu Radio can do about it, I guess. -- 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] Hi all, how to use gnuradio to get the distance between a gsm mobil phone and the usrp receiver?
Hi all, how to use gnuradio to get the distance between a gsm mobil phone and the usrp receiver? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Unexplained out-of-sequence packets...
On Tue, May 11, 2010 at 10:45:05AM +0930, Ian Holland wrote: Not sure if this sheds any more light on the issue, but I have found that if I shut down the PC and turn it on again, before retrying the same tests, the problem disappears. However, as I have encountered it before as well I am still puzzled as to why this should ever occur. Ian. CPU throttling. Check power management configuration. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Unexplained out-of-sequence packets...
Thanks Eric I checked the power management preferences and couldn't see anything about CPU throttling, though I did verify it would never go to sleep after inactivity. Then, I found some info on http://blog.mpathirage.com/2009/10/04/how-to-disable-dynamic-frequency-s calingcpu-throttling-in-ubuntu-jaunty9-04/ to disable the CPU throttling (I know I am using 9.10, not 9.04, but I imagine it should be the same). After rebooting (only once), I haven't yet seen the problem again. Unfortunately, given the seemingly random nature of the problem, I guess it is a wait-and-see matter as to whether it ever does resurface. Cheers Ian. -Original Message- From: Eric Blossom [mailto:e...@comsec.com] Sent: Tuesday, 11 May 2010 10:55 AM To: Ian Holland Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Unexplained out-of-sequence packets... On Tue, May 11, 2010 at 10:45:05AM +0930, Ian Holland wrote: Not sure if this sheds any more light on the issue, but I have found that if I shut down the PC and turn it on again, before retrying the same tests, the problem disappears. However, as I have encountered it before as well I am still puzzled as to why this should ever occur. Ian. CPU throttling. Check power management configuration. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
