Hi,
On 07/08/2017 07:11 PM, sumitstop wrote:
Wao superb! you cleaned it out also. Yes it works. Thanks much.
But did you figure out what was the issue at the first place :)
I'm not sure. Maybe it was related to one of the Packet Pad blocks.
Since you resampled, you also changed the length of
Wao superb! you cleaned it out also. Yes it works. Thanks much.
But did you figure out what was the issue at the first place :)
I have another related question about the wireshark connector in
transceiver_OQPSK.grc. I see that wireshark connector gets input from two
different outputs.
One fro
Hi,
On 07/06/2017 07:55 AM, sumitstop wrote:
Hello Bastian,
Sorry for late response.
I am attaching the files for your reference. There are 2 grc files
1. wifi_zigbee.grc : wifi and zigbee loopbacks are running in parallel >>
works good
2. wifi_zigbee_interference.grc : Here I interpolate the
Hello Bastian,
Sorry for late response.
I am attaching the files for your reference. There are 2 grc files
1. wifi_zigbee.grc : wifi and zigbee loopbacks are running in parallel >>
works good
2. wifi_zigbee_interference.grc : Here I interpolate the zigbee output by 5,
feed to channel, add to 2
Hi,
thanks for the detailed description. I’m not sure what the actual error is.
What do you mean with grc turns dark.
Does it crash or stop receiving or actually show a black window? Did grc turn
dark or the flow graph?
Best,
Bastian
> On 4. Jul 2017, at 22:10, sumitstop wrote:
>
> Hello,
Hello,
(Its a long post :) as I want to give as much details as possible)
Today I did a strange experiment. Under GNU Radio companion, I created a
blank project. Then I copy pasted the wifi_loopback.grc from gr-ieee 802.11
to my blank project and made it run. Off course I took care of the initial
ah sorry, that was confusing:
after SIGILL, please "continue", untill you get SIGSEGV, then type
"backtrace".
Best regards,
Marcus
On 01.02.2016 20:08, Gabriel Pechiarovich wrote:
> Hi, this is the full output:
>
>
> set_min_output_buffer on block 10 to 96000
> set_min_output_buffer on block 12 t
Hi, this is the full output:
set_min_output_buffer on block 10 to 96000
set_min_output_buffer on block 12 to 96000
set_min_output_buffer on block 14 to 96000
set_min_output_buffer on block 15 to 96000
set_min_output_buffer on block 18 to 96000
set_min_output_buffer on block 29 to 96000
[New Threa
Hi Gabriel,
that might actually be part of OpenSSL's CPU feature detection, be
caught and handled normally; maybe it's hiding another fault. I assume
when you type "continue" on the gdb prompt the program actually crashes
with SIGSEGV?
Best regards,
Marcus
On 01.02.2016 18:54, Gabriel Pechiarovi
Hi
I used the backtrace and got this:
(gdb) run wifi_loopback_ngui.py
Starting program: /usr/bin/python wifi_loopback_ngui.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
Program received signal SIGILL, Illegal instruction.
_armv7_tick ()
Hi,
> On 29 Jan 2016, at 10:16, Gabriel Pechiarovich wrote:
>
> Hi all, I just installed this module in my E310, to run the loopback in the
> E310 i modified the flow graph so it is no gui, but when i'm running in the
> E310 i got a segmentation fault and the program stops:
How did you insta
Hi all, I just installed this module in my E310, to run the loopback in the
E310 i modified the flow graph so it is no gui, but when i'm running in the
E310 i got a segmentation fault and the program stops:
root@ettus-e300:~/wifi-master# python wifi_loopback_ngui.py
linux; GNU C++ version 4.9.1; B
On 11/30/2015 08:39 PM, Neel Pandeya wrote:
Hello Kerry:
Perhaps your computer is behind a firewall or proxy server?? Many
companies and universities use them, and they often block these type
of downloads.
--Neel
Actually, looking at the message, it looks like an incompatibility
between wh
Hello Kerry:
Perhaps your computer is behind a firewall or proxy server?? Many companies
and universities use them, and they often block these type of downloads.
--Neel
On 30 November 2015 at 13:41, James Humphries
wrote:
> Hi Kerry,
>
> Did you hook your computer back up to the internet bef
Hi Kerry,
Did you hook your computer back up to the internet before you ran
uhd_images_downloader.py?
-Trip
On Mon, Nov 30, 2015 at 3:22 PM, kerry wrote:
> Hi,all:
>
> I try to run an example about gnu radio. The runtime errors are captured
> as:
>
> Using Volk machine: sse4_1_64_orc
> gr-osmo
Hi,all:
I try to run an example about gnu radio. The runtime errors are captured as:
Using Volk machine: sse4_1_64_orc
gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7.2
built-in source types: file fcd rtl rtl_tcp uhd bladerf rfspace
-- Opening a USRP2/N-Series device...
-- Current recv
Hi,
I did the following command, as suggested:
Patricks-iMac:work patrick$ sudo port select python python27
Selecting 'python27' for 'python' succeeded. 'python27' is now active.
Patricks-iMac:work patrick$ python if_else_mod.py
Fatal Python error: PyThreadState_Get: no current thread
Abort tra
Hi Patrick - You're on the right track. We're just following what is written
(roughly) in < http://gnuradio.org/redmine/projects/gnuradio/wiki/MacInstall >.
Please also note that unless you play some tricks with the +quartz variant that
is available many GR dependencies, you'll have to install X
Hey Michael, Hey Kevin, Hey all,
thanks for your help!
I found that by specifying the python version I want to use when running the
file, everything works fine. Like this:
python2.7 if_else_mod.py
This would be acceptable for me, however, I decided to do some of the stuff you
suggested. I get
Hi Patrick - So what's happening is that with GRC, because it was
installed via MacPorts the MP version of Python is used. The terminal
only knows what you tell it via environment variables such as PYTHONPATH
(already suggested by Kevin Hofschröer) and PATH. In your case right
now, I'll bet that th
Hi Patrick,
I think I might have the answer, although Michael Dickens could
certainly provide better explanations and all that.
You need to check your environment variables. You can do that in the
command line by typing "env".
Normally you should see something like
"
PYTHONPATH=/opt/local/Library
Hi everybody,
I installed GNURadio on a fresh machine with Mac OS X 10.10.5 via MacPorts. I
now have 2 Python installs in /usr/bin, python2.6 and python2.7. Running
flowgraphs with GRC is no problem. However, when trying to run a .py-file from
the terminal, as suggested in the guided tutorial 3
Hi Johannes,
THANKS a lot Yes you did really helped, as you said I was trying to
run the wrong .py!!! The example generates two .py on on the main
directory, as you said, and another on the ~/.grc_gnuradio. I had seen
somewhere that gnuradio companion generate code on the ~/.grc_gnuradio.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Daniel,
> OK I have a code, generated with Gnu radio companion that i want
> to run over the command line to follow with GDB. I was under the
> impression that if I simply got the code generated in the
> ~/.grc_gnuradio, add the
This folder usually
Hi people,
Sorry for the dummy question, but I didn't find a simple and direct
answer searching around for this. (Not need to say also that I am just
starting with GNU Radio... :)
OK I have a code, generated with Gnu radio companion that i want to run
over the command line to follow with GDB.
That fixed it! Thanks!!
2014-11-25 18:48 GMT+01:00 Marcus Müller :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Does increasing kernel.shmmni using sysctl to let's say 16k improve
> the situation?
>
> On 11/25/2014 06:37 PM, Marcus Müller wrote:
> > Hi Felix,
> >
> >
> > On 11/25/2014 06
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Does increasing kernel.shmmni using sysctl to let's say 16k improve
the situation?
On 11/25/2014 06:37 PM, Marcus Müller wrote:
> Hi Felix,
>
>
> On 11/25/2014 06:15 PM, Felix W. wrote:
>> Between every run, I call tb.stop() followed by tb.wait().
I built GR from source on the machine and the machine is running Ubuntu
14.04 64-bit. So I guess my GR is 64-bit, too.
Actually, while watching the simulation running at the moment, I noticed
that memory usage is indeed increasing slowly (but at a rate that wouldn't
fill up the system memory in da
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Felix,
On 11/25/2014 06:15 PM, Felix W. wrote:
> Between every run, I call tb.stop() followed by tb.wait().
> Unfortunately, after a few runs (around 20), I get the following
> error message:
>
> gr::vmcircbuf_sysv_shm: shmget (2): No space left
Hi list,
I'm currently performing BER measurements for an IEEE 802.15.4 system. In
order to do so, I have created a flowgraph (in GRC/python) that is executed
for different SNR values until a certain number of bits has been processed.
Between every run, I call tb.stop() followed by tb.wait(). Unfo
should I already have that installed due having installed gr-osmosdr or do I
need to get it from somewhere else?
I was thinkinkg of having a go with multimode.py as well, thats your piece of
work i think?
On Monday, 8 September 2014, 16:57, "mle...@ripnet.com"
wrote:
If you want to do
If you want to do the equivalent of uhd_fft for non-Ettus devices, just
use osmocom_fft
On 2014-09-08 11:52, Ben Hiett wrote:
> is it possible to run uhd_fft directly from the IQ data coming over usb from
> an rtlsdr stick?
> or is this only for use with an ettus usrp device?
>
> __
is it possible to run uhd_fft directly from the IQ data coming over usb from an
rtlsdr stick?
or is this only for use with an ettus usrp device?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnu
On 04/01/2014 11:29 PM, Rob Miller wrote:
> Is it possible to run more than one top_block at a time in gnuradio
> 3.7.x? I have an application where I wish to run an additional flow
> graph periodically. I have set up a thread that grabs samples via a
> probe from my main flow graph that is runni
Hi -
Is it possible to run more than one top_block at a time in gnuradio 3.7.x? I
have an application where I wish to run an additional flow graph periodically.
I have set up a thread that grabs samples via a probe from my main flow graph
that is running all of the time, and uses tha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Ruecan,
On 12.03.2014 22:52, Ruecan wrote:
> Hello GR,
>
> * Is there a way how to run my flowgraph for a given number of
> minutes/seconds then stop it.
Of course.
If what you really want to do is doing a certain number of samples,
the head bloc
Hello GR,
* Is there a way how to run my flowgraph for a given number of
minutes/seconds then stop it.
* I'd like to know too how to reconfigure my flowgraph (after I stop it from
runtime) and resume its run after I changed for example the signal source at
the begin of the flowgraph.
I tried:
M
On Mon, Mar 10, 2014 at 5:08 PM, Mike Harpe wrote:
> I have been working for a week or so on getting GNU Radio going on a Debian
> Linux platform running inside a VM.
>
> GNU Radio is compiled and runs fine. The VM sees my Funcube Pro+ dongle.
> Using 'plughw:0,0' got rid of the audio stuttering p
I have been working for a week or so on getting GNU Radio going on a Debian
Linux platform running inside a VM.
GNU Radio is compiled and runs fine. The VM sees my Funcube Pro+ dongle.
Using 'plughw:0,0' got rid of the audio stuttering problem. After
struggling with a couple of the demo flowgraphs
To put it in simple words, I am wondering why the GMSK-Mod blocks always
outputs 8192 bits - no matter when I input 50 bits or 255 bits.
Is there a GMSK-burst-like modulation happening?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https:
I trying to run a GMSK mod/demod test under GRC. My objective is to
create a single GSM-like burst and to store it in a file. The waveform
should have defined bits (by now I assume them to be random).
Thus I created a flowgraph that looks like this
Random Source (fixed # of samples, no repeat)
On Tue, Oct 16, 2012 at 6:34 PM, Tom Hendrick wrote:
> Hello,
>
> I have ubuntu 12.04 and GNURadio 3.6.2. I was trying to run some older
> scripts which uses the USRP. These scripts were made with GNURadio
> Companion about 3 years ago, and then I added some extra menu options by
> manually edit
Hello,
I have ubuntu 12.04 and GNURadio 3.6.2. I was trying to run some older scripts
which uses the USRP. These scripts were made with GNURadio Companion about 3
years ago, and then I added some extra menu options by manually editing the
python script made by GRC.
Unfortunately when I run t
On Tue, Mar 13, 2012 at 1:23 PM, Philip Balister wrote:
> On 03/13/2012 12:30 PM, Tom Rondeau wrote:
> > On Tue, Mar 13, 2012 at 10:26 AM, Philip Balister >wrote:
> >
> >> I am working on improving the wfm_tx transmitter for the e100 and am in
> >> the process of replacing calls to libm for sin/c
On 03/13/2012 12:30 PM, Tom Rondeau wrote:
> On Tue, Mar 13, 2012 at 10:26 AM, Philip Balister wrote:
>
>> I am working on improving the wfm_tx transmitter for the e100 and am in
>> the process of replacing calls to libm for sin/cos with the fixed point
>> (argument only) version already in gnurad
On Tue, Mar 13, 2012 at 10:26 AM, Philip Balister wrote:
> I am working on improving the wfm_tx transmitter for the e100 and am in
> the process of replacing calls to libm for sin/cos with the fixed point
> (argument only) version already in gnuradio.
>
> It does not look like the qa_code actually
I am working on improving the wfm_tx transmitter for the e100 and am in
the process of replacing calls to libm for sin/cos with the fixed point
(argument only) version already in gnuradio.
It does not look like the qa_code actually runs though (cmake build).
Any hints on getting the qa code to run
The XCVR2450 hardware is incapable of full-duplex operation. It *cannot*
transmit and receive at the same time.
Yes, you are right but consider we are transmitting ping requests just
for a very short moment (since they are also containing only 84 bytes)
with a frequency of 1 Hz. Hence, we are
The XCVR2450 hardware is incapable of full-duplex operation. It
*cannot* transmit and receive at the same time.
On Wed, 01 Feb 2012
18:05:53 +0100, Florian Schlembach wrote:
>>> We are now trying to
establish an TCP/IP connection between both USRP2s with the tunnel.py
script. Unfortunately,
We are now trying to establish an TCP/IP connection between both USRP2s
with the tunnel.py script.
Unfortunately, it says "Destination Host unreachable" when pinging the
other USRP. We should have set up the tunnel correct as some packets are
received and transmitted after having configured the IP
We are now trying to establish an TCP/IP connection between both USRP2s
with the tunnel.py script.
Unfortunately, it says "Destination Host unreachable" when pinging the
other USRP. We should have set up the tunnel correct as some packets are
received and transmitted after having configured the IP
On 01/31/2012 08:21 PM, Andrew Davis wrote:
That's kinda odd now that I think about it, I had a similar problem
and on an oscilloscope it looked like DAC clipping, but I could have
been non-linearity in the final amp, what kind of problems do
XCVR2450 have at high outputs?
All amplifiers will
That's kinda odd now that I think about it, I had a similar problem and on
an oscilloscope it looked like DAC clipping, but I could have been
non-linearity in the final amp, what kind of problems do XCVR2450 have at
high outputs?
On Tue, Jan 31, 2012 at 9:00 AM, Marcus D. Leech wrote:
> **
> On
On 01/31/2012 02:48 PM, Florian Schlembach wrote:
> Ok, that definitely makes sense if there is no error correction is
> implemented.
>
> We are now trying to establish an TCP/IP connection between both USRP2s
> with the tunnel.py script.
> Unfortunately, it says "Destination Host unreachable"
Ok, that definitely makes sense if there is no error correction is
implemented.
We are now trying to establish an TCP/IP connection between both USRP2s
with the tunnel.py script.
Unfortunately, it says "Destination Host unreachable" when pinging the
other USRP. We should have set up the tunnel
On 31/01/12 08:28 AM, Florian Schlembach wrote:
>> But fiddling with gain values is often useful; even if you've already
>> done that I recommend trying again, by reducing tx-amplitude and the
>> actual gain values, shifting the terminals around (perhaps they're too
>> close?).
>>
> We have no
On 31/01/12 08:37 AM, Andrew Davis wrote:
> >One thing that I noticed was that the --tx-amp=0.8. That's very high
> for OFDM with it's large PAPR.
>
> I'm thinking that too, there really should be some kind of warning
> when you drive the DAC to saturation.
It's not the DAC that's typically the pro
>One thing that I noticed was that the --tx-amp=0.8. That's very high for
OFDM with it's large PAPR.
I'm thinking that too, there really should be some kind of warning when you
drive the DAC to saturation.
If you need more range use an external amp.
On Tue, Jan 31, 2012 at 8:28 AM, Tom Rondeau
On Mon, Jan 30, 2012 at 11:12 AM, Martin Braun wrote:
> On Mon, Jan 30, 2012 at 04:11:05PM +0100, Florian Schlembach wrote:
> > We have now extended our tests to the tests with two USRP2s with
> > daughterboards: Neither the benchmark_tx.py example nor the tunnel.py is
> > receiving any packets.
On Tue, Jan 31, 2012 at 8:28 AM, Florian Schlembach <
florian.schlemb...@tu-ilmenau.de> wrote:
> > But fiddling with gain values is often useful; even if you've already
> > done that I recommend trying again, by reducing tx-amplitude and the
> > actual gain values, shifting the terminals around (p
> But fiddling with gain values is often useful; even if you've already
> done that I recommend trying again, by reducing tx-amplitude and the
> actual gain values, shifting the terminals around (perhaps they're too
> close?).
We have now found out that we need a sampling rate of at least 2Msps
wh
On Mon, Jan 30, 2012 at 04:11:05PM +0100, Florian Schlembach wrote:
> We have now extended our tests to the tests with two USRP2s with
> daughterboards: Neither the benchmark_tx.py example nor the tunnel.py is
> receiving any packets. We checked the spectrum and tuned the gains as well.
> (OFDM)
>
Hey guys,
we are trying to get run the tunnel.py / benchmark_rx.py (OFDM) in order to
measure the datarate between two USRP2 (located with distance of 1 m) with
daughterboards XCVR2450.
We are running the benchmark_tx/rx.py as follows:
benchmark_tx.py -f 2.4G --tx-gain=10 --tx-amplitude=0.8 -v
be
Fon -
Can you detail how you are combining them? If you are executing GNU Radio
stuff from the primary thread in your GUI application, it will stop
re-drawing the window (because the thread is busy executing GNU Radio).
Also, all GUI updates must happen from your main thread.
Cheers,
Ben
On Fr
Hi all,
I'm trying to create a GUI for my GNURadio program using python-gtk on a
USRP E100. I have GNURadio and pythong-gtk working separately. But now that
I'm combining them, the graphic windows goes blank and waits for the
GNURadio part to finish. Is there a better way to do this?
Thank you,
R
On Wed, Jul 27, 2011 at 4:16 PM, Thomas Tsou wrote:
> 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
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,
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, which is crazy high. Btw, I'm measuring the latency (approx)
I receive the following error when connecting to a ubuntu 10.10
platform from a debian lenny machine:
pwilliams@ubuntu:~/gnuradio_test$ ./top_block.py
linux; GNU C++ version 4.4.5; Boost_104200; UHD_003.000.001-release
Xlib: extension "RANDR" missing on display "localhost:10.0".
Segmentation f
I receive the following error when connecting to a ubuntu 10.10 platform
from a debian lenny machine:
pwilliams@ubuntu:~/gnuradio_test$ ./top_block.py
linux; GNU C++ version 4.4.5; Boost_104200; UHD_003.000.001-release
Xlib: extension "RANDR" missing on display "localhost:10.0".
Segmentation fau
On 04/04/2011 01:21 PM, Fon, Rithirong Thandee wrote:
Hello,
I'm trying to run a ucla zigbee phy code (
https://www.cgran.org/wiki/UCLAZigBee) with gr-uhd on the usrp e100. But I'm
getting an error
Traceback (most recent call last):
File "./cc2420_txtest_uhd.py", line 10, in
from gnura
Hello,
I'm trying to run a ucla zigbee phy code (
https://www.cgran.org/wiki/UCLAZigBee) with gr-uhd on the usrp e100. But I'm
getting an error
Traceback (most recent call last):
> File "./cc2420_txtest_uhd.py", line 10, in
> from gnuradio import uhd
> File "/usr/lib/python2.6/site-packa
On Mon, Aug 30, 2010 at 08:42:51PM -0400, Philip Balister wrote:
> I've got gnuradio cross compiled for the armv7 and have it NFS
> mounted on the target hw. Is there an easy way to test gnuradio by
> running applications out of the build tree?
Easy way? No.
> I know about running make check on
I've got gnuradio cross compiled for the armv7 and have it NFS mounted
on the target hw. Is there an easy way to test gnuradio by running
applications out of the build tree?
I know about running make check on the target, but I am interested in
testing more complex flowgraphs.
Philip
___
Of Tom Rondeau
> Sent: Thursday, 4 February 2010 11:56 PM
> To: bin zan
> Cc: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] running OFDM on USRP2
>
> On Wed, Feb 3, 2010 at 1:55 PM, bin zan wrote:
> > Hi Tom,
> > In our case, even with script from Veljko
u.org
[mailto:discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org] On
Behalf Of Tom Rondeau
Sent: Thursday, 4 February 2010 11:56 PM
To: bin zan
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] running OFDM on USRP2
On Wed, Feb 3, 2010 at 1:55 PM, bin zan wrote:
> Hi Tom,
> In our
On Mon, Feb 22, 2010 at 07:34:01AM -0600, Jason Uher wrote:
> On Mon, Feb 22, 2010 at 3:55 AM, amarnath alapati
> wrote:
> > hi everyone,
> > Is there any way for me to run the benchmark_tx and
> > benchmark_rx.py files in debugging mode so that I can see the entire flow
> > structure?
On Mon, Feb 22, 2010 at 3:55 AM, amarnath alapati
wrote:
> hi everyone,
> Is there any way for me to run the benchmark_tx and
> benchmark_rx.py files in debugging mode so that I can see the entire flow
> structure? I am curious to know the steps that take place from the calling
> of the
hi everyone,
Is there any way for me to run the benchmark_tx and
benchmark_rx.py files in debugging mode so that I can see the entire flow
structure? I am curious to know the steps that take place from the calling
of the python script to the point where the modulated symbols are
transmit
On Thu, Feb 04, 2010 at 07:25:47AM -0600, Tom Rondeau wrote:
> On Wed, Feb 3, 2010 at 1:55 PM, bin zan wrote:
> > Hi Tom,
> > In our case, even with script from Veljko, the OFDM receiver doesn't show
> > any thing. And we always see "usrp2: failed to enable realtime scheduling".
> > Do you think t
On Wed, Feb 3, 2010 at 1:55 PM, bin zan wrote:
> Hi Tom,
> In our case, even with script from Veljko, the OFDM receiver doesn't show
> any thing. And we always see "usrp2: failed to enable realtime scheduling".
> Do you think that will cause problem?
>
> Thanks,
> Bin
No, that message is just te
Hi Tom,
In our case, even with script from Veljko, the OFDM receiver doesn't show
any thing. And we always see "usrp2: failed to enable realtime scheduling".
Do you think that will cause problem?
Thanks,
Bin
On Wed, Feb 3, 2010 at 12:57 PM, Anupama Purohit
wrote:
> Hi Tom ,
> Thanks , we did try
Hi Tom ,
Thanks , we did try the updated script from Veljko . It works though we have
missing packets after a while ( as suggested in the forum we would play with
the interpolation and decimation ) though the 2 USRP2s are directly
connected .
We are still probing into the permissions issue as ind
On Wed, Jan 27, 2010 at 11:21 AM, bin zan wrote:
> Hello,
> I was trying to run following OFDM command on USRP2, however, I got a
> bunch of "Stime out" at the receiver side.
>
> ./benchmark_ofdm_tx.py -f 2.4G -i 512 --fft-length=64 --occupied-tones=32
> --cp-length=4
> ./benchmark_ofdm
On Tue, Feb 2, 2010 at 4:34 PM, Anu000 wrote:
>
> Hi,
> We did try the below command on two USRP2s coneected via a SMA Cable (Tx-Rx)
> with freq = 25M however it returned the following error on both sides
>
> At Rx side it shows like the below -
>
> [r...@gnuradio1 ofdm]# ./benchmark_ofdm_rx.py -
cessfully
> > running them for USRP2s.
> >
> > Ian.
> >
> >
> >
> > -Original Message-
> > From: discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org
> > [mailto:discuss-gnuradio-bounces+ian.holland
> =rlmgroup.com...@gnu.org
holland=rlmgroup.com...@gnu.org
> [mailto:discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org] On
> Behalf Of Anu000
> Sent: Wednesday, 3 February 2010 8:04 AM
> To: Discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] running OFDM on USRP2
>
>
> Hi,
> We did
> From: discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org
> [mailto:discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org] On
> Behalf Of Anu000
> Sent: Wednesday, 3 February 2010 8:04 AM
> To: Discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] running O
t: Re: [Discuss-gnuradio] running OFDM on USRP2
Hi,
We did try the below command on two USRP2s coneected via a SMA Cable
(Tx-Rx)
with freq = 25M however it returned the following error on both sides
At Rx side it shows like the below -
[r...@gnuradio1 ofdm]# ./benchmark_ofdm_rx.py -f 25M -d 256
--fft-l
Hi,
We did try the below command on two USRP2s coneected via a SMA Cable (Tx-Rx)
with freq = 25M however it returned the following error on both sides
At Rx side it shows like the below -
[r...@gnuradio1 ofdm]# ./benchmark_ofdm_rx.py -f 25M -d 256 --fft-length=64
--occupied-tones=32 --cp-lengt
Thanks Veljko, Did you do any modification on the gnuradio 3.2.2 code?
(Because at my side the interpolation/decimation was not the problem, I
forgot to change the value in the email)
Bin
On Wed, Jan 27, 2010 at 2:44 PM, Veljko Pejovic wrote:
> Hi,
>
> I have gnuradio 3.2.2 installed on Ubintu
Hi,
I have gnuradio 3.2.2 installed on Ubintu 9.10 and I'm using USRP2s
with XCVR2450 daughterboards.
I tried your example but I changed the interpolation to correspond to
the decimation at the receiver:
./benchmark_ofdm_tx.py -f 2.4G -i 256 --fft-length=64
--occupied-tones=32 --cp-length=4
./ben
Hello,
I was trying to run following OFDM command on USRP2, however, I got a
bunch of "Stime out" at the receiver side.
./benchmark_ofdm_tx.py -f 2.4G -i 512 --fft-length=64 --occupied-tones=32
--cp-length=4
./benchmark_ofdm_rx.py -f 2.4G -d 256 --fft-length=64 --occupied-tones=32
--cp-
Hey -
This is a strange thing that I've been facing. We recently purchased new
XCVR2450 daughterboards and wanted to test the ofdm benchmark code on it
(with default settings). Both the USRPs (USRP1), were almost next to each
other but yet, the receiver USRP does not show any packets being receive
Dear all,
I just installed gnuradio and a USRP. When running the python tests such
as the one bellow I am getting the following error message that seems to
do with some upgrade:
test_dft_synth.py usrp_tv_rcv.py
%: ~/gnuradio-3.1.3/gnuradio-examples/python/usrp$
./test_dft_analysis
On Fri, Nov 14, 2008 at 7:53 AM, Catalin Lacatus
<[EMAIL PROTECTED]> wrote:
> I attached the results of svn info for:
Thanks. While it looks like your repository is in order, the version
of the Python script you are running doesn't appear to match the
version of the USRP2 library that is actuall
Hello,
I attached the results of svn info for:
gnuradio
usrp2_wfm_rcv.py
usrp2_fft.py
The reversions are below.
gnuradio
Repository Root: http://gnuradio.org/svn
Repository UUID: 221aa14e-8319-0410-a670-987f0aec2ac5
Revision: 9900
Node Kind: directory
Schedule: normal
Last Changed Autho
On Thu, Nov 13, 2008 at 5:48 AM, Catalin LACATUS
<[EMAIL PROTECTED]> wrote:
> -I tried to run usrp2_wfm_rcv.py to test my USRP2 with a BasicRX board and I
> got the following error.
> ¨AttributeError: 'usrp2_source_32fc_sptr' object has no attribute
> 'adc_rate'¨
Could you please confirm which re
On Thu, 2008-11-13 at 10:12 -0500, Newman, Timothy wrote:
> For both those functions you need to pass in the variable you want
> assigned the value as an input parameter.
>
>
>
> Look at gnuradio/trunk/gr-usrp2/src/usrp2_source_base.cc for the
> function definitions of adc_rate and daughterboar
On Thu, 2008-11-13 at 08:48 -0500, Catalin LACATUS wrote:
> -I tried to run usrp2_wfm_rcv.py to test my USRP2 with a BasicRX board
> and I got the following error.
> ¨AttributeError: 'usrp2_source_32fc_sptr' object has no attribute
> 'adc_rate'¨
This likely a bug in the host driver for the USRP2;
1 - 100 of 124 matches
Mail list logo
