On Thu, Jul 25, 2013 at 6:42 AM, Ralph A. Schmid, dk5ras
wrote:
> To get OpenBTS up and running together with the USRP1 I need gnuradio 3.4.2.
> These instructions here
>
> http://gnuradio.org/redmine/projects/gnuradio/wiki/UsingLibusrpWith3_5
>
> are a good way to go, did this several times with
On Wed, Jul 24, 2013 at 10:00 AM, Nemanja Savic wrote:
> today I tried installing 3.7.0 on my RHEL machine, but without success and
> with the following error message during make:
>
> [ 70%] Building CXX object
> gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/TimeDomainDisplayPlot.cc.o
> /home/savi_ne
On Sat, Mar 23, 2013 at 5:36 PM, Sid Boyce wrote:
> I don't know if anyone has attempted it but I thought I'd have a go on
> Ubuntu 12.10 on an ODROID-X.
> Main problem it reports is a known bad version of boost that prohibits it
> building gnuradio-core and other components.
I just compiled on A
On Thu, Jan 17, 2013 at 11:20 AM, Ed Criscuolo
wrote:
> I thought it has an Arm11! From Wikipedia:
>
> "The Raspberry Pi has a Broadcom BCM2835 system on a chip (SoC),[3] which
> includes an ARM1176JZF-S 700 MHz processor VideoCore IV GPU,[12] and
> originally shipped with 256 megabytes of RA
On Sun, Jun 3, 2012 at 9:49 AM, Pan, Luyuan wrote:
> Hello,
> I want to set up the OpenBTS, and I want to know which board is better,
> USRP1 or USRP2? Or any other suggestion? Thank you.
Both USRP1 and USRP2 work with OpenBTS and neither can be considered
"better" without describing your requ
On Wed, May 2, 2012 at 8:18 AM, Ben Wojtowicz wrote:
> Thomas,
>
> Thanks for giving it a try!! If you get me your VZW recording, I can
> take a closer look to see what is going wrong with the SIB decoding.
I'll try to post some captures by the end of the week. I should
mention that I used some
On Wed, May 2, 2012 at 3:20 AM, Vanessa Quaranta
wrote:
> transceiver: usrp_standard.cc:1024: virtual bool
> usrp_standard_tx::set_tx_freq(int, double): Assertion `dac_rate () ==
> 12800' failed.
> 1335942873.3055 WARN 3078358736 TRXManager.cpp:254:sendCommandPacket: TRX
> link timeout on atte
On Sat, Apr 28, 2012 at 9:26 PM, Ben Wojtowicz wrote:
> I am pleased to announce version 00.05 of openLTE, an open source LTE
> project (sourceforge.net/projects/openlte). This version includes a
> gnuradio application that reads recorded I/Q downlink LTE data from a
> file, decodes MIB and SIB1,
On Sat, Apr 7, 2012 at 10:12 PM, Marcus D. Leech wrote:
> Here's a little beauty of a code snippet:
>
> d_access_code = 0;
> for (unsigned i=0; i < 64; i++){
> d_access_code <<= 1;
> if (i < len)
> d_access_code |= access_code[i] & 1; // look at LSB only
> }
The piece was committ
On Tue, Dec 20, 2011 at 5:11 AM, Sebastian Döring
wrote:
>> --
>> #0 0x0013a455 in sem_post@@GLIBC_2.1 () from
>> /lib/tls/i686/cmov/libpthread.so.0
>> #1 0x0810ab61 in PyThread_release_lock (lock
2011/11/29 signalswdm :
> Dear everyone:
> You see in usrp_basic.h there is a function named _write_9862() and
> it uses function usrp_9862_write(),defined in usrp_prims_common.h. And
> usrp_9862_write() uses function usrp_spi_write(), also defined in
> usrp_prims_common.h.
> usrp_spi_write()
On Fri, Nov 4, 2011 at 6:08 AM, Martin Flasskamp
wrote:
> Hello all,
>
> I want to set up a demonstrator system for wireless communication
> between two USRP devices. Some weeks ago, Matthias Wilhelm proposed the
> UCLA Zigbee implementation as a good starting point because of its
> complete and r
On Thu, Nov 3, 2011 at 12:15 PM, Marcus M wrote:
> My adviser accidentally plugged in a laptop's power adapter into a USRP for
> a few seconds and now it doesn't respond and GNU Radio doesn't detect it
> either after connecting to the laptop and testing it. What do I do? I hope
> that there must b
On Oct 28, 2011 11:57 PM, "Josh Blum" wrote:
> On 10/28/2011 12:20 PM, Vanessa Gardellin wrote:
> > Please let me know if you solve the problem, I also have a seg fault...
> >
>
> So help me help you...
>
> What version of gnuradio?
> What version of uhd?
>
> Do the uhd example apps work?
> Can yo
On Sat, Aug 6, 2011 at 9:56 PM, Ben Reynwar wrote:
> I'm wanting to have a play with gnuradio with some real data, rather
> than make-pretend software generated stuff, but don't have any
> particular transmission type in mind. I thought there were a couple
> of websites where people had uploaded
On Tue, Aug 2, 2011 at 7:31 PM, Lin HUANG 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 th
On Wed, Jul 27, 2011 at 1:23 PM, Colby Boyer wrote:
> Hi all,
> I'm running a duplex system on the USRP1; using UHD drivers (about 1 month
> old). For the sample rates, I have 640KHz to the USRP and 1MHz from the
> USRP. The turn around time for a simple amplitude detected signal is approx
> 20ms,
On Fri, Jul 15, 2011 at 1:47 PM, Marcus D. Leech wrote:
> On 07/15/2011 04:42 PM, Philip Balister wrote:
>>
>> From a quick look at Tom's oprofile results, first find out who is calling
>> into libm and see if you can change the block to stopp calling libm. For
>> example, calculate sin/cos via a
On Fri, Jul 15, 2011 at 1:24 PM, Marcus D. Leech wrote:
> On 07/13/2011 04:40 AM, Riadh Elloumi wrote:
>> I used all the optimized code for Cortex-A8 like dotprod_ccf_armv7_a.c.
>> My compilation flags are: -mcpu=cortex-a8 -mfloat-abi=softfp -mfpu=neon
>> -O2. I used fftw-3.2.2.
>
> What does -mfl
On Wed, Jul 13, 2011 at 1:40 AM, Riadh Elloumi wrote:
> Hi all,
>
> I complied DAB demodulation for ARM Cortex-A8 (TI OMAP 3). It
> successfully demodulate DAB+ but spends 13 seconds decoding 1 second of
> radio baseband (USRP file).
I tested the demodulator with similar results. Decoding a file
On Tue, Jun 28, 2011 at 2:57 PM, Praveen Vikram
wrote:
> Thanks Josh and Thomas,
> I followed the current instructions on the wiki and updated the kernel
> modules (for my current 2.6.35 kernel).
> Now I'am able to run uhd_usrp_probe with this image
> http://www.ettus.com/downloads/uhd_images/usrp
On Wed, Jun 22, 2011 at 2:13 PM, Philip Balister wrote:
>
> Did you rerun configure adding -fPIC to CFLAGS? I ddi get the library to
> build as a shared library.
That worked for me.
Thomas
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
h
On Wed, Jun 22, 2011 at 4:25 AM, Tom Rondeau wrote:
> Martin,
> That was odd. When I clicked on your link, it too me to:
> http://gnuradio.org/redmine/wiki/gnuradio/
>
> That's the old-style Redmine layout. The new one is:
> http://gnuradio.org/redmine/projects/gnuradio/wiki
> Which makes more log
On Tue, Jun 7, 2011 at 3:28 AM, Paul Lambert wrote:
> Hello list,
>
> I'm having a lot of trouble here while trying to make openBTS work with my
> USRP1
> to play with GSMs.
This question belongs on the OpenBTS list.
> First of all, a little description of my setup:
> Software:
> openbts-2.6.0M
On Mon, May 30, 2011 at 6:26 PM, Brett L. Trotter wrote:
> I've seen the error with both fusb tech libusb1 and 0.1 as well as on
> various desktops and laptops and operating systems from various vendors.
> For what its worth, our USRPs are low serial number (no software serial,
> physical serial a
On Mon, May 30, 2011 at 5:20 AM, Johannes Schmitz wrote:
>
> We tried to run the code on Ubuntu 10.04, 10.10 and 11.04.
> Every time we get the fusb error :(
> It seems we have to throw away our USRP1's and move to USRP2...
I'm not able to reproduce this error with the posted examples. Please
try
On Sat, May 28, 2011 at 12:11 PM, Brett L. Trotter wrote:
> I just discovered the not well published --with-fusb-tech=libusb1 option
> to configure, hoping to resolve the USRP1 non-uhd crashing issues myself
> and one other person are seeing when the flowgraphs do a lock or stop.
> Unfortunately,
On Fri, May 27, 2011 at 7:28 AM, Johannes Schmitz wrote:
> I am getting this error:
>
> fusb: (rd status -2) No such file or directory
>
> What does it mean and what can I do to solve this.
> Crazy thing is it doesn't happen every time I call my rx script.
> I tried to pull usrp power plug and usb
On Fri, May 27, 2011 at 1:08 AM, Brett L. Trotter wrote:
> So after discovering that while I had libusb-devel-0.1 and
> libusb1-devel-1.0.3 installed on my RHEL-6 machine here (and ubuntu),
> gnuradio compiled against 0.1 despite 0.1 being "ancient and
> unsupported". I then removed libusb-devel a
On Tue, Apr 5, 2011 at 12:55 PM, Khalid Jamil wrote:
> Hello,
> Does anyone know if openBTS can be run on E100 standalone?
The current OpenBTS-UHD code will compile and run on the E100, but is
limited by the default 64 MHz clock configuration and required sample
rate conversion.
I will be pushin
On Tue, Mar 22, 2011 at 8:47 PM, wrote:
> Hello.
>
> Pardon if it was discussed before - quick googling failed me.
>
> How do I specify local installation of gnuradio instead of system-wide for
> openbts
> build - something like:
> ./configure --gnuradio-prefix=/home/user/gnuradio
> ?
pkg-conf
On Wed, Feb 23, 2011 at 11:25 PM, Almohanad Fayez wrote:
> I was wondering about people's experience with the UHD driver on the E100 or
> the Beagleboard. I am able to use it to receive IQ data from the USRP but I
> can't seem to transmit anything from it ... if I take the same flowgraph to
> a l
On Fri, Feb 25, 2011 at 8:32 PM, Josh Blum wrote:
> Hello list,
>
> In preparation for the coming gnuradio release, and the cut-over from
> next to master, changes have been pushed to both the uhd.git master
> branch and the gnuradio.git next branch.
I'm getting the following timeouts after the u
On Fri, Feb 25, 2011 at 8:32 PM, Josh Blum wrote:
> ---
> -- re-clocking support
> ---
> Re-clocking support has been added to the API:
> http://www.ettus.com/uhd
On Sun, Feb 27, 2011 at 11:39 PM, Almohanad Fayez wrote:
> I think I made some progress in diagnosing the UHD/Beagleboard USRP1 issue.
> I've tried bitbaking Philip's GNU Radio 3.2.1 recipe and the compilation
> fails because of the libusb-0.1.12 link, more specifically the
> "libusb-gnur.a" libra
On Sat, Feb 26, 2011 at 12:34 AM, Brett L. Trotter wrote:
> I've got several different flowgraphs here that upon shutting down some
> portion of the time, they emit a series of errors and then totally tank
> my USB controller on a number of test systems, requiring a full system
> reboot to reset t
On Wed, Feb 16, 2011 at 3:54 AM, Arya Santini wrote:
> Hi All,
>
> Can anyone shed some light on how the FX2 firmware / GPIF handles
> simultaneous reads and writes? I mean if I set up my USRP1 to receive
> and transmit simultaneously, what is happening exactly down there at
> the GPIF level? Give
I'm getting unexplained behavior receiving timed samples in continuous
mode with yesterday's merge. First run after boot is fine, but I get
overruns and a bizarre timestamp on subsequent runs. This occurs with the
USRP2 and N210. Running rx_timed_samples with the following diff
On Wed, Dec 15, 2010 at 2:04 PM, Josh Blum wrote:
>
>> It would be really nice if the send-function in the API have a TDMA
>> mode where fragments of samples are dropped when an underrun occur so
>> that the majority of the samples are aligned to the
>> start_of_burst_time (see above example (1) a
On Tue, Dec 14, 2010 at 6:34 PM, Josh Blum wrote:
>
>> Our observations shows also that the usrp2 doesn't drop any samples
>> when an underrun occur. If we drop samples at the host, can we get a
>> continous stream of sample at 25Msamp/s that is synchronous? What is
>> your maximum continous bandw
On Thu, Dec 9, 2010 at 5:11 AM, Patrik Eliardsson
wrote:
> Dear list,
>
> What is the expected behavior when we get underruns with the UHD and the flow
> control using the USRP2?
>
> 1) When we get underruns, does the usrp2 send some random samples until the
> host computer manage to feed the us
On Tue, Nov 16, 2010 at 4:38 PM, Marcus D. Leech wrote:
> I did a "git pull" for both UHD (master) and gnuradio (next) today, and a
> "make clean; make" in both places. The build is currently broken:
...
> /usr/local/include/uhd/types/ranges.hpp:59: Error: Syntax error in input(3).
> make[5]: **
On Wed, Nov 10, 2010 at 12:44 AM, Brett L. Trotter wrote:
> Does any alteration to code or firmware need to be made in order to get
> a USRP2 to lock to an external 10MHz reference?
No firmware changes with UHD. Code looks something like this.
uhd::clock_config_t clock_config;
clock_config.ref_s
On Mon, Oct 25, 2010 at 11:15 AM, zhdiamond wrote:
>
> My USRP has something wrong when started. when i want to open USRP, I input
> the command: usrp_fft.py -R B. but the system mentioned that:
> RuntimeError: cant open usrp, failed to load fpga bitstream
> /usr/share/usrp/rev4/std_2rxhb_2tx
On Tue, Sep 21, 2010 at 10:20 AM, Fabrizio Tappero
wrote:
> Dear All,
> I'd like to add a little piece of information about this problem.
> if I try to compile the previously mentioned code with:
> g++ usrp_test_c++.cpp -o testusrp `pkg-config --cflags usrp`
> `pkg-config --libs usrp`
>
> and I ch
On Mon, Sep 13, 2010 at 5:20 PM, Mason Scott wrote:
> I have to do my diploma work and I have to us an USRP to make an
> application, to be able to read some data from a hardware, to show how it
> can be integrated in a system, I'not giving any more details because it's
> not important. My who
On Sun, Sep 5, 2010 at 1:03 PM, Michael Kimzey wrote:
>
> Hello all.
> I'm a bit of a noobie and getting my feet wet here. I hope to use my
> recently received USRP1 to receive the GOES weather satellite LRIT data using
> software from their site. (here: http://www.goes-r.gov/hrit_emwin/index.
On Sun, Sep 5, 2010 at 1:24 PM, Josh Blum wrote:
>
>
> On 09/05/2010 04:11 AM, Elvis Dowson wrote:
>>
>> Hi,
>> More specifically, there is a problem with calls to
>> libusb_cpu_to_le16(x) in libusb.h
>>
>> /** \def libusb_cpu_to_le16
>> * \ingroup misc
>> * Convert a 16-bit value from hos
On Wed, Aug 25, 2010 at 9:58 AM, Vincenzo Pellegrini wrote:
> Hi everybody,
> Just a very simple question:
> Is it possible to obtain 10 bit samples out of USRP (either 1 or 2) by using
> suitable libusrp primitives / parameters?
No. But you can produce 8-bit samples on the USRP1 by appropriately
On Tue, Aug 24, 2010 at 4:18 PM, Mark J. Blair wrote:
>
> Now usrper appears to be happy:
>
> ~/gnuradio% usrper -v load_standard_bits
> usrper: found unconfigured usrp; needs firmware.
> ~/gnuradio% usrper -v get_hash0
> hash: ???7???g8!?_Md
> ~/gnuradio% usrper -v set_hash0 deadbeef
> ~/gnuradio
On Wed, Aug 11, 2010 at 11:07 AM, wrote:
> Hello-
>
> I am having a usb/USRP issue under x86_64 Mandriva 2010.1 with gnuradio-3.3.0.
>
> I compiled and installed using the default procedure:
> ./configure
> make
> sudo make install
>
> When I try to use usrp_fft.py, I get many errors (see below).
2010/8/2 shanki :
> thanks Thomas,
> in order to test these two calls, i write some test codes: i put a rxpath
> and a txpath in one topblock, my daughterboard is RFX2400, and i want to
> perform receiving while transmiting.
> Firstly, i used set_auto_tr(True), but i did't receive anything
On Wed, Aug 4, 2010 at 3:30 PM, Patrik Tast wrote:
> Hi All,
>
> The free USRP1 has suddenly decided to stop communicating. We suspect (from
> the output)
> that it might be an USB problem?
Very likely.
> It runs for about 30 - 60 secs and then freezes. The led on the motherboard
> is still blin
2010/7/30 蒲盟 :
> Hi ,
> I am confued by set_auto_tr() and set_enable(). In my opinion
> set_auto_tr(True) means that if there is something to transmit( something
> sent to the FPGA), the Rx path will be disabled, but if there is nothing
> sent to the FPGA, then the Rx path will be always enable
hanges to 1.04 after the firmware loads.
Thomas
> Thanks so much for the help guys.
> Regards
>
> Craig Tong
> Radar Remote Sensing Group
> University of Cape Town
>
>
> On 27/07/2010 02:36, Thomas Tsou wrote:
>>
>> On Mon, Jul 26, 2010 at 1:39 AM, Craig
found in the built source.
usrp/firmware/src/usrp2/burn-usrp4-eeprom
Disregard the directory naming.
Thomas
> Craig Tong
> Radar Remote Sensing Group
> University of Cape Town
>
>
> On 23/07/2010 19:49, Thomas Tsou wrote:
>>
>> On Fri, Jul 23, 2010 at 1:51 AM, C
On Sun, Jul 25, 2010 at 12:45 AM, Bishal Thapa wrote:
> Hi GNURadioers,
> I have a quick question. I am trying to use USRP running gnuradio-3.3.0
> with two daughterboards... RFX2400. I am going to use one daughterboard to
> receive and another to transmit. Do I use the standard firmware that is
04, which means unconfigured (high byte) and rev4
(low byte).
Thomas
> Craig Tong
> Radar Remote Sensing Group
> University of Cape Town
>
>
> On 22/07/2010 20:15, Thomas Tsou wrote:
>>
>> On Thu, Jul 22, 2010 at 4:35 AM, Craig Tong
>> wrote:
>>
>>&
tifiers. Either the
data is somehow corrupt or not being read.
What appears when you run lsusb on the command line?
Thomas
> Craig Tong
> Radar Remote Sensing Group
> University of Cape Town
>
>
> On 21/07/2010 19:15, Thomas Tsou wrote:
>>
>> On Wed, Jul 21, 2010 at
On Wed, Jul 21, 2010 at 1:36 AM, Craig Tong wrote:
> Hi,
>
> I'm having some trouble getting my USRP board running with just about any
> software. It always seems to die with "Can't find firmware: std.ihx". I've
> tried a whole array of applications including usrp_fft.py and similar,
> usrp_probe
On Sun, Jul 18, 2010 at 6:50 PM, John Wu wrote:
> Hi all,
> I create a standard rx which contain 2 channels for two rx daughter board.
> Now I use read function read the sampled data,
> and deinterleave the data, but which channel is related to which daughter
> board, and the deinterleaved data is
On Fri, Jul 16, 2010 at 2:30 AM, wrote:
> Hi,
>
> It sais, that the USRP digital downconverters have a programmable decimation
> rate. What does this decimation rate do? Is this the filter restricting the
> frequencies of the signal + noise?
>
> And how do I change this decimation rate?
Decimati
They refer to version specific code for libusb (v0.1 or v1.0). Most of
the code is made common between versions, but the remaining parts are
in those files. Which file is compiled is determined by configure and
will depend on your system setup.
Thomas
On 12/07/2010, John Wu wrote:
> what is
On Tue, Jun 29, 2010 at 9:46 AM, Monica Sit wrote:
>
> Hi,
>
> I am trying to install gnuradio-3.2.2 on Linux Mandriva 2010.0 i586.
> The PC is a 32 bit Intel P4 machine.
> When I run the command './configure', all gnuradio components passed the
> configuration tests except
[snip]
> libtool: li
On Tue, Jun 22, 2010 at 12:28 PM, Tuan Ta wrote:
> Hi all,
>
> This question might be a little bit off-topic but going through the code on
> the transmission side, I didn't see CRC method got invoked anywhere. Though
> I did see that the CRC got removed and checked in the receiving side. I'd be
>
On Tue, Jun 22, 2010 at 10:15 AM, Jakub Moskal wrote:
> Hi,
>
> I'm using the digital/benchmark_*.py from the GIT repository and am
> getting a very low ratio of corrupt packets, usually under 0.5%. I use
> the default gmsk modulation, USRP1's with RFX2400 and run the
> benchmark with a frequency
On Tue, Jun 22, 2010 at 11:15 AM, wrote:
> Hello everyone,
>
> When I run usrp_benchmark_usb.py, the two fastest tests fail, leaving me
> with 8 MB/sec maximum. I have two questions:
>
> First, how do I get the 16MB and 32MB tests to pass? Do I need a faster CPU?
Perhaps. What type of system are
On Thu, Jun 17, 2010 at 8:17 AM, Philip Balister wrote:
> I just noticed Swig 2.0 is out. Has anyone tried it with gnuradio yet?
>
> Philip
I just tried it with a new build. I didn't notice any immediate differences.
Thomas
___
Discuss-gnuradio mail
On Mon, Jun 14, 2010 at 10:16 AM, Juan Quiroz wrote:
> Hi
>
> On the output path of the FPGA there's a FIFO, Is 512 byte the size of each
> packet stored in FIFO?
> If true, why do I have option for fusb_block_size = 1024?
> I think it would be better to send 512 byte packets instead of 1024 to a
2010/5/31 weizhongshan :
> hello every !
> i use one usrp to transmit complex gr_sin_wave,and use another two_channel
> usrp as the receiver.
> i thought the mux should be set to "32103210",but when i did this ,i got
> nothing but noisy .then i changed the mux to "33221100",i got the ecpected
> ort
On Fri, May 21, 2010 at 2:59 PM, Catalin Patulea
wrote:
> On Fri, May 21, 2010 at 2:01 PM, Thomas Tsou wrote:
>> http://github.com/ttsou/gnuradio-ttsou/tree/releases/3.2
> The best I've been able to find in there is 24d0fd9:
> http://github.com/ttsou/g
On Thu, May 20, 2010 at 5:29 PM, Catalin Patulea
wrote:
> Hi,
>
> I'm trying to create a patch that applies cleanly onto a 3.2.2
> tarball. I would like to maintain my changes in the form of a Git
> branch.
>
> I can't seem to find a commit that matches up with the 3.2.2 release.
> The best I've b
On Thu, May 13, 2010 at 4:25 PM, George Nychis wrote:
> I'm trying to grab a copy of the GNU Radio code through git which still has
> the old USRP inband code. I noticed this commit from Jonathan in my search:
>
> Author: jcorgan
> Date: Thu Jul 9 02:55:51 2009 +
>
> Merged r11377:1139
2010/5/11 zzw.1012 :
> Hi, Thomas
> thanks for your help ! you are right!
> I add printf code in the function of usrp_basic.cc like this:
> int usrp_basic_tx::write(const void *buf, int len, bool *underrun)
> {
> ...
> printf ("len = %d\n", len);
> if (len < 0 || (len % 512) != 0)
> {
On Sat, May 8, 2010 at 6:09 PM, Marcus D. Leech 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
>
On Sun, May 9, 2010 at 11:28 PM, zzw.1012 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_pr
On Mon, May 3, 2010 at 7:57 PM, Vincenzo Pellegrini wrote:
> Hi everybody,
> I have notice an oddity with recent trunks.. since I updated a couple of
> months ago, my USRP (#541) is not working any more with the current trunk.
> When I try to send out an 8MHz band, samples get consumed by the USRP
On Mon, May 3, 2010 at 10:32 AM, Rafael Diniz wrote:
> Hello people,
> I'd like to know if I can do some modification in the WBX to go as low as
> 26MHz, is it possible?
> If not, what is better - BasicTX or LFTX, and what kind of RF frontend
> should I use - amplifiers and what more? Is there any
On Wed, Apr 28, 2010 at 1:59 AM, William Pretty Security Inc
wrote:
> Is there some bench mark I can run to test the USB and CPU loading ?
>
> Apparently there is a problem with usrp_benchmark_sub.py …
Some basic tests for USRP operation.
usrp_fft.py -d 8
usrp/host/apps/test_usrp_standard_rx
us
On Mon, Apr 26, 2010 at 8:57 PM, wrote:
> Thank you for you answer. Do you mean I can not achieve the goal by
> modifying its softare code beause of hardware restriction ? I have nothing to
> do except using more usrps?Thank you!
You cannot use two instances to tunnel.py to create two network
2010/4/26 lishan_wh :
> Hi all,
> I want to use tunnel.py to make a usrp with two daughter boards work as
> two pieces of wireless cards. The first time I run tunnel.py, it works well,
> and generate gr0. But when I run tunnel.py for the second time (in another
> terminal) to configure the other
On Sat, Apr 24, 2010 at 1:05 AM, Firas Abbas wrote:
>
> http://gnuradio.org/redmine/wiki/gnuradio/DevelopingWithGit
>
Perhaps I should rephrase my question. In git, I want to track
changesets between the current development tree and previous
*releases*.
It turns out to be a silly question becaus
Is it possible to find a git commit or svn revision number
corresponding to previous GNU Radio releases? I'm working with some
old driver code that was tested with release 3.1.3. The only tag I see
if for 3.3git. Thanks.
Thomas
___
Discuss-gnuradio ma
On Thu, Apr 22, 2010 at 4:38 PM, Yan Nie wrote:
> 2. How does the tune() function work? Does that tune the signal after ADC,
> by creating a analog daughterboard? or it tunes the signal on the LFRX
> daughterboard before ADC?
I looked at the source and found the following.
/*!
* \brief Hig
On Fri, Apr 9, 2010 at 4:21 AM, voipas wrote:
> Hello,
>
> Today the USRP stoped work at all. And we found the something wrong with
> power. Maybe due this issue, we had this problems.
That's unfortunate. If the USRP stopped working entirely, the fuse
(F501) may be blown. If you have an oscillo
On Wed, Apr 7, 2010 at 9:03 PM, voipas wrote:
> Hi,
>
> Any suggestions what's wrong could be here?
> Thanks
>
What's happening is that the kernel is throwing an EPROTO error on
certain control transfers. The error code passes through libusb and
the USRP driver simply reports the error. Unfortu
On Wed, Apr 7, 2010 at 8:03 AM, voipas wrote:
> Hello,
>
> I've problem with USRP. Since I've upgraded my Ubuntu to 9.0.4 - usrp
> doesn't work:
> /usr/local/share/gnuradio/examples/usrp/usrp_benchmark_usb.py
> Exception RuntimeError: 'maximum recursion depth exceeded while calling a
> Python ob
On Thu, Jan 21, 2010 at 12:43 PM, Ketan Mandke wrote:
> Hi all,
>
> I have been using an old version of the gnuradio trunk. I wanted to
> check out that old version again, but I noticed that the switch over
> to git has been completed and the subversion repository has been taken
> down. Although,
On Tue, Nov 24, 2009 at 10:32 AM, Philip Balister wrote:
> I running the latest gnuradio from git and see these messages when I run:
>
> usrper load_standard_bit
>
> [balis...@moose gnuradio]$ usrper load_standard_bits
> usrper: found unconfigured usrp; needs firmware.
> usb_control_msg failed: er
On Mon, Nov 2, 2009 at 4:35 PM, Alexander Chemeris
wrote:
>
> Thank you for information!
> I do hate this awkward heap, named git, so I'd better go with patches.
No problem. I'm quite fond of git, but that discussion is for another
time and place. To each their own.
> Hum, why branch GnuRadio if
On Sun, Nov 1, 2009 at 6:13 PM, Alexander Chemeris
wrote:
>
> Could any of GnuRadio developers remove this assert?
>
> usrp_standard.cc:1024: virtual bool usrp_standard_tx::set_tx_freq(int,
> double): Assertion `dac_rate () == 12800' failed.
>
> It's no longer valid when you reclock your USRP
On Tue, Oct 20, 2009 at 4:43 PM, George Lee wrote:
> When I tried to set the center frequency to 80M using Basic Tx board, the
> error message I got is as follows. I also tried some other frequency, from
> 70M - 84M , and had the same error. For most of the other frequency, it
> works fine. $ ./us
On Thu, Oct 8, 2009 at 5:19 PM, Jonathan P Jacky wrote:
>
> I am building from gnuradio-3.2.2.tar from Trac on an iMac9,1 with an
> Intel Core 2 Duo running Mac OS X 10.6.1 (Snow Leopard), XCode version
> 3.2, gcc version 4.2.1.
>
> I am following the directions at
> https://radioware.nd.edu/docum
On Mon, Sep 14, 2009 at 8:00 PM, Robert and Millie
wrote:
>
> python dial_tone.py
> Traceback (most recent call last):
> File "dial_tone.py", line 23, in
> from gnuradio import gr
> ImportError: No module named gnuradio
>
> This is where I am stuck. Any help would be gladly appreciated.
>
On Tue, Sep 29, 2009 at 9:26 PM, Mir M. Ali wrote:
> Hi,
> I have a package with a few gnuradio modules that I developed. This package
> installs wihtout a hitch on my laptop. I then copied the package folder on
> to two ohter computers but the installation always fails. When doing 'make'
> it giv
On Mon, Sep 28, 2009 at 1:50 PM, Bishal Thapa wrote:
> Dear Tim,
> First of all, thanks for your time answering my question. Secondly, one
> point you left out is: I am sending 104*128 bytes in reality, because I am
> spreading a packet of size 128 bytes with a 104 bits long spreading sequence
>
I pushed an update of the libusb-1.0 support patch to a public github
repository.
Public clone
git clone git://github.com/ttsou/gnuradio-libusb-1.0.git
Viewable at
http://github.com/ttsou/gnuradio-libusb-1.0
Libusb-1.0 is enabled with,
./configure --fusb-tech=libusb1
Why libusb-1.0?
The prio
Hi Steven,
> If I uncomment the sleep, I never see this message. So:
> Q1) Any idea what this error is all about? Is this a race condition that
> needs to be addressed, or am I doing something wrong?
This part I'm not sure about.
> Q2) The original audio file is 350.0KB. Sometimes the resulting
On 8/23/07, Jeffrey Karrels <[EMAIL PROTECTED]> wrote:
> Hello all
>
> i am looking at gmsk again. i had two questions come up.
>
> 1) does clock recovery normally take place after fm demod?
Sure.
> 2) what clock recovery algo would one normally find in a receiver like
> a GSM receiver?
M&M, Gar
In the clock recovery, the useful term in the output of the M&M error
detector becomes small for long sequences of identical symbols. This
affects the sampling instant, and I suspect is related to what you are
seeing. You can modify the gain_mu value to get these and similar
effects.
-TT
On 8/13/
1 - 100 of 101 matches
Mail list logo