Hi Vidyadhar,
You need to burn the fpga image on to the usrp 2. You
can either run the command given above or go to
cd /usr/local/share/uhd/utils from your home folder and then open
usrp_n2xx_net_burner_gui.py and then run in terminal. Then you get a gui
with two fields
200: import scipy
200: ImportError: No module named scipy
1/1 Test #200: qa_ofdm_txrx .***Failed0.42 sec
Wouldnt worry about it. I wonder if scipy is an intentional dependency
for the QA test though?
0% tests passed, 1 tests failed out of 1
Total Test time
Hi,
Mainly used for HAM purposes, no need for it anymore.
For sale :
- USRP1
- WBX Board
- LFRX Board
Total New Price is $1550
Selling for $1350 via Paypal or banktransfer, (ex registered shipping)
Jasper Kanbier
Unix Beheer
BVS
ICT Shared Service Centre
Universiteit
On Mon, Jun 3, 2013 at 2:51 AM, Josh Blum j...@joshknows.com wrote:
200: import scipy
200: ImportError: No module named scipy
1/1 Test #200: qa_ofdm_txrx .***Failed0.42 sec
Wouldnt worry about it. I wonder if scipy is an intentional dependency
for the QA
I Checked the levels with the clock connected to the USRP ( and without)
The levels are fine ( about 600 mV rms on the scope)
additionally, I disconnected it from the load (USRP) to see if the level
changed. and they did (proving the cables are connected to a load).
the problem remains,
is there
I Checked the levels with the clock connected to the USRP ( and without)
The levels are fine ( about 600 mV rms on the scope)
additionally, I disconnected it from the load (USRP) to see if the
level changed. and they did (proving the cables are connected to a load).
the problem remains,
is
Hello all, one more introduction
I am also a GSoC participant this summer. I'm a first year aerospace
engineering graduate student at the University of Texas at Arlington. My area
of research is satellite communication links, which is what lead me to GNU
Radio.
Manu and I both wrote
Hi all guys (yet again),
I have a question about calibrating received power level of my USRP,
equipped with wbx, lftx and lfrx.
I am not sure whether it is apropriate to discuss that here.
Basically I would like to be able to determine absolute power level I am
receiving. I suppose that basic
Indeed, the only way to do this is to use a signal generator with known power levels, and precision attenuators. You'll have to repeat the process over the full tuning range of the device(s) in question, sinceeffective gain will change a little with tuned frequency--that's just a natural property
Thank you Marcus for super fast answer. Well, for the begining I would like
to skip temperature calibration, only power level calibration regarding
frequency. I have following doubts:
1. To which frequency should be tuned USRP if for example generator
generates 400 MHz. Should it be almost the
Hello all,
This will be an exciting summer for GNU Radio and FPGA development. My GSoC
project aims to add FPGA acceleration to GNU Radio with Xilinx's Zynq FPGA.
My git repo (with my proposal) is at:
https://github.com/jpendlum/GnuRadio_Zynq
https://github.com/jpendlum/GnuRadio_Zynq . I will
I have testers that might not see the graphical version of the flowgraph they
are testing. To them, they run the flowgraph on the command line, passing in
various parameter values using the Short IDs set up in the original flowgraph
and built by GRC for the target.
Is there a way, for example,
Dear list,
Now I meet a problem about counting all the input samples. I hope I can get
some assistant from here. The problems are as follows,
In one of my blocks, I want to count all the consumed input samples to get the
timestamp of the received packet. I have used GPS to synchronize two usrps
On 06/03/2013 01:10 PM, ÀîÔÞ wrote:
Dear list, Now I meet a problem about counting all the input samples.
I hope I can get some assistant from here. The problems are as
follows, In one of my blocks, I want to count all the consumed input
samples to get the timestamp of the received packet. I
Hi.
Decided to refresh my system, started clean with Ubuntu 12.04 LTS 64 bits
on an I3 system.
Had to re-install Gnuradio and noticed that the build-gnuradio script
failed install. Then I noticed the remarks from Marcus that only the newest
version would install but I was running a one week old
On 06/03/2013 12:26 PM, Monahan-Mitchell, Tim wrote:
I have testers that might not see the graphical version of the
flowgraph they are testing. To them, they run the flowgraph on the
command line, passing in various parameter values using the Short IDs
set up in the original flowgraph and
How old is your build-gnuradio?
A fix went in for osmosdr sometime last week--Thursday night.
on Jun 03, 2013, Ben Z eigen...@binik.nl wrote:
Hi.
Decided to refresh my system, started clean with Ubuntu 12.04 LTS 64 bits on an I3 system.
Had to re-install Gnuradio and noticed that the
LED E is always on, even when I disconnect the external source
I used this command on the Tx:
uhd.tune_request(91500)
and this command on the Rx:
uhd.tune_request(91500,10e6)
the freq is now very stable
but there is a constant shift of 570 Hz between Rx and Tx
another strange thing
On 06/03/2013 12:26 PM, Monahan-Mitchell, Tim wrote:
I have testers that might not see the graphical version of the
flowgraph they are testing. To them, they run the flowgraph on the
command line, passing in various parameter values using the Short IDs
set up in the original flowgraph and
Tune request is independant of external clocking--that's an orthogonal property of an instantiated device object.
On TX the LO will be tuned to whatever you've set as the LO offset, so any LO leakage will appear there, but your signal will be where it's supposed to be.
570hz/915e6Hz is a residual
I started to work on making the TDMA work on two B100s with WBX I have.
I have them connected to a common 1 pps (rubidium based clock refrance) and
10MHz clock
the computer I am working in is a bit old, dell latitude 620, with ubuntu
12.04 LTS
I have all the latest software installed
the simple
Guy,
Thanks for trying out pre-cog. I am glad you got it working, despite the
poor documentation. Its worth mentioning that there's an effort to
incorporate some of the functionality of pre-cog into gnuradio.
sample rate is set to 256000, any other value didn't work, but
What does it mean
The above text would be entered someplace on the flowgraph in GRC,
like maybe the description field in the Options block. Then output of
that text to stdout is triggered by a selectable Short ID from a
parameter block on the flowgraph, or maybe is always hard coded to an
option like --help?
Hi Guys!
I am trying to develop a half duplex application with N210 and SBX
daughterboard with the latest (git head) gnuradio that needs precise
TX/RX switching times (like in TDMA) in the order of a few samples
(nanoseconds). I have played with the tx_time, tx_sob, tx_eob tags and
they do not
Hi All,
My F17 started to cry Disk failure is imminent. Please backup your disk
and have it replaced!, done!
It still boots, kernel 3.8.13-100.fc17.x86_64, but I can hear hd probs
(seeking).
My question is, after fetching a new HD, should I update to F18 or stay
at 17?
I've tried earlier GR
If you choose TX/RX as both your transmit and receive antenna, the FPGA
will switch between TX and RX automatically. It'll switch to TX when it
receives samples to send.
-John
On Mon, Jun 3, 2013 at 3:33 PM, Miklos Maroti mmar...@gmail.com wrote:
Hi Guys!
I am trying to develop a half
Hi Guys!
I am trying to develop a half duplex application with N210 and SBX
daughterboard with the latest (git head) gnuradio that needs precise
TX/RX switching times (like in TDMA) in the order of a few samples
(nanoseconds). I have played with the tx_time, tx_sob, tx_eob tags and
they do not
Hi John,
Thanks for you quick reply, but you did not answer any of my
questions. Will the FPGA switch from TX to RX when it has already
received from the host a UDP packet with a timestamp tag (tx_time)
that is in the future? Also, when exactly will the RX to TX switch
occur?
Miklos
On Mon, Jun
Hello,
We are working on our senior design project using gnuradio and USRP N210. We
are connecting two USRP's together through a coax cable with a 30 dB attenuator
and each USRP is connected to a host computer via a gigabit ethernet
connection.
Right now we are trying to modulate and
Hi Marcus,
Thanks for the quick comments. Yes, I totally agree that using full
duplex with RX2 and TX/RX would be the ideal way to go, and as you say
I can easily ignore and synchronize with my own transmissions. The
problem is that I am required to use a single antenna, so I have to do
a half
Hi Marcus,
Thanks for the quick comments. Yes, I totally agree that using full
duplex with RX2 and TX/RX would be the ideal way to go, and as you say
I can easily ignore and synchronize with my own transmissions. The
problem is that I am required to use a single antenna, so I have to do
a half
Hi All,
I would like to try some experiments with gnuradio using the Jack Audio
Connection Kit as the input source. Following a note from 2009 that
Eric made, I put did the following:
Much easier to just edit ~/.gnuradio/config.conf
Add these three lines to the file:
[audio]
verbose =
Hi Marcus,
Thanks for the quick comments. Yes, I totally agree that using full
duplex with RX2 and TX/RX would be the ideal way to go, and as you say
I can easily ignore and synchronize with my own transmissions. The
problem is that I am required to use a single antenna, so I have to do
a half
You see L because you are sending your bursts far enough advance
should have read:
aren't sending your bursts far enough in advance
On Mon, Jun 3, 2013 at 5:59 PM, John Malsbury john.malsb...@ettus.comwrote:
It'll switch to TX when it receives samples to send.
There may be some small
It'll switch to TX when it receives samples to send.
There may be some small [intentional] delays, but the FPGA will switch to
Tx on the first sample to be sent. Josh can specify the timing in more
detail.
You see L because you are sending your bursts far enough advance. In my
applications,
Hi John,
On Mon, Jun 3, 2013 at 8:00 PM, John Malsbury john.malsb...@ettus.com wrote:
You see L because you are sending your bursts far enough advance
should have read:
aren't sending your bursts far enough in advance
On Mon, Jun 3, 2013 at 5:59 PM, John Malsbury john.malsb...@ettus.com
You say that it switch from TX to RX if the next timestamp is in the
future and switch from RX to TX just when the timestamp is triggered.
You see L because you are sending your bursts far enough advance. In my
applications, the bursts are sent to the USRP about ~5ms before the actual
Wont switch until txtime occurs. Sorry.
John
On Jun 3, 2013 6:10 PM, Miklos Maroti mmar...@gmail.com wrote:
Hi John,
On Mon, Jun 3, 2013 at 8:00 PM, John Malsbury john.malsb...@ettus.com
wrote:
You see L because you are sending your bursts far enough advance
should have read:
Hi Marcus,
On Mon, Jun 3, 2013 at 8:15 PM, Marcus D. Leech mle...@ripnet.com wrote:
You say that it switch from TX to RX if the next timestamp is in the
future and switch from RX to TX just when the timestamp is triggered.
You see L because you are sending your bursts far enough advance. In
Hi Ian,
Wow, thanks for the technical explanation! That makes a whole lot of
sense (see below for further questions).
On Mon, Jun 3, 2013 at 8:19 PM, Ian Buckley i...@ianbuckley.net wrote:
Miklos,
Here's a little bit more information about how the half-duplex operation
works from the H/W
Hi Marcus,
On Mon, Jun 3, 2013 at 9:20 PM, Marcus Leech mle...@ripnet.com wrote:
The 1PPS is used only to latch-in a time-of-day update from the host--it is
used when doing time synchronization across multiple devices, and in fact is
critical for that function to work correctly.
The problem
Hi all,
I'm working on a OOT module and created a hierarchical block in GRC. I
wonder if there is a nice way to include it in the installation process.
Currently, the user would have to open the hier block in GRC, build it,
restart GRC and open the actual flow graph that is utilizing the
42 matches
Mail list logo
