]
Sent: Wednesday, 18 August 2010 1:09 AM
To: Ian Holland
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Changing external reference frequency with
USRP2...
On 08/16/2010 09:22 PM, Ian Holland wrote:
Please disregard my last. I must have got something wrong in my
testing. It now
Hi All
Sorry - it turns out I was missing the Microblaze tools on the machine I used
to do the make.
I have since fixed the problem.
Ian.
From: Ian Holland
Sent: Monday, 16 August 2010 2:50 PM
To: 'discuss-gnuradio@gnu.org'
Subject: Unable to build firmware
Regards
Ian.
-Original Message-
From: Matt Ettus [mailto:m...@ettus.com]
Sent: Saturday, 14 August 2010 2:15 AM
To: Ian Holland
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Changing external reference frequency with
USRP2...
gnuradio/usrp2/firmware/lib/clocks.c, starting
...@ettus.com]
Sent: Tuesday, 17 August 2010 2:15 AM
To: Ian Holland
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Changing external reference frequency with
USRP2...
On 08/16/2010 12:21 AM, Ian Holland wrote:
Thanks Matt
I tried to change to get the external reference frequency
.
-Original Message-
From: Ian Holland
Sent: Tuesday, 17 August 2010 9:24 AM
To: 'Matt Ettus'
Cc: discuss-gnuradio@gnu.org
Subject: RE: [Discuss-gnuradio] Changing external reference frequency with
USRP2...
Hi Matt
I will try this, though given P = 2, I was under the impression the resulting
VCO
samples later.
Is this expected when using a reference different to 10 MHz? When I have used
two USRP2s both locked to a 10 MHz reference, I never saw this problem.
-Original Message-
From: Ian Holland
Sent: Tuesday, 17 August 2010 11:33 AM
To: Ian Holland; Matt Ettus
Cc: discuss-gnuradio
Hi
I have recently made some changes to the usrp2 firmware, and tried to build
according to USRP2 User FAQ.
As far as I could tell from the aforementioned FAQ, this should have resulted
in a file txrx.bin being created, that I can download to the SD card for the
USRP2.
However, in the first
Hi
I have read on the FAQ that is possible to change the external reference
frequency for the USRP2 from 10 MHz to another value simply by changing one
line in the firmware.
However, I have as yet been unable to locate the actual source file in which I
need to make this change, and what the
...@gnu.org
[mailto:discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org] On
Behalf Of Ian Holland
Sent: Tuesday, 11 May 2010 11:14 AM
To: Eric Blossom
Cc: discuss-gnuradio@gnu.org
Subject: RE: [Discuss-gnuradio] Unexplained out-of-sequence packets...
Thanks Eric
I checked the power management
version thereof) for the time
being, after formatting the hard drive, and am hoping it will work on
this PC afterwards.
Cheers
Ian.
-Original Message-
From: Eric Blossom [mailto:e...@comsec.com]
Sent: Thursday, 13 May 2010 4:07 AM
To: Ian Holland
Cc: discuss-gnuradio@gnu.org
Subject: Re
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,
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)
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
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
-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org] On
Behalf Of Matt Ettus
Sent: Thursday, 22 April 2010 4:15 PM
To: Ian Holland
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Large number of overflows...
On 04/11/2010 09:22 PM, Ian Holland wrote:
Hi All
I am trying a modified
Thanks Marcus
Actually, the only filtering I did in the C++ version is for the MM
clock recovery, i.e. in interpolating to get the symbols based on
imperfectly timed samples. In the GRC example, I also had an RRC filter,
with 11*samples_per_symbol taps, but this didn't appear to be the
Hi Matt
Yes, -9 dBm is safe.
Glad to know it was all safe re input levels.
I have not seen the problem locking without trying a lower frequency.
What if you try 5 GHz twice in a row?
The problem with the not locking to 5G is very intermittent. A few times
when it did occur, I tried your
. Anyway, your
response has cleared things up for me.
Best Regards
Ian.
-Original Message-
From: Johnathan Corgan [mailto:jcor...@corganenterprises.com]
Sent: Tuesday, 13 April 2010 4:36 PM
To: Ian Holland
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Why no phase ambiguity
Thanks, I wasn't 100% clear if there were some conditions for interchangability
after Jonathon's reply, but it sounds like not.
Cheers
Ian.
-Original Message-
From: discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org
To: Ian Holland
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] IQ imbalance...
As long as the input level is in the safe range, having too much gain
would probably not damage anything. On the WBX, however, too much gain
with a strong but normally safe level might be a problem.
Matt
Hi Umair
I believe the decimation factor you have chosen is beyond the maximum
allowed (I think, from memory this is 512, which is well less than 1M =
1 times 10^6).
It seems you are trying to sample the passband signal to show a spectrum
at 1 GHz, however a digital-down conversion is performed
To: Ian Holland
Subject: RE: [Discuss-gnuradio] Spectrum at 1 GHz
So If I need to see in the baseband region then what should be the
parameters of USRP2 source for my case (i.e. Decimation and Frequency).
Should I give 1 GHz in the frequency parameter or in the baseband
region?
Thanks for help
Hi All
I have been studying up on the Costas loop, and have a couple of queries as to
the benchmark_tx.py and benchmark_rx.py as a result.
Firstly, for BPSK, there should in theory be a 180 deg. phase ambiguity when
using a Costas loop. Why does this not seem to occur with the benchmark_rx.py
...@ettus.com]
Sent: Friday, 9 April 2010 11:37 PM
To: Ian Holland
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] IQ imbalance...
On 04/08/2010 09:16 PM, Ian Holland wrote:
Hi All
I am using a pair of USRP2s, each equipped with a XCVR2450, for
transmission over-the-air of an RRC-filtered
Hi All
I am trying a modified example of the digital-bert routines, for
communication between 2 USRP2s, and notice that I am getting a very
large number of overflows () even with decimation rate at the
receiver of 20, and 4 samples per symbol (sometimes even with 20
samples/symbol). If I
Hi All
I am using a pair of USRP2s, each equipped with a XCVR2450, for transmission
over-the-air of an RRC-filtered BPSK signal. The Tx antenna has 3dBi gain, and
the Rx antenna has 18 dBi gain. The transmitted signal is at maximum amplitude,
with gain set to 30 dB. The clocks on each end of
Not sure if this got through the first time, as I never received it
myself. Apologies if this is a double post.
-Original Message-
From: Ian Holland
Sent: Wednesday, 7 April 2010 1:51 PM
To: discuss-gnuradio@gnu.org
Subject: Question regarding gr_mpsk_receiver_cc::mm_error_tracking
Hi
Hi All
I am trying to understand how the optimised modified Mueller and Muller
algorithm is implemented in GNU Radio.
I had a look at the method gr_mpsk_reciever_cc::mm_error_tracking, to
see how this is done. As far as I can tell, lines 242-245 are intended
to implement equation (8) of the
I have been inactive on this for some time due to other issues with my
USRP2s. However, I have been able to look into this again now, with
Veljko's modified code. I run as root, and also had the realtime
scheduling enabled, however on the receive side I see nothing until the
transmitter stops
Hi All
Does anybody have information on what the receiver sensitivity or noise
floor is for the XCVR2450 boards with a USRP2. I need to know at what
level a spurious signal from another source could cause noticeable
interference to a desired signal.
Regards
Ian.
Hi Matt
Apologies is you got a similar reply about 10 minutes ago, but the webmail
logged me out whilst I was trying to send it and it didn't appear in my sent
items when I logged back in.
You should know that we only spec the boards from 2.4 to 2.5 GHz and 4.9
to 5.9 GHz. When we test XCVRs
Hi Matt
I have completed the probing as you suggested. The results are in the
following table. Please note that the voltages did not seem to be stable
when I tried reprobing in some cases. An example of this is for R45,
where I give two sets of results for Combo D. Also, please note the
following
Hi Matt
Additional to below:
I tried to resume normal testing with A as Rx and D as Tx. Now, it seems
I have an offset of about 2 MHz using internal clocks and running
usrp2_fft.py on A, when I transmit a BPSK signal from D. Moreover, I am
unable to tune D for the low (2.4 GHz) band anymore. In
Hi Matt
Additional to below:
I tried to resume normal testing with A as Rx and D as Tx. Now, it seems
I have an offset of about 2 MHz using internal clocks and running
usrp2_fft.py on A, when I transmit a BPSK signal from D. Moreover, I am
unable to tune D for the low (2.4 GHz) band anymore. In
On 02/01/2010 06:08 PM, Ian Holland wrote:
Thanks Josh
I can now confirm that it is definitely failing to lock. I have
noticed
on some rare occasions that it actually does lock. However, as soon as
the USRP2 is power-cycled it goes back to the default behaviour of
being
unable to lock
Hi Matt
Are you able to also comment on the problem that I am having? (Summary
below):
- 1 of our 2 XCVR2450s works with both of our USRP2s.
- The other XCVR2450 works with only one of our USRP2s (i.e., it fails
to lock over the full high band and low band on the second USRP2).
Thanks
Ian.
Ian Holland would like to recall the message, [Discuss-gnuradio] Unable to
tune Tx or Rx with XCVR2450 on USRP2.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
.
-Original Message-
From: Matt Ettus [mailto:m...@ettus.com]
Sent: Thursday, 4 February 2010 4:24 PM
To: Ian Holland
Cc: j...@ettus.com; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on
USRP2
Ian,
When you said it fails to lock over the full
Hi Anupama
Unfortunately, I can't offer a solution at this stage. However, I had
similar error messages a few days ago. I thought perhaps these python
scripts were to be used exclusively for the original USRPs, though I
think in one or two posts I have seen, people mentioned successfully
running
and if
it looks like OFDM.
cheers,
veljko
2010/2/2 Ian Holland ian.holl...@rlmgroup.com.au:
Hi Anupama
Unfortunately, I can't offer a solution at this stage. However, I had
similar error messages a few days ago. I thought perhaps these python
scripts were to be used exclusively for the original
/db_xcvr2450.c
Add some printfs to the xcvr2450_set_freq function and try to raise the
value of N_DIV_MIN_Q16 and see if you can get it to lock.
I hope that helps,
-Josh
On 02/01/2010 06:08 PM, Ian Holland wrote:
Thanks Josh
I can now confirm that it is definitely failing to lock. I have
]
Sent: Wednesday, 3 February 2010 10:54 AM
To: Ian Holland
Cc: j...@ettus.com; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on
USRP2
Hi,
The problem I guess is with the SD cards only. Even I was facing the
same problem. But today I tried
.
Actually we had got around 20 USRP's/daughterboards from Ettus and none of
them were working with the SD cards they supplied with them (20 in all).
When I tried with an older SD card, it worked.
On Tue, Feb 2, 2010 at 5:43 PM, Ian Holland ian.holl...@rlmgroup.com.au
wrote
://gnuradio.org/redmine/repositories/entry/gnuradio/usrp2/firmware/
lib/db_xcvr2450.c
Add some printfs to the xcvr2450_set_freq function and try to raise the
value of N_DIV_MIN_Q16 and see if you can get it to lock.
I hope that helps,
-Josh
On 02/01/2010 06:08 PM, Ian Holland wrote:
Thanks Josh
I can
. attach a 3.3v level serial port
On 01/28/2010 10:09 PM, Ian Holland wrote:
Hi Josh
The xcvr has a high band and a low band, which means there is a gap
in
the tunable frequency range for the xcvr. Therefore, the
auto-calculated mid-point frequency is an invalid frequency for the
xcvr. Pick
.
From: Manav Seth [mailto:smartyma...@gmail.com]
Sent: Friday, 29 January 2010 6:11 PM
To: Ian Holland
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on
USRP2
Hey Ian,
How did the problem get fixed? I mean what frequency you
On Wed, Jan 27, 2010 at 8:52 PM, Ian Holland
ian.holl...@rlmgroup.com.au wrote:
Hi All
I have been trying to set the Tx and Rx frequencies when using an
XCVR2450 with a USRP2, but it seems these keep failing. A snippet of my
source code is below for setting the Tx frequency.
The output
]
Sent: Friday, 29 January 2010 12:35 PM
To: Manav Seth
Cc: Ian Holland; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on
USRP2
The -f argument to usrp2_fft.py is the frequency. By putting -f 1000
you are telling the system to try to tune
.
(...etc...)
Your firmware and fpga images on the sd card are probably out of sync.
You can find images here: http://gnuradio.org/releases/usrp2-bin/trunk/
and here are instructions on how to burn:
http://gnuradio.org/redmine/wiki/gnuradio/USRP2UserFAQ
-Josh
On 01/28/2010 06:14 PM, Ian Holland
Hi Josh
The xcvr has a high band and a low band, which means there is a gap in
the tunable frequency range for the xcvr. Therefore, the
auto-calculated mid-point frequency is an invalid frequency for the
xcvr. Pick a frequency in the high band or low band range:
#define LB_FREQ_MIN
Hi All
I have been trying to set the Tx and Rx frequencies when using an
XCVR2450 with a USRP2, but it seems these keep failing. A snippet of my
source code is below for setting the Tx frequency.
The output of this portion of code is Failed to tune Tx, and the
frequencies are all 0, with
51 matches
Mail list logo
