Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: WiMAX scanner (Mike McLernon)
2. Re: problem with USRP example on X310 with CBX-120 (Jim Hunziker)
3. Re: uhd_cal_tx_iq_balance skips wide frequency range
(Urban Hakansson)
4. Re: uhd_cal_tx_iq_balance skips wide frequency range
(Marcus D. Leech)
5. Re: Storing signals with full bandwidth of USRP x300/x310
(Robert Kossler)
6. Re: uhd_cal_tx_iq_balance skips wide frequency range
(Michael West)
7. Re: uhd_cal_tx_iq_balance skips wide frequency range
(Urban Hakansson)
8. Re: uhd_cal_tx_iq_balance skips wide frequency range
(Michael West)
9. Full Duplex vs. Half Duplex operation? (Radio User)
10. Re: Full Duplex vs. Half Duplex operation? (Ian Buckley)
11. Re: Full Duplex vs. Half Duplex operation? (Radio User)
12. Re: Full Duplex vs. Half Duplex operation? (Ian Buckley)
13. X310 MTU frame size issue (Louis Brown)
14. Re: X310 MTU frame size issue (Michael West)
15. Re: X310 MTU frame size issue (Louis Brown)
----------------------------------------------------------------------
Message: 1
Date: Thu, 23 Oct 2014 16:13:19 +0000
From: Mike McLernon <[email protected]>
To: Sebastian Komorowski <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] WiMAX scanner
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Sebastian,
If you want to use MATLAB/Simulink to import the data, you can download the
hardware support package described
here<http://www.mathworks.com/hardware-support/usrp.html>. The Communications
System Toolbox contains a Simulink-based WiMAX PHY simulation, described
here<http://www.mathworks.com/help/comm/examples/ieee-802-16-2009-wirelessman-ofdma-phy-downlink-pusc.html?prodcode=CM&language=en>.
Also, the MATLAB File Exchange lists a MATLAB-based WiMAX simulation
here<http://www.mathworks.com/matlabcentral/fileexchange/24369-wimax-physical-layer-simulation>.
Hth,
Mike
-----Original Message-----
From: Sebastian Komorowski [mailto:[email protected]]
Sent: Wednesday, October 22, 2014 3:48 PM
To: Mike McLernon
Subject: RE: [USRP-users] WiMAX scanner
It's no matter.
Regards
Sebastian
Dnia 22 pa?dziernika 2014 21:25 Mike McLernon
<[email protected]<mailto:[email protected]>> napisa?(a):
> Hi Sebastian,
>
> What do you want to use to get the data into MATLAB? GNU Radio, GNU Radio
> Companion, MATLAB, Simulink?
>
> Best,
> Mike
>
>
> -----Original Message-----
> From: USRP-users [mailto:[email protected]] On Behalf Of
> Sebastian Komorowski via USRP-users
> Sent: Wednesday, October 22, 2014 2:54 AM
> To: [email protected]<mailto:[email protected]>
> Subject: [USRP-users] WiMAX scanner
>
> Hello,
>
>
> I am interested in WiMAX technology (802.16e). In my research I am dealing
> with algorithms for admission control in Matlab. Typically these algorithms
> are located ?within base station? ? although they are not standardized by any
> organization. In simulations it is simple to ?deploy them? as they are
> located inside BTS source code.
>
>
> As regards verification and validation of such algorithms I am currently
> using well known simulator which is ns2 ? i.e. well known to the research
> community. It is clear however that ?simulations vs reality? is not always
> very close?. That is why I am interested in collecting data from real network
> in a vendor agnostic way (in general from any network i.e.
> build upon BTSes delivered by any vendor) ? it means that I would like to
> ?observe? traffic intensity/duration/etc directly from the radio. I am using
> PureWave 6600 at university premises.
>
>
> The input data for the algorithms I am interested in is the wireless
> connection characteristics e.g.: connection requests, time of connection,
> type of traffic, connection close, etc.
>
> Unfortunately to my knowledge there is no one-fits-all (or virtually any)
> solution to communicate with inside components of a BTS in an automated
> manner (i.e. from within a software program that is learning for best policy
> etc).
>
>
> That is why I have started to think about using USRP (or its brother from NI
> / or any other SDR) to play a role of passive probe for WiMAX wireless
> signalling. I have seen that there is a ?wimax scanner? project but it seems
> unfinished (or would it actually be operational in the area I mention?).
> Please let me know:
>
> 1. Is it possible to use ?wimax scanner? with USRP right away
> (i.e. without much effort spent on programming)?
>
> 2. Is wimax scanner full featured solution? (i.e. what can I do with
> it)
>
> 3. What statistics I could capture with it?
>
> 4. What limitations does it has?
>
> 5. Are there any plans for continuing its development?
>
> 6. Do you know if there is already happening an approach to develop
> complete WiMAX stack as there is for GSM ? OpenBTS??
>
>
>
> Thank you for the assessment of my question or any hints.
>
>
>
> Best,
>
> Sebastian
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]<mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141023/173b55ca/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 23 Oct 2014 13:40:06 -0400
From: Jim Hunziker <[email protected]>
To: usrp-users <[email protected]>
Subject: Re: [USRP-users] problem with USRP example on X310 with
CBX-120
Message-ID:
<CAGH06JtDskfnMb=HjUp5ZTdwM8tt6-izk2=wbjuoi9hvaty...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Marcus Leech responded to me off-list that I was using gain settings that
were too low. Setting them to 10 greatly improved my signal, though there's
still a carrier component that's bigger than my signal and not getting
removed. A colleague tells me he's working with Ettus regarding this
problem.
--
Jim Hunziker
BCI Systems and Software Engineering
(973) 348-9299
[email protected]
On Wed, Oct 22, 2014 at 4:42 PM, Jim Hunziker <[email protected]>
wrote:
> It looks like some of my problem was plotting abs(sig_c) rather than
> real(sig_c), but the signal still doesn't look great.
>
>
> --
> Jim Hunziker
> BCI Systems and Software Engineering
> (973) 348-9299
> [email protected]
>
> On Wed, Oct 22, 2014 at 12:15 PM, Jim Hunziker <[email protected]>
> wrote:
>
>> Hi. I have an X310 with a CBX-120 and a GPSDO, and I'm running the
>> txrx_loopback_to_file example with UHD version 3.7.3 like this:
>>
>> ./txrx_loopback_to_file --tx-args addr=10.10.10.90 --nsamps=250000
>> --tx-rate 2500000 --rx-rate 2500000 --tx-freq 56000000
>> 00 --rx-freq 5600000000 --rx-ant CAL --wave-type SINE --ref internal
>> --wave-freq 1000
>>
>> (It makes no difference if I use the RX2 antenna and a loopback cable.)
>>
>> With a sampling rate of 2.5 MHz and a sine wave of 1 KHz, I expect to see
>> a sinusoidal cycle every 2500 samples. I'm plotting them with GNU Octave
>> and the following commands:
>>
>> fid = fopen("~/uhd/host/build/examples/usrp_samples.dat", "rb");
>> [sig, count] = fread(fid, Inf, "int16");
>> sig_c = sig(1:2:end) + j * sig(2:2:end);
>> plot(abs(sig_c));
>>
>> The signal seems very noisy, and it's pretty much gone towards the end of
>> the capture. Am I doing something wrong?
>>
>> --
>> Jim Hunziker
>> BCI Systems and Software Engineering
>> [email protected]
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141023/296a4e15/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 23 Oct 2014 13:56:31 -0400 (EDT)
From: Urban Hakansson <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] uhd_cal_tx_iq_balance skips wide frequency
range
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
I just read
http://www.analog.com/static/imported-files/application_notes/AN-1100.pdf and
from what I understand I/Q DAC gain/phase mismatch can also contribute to the
undesired sideband I am observing. So it may not be it is the SBX
daughter-board (the IQ modulator in particular) that alone creates the
undesired sideband, it could be that the N210 motherboard have a mismatched
pair of DACs. Is that correct or am I completely missing something?
----- Original Message -----
From: "Marcus D. Leech via USRP-users" <[email protected]>
To: [email protected]
Sent: Thursday, October 23, 2014 10:42:51 AM
Subject: Re: [USRP-users] uhd_cal_tx_iq_balance skips wide frequency range
On 10/23/2014 10:31 AM, Urban Hakansson via USRP-users wrote:
Hi Michael,
Thanks for running the test on your N210+SBX setup.
Nothing was connected to the N210 when I did the calibration.
mleech sent me a link to the mixer that is used on the SBX daughter-board,
http://www.analog.com/static/imported-files/data_sheets/ADL5375.pdf
Based on my understanding of the data sheet we should both expect better
performance than ~ 20dB suppression from the SBX daughter-board for all bands.
Considering your test results, My SBX is certainly much worse than yours, so to
conclude, it is likely I have a bad SBX daughter board, but you may have one
too.
Regards,
Urban
There's a handy chart on page 5 of:
http://www.analog.com/static/imported-files/application_notes/AN-1039.pdf
Showing image-suppression characteristics for various phase/amplitude errors
The whole field of I/Q imbalance estimation (and the corrections that proceed
from those estimates) is one in which there isn't wide, solid, agreement
on the approach, and the approaches vary depending on application.
I do wonder whether sometimes the estimates are thrown-off by LO spurs causing
false responses that are unrelated to quadrature balance.
<blockquote>
----- Original Message -----
From: "Michael West" <[email protected]>
To: "Urban Hakansson" <[email protected]>
Cc: "[email protected]" <[email protected]>
Sent: Wednesday, October 22, 2014 10:51:27 PM
Subject: Re: [USRP-users] uhd_cal_tx_iq_balance skips wide frequency range
Hi Urban,
Thanks for the information and the flow graph. I grabbed an N210+SBX and a
spectrum analyzer to reproduce your test. After running the calibration, I
observed the following on my set up:
c(MHz) P_(fc-f)/P_(fc+f)(dB)
700 -22
800 -32
900 -22
1000 -27
1100 -34
1200 -23
1300 -29
1400 -23
1500 -26
1600 -27
1700 -32
1800 -47
1900 -47
2000 -47
2100 -46
2200 -45
2300 -45
2400 -44
2500 -43
2600 -43
2700 -43
2800 -42
2900 -42
3000 -42
The bottom line is that it looks as to the -40 dB or better across all bands is
not realistic for an N210+SBX set up. But it does look like your particular SBX
is a bit worse off than the one I tested. I was able to get at least -22 dB
across the same range. The anomalies you are seeing at 2100 and 2200 MHz are
particularly strange. Just to be clear, the calibration should be done with
nothing connected to the SBX. If something was connected, you should run
calibration again. If you believe the board to be bad, contact
[email protected] and they will help you further.
Best regards,
Michael
On Wed, Oct 22, 2014 at 8:37 AM, Urban Hakansson < [email protected] >
wrote:
<blockquote>
Micahel,
Do you mean the if condition in for example uhd_cal_tx_iq_balance should be if
( best_suppression > initial_suppression ) ?
To answer your questions. I am now focusing on calibrating the TX path.
I generate x(t) = r*exp(j*2*pi*f*t) using a very simple Gnuradio flowgraph that
I attach. As you can see in the flowgraph, I set r = 0.1 and f = 1.25MHz. I set
the sample rate to 6.25 MHz (100MHz/(2^4)) to make it as easy for the FPGA
filters as possible when interpolating, and the analog tx gain to 0 dB. Given
the amplitude and tx gain settings I should be operating well within the linear
range of the amplifier.
I sweep the center frequency fc from 700 MHz to 3GHz in 100MHz steps.
I measure the IQ imbalance by connecting my N210 TX/RX port to a Rohde Schwarz
FSP Spectrum Analyzer with 50 Ohm input load using a low loss Coaxial Cable
(LMR-400 3/8").
I measure the power of the desired signal x(t) = r*exp(j*2*pi*(fc+f)*t), and
the undesired replica x'(t) = r'*exp(j*2*pi*(fc-f)*t), putting a spectrum
analyzer marker on each peak, and see what the delta is.
I tried running free without calibration script and the result was worse.
with 200kHz calibration script without calibration scripts
c (MHz) P_(fc-f)/P_(fc+f) (dB) P_(fc-f)/P_(fc+f) (dB)
700 -40 -18
800 -23 -14
900 -17 -11
1000 -22 -13
1100 -27 -15
1200 -40 -20
1300 -12 -16
1400 -15 -23
1500 -40 -18
1600 -40 -14
1700 -21 -11
1800 -13 -11
1900 -40 -20
2000 to small to measure (-infinity) -23
2100 -12 -15
2200 -14 -19
2300 to small to measure (-infinity) -21
2400 to small to measure (-infinity) -24
2500 to small to measure (-infinity) -27
2600 to small to measure (-infinity) -29
2700 to small to measure (-infinity) -35
2800 to small to measure (-infinity) to small to measure (-infinity)
2900 to small to measure (-infinity) to small to measure (-infinity)
3000 to small to measure (-infinity) -33
So calibrating did improve the IQ balance but not enough it seems. I expected
the suppression to be at least 40dB.
I attach the tx calibration scripts for 200kHz step size, when using if
(best_suppression > 15) as the criterion.
Urban
From: "Michael West" < [email protected] >
To: "Urban Hakansson" < [email protected] >
Cc: " [email protected] " < [email protected] >
Sent: Tuesday, October 21, 2014 7:51:10 PM
Subject: Re: [USRP-users] uhd_cal_tx_iq_balance skips wide frequency range
Hi Urban,
First, I honestly do not know why the value of 30 was hard coded. I believe the
"initial_suppression" value should be used, which is the measured value with no
correction applied.
Regarding the IQ imbalance you are seeing, I have a few questions. Is it on TX
or RX? How are you measuring it? What is your set up (are you looping back or
connected to a signal generator and/or spectrum analyzer)? What gain level(s)
are you using? Also, sharing the flowgraph you are using would help.
Best regards,
Michael
On Tue, Oct 21, 2014 at 6:58 AM, Urban Hakansson < [email protected] >
wrote:
<blockquote>
Michael,
Thanks for your reply.
We changed the threshold to 15 and now we get calibration data written to file
for each freq step.
Q: What is the reason the threshold is set to 30? Is there any reason I should
not set it to 15 or any other value? Is there is a reason this parameter value
is hard coded and is not something you can pass in as an argument?
Regardless, the original problem I wanted to solve by calibrating in finer
frequency steps still remains, namely, the residual IQ imbalance is too large
in certain bands.
I calibrated the entire N210+SBX frequency range from 400 to 4400 MHz in 200kHz
steps, thinking that should do it.
To check for any residual IQ imbalance I then generated a complex exponential
with amplitude 0.1 and frequency f = 1.25 MHz, sampled at Fs = 6.25 MHz, and
set tx gain to 0dB (using GnuRadio flowdiagram).
I varied the center frequency fc (LO) in 100MHz steps from 700 MHz to 3000 MHz,
measured the power-ratio between fc+f and the undesired replica at fc-f which
is due to residual IQ imbalance.
fc (MHz) P_(fc-f)/P_(fc+f) (dB)
700 -40
800 -23
900 -17
1000 -22
1100 -27
1200 -40
1300 -12
1400 -15
1500 -40
1600 -40
1700 -21
1800 -13
1900 -40
2000 to small to measure (-infinity)
2100 -12
2200 -14
2300 to small to measure (-infinity)
... ...
3000 to small to measure (-infinity)
I thought that by calibrating the residual IQ imbalance would result in a power
ratio of at least < -40dB between the undesired replica at fc-f and the
original signal at fc+f.
Maybe my expectations are too high, or perhaps I have a bad SBX daughterboard?
Q: What results should I realistically be able to expect using the N210 + SBX
combination?
Regards,
Urban
From: "Michael West" < [email protected] >
To: "Urban Hakansson" < [email protected] >
Cc: " [email protected] " < [email protected] >
Sent: Thursday, October 9, 2014 3:03:08 PM
Subject: Re: [USRP-users] uhd_cal_tx_iq_balance skips wide frequency range
Hi Urban,
If I am understanding you correctly, you are saying that there is no
calibration data for those frequencies in the resulting file. That does not
mean the frequencies are being skipped by the utility. That only means that a
suppression of over 30 dB could not be achieved for those frequencies, so no
correction data was saved. You can set a lower threshold for the minimum
suppression by changing the value in the following line in each IQ calibration
utility:
if (best_suppression > 30){ //most likely valid, keep result
Best regards,
Michael
On Thu, Oct 9, 2014 at 8:57 AM, Urban Hakansson via USRP-users <
[email protected] > wrote:
<blockquote>
Hi everybody,
I am trying to calibrate my N210 SBX daughterboard using the three calibration
scripts uhd_cal_rx_iq_balance, uhd_cal_tx_iq_balance,and uhd_cal_tx_dc_offset
using different values for freq_start, freq_stop, and freq_step.
uhd_cal_tx_iq_balance utility that is not behaving as I expected.
(uhd_cal_rx_iq_balance and uhd_cal_tx_dc_offset give me no problems).
If I run uhd_cal_tx_iq_balance with any other values besides the default values
it will skip approximately 300MHz of frequencies from 790 MHz to ~ 1100MHz.
Here are a few of my attempts.
uhd_cal_tx_iq_balance --freq_start 500000000
uhd_cal_tx_iq_balance --freq_start 600000000
uhd_cal_tx_iq_balance --freq_start 700000000
uhd_cal_tx_iq_balance --freq_start 785000000
uhd_cal_tx_iq_balance --verbose --freq_step 100000
uhd_cal_tx_iq_balance --verbose --freq_step 110000
uhd_cal_tx_iq_balance --verbose --freq_step 225000
uhd_cal_tx_iq_balance --verbose --freq_step 900000
uhd_cal_tx_iq_balance --verbose --freq_step 1000000
uhd_cal_tx_iq_balance --verbose --freq_step 1100000
uhd_cal_tx_iq_balance --verbose --freq_step 2000000
...
uhd_cal_tx_iq_balance --verbose --freq_step 7300000
uhd_cal_tx_iq_balance always stops just before 790MHz and just sits there, but
does not abort, and after a really long time continues at ~ 1100MHz and
continues all the way to 4370MHz without any further gaps.
I attach the calibration scripts I am using and the three csv files for one
example, uhd_cal_tx_iq_balance --verbose --freq_step 225000.
General background information about my environment:
Fedora 17 Linux; GNU C++ version 4.7.0 20120507 (Red Hat 4.7.0-5);
Boost_104800; UHD_003.007.001-0-unknown
N210 informationfrom uhd_usrp_probe:
| Device: USRP2 / N-Series Device
| _____________________________________________________
| /
| | Mboard: N210r4
| | hardware: 2577
| | mac-addr: 00:80:2f:0a:e6:15
| | ip-addr: 192.168.2.199
| | subnet: 255.255.255.255
| | gateway: 255.255.255.255
| | gpsdo: none
| | serial: F4A09C
| | FW Version: 12.4
| | FPGA Version: 10.1
What could the cause of this behaviour be? Are there only certain combination
of values that work? What do I need to do to make uhd_tx_iq_balance not hang
right before 790MHz?
Thanks for you consideration.
Regards,
Urban Hakansson
Senior Software Engineer
Tecore Networks
Phone: +1 410 872 6315
Fax: +1 410 872 6010
Email: [email protected]
Urban Hakansson Senior Software Engineer Tecore Networks Phone: +1 410 872 6315
Fax: +1 410 872 6010 Email: [email protected]
Urban Hakansson
Senior Software Engineer
Tecore Networks
Phone: +1 410 872 6315
Fax: +1 410 872 6010
Email: [email protected]
This e-mail may contain privileged, confidential, copyrighted or other legally
protected information, and is intended exclusively for the intended recipient.
If you are not the intended recipient (even if the e-mail address above is
yours), you may not review, store, use, copy, disclose or retransmit it in any
form. If you are not the intended recipient or otherwise have received this by
mistake, please immediately notify the sender by return e-mail (or
[email protected] ), then delete the message in its entirety. Thank you.
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
</blockquote>
This e-mail may contain privileged, confidential, copyrighted or other legally
protected information, and is intended exclusively for the intended recipient.
If you are not the intended recipient (even if the e-mail address above is
yours), you may not review, store, use, copy, disclose or retransmit it in any
form. If you are not the intended recipient or otherwise have received this by
mistake, please immediately notify the sender by return e-mail (or
[email protected] ), then delete the message in its entirety. Thank you.
</blockquote>
This e-mail may contain privileged, confidential, copyrighted or other legally
protected information, and is intended exclusively for the intended recipient.
If you are not the intended recipient (even if the e-mail address above is
yours), you may not review, store, use, copy, disclose or retransmit it in any
form. If you are not the intended recipient or otherwise have received this by
mistake, please immediately notify the sender by return e-mail (or
[email protected] ), then delete the message in its entirety. Thank you.
</blockquote>
This e-mail may contain privileged, confidential, copyrighted or other legally
protected information, and is intended exclusively for the intended recipient.
If you are not the intended recipient (even if the e-mail address above is
yours), you may not review, store, use, copy, disclose or retransmit it in any
form. If you are not the intended recipient or otherwise have received this by
mistake, please immediately notify the sender by return e-mail (or
[email protected] ), then delete the message in its entirety. Thank you.
_______________________________________________
USRP-users mailing list [email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
</blockquote>
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
This
e-mail may contain privileged, confidential, copyrighted or other legally
protected information, and is intended exclusively for the intended recipient.
If you are not the intended recipient (even if the e-mail address above is
yours), you may not review, store, use, copy, disclose or retransmit it in any
form. If you are not the intended recipient or otherwise have received this by
mistake, please immediately notify the sender by return e-mail (or
[email protected]), then delete the message in its entirety. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141023/92dada4f/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 23 Oct 2014 14:00:12 -0400
From: "Marcus D. Leech" <[email protected]>
To: Urban Hakansson <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] uhd_cal_tx_iq_balance skips wide frequency
range
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 10/23/2014 01:56 PM, Urban Hakansson wrote:
> I just read
> http://www.analog.com/static/imported-files/application_notes/AN-1100.pdf
> and from what I understand I/Q DAC gain/phase mismatch can also
> contribute to the undesired sideband I am observing. So it may not be
> it is the SBX daughter-board (the IQ modulator in particular) that
> alone creates the undesired sideband, it could be that the N210
> motherboard have a mismatched pair of DACs. Is that correct or am I
> completely missing something?
The DAC that is used is a dual synchronized DAC. I wouldn't expect
significant phase errors, but there could be very-small amplitude errors.
But the calibration should null all components that are contributing,
regardless of their source.
>
> ------------------------------------------------------------------------
> *From: *"Marcus D. Leech via USRP-users" <[email protected]>
> *To: *[email protected]
> *Sent: *Thursday, October 23, 2014 10:42:51 AM
> *Subject: *Re: [USRP-users] uhd_cal_tx_iq_balance skips wide frequency
> range
>
> On 10/23/2014 10:31 AM, Urban Hakansson via USRP-users wrote:
>
> Hi Michael,
>
> Thanks for running the test on your N210+SBX setup.
>
> Nothing was connected to the N210 when I did the calibration.
>
> mleech sent me a link to the mixer that is used on the SBX
> daughter-board,
> http://www.analog.com/static/imported-files/data_sheets/ADL5375.pdf
>
> Based on my understanding of the data sheet we should both expect
> better performance than ~ 20dB suppression from the SBX
> daughter-board for all bands.
>
> Considering your test results, My SBX is certainly much worse than
> yours, so to conclude, it is likely I have a bad SBX daughter
> board, but you may have one too.
>
> Regards,
>
> Urban
>
> There's a handy chart on page 5 of:
>
> http://www.analog.com/static/imported-files/application_notes/AN-1039.pdf
>
> Showing image-suppression characteristics for various phase/amplitude
> errors
>
> The whole field of I/Q imbalance estimation (and the corrections that
> proceed from those estimates) is one in which there isn't wide,
> solid, agreement
> on the approach, and the approaches vary depending on application.
>
> I do wonder whether sometimes the estimates are thrown-off by LO spurs
> causing false responses that are unrelated to quadrature balance.
>
>
> ------------------------------------------------------------------------
> *From: *"Michael West" <[email protected]>
> *To: *"Urban Hakansson" <[email protected]>
> *Cc: *"[email protected]" <[email protected]>
> *Sent: *Wednesday, October 22, 2014 10:51:27 PM
> *Subject: *Re: [USRP-users] uhd_cal_tx_iq_balance skips wide
> frequency range
>
> Hi Urban,
>
> Thanks for the information and the flow graph. I grabbed an
> N210+SBX and a spectrum analyzer to reproduce your test. After
> running the calibration, I observed the following on my set up:
>
> c(MHz)P_(fc-f)/P_(fc+f)(dB)
> 700-22
> 800-32
> 900-22
> 1000 -27
> 1100 -34
> 1200 -23
> 1300 -29
> 1400 -23
> 1500 -26
> 1600 -27
> 1700 -32
> 1800 -47
> 1900 -47
> 2000 -47
> 2100 -46
> 2200 -45
> 2300 -45
> 2400 -44
> 2500 -43
> 2600 -43
> 2700 -43
> 2800 -42
> 2900 -42
> 3000 -42
>
> The bottom line is that it looks as to the -40 dB or better across
> all bands is not realistic for an N210+SBX set up. But it does
> look like your particular SBX is a bit worse off than the one I
> tested. I was able to get at least -22 dB across the same range.
> The anomalies you are seeing at 2100 and 2200 MHz are particularly
> strange. Just to be clear, the calibration should be done with
> nothing connected to the SBX. If something was connected, you
> should run calibration again. If you believe the board to be bad,
> contact [email protected] <mailto:[email protected]> and they will
> help you further.
>
> Best regards,
> Michael
>
> On Wed, Oct 22, 2014 at 8:37 AM, Urban Hakansson
> <[email protected] <mailto:[email protected]>> wrote:
>
> Micahel,
>
> Do you mean the if condition in for example
> uhd_cal_tx_iq_balance should be if ( best_suppression >
> initial_suppression ) ?
>
> To answer your questions. I am now focusing on calibrating the
> TX path.
>
> I generate x(t) = r*exp(j*2*pi*f*t) using a very simple
> Gnuradio flowgraph that I attach. As you can see in the
> flowgraph, I set r = 0.1 and f = 1.25MHz. I set the sample
> rate to 6.25 MHz (100MHz/(2^4)) to make it as easy for the
> FPGA filters as possible when interpolating, and the analog tx
> gain to 0 dB. Given the amplitude and tx gain settings I
> should be operating well within the linear range of the amplifier.
>
> I sweep the center frequency fc from 700 MHz to 3GHz in 100MHz
> steps.
>
> I measure the IQ imbalance by connecting my N210 TX/RX port to
> a Rohde Schwarz FSP Spectrum Analyzer with 50 Ohm input load
> using a low loss Coaxial Cable (LMR-400 3/8").
>
> I measure the power of the desired signal x(t) =
> r*exp(j*2*pi*(fc+f)*t), and the undesired replica x'(t) =
> r'*exp(j*2*pi*(fc-f)*t), putting a spectrum analyzer marker on
> each peak, and see what the delta is.
>
> I tried running free without calibration script and the result
> was worse.
>
> with 200kHz calibration
> script without calibration scripts
> c (MHz) P_(fc-f)/P_(fc+f) (dB)P_(fc-f)/P_(fc+f) (dB)
> 700-40-18
> 800-23-14
> 900-17-11
> 1000-22-13
> 1100-27-15
> 1200-40-20
> 1300-12-16
> 1400-15-23
> 1500-40-18
> 1600-40-14
> 1700-21-11
> 1800-13-11
> 1900-40-20
> 2000 to small to measure (-infinity)-23
> 2100-12 -15
> 2200-14-19
> 2300 to small to measure (-infinity)-21
> 2400to small to measure (-infinity)-24
> 2500to small to measure (-infinity)-27
> 2600to small to measure (-infinity)-29
> 2700to small to measure (-infinity)-35
> 2800to small to measure (-infinity)to small to measure (-infinity)
> 2900to small to measure (-infinity)to small to measure (-infinity)
> 3000to small to measure (-infinity)-33
>
> So calibrating did improve the IQ balance but not enough it
> seems. I expected the suppression to be at least 40dB.
>
> I attach the tx calibration scripts for 200kHz step size, when
> using if (best_suppression > 15) as the criterion.
>
> Urban
>
> ------------------------------------------------------------------------
> *From: *"Michael West" <[email protected]
> <mailto:[email protected]>>
> *To: *"Urban Hakansson" <[email protected]
> <mailto:[email protected]>>
> *Cc: *"[email protected]
> <mailto:[email protected]>"
> <[email protected] <mailto:[email protected]>>
> *Sent: *Tuesday, October 21, 2014 7:51:10 PM
>
> *Subject: *Re: [USRP-users] uhd_cal_tx_iq_balance skips wide
> frequency range
>
> Hi Urban,
>
> First, I honestly do not know why the value of 30 was hard
> coded. I believe the "initial_suppression" value should be
> used, which is the measured value with no correction applied.
>
> Regarding the IQ imbalance you are seeing, I have a few
> questions. Is it on TX or RX? How are you measuring it?
> What is your set up (are you looping back or connected to a
> signal generator and/or spectrum analyzer)? What gain
> level(s) are you using? Also, sharing the flowgraph you are
> using would help.
>
> Best regards,
> Michael
>
> On Tue, Oct 21, 2014 at 6:58 AM, Urban Hakansson
> <[email protected] <mailto:[email protected]>> wrote:
>
> Michael,
>
> Thanks for your reply.
>
> We changed the threshold to 15 and now we get calibration
> data written to file for each freq step.
>
> Q: What is the reason the threshold is set to 30? Is
> there any reason I should not set it to 15 or any other
> value? Is there is a reason this parameter value is hard
> coded and is not something you can pass in as an argument?
>
> Regardless, the original problem I wanted to solve by
> calibrating in finer frequency steps still remains,
> namely, the residual IQ imbalance is too large in certain
> bands.
>
> I calibrated the entire N210+SBX frequency range from 400
> to 4400 MHz in 200kHz steps, thinking that should do it.
>
> To check for any residual IQ imbalance I then generated a
> complex exponential with amplitude 0.1 and frequency f =
> 1.25 MHz, sampled at Fs = 6.25 MHz, and set tx gain to 0dB
> (using GnuRadio flowdiagram).
>
> I varied the center frequency fc (LO) in 100MHz steps from
> 700 MHz to 3000 MHz, measured the power-ratio between fc+f
> and the undesired replica at fc-f which is due to residual
> IQ imbalance.
>
> fc (MHz) P_(fc-f)/P_(fc+f) (dB)
> 700
> -40
> 800
> -23
> 900-17
> 1000-22
> 1100-27
> 1200-40
> 1300-12
> 1400-15
> 1500-40
> 1600-40
> 1700-21
> 1800-13
> 1900-40
> 2000 to small to measure (-infinity)
> 2100-12
> 2200-14
> 2300 to small to measure (-infinity)
> ......
> 3000to small to measure (-infinity)
>
> I thought that by calibrating the residual IQ imbalance
> would result in a power ratio of at least < -40dB between
> the undesired replica at fc-f and the original signal at fc+f.
>
> Maybe my expectations are too high, or perhaps I have a
> bad SBX daughterboard?
>
> Q: What results should I realistically be able to expect
> using the N210 + SBX combination?
>
> Regards,
>
> Urban
>
>
> ------------------------------------------------------------------------
> *From: *"Michael West" <[email protected]
> <mailto:[email protected]>>
> *To: *"Urban Hakansson" <[email protected]
> <mailto:[email protected]>>
> *Cc: *"[email protected]
> <mailto:[email protected]>"
> <[email protected]
> <mailto:[email protected]>>
> *Sent: *Thursday, October 9, 2014 3:03:08 PM
> *Subject: *Re: [USRP-users] uhd_cal_tx_iq_balance skips
> wide frequency range
>
>
> Hi Urban,
>
> If I am understanding you correctly, you are saying that
> there is no calibration data for those frequencies in the
> resulting file. That does not mean the frequencies are
> being skipped by the utility. That only means that a
> suppression of over 30 dB could not be achieved for those
> frequencies, so no correction data was saved. You can set
> a lower threshold for the minimum suppression by changing
> the value in the following line in each IQ calibration
> utility:
>
> if (best_suppression > 30){ //most likely valid,
> keep result
>
> Best regards,
> Michael
>
> On Thu, Oct 9, 2014 at 8:57 AM, Urban Hakansson via
> USRP-users <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hi everybody,
>
> I am trying to calibrate my N210 SBX daughterboard
> using the three calibration scripts
> uhd_cal_rx_iq_balance, uhd_cal_tx_iq_balance,and
> uhd_cal_tx_dc_offset using different values for
> freq_start, freq_stop, and freq_step.
>
> uhd_cal_tx_iq_balance utility that is not behaving as
> I expected.
> (uhd_cal_rx_iq_balance and uhd_cal_tx_dc_offset give
> me no problems).
>
> If I run uhd_cal_tx_iq_balance with any other values
> besides the default values it will skip approximately
> 300MHz of frequencies from 790 MHz to ~ 1100MHz.
>
> Here are a few of my attempts.
>
> uhd_cal_tx_iq_balance --freq_start 500000000
> uhd_cal_tx_iq_balance --freq_start 600000000
> uhd_cal_tx_iq_balance --freq_start 700000000
> uhd_cal_tx_iq_balance --freq_start 785000000
> uhd_cal_tx_iq_balance --verbose --freq_step 100000
> uhd_cal_tx_iq_balance --verbose --freq_step 110000
> uhd_cal_tx_iq_balance --verbose --freq_step 225000
> uhd_cal_tx_iq_balance --verbose --freq_step 900000
> uhd_cal_tx_iq_balance --verbose --freq_step 1000000
> uhd_cal_tx_iq_balance --verbose --freq_step 1100000
> uhd_cal_tx_iq_balance --verbose --freq_step 2000000
> ...
> uhd_cal_tx_iq_balance --verbose --freq_step 7300000
>
> uhd_cal_tx_iq_balance always stops just before 790MHz
> and just sits there, but does not abort, and after a
> really long time continues at ~ 1100MHz and continues
> all the way to 4370MHz without any further gaps.
>
> I attach the calibration scripts I am using and the
> three csv files for one example, uhd_cal_tx_iq_balance
> --verbose --freq_step 225000.
>
> General background information about my environment:
> Fedora 17 Linux; GNU C++ version 4.7.0 20120507 (Red
> Hat 4.7.0-5); Boost_104800; UHD_003.007.001-0-unknown
>
> N210 informationfrom uhd_usrp_probe:
> | Device: USRP2 / N-Series Device
> | _____________________________________________________
> | /
> | | Mboard: N210r4
> | | hardware: 2577
> | | mac-addr: 00:80:2f:0a:e6:15
> | | ip-addr: 192.168.2.199
> | | subnet: 255.255.255.255
> | | gateway: 255.255.255.255
> | | gpsdo: none
> | | serial: F4A09C
> | | FW Version: 12.4
> | | FPGA Version: 10.1
>
> What could the cause of this behaviour be? Are there
> only certain combination of values that work? What do
> I need to do to make uhd_tx_iq_balance not hang right
> before 790MHz?
>
> Thanks for you consideration.
>
> Regards,
>
> Urban Hakansson
> Senior Software Engineer
> Tecore Networks
> Phone: +1 410 872 6315 <tel:%2B1%20410%20872%206315>
> Fax: +1 410 872 6010 <tel:%2B1%20410%20872%206010>
> Email: [email protected]
> <mailto:[email protected]>
>
>
> Urban Hakansson Senior Software Engineer Tecore
> Networks Phone: +1 410 872 6315
> <tel:%2B1%20410%20872%206315> Fax: +1 410 872 6010
> <tel:%2B1%20410%20872%206010> Email:
> [email protected] <mailto:[email protected]>
>
> Urban Hakansson
> Senior Software Engineer
> Tecore Networks
> Phone: +1 410 872 6315 <tel:%2B1%20410%20872%206315>
> Fax: +1 410 872 6010 <tel:%2B1%20410%20872%206010>
> Email: [email protected]
> <mailto:[email protected]>
>
>
>
>
>
> This e-mail may contain privileged,
> confidential, copyrighted or other legally protected
> information, and is intended exclusively for the
> intended recipient. If you are not the intended
> recipient (even if the e-mail address above is yours),
> you may not review, store, use, copy, disclose or
> retransmit it in any form. If you are not the
> intended recipient or otherwise have received this by
> mistake, please immediately notify the sender by
> return e-mail (or [email protected]
> <mailto:[email protected]>), then delete the message
> in its entirety. Thank you.
> _______________________________________________
> USRP-users mailing list
> [email protected]
> <mailto:[email protected]>
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> This e-mail may contain privileged, confidential,
> copyrighted or other legally protected information, and is
> intended exclusively for the intended recipient. If you
> are not the intended recipient (even if the e-mail address
> above is yours), you may not review, store, use, copy,
> disclose or retransmit it in any form. If you are not the
> intended recipient or otherwise have received this by
> mistake, please immediately notify the sender by return
> e-mail (or [email protected]
> <mailto:[email protected]>), then delete the message in
> its entirety. Thank you.
>
>
>
>
> This e-mail may contain privileged, confidential, copyrighted
> or other legally protected information, and is intended
> exclusively for the intended recipient. If you are not the
> intended recipient (even if the e-mail address above is
> yours), you may not review, store, use, copy, disclose or
> retransmit it in any form. If you are not the intended
> recipient or otherwise have received this by mistake, please
> immediately notify the sender by return e-mail (or
> [email protected] <mailto:[email protected]>), then delete
> the message in its entirety. Thank you.
>
>
>
>
> This e-mail may contain privileged, confidential, copyrighted or
> other legally protected information, and is intended exclusively
> for the intended recipient. If you are not the intended recipient
> (even if the e-mail address above is yours), you may not review,
> store, use, copy, disclose or retransmit it in any form. If you
> are not the intended recipient or otherwise have received this by
> mistake, please immediately notify the sender by return e-mail (or
> [email protected]), then delete the message in its entirety.
> Thank you.
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> This e-mail may contain privileged, confidential, copyrighted or other
> legally protected information, and is intended exclusively for the
> intended recipient. If you are not the intended recipient (even if the
> e-mail address above is yours), you may not review, store, use, copy,
> disclose or retransmit it in any form. If you are not the intended
> recipient or otherwise have received this by mistake, please
> immediately notify the sender by return e-mail (or
> [email protected]), then delete the message in its entirety. Thank you.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141023/4079699f/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 23 Oct 2014 14:09:49 -0400
From: Robert Kossler <[email protected]>
To: Perper <[email protected]>
Cc: USRP List <[email protected]>
Subject: Re: [USRP-users] Storing signals with full bandwidth of USRP
x300/x310
Message-ID:
<cab__htqivwiqgktrz6fnat5ql0gra3qhkgbl-andn4-iefy...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Does anyone have experience using something like the OCZ RevoDrive 350 PCIe
x8 SSD rather than a RAID array?
http://ocz.com/consumer/revodrive-350-pcie-ssd
On Thu, Oct 23, 2014 at 6:16 AM, Perper via USRP-users <
[email protected]> wrote:
> Thank you Matt for the quick reply.
>
> The requirement to store the data is quite common in radiolocation (i.e.
> SAR imaging) as the radar data is often postprocessed with use of
> different algorithms. Examples of equipment that can be attached to USRP
> x300 in order to store/send large amounts of data with high bandwidth
> might be very valuable for users performing radar measurements with use
> of the USRPs.
>
> Best Regards,
> Piotr Krysik
>
> W dniu 23.10.2014 o 00:57, Matt Ettus pisze:
> >
> > Piotr,
> >
> > The majority of users of X300/X310 are actually processing the data in
> > real time either in the host computer or in the FPGA. Storing samples
> > at 200 MS/s is possible, but not easy. There are consumer-level SSDs
> > which can do sequential writes at about 500 MB/s:
> >
> >
> http://www.anandtech.com/show/8528/micron-m600-128gb-256gb-1tb-ssd-review-nda-placeholder
> >
> > With 2 or 3 of those in a RAID configuration you should be able to
> > keep up if you design your app right. That being said, you'll fill
> > the drive pretty quickly, so an array of cheaper spinning disks may
> > make more sense. Some people have had luck with 8 drive arrays.
> >
> > Matt
> >
> >
> > On Wed, Oct 22, 2014 at 12:06 PM, Perper via USRP-users
> > <[email protected] <mailto:[email protected]>> wrote:
> >
> > Hi all,
> >
> > USRP x300/x310 is able to stream 200MS/s (800MB/s), which is enormous
> > volume of information. Not many PC's are able to receive such flow of
> > data, let alone to store several dozen minutes of it.
> >
> > Thus I want to ask you, USRP x300/x310 developers and users, what
> > set of
> > hardware enable you to store the data flow from your USRPs?
> >
> > In my case I need a system that can be powered with battery, possibly
> > small and mobile (quite conflicting requirements). However at the
> > moment
> > proposition of any system that is able to sustain 200MS/s and store
> it
> > will be good.
> >
> > Best Regars,
> > Piotr Krysik
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected] <mailto:[email protected]>
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141023/3425d1e1/attachment-0001.html>
------------------------------
Message: 6
Date: Thu, 23 Oct 2014 12:35:55 -0700
From: Michael West <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] uhd_cal_tx_iq_balance skips wide frequency
range
Message-ID:
<cam4xkromrnwwybf1gisar7natdvn2na+npdunwyn9zw3__p...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks for the data sheet info, Marcus. Yes, it looks like the SBX board I
grabbed was not so good. I grabbed another SBX and got much better results:
P_(fc-f)/P_(fc+f)(dB)
c(MHz) uncalibrated calibrated
------ ------------ ----------
700 -35 -50
800 -30 -50
900 -39 -52
1000 -40 -50
1100 -38 -52
1200 -35 -51
1300 -39 -50
1400 -40 -52
1500 -38 -49
1600 -32 -50
1700 -30 -50
1800 -28 -49
1900 -31 -50
2000 -34 -50
2100 -34 -48
2200 -33 -49
2300 -36 -47
2400 -36 -55
2500 -36 -52
2600 -37 -55
2700 -36 -53
2800 -36 -53
2900 -35 -53
3000 -36 -53
So it looks like getting at least -40 dB of suppression is a very
reasonable expectation after all.
I did, however, find an issue in the calibration utility. At the lower
frequencies (<2 GHz), the signal was saturated and the calibration was
resulting bad correction values. To calibrate the board successfully, I
changed the UHD code to reduce the RX gain setting for the SBX board from
25 to 15 in the calibration utilities (changed line 103 of
host/utils/usrp_cal_utils.hpp to be "usrp->set_rx_gain(15)").
Regards,
Michael
On Thu, Oct 23, 2014 at 11:00 AM, Marcus D. Leech via USRP-users <
[email protected]> wrote:
> On 10/23/2014 01:56 PM, Urban Hakansson wrote:
>
> I just read
> http://www.analog.com/static/imported-files/application_notes/AN-1100.pdf
> and from what I understand I/Q DAC gain/phase mismatch can also contribute
> to the undesired sideband I am observing. So it may not be it is the SBX
> daughter-board (the IQ modulator in particular) that alone creates the
> undesired sideband, it could be that the N210 motherboard have a mismatched
> pair of DACs. Is that correct or am I completely missing something?
>
> The DAC that is used is a dual synchronized DAC. I wouldn't expect
> significant phase errors, but there could be very-small amplitude errors.
>
> But the calibration should null all components that are contributing,
> regardless of their source.
>
>
>
>
> ------------------------------
> *From: *"Marcus D. Leech via USRP-users" <[email protected]>
> <[email protected]>
> *To: *[email protected]
> *Sent: *Thursday, October 23, 2014 10:42:51 AM
> *Subject: *Re: [USRP-users] uhd_cal_tx_iq_balance skips wide frequency
> range
>
> On 10/23/2014 10:31 AM, Urban Hakansson via USRP-users wrote:
>
> Hi Michael,
>
> Thanks for running the test on your N210+SBX setup.
>
> Nothing was connected to the N210 when I did the calibration.
>
> mleech sent me a link to the mixer that is used on the SBX daughter-board,
> http://www.analog.com/static/imported-files/data_sheets/ADL5375.pdf
>
> Based on my understanding of the data sheet we should both expect better
> performance than ~ 20dB suppression from the SBX daughter-board for all
> bands.
>
> Considering your test results, My SBX is certainly much worse than yours,
> so to conclude, it is likely I have a bad SBX daughter board, but you may
> have one too.
>
> Regards,
>
> Urban
>
> There's a handy chart on page 5 of:
>
> http://www.analog.com/static/imported-files/application_notes/AN-1039.pdf
>
> Showing image-suppression characteristics for various phase/amplitude
> errors
>
> The whole field of I/Q imbalance estimation (and the corrections that
> proceed from those estimates) is one in which there isn't wide, solid,
> agreement
> on the approach, and the approaches vary depending on application.
>
> I do wonder whether sometimes the estimates are thrown-off by LO spurs
> causing false responses that are unrelated to quadrature balance.
>
>
> ------------------------------
> *From: *"Michael West" <[email protected]> <[email protected]>
> *To: *"Urban Hakansson" <[email protected]> <[email protected]>
> *Cc: *"[email protected]" <[email protected]>
> <[email protected]> <[email protected]>
> *Sent: *Wednesday, October 22, 2014 10:51:27 PM
> *Subject: *Re: [USRP-users] uhd_cal_tx_iq_balance skips wide frequency
> range
>
> Hi Urban,
>
> Thanks for the information and the flow graph. I grabbed an N210+SBX and
> a spectrum analyzer to reproduce your test. After running the calibration,
> I observed the following on my set up:
>
> c(MHz) P_(fc-f)/P_(fc+f)(dB)
> 700 -22
> 800 -32
> 900 -22
> 1000 -27
> 1100 -34
> 1200 -23
> 1300 -29
> 1400 -23
> 1500 -26
> 1600 -27
> 1700 -32
> 1800 -47
> 1900 -47
> 2000 -47
> 2100 -46
> 2200 -45
> 2300 -45
> 2400 -44
> 2500 -43
> 2600 -43
> 2700 -43
> 2800 -42
> 2900 -42
> 3000 -42
>
> The bottom line is that it looks as to the -40 dB or better across all
> bands is not realistic for an N210+SBX set up. But it does look like your
> particular SBX is a bit worse off than the one I tested. I was able to get
> at least -22 dB across the same range. The anomalies you are seeing at
> 2100 and 2200 MHz are particularly strange. Just to be clear, the
> calibration should be done with nothing connected to the SBX. If something
> was connected, you should run calibration again. If you believe the board
> to be bad, contact [email protected] and they will help you further.
>
> Best regards,
> Michael
>
> On Wed, Oct 22, 2014 at 8:37 AM, Urban Hakansson <[email protected]>
> wrote:
>
>> Micahel,
>>
>> Do you mean the if condition in for example uhd_cal_tx_iq_balance should
>> be if ( best_suppression > initial_suppression ) ?
>>
>> To answer your questions. I am now focusing on calibrating the TX path.
>>
>> I generate x(t) = r*exp(j*2*pi*f*t) using a very simple Gnuradio
>> flowgraph that I attach. As you can see in the flowgraph, I set r = 0.1
>> and f = 1.25MHz. I set the sample rate to 6.25 MHz (100MHz/(2^4)) to make
>> it as easy for the FPGA filters as possible when interpolating, and the
>> analog tx gain to 0 dB. Given the amplitude and tx gain settings I should
>> be operating well within the linear range of the amplifier.
>>
>> I sweep the center frequency fc from 700 MHz to 3GHz in 100MHz steps.
>>
>> I measure the IQ imbalance by connecting my N210 TX/RX port to a Rohde
>> Schwarz FSP Spectrum Analyzer with 50 Ohm input load using a low loss
>> Coaxial Cable (LMR-400 3/8").
>>
>> I measure the power of the desired signal x(t) = r*exp(j*2*pi*(fc+f)*t),
>> and the undesired replica x'(t) = r'*exp(j*2*pi*(fc-f)*t), putting a
>> spectrum analyzer marker on each peak, and see what the delta is.
>>
>> I tried running free without calibration script and the result was worse.
>>
>> with 200kHz calibration
>> script without calibration scripts
>> c (MHz) P_(fc-f)/P_(fc+f) (dB) P_(fc-f)/P_(fc+f) (dB)
>> 700 -40 -18
>> 800 -23 -14
>> 900 -17 -11
>> 1000 -22 -13
>> 1100 -27 -15
>> 1200 -40 -20
>> 1300 -12 -16
>> 1400 -15 -23
>> 1500 -40 -18
>> 1600 -40 -14
>> 1700 -21 -11
>> 1800 -13 -11
>> 1900 -40 -20
>> 2000 to small to measure (-infinity) -23
>> 2100 -12 -15
>> 2200 -14 -19
>> 2300 to small to measure (-infinity) -21
>> 2400 to small to measure (-infinity) -24
>> 2500 to small to measure (-infinity) -27
>> 2600 to small to measure (-infinity) -29
>> 2700 to small to measure (-infinity) -35
>> 2800 to small to measure (-infinity) to small to measure (-infinity)
>> 2900 to small to measure (-infinity) to small to measure (-infinity)
>> 3000 to small to measure (-infinity) -33
>>
>> So calibrating did improve the IQ balance but not enough it seems. I
>> expected the suppression to be at least 40dB.
>>
>> I attach the tx calibration scripts for 200kHz step size, when using if
>> (best_suppression > 15) as the criterion.
>>
>> Urban
>> ------------------------------
>> *From: *"Michael West" <[email protected]>
>> *To: *"Urban Hakansson" <[email protected]>
>> *Cc: *"[email protected]" <[email protected]>
>> *Sent: *Tuesday, October 21, 2014 7:51:10 PM
>>
>> *Subject: *Re: [USRP-users] uhd_cal_tx_iq_balance skips wide frequency
>> range
>>
>> Hi Urban,
>>
>> First, I honestly do not know why the value of 30 was hard coded. I
>> believe the "initial_suppression" value should be used, which is the
>> measured value with no correction applied.
>>
>> Regarding the IQ imbalance you are seeing, I have a few questions. Is
>> it on TX or RX? How are you measuring it? What is your set up (are you
>> looping back or connected to a signal generator and/or spectrum
>> analyzer)? What gain level(s) are you using? Also, sharing the flowgraph
>> you are using would help.
>>
>> Best regards,
>> Michael
>>
>> On Tue, Oct 21, 2014 at 6:58 AM, Urban Hakansson <[email protected]>
>> wrote:
>>
>>> Michael,
>>>
>>> Thanks for your reply.
>>>
>>> We changed the threshold to 15 and now we get calibration data written
>>> to file for each freq step.
>>>
>>> Q: What is the reason the threshold is set to 30? Is there any reason I
>>> should not set it to 15 or any other value? Is there is a reason this
>>> parameter value is hard coded and is not something you can pass in as an
>>> argument?
>>>
>>> Regardless, the original problem I wanted to solve by calibrating in
>>> finer frequency steps still remains, namely, the residual IQ imbalance is
>>> too large in certain bands.
>>>
>>> I calibrated the entire N210+SBX frequency range from 400 to 4400 MHz in
>>> 200kHz steps, thinking that should do it.
>>>
>>> To check for any residual IQ imbalance I then generated a complex
>>> exponential with amplitude 0.1 and frequency f = 1.25 MHz, sampled at Fs =
>>> 6.25 MHz, and set tx gain to 0dB (using GnuRadio flowdiagram).
>>>
>>> I varied the center frequency fc (LO) in 100MHz steps from 700 MHz to
>>> 3000 MHz, measured the power-ratio between fc+f and the undesired replica
>>> at fc-f which is due to residual IQ imbalance.
>>>
>>> fc (MHz) P_(fc-f)/P_(fc+f) (dB)
>>> 700
>>> -40
>>> 800
>>> -23
>>> 900 -17
>>> 1000 -22
>>> 1100 -27
>>> 1200 -40
>>> 1300 -12
>>> 1400 -15
>>> 1500 -40
>>> 1600 -40
>>> 1700 -21
>>> 1800 -13
>>> 1900 -40
>>> 2000 to small to measure (-infinity)
>>> 2100 -12
>>> 2200 -14
>>> 2300 to small to measure (-infinity)
>>> ... ...
>>> 3000 to small to measure (-infinity)
>>>
>>> I thought that by calibrating the residual IQ imbalance would result in
>>> a power ratio of at least < -40dB between the undesired replica at fc-f and
>>> the original signal at fc+f.
>>>
>>> Maybe my expectations are too high, or perhaps I have a bad SBX
>>> daughterboard?
>>>
>>> Q: What results should I realistically be able to expect using the N210
>>> + SBX combination?
>>>
>>> Regards,
>>>
>>> Urban
>>>
>>> ------------------------------
>>> *From: *"Michael West" <[email protected]>
>>> *To: *"Urban Hakansson" <[email protected]>
>>> *Cc: *"[email protected]" <[email protected]>
>>> *Sent: *Thursday, October 9, 2014 3:03:08 PM
>>> *Subject: *Re: [USRP-users] uhd_cal_tx_iq_balance skips wide frequency
>>> range
>>>
>>>
>>> Hi Urban,
>>>
>>> If I am understanding you correctly, you are saying that there is no
>>> calibration data for those frequencies in the resulting file. That does
>>> not mean the frequencies are being skipped by the utility. That only means
>>> that a suppression of over 30 dB could not be achieved for those
>>> frequencies, so no correction data was saved. You can set a lower
>>> threshold for the minimum suppression by changing the value in the
>>> following line in each IQ calibration utility:
>>>
>>> if (best_suppression > 30){ //most likely valid, keep result
>>>
>>> Best regards,
>>> Michael
>>>
>>> On Thu, Oct 9, 2014 at 8:57 AM, Urban Hakansson via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> Hi everybody,
>>>>
>>>> I am trying to calibrate my N210 SBX daughterboard using the three
>>>> calibration scripts uhd_cal_rx_iq_balance, uhd_cal_tx_iq_balance,and
>>>> uhd_cal_tx_dc_offset using different values for freq_start, freq_stop, and
>>>> freq_step.
>>>>
>>>> uhd_cal_tx_iq_balance utility that is not behaving as I expected.
>>>> (uhd_cal_rx_iq_balance and uhd_cal_tx_dc_offset give me no problems).
>>>>
>>>> If I run uhd_cal_tx_iq_balance with any other values besides the
>>>> default values it will skip approximately 300MHz of frequencies from 790
>>>> MHz to ~ 1100MHz.
>>>>
>>>> Here are a few of my attempts.
>>>>
>>>> uhd_cal_tx_iq_balance --freq_start 500000000
>>>> uhd_cal_tx_iq_balance --freq_start 600000000
>>>> uhd_cal_tx_iq_balance --freq_start 700000000
>>>> uhd_cal_tx_iq_balance --freq_start 785000000
>>>> uhd_cal_tx_iq_balance --verbose --freq_step 100000
>>>> uhd_cal_tx_iq_balance --verbose --freq_step 110000
>>>> uhd_cal_tx_iq_balance --verbose --freq_step 225000
>>>> uhd_cal_tx_iq_balance --verbose --freq_step 900000
>>>> uhd_cal_tx_iq_balance --verbose --freq_step 1000000
>>>> uhd_cal_tx_iq_balance --verbose --freq_step 1100000
>>>> uhd_cal_tx_iq_balance --verbose --freq_step 2000000
>>>> ...
>>>> uhd_cal_tx_iq_balance --verbose --freq_step 7300000
>>>>
>>>> uhd_cal_tx_iq_balance always stops just before 790MHz and just sits
>>>> there, but does not abort, and after a really long time continues at ~
>>>> 1100MHz and continues all the way to 4370MHz without any further gaps.
>>>>
>>>> I attach the calibration scripts I am using and the three csv files for
>>>> one example, uhd_cal_tx_iq_balance --verbose --freq_step 225000.
>>>>
>>>> General background information about my environment:
>>>> Fedora 17 Linux; GNU C++ version 4.7.0 20120507 (Red Hat 4.7.0-5);
>>>> Boost_104800; UHD_003.007.001-0-unknown
>>>>
>>>> N210 informationfrom uhd_usrp_probe:
>>>> | Device: USRP2 / N-Series Device
>>>> | _____________________________________________________
>>>> | /
>>>> | | Mboard: N210r4
>>>> | | hardware: 2577
>>>> | | mac-addr: 00:80:2f:0a:e6:15
>>>> | | ip-addr: 192.168.2.199
>>>> | | subnet: 255.255.255.255
>>>> | | gateway: 255.255.255.255
>>>> | | gpsdo: none
>>>> | | serial: F4A09C
>>>> | | FW Version: 12.4
>>>> | | FPGA Version: 10.1
>>>>
>>>> What could the cause of this behaviour be? Are there only certain
>>>> combination of values that work? What do I need to do to make
>>>> uhd_tx_iq_balance not hang right before 790MHz?
>>>>
>>>> Thanks for you consideration.
>>>>
>>>> Regards,
>>>>
>>>> Urban Hakansson
>>>> Senior Software Engineer
>>>> Tecore Networks
>>>> Phone: +1 410 872 6315
>>>> Fax: +1 410 872 6010
>>>> Email: [email protected]
>>>>
>>>>
>>>> Urban Hakansson Senior Software Engineer Tecore Networks Phone: +1 410
>>>> 872 6315 <%2B1%20410%20872%206315> Fax: +1 410 872 6010 Email:
>>>> [email protected]
>>>>
>>>> Urban Hakansson
>>>> Senior Software Engineer
>>>> Tecore Networks
>>>> Phone: +1 410 872 6315
>>>> Fax: +1 410 872 6010
>>>> Email: [email protected]
>>>>
>>>>
>>>>
>>>>
>>>> This e-mail may contain privileged, confidential, copyrighted or
>>>> other legally protected information, and is intended exclusively for the
>>>> intended recipient. If you are not the intended recipient (even if the
>>>> e-mail address above is yours), you may not review, store, use, copy,
>>>> disclose or retransmit it in any form. If you are not the intended
>>>> recipient or otherwise have received this by mistake, please immediately
>>>> notify the sender by return e-mail (or [email protected]), then
>>>> delete the message in its entirety. Thank you.
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>>
>>>
>>>
>>>
>>> This e-mail may contain privileged, confidential, copyrighted or other
>>> legally protected information, and is intended exclusively for the intended
>>> recipient. If you are not the intended recipient (even if the e-mail
>>> address above is yours), you may not review, store, use, copy, disclose or
>>> retransmit it in any form. If you are not the intended recipient or
>>> otherwise have received this by mistake, please immediately notify the
>>> sender by return e-mail (or [email protected]), then delete the
>>> message in its entirety. Thank you.
>>>
>>>
>>
>>
>>
>> This e-mail may contain privileged, confidential, copyrighted or other
>> legally protected information, and is intended exclusively for the intended
>> recipient. If you are not the intended recipient (even if the e-mail
>> address above is yours), you may not review, store, use, copy, disclose or
>> retransmit it in any form. If you are not the intended recipient or
>> otherwise have received this by mistake, please immediately notify the
>> sender by return e-mail (or [email protected]), then delete the
>> message in its entirety. Thank you.
>>
>>
>
>
>
> This e-mail may contain privileged, confidential, copyrighted or other
> legally protected information, and is intended exclusively for the intended
> recipient. If you are not the intended recipient (even if the e-mail
> address above is yours), you may not review, store, use, copy, disclose or
> retransmit it in any form. If you are not the intended recipient or
> otherwise have received this by mistake, please immediately notify the
> sender by return e-mail (or [email protected]), then delete the message
> in its entirety. Thank you.
>
>
> _______________________________________________
> USRP-users mailing
> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> This e-mail may contain privileged, confidential, copyrighted or other
> legally protected information, and is intended exclusively for the intended
> recipient. If you are not the intended recipient (even if the e-mail
> address above is yours), you may not review, store, use, copy, disclose or
> retransmit it in any form. If you are not the intended recipient or
> otherwise have received this by mistake, please immediately notify the
> sender by return e-mail (or [email protected]), then delete the message
> in its entirety. Thank you.
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141023/361aee0d/attachment-0001.html>
------------------------------
Message: 7
Date: Thu, 23 Oct 2014 16:24:42 -0400 (EDT)
From: Urban Hakansson <[email protected]>
To: Michael West <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] uhd_cal_tx_iq_balance skips wide frequency
range
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Michael,
That looks great. That is the result I had expected. I looks like I may just
have to get a new SBX daughter board.
Q. How does reducing the RX gain setting for the SBX board from 25 to 15 in
usrp_cal_utils.hpp help when calibrating the TX path?
Urban
----- Original Message -----
From: "Michael West" <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "Urban Hakansson" <[email protected]>, "[email protected]"
<[email protected]>
Sent: Thursday, October 23, 2014 3:35:55 PM
Subject: Re: [USRP-users] uhd_cal_tx_iq_balance skips wide frequency range
Thanks for the data sheet info, Marcus. Yes, it looks like the SBX board I
grabbed was not so good. I grabbed another SBX and got much better results:
P_(fc-f)/P_(fc+f)(dB)
c(MHz) uncalibrated calibrated
------ ------------ ----------
700 -35 -50
800 -30 -50
900 -39 -52
1000 -40 -50
1100 -38 -52
1200 -35 -51
1300 -39 -50
1400 -40 -52
1500 -38 -49
1600 -32 -50
1700 -30 -50
1800 -28 -49
1900 -31 -50
2000 -34 -50
2100 -34 -48
2200 -33 -49
2300 -36 -47
2400 -36 -55
2500 -36 -52
2600 -37 -55
2700 -36 -53
2800 -36 -53
2900 -35 -53
3000 -36 -53
So it looks like getting at least -40 dB of suppression is a very reasonable
expectation after all.
I did, however, find an issue in the calibration utility. At the lower
frequencies (<2 GHz), the signal was saturated and the calibration was
resulting bad correction values. To calibrate the board successfully, I changed
the UHD code to reduce the RX gain setting for the SBX board from 25 to 15 in
the calibration utilities (changed line 103 of host/utils/usrp_cal_utils.hpp to
be "usrp->set_rx_gain(15)").
Regards,
Michael
On Thu, Oct 23, 2014 at 11:00 AM, Marcus D. Leech via USRP-users <
[email protected] > wrote:
On 10/23/2014 01:56 PM, Urban Hakansson wrote:
<blockquote>
I just read
http://www.analog.com/static/imported-files/application_notes/AN-1100.pdf and
from what I understand I/Q DAC gain/phase mismatch can also contribute to the
undesired sideband I am observing. So it may not be it is the SBX
daughter-board (the IQ modulator in particular) that alone creates the
undesired sideband, it could be that the N210 motherboard have a mismatched
pair of DACs. Is that correct or am I completely missing something?
The DAC that is used is a dual synchronized DAC. I wouldn't expect significant
phase errors, but there could be very-small amplitude errors.
But the calibration should null all components that are contributing,
regardless of their source.
<blockquote>
From: "Marcus D. Leech via USRP-users" <[email protected]>
To: [email protected]
Sent: Thursday, October 23, 2014 10:42:51 AM
Subject: Re: [USRP-users] uhd_cal_tx_iq_balance skips wide frequency range
On 10/23/2014 10:31 AM, Urban Hakansson via USRP-users wrote:
<blockquote>
Hi Michael,
Thanks for running the test on your N210+SBX setup.
Nothing was connected to the N210 when I did the calibration.
mleech sent me a link to the mixer that is used on the SBX daughter-board,
http://www.analog.com/static/imported-files/data_sheets/ADL5375.pdf
Based on my understanding of the data sheet we should both expect better
performance than ~ 20dB suppression from the SBX daughter-board for all bands.
Considering your test results, My SBX is certainly much worse than yours, so to
conclude, it is likely I have a bad SBX daughter board, but you may have one
too.
Regards,
Urban
</blockquote>
There's a handy chart on page 5 of:
http://www.analog.com/static/imported-files/application_notes/AN-1039.pdf
Showing image-suppression characteristics for various phase/amplitude errors
The whole field of I/Q imbalance estimation (and the corrections that proceed
from those estimates) is one in which there isn't wide, solid, agreement
on the approach, and the approaches vary depending on application.
I do wonder whether sometimes the estimates are thrown-off by LO spurs causing
false responses that are unrelated to quadrature balance.
<blockquote>
From: "Michael West" <[email protected]>
To: "Urban Hakansson" <[email protected]>
Cc: "[email protected]" <[email protected]>
Sent: Wednesday, October 22, 2014 10:51:27 PM
Subject: Re: [USRP-users] uhd_cal_tx_iq_balance skips wide frequency range
Hi Urban,
Thanks for the information and the flow graph. I grabbed an N210+SBX and a
spectrum analyzer to reproduce your test. After running the calibration, I
observed the following on my set up:
c(MHz) P_(fc-f)/P_(fc+f)(dB)
700 -22
800 -32
900 -22
1000 -27
1100 -34
1200 -23
1300 -29
1400 -23
1500 -26
1600 -27
1700 -32
1800 -47
1900 -47
2000 -47
2100 -46
2200 -45
2300 -45
2400 -44
2500 -43
2600 -43
2700 -43
2800 -42
2900 -42
3000 -42
The bottom line is that it looks as to the -40 dB or better across all bands is
not realistic for an N210+SBX set up. But it does look like your particular SBX
is a bit worse off than the one I tested. I was able to get at least -22 dB
across the same range. The anomalies you are seeing at 2100 and 2200 MHz are
particularly strange. Just to be clear, the calibration should be done with
nothing connected to the SBX. If something was connected, you should run
calibration again. If you believe the board to be bad, contact
[email protected] and they will help you further.
Best regards,
Michael
On Wed, Oct 22, 2014 at 8:37 AM, Urban Hakansson < [email protected] >
wrote:
<blockquote>
Micahel,
Do you mean the if condition in for example uhd_cal_tx_iq_balance should be if
( best_suppression > initial_suppression ) ?
To answer your questions. I am now focusing on calibrating the TX path.
I generate x(t) = r*exp(j*2*pi*f*t) using a very simple Gnuradio flowgraph that
I attach. As you can see in the flowgraph, I set r = 0.1 and f = 1.25MHz. I set
the sample rate to 6.25 MHz (100MHz/(2^4)) to make it as easy for the FPGA
filters as possible when interpolating, and the analog tx gain to 0 dB. Given
the amplitude and tx gain settings I should be operating well within the linear
range of the amplifier.
I sweep the center frequency fc from 700 MHz to 3GHz in 100MHz steps.
I measure the IQ imbalance by connecting my N210 TX/RX port to a Rohde Schwarz
FSP Spectrum Analyzer with 50 Ohm input load using a low loss Coaxial Cable
(LMR-400 3/8").
I measure the power of the desired signal x(t) = r*exp(j*2*pi*(fc+f)*t), and
the undesired replica x'(t) = r'*exp(j*2*pi*(fc-f)*t), putting a spectrum
analyzer marker on each peak, and see what the delta is.
I tried running free without calibration script and the result was worse.
with 200kHz calibration
script without calibration scripts
c (MHz) P_(fc-f)/P_(fc+f) (dB) P_(fc-f)/P_(fc+f) (dB)
700 -40 -18
800 -23 -14
900 -17 -11
1000 -22 -13
1100 -27 -15
1200 -40 -20
1300 -12 -16
1400 -15 -23
1500 -40 -18
1600 -40 -14
1700 -21 -11
1800 -13 -11
1900 -40 -20
2000 to small to measure (-infinity) -23
2100 -12 -15
2200 -14 -19
2300 to small to measure (-infinity) -21
2400 to small to measure (-infinity) -24
2500 to small to measure (-infinity) -27
2600 to small to measure (-infinity) -29
2700 to small to measure (-infinity) -35
2800 to small to measure (-infinity) to small to measure (-infinity)
2900 to small to measure (-infinity) to small to measure (-infinity)
3000 to small to measure (-infinity) -33
So calibrating did improve the IQ balance but not enough it seems. I expected
the suppression to be at least 40dB.
I attach the tx calibration scripts for 200kHz step size, when using if
(best_suppression > 15) as the criterion.
Urban
From: "Michael West" < [email protected] >
To: "Urban Hakansson" < [email protected] >
Cc: " [email protected] " < [email protected] >
Sent: Tuesday, October 21, 2014 7:51:10 PM
Subject: Re: [USRP-users] uhd_cal_tx_iq_balance skips wide frequency range
Hi Urban,
First, I honestly do not know why the value of 30 was hard coded. I believe the
"initial_suppression" value should be used, which is the measured value with no
correction applied.
Regarding the IQ imbalance you are seeing, I have a few questions. Is it on TX
or RX? How are you measuring it? What is your set up (are you looping back or
connected to a signal generator and/or spectrum analyzer)? What gain level(s)
are you using? Also, sharing the flowgraph you are using would help.
Best regards,
Michael
On Tue, Oct 21, 2014 at 6:58 AM, Urban Hakansson < [email protected] >
wrote:
<blockquote>
Michael,
Thanks for your reply.
We changed the threshold to 15 and now we get calibration data written to file
for each freq step.
Q: What is the reason the threshold is set to 30? Is there any reason I should
not set it to 15 or any other value? Is there is a reason this parameter value
is hard coded and is not something you can pass in as an argument?
Regardless, the original problem I wanted to solve by calibrating in finer
frequency steps still remains, namely, the residual IQ imbalance is too large
in certain bands.
I calibrated the entire N210+SBX frequency range from 400 to 4400 MHz in 200kHz
steps, thinking that should do it.
To check for any residual IQ imbalance I then generated a complex exponential
with amplitude 0.1 and frequency f = 1.25 MHz, sampled at Fs = 6.25 MHz, and
set tx gain to 0dB (using GnuRadio flowdiagram).
I varied the center frequency fc (LO) in 100MHz steps from 700 MHz to 3000 MHz,
measured the power-ratio between fc+f and the undesired replica at fc-f which
is due to residual IQ imbalance.
fc (MHz) P_(fc-f)/P_(fc+f) (dB)
700
-40
800
-23
900 -17
1000 -22
1100 -27
1200 -40
1300 -12
1400 -15
1500 -40
1600 -40
1700 -21
1800 -13
1900 -40
2000 to small to measure (-infinity)
2100 -12
2200 -14
2300 to small to measure (-infinity)
... ...
3000 to small to measure (-infinity)
I thought that by calibrating the residual IQ imbalance would result in a power
ratio of at least < -40dB between the undesired replica at fc-f and the
original signal at fc+f.
Maybe my expectations are too high, or perhaps I have a bad SBX daughterboard?
Q: What results should I realistically be able to expect using the N210 + SBX
combination?
Regards,
Urban
From: "Michael West" < [email protected] >
To: "Urban Hakansson" < [email protected] >
Cc: " [email protected] " < [email protected] >
Sent: Thursday, October 9, 2014 3:03:08 PM
Subject: Re: [USRP-users] uhd_cal_tx_iq_balance skips wide frequency range
Hi Urban,
If I am understanding you correctly, you are saying that there is no
calibration data for those frequencies in the resulting file. That does not
mean the frequencies are being skipped by the utility. That only means that a
suppression of over 30 dB could not be achieved for those frequencies, so no
correction data was saved. You can set a lower threshold for the minimum
suppression by changing the value in the following line in each IQ calibration
utility:
if (best_suppression > 30){ //most likely valid, keep result
Best regards,
Michael
On Thu, Oct 9, 2014 at 8:57 AM, Urban Hakansson via USRP-users <
[email protected] > wrote:
<blockquote>
Hi everybody,
I am trying to calibrate my N210 SBX daughterboard using the three calibration
scripts uhd_cal_rx_iq_balance, uhd_cal_tx_iq_balance,and uhd_cal_tx_dc_offset
using different values for freq_start, freq_stop, and freq_step.
uhd_cal_tx_iq_balance utility that is not behaving as I expected.
(uhd_cal_rx_iq_balance and uhd_cal_tx_dc_offset give me no problems).
If I run uhd_cal_tx_iq_balance with any other values besides the default values
it will skip approximately 300MHz of frequencies from 790 MHz to ~ 1100MHz.
Here are a few of my attempts.
uhd_cal_tx_iq_balance --freq_start 500000000
uhd_cal_tx_iq_balance --freq_start 600000000
uhd_cal_tx_iq_balance --freq_start 700000000
uhd_cal_tx_iq_balance --freq_start 785000000
uhd_cal_tx_iq_balance --verbose --freq_step 100000
uhd_cal_tx_iq_balance --verbose --freq_step 110000
uhd_cal_tx_iq_balance --verbose --freq_step 225000
uhd_cal_tx_iq_balance --verbose --freq_step 900000
uhd_cal_tx_iq_balance --verbose --freq_step 1000000
uhd_cal_tx_iq_balance --verbose --freq_step 1100000
uhd_cal_tx_iq_balance --verbose --freq_step 2000000
...
uhd_cal_tx_iq_balance --verbose --freq_step 7300000
uhd_cal_tx_iq_balance always stops just before 790MHz and just sits there, but
does not abort, and after a really long time continues at ~ 1100MHz and
continues all the way to 4370MHz without any further gaps.
I attach the calibration scripts I am using and the three csv files for one
example, uhd_cal_tx_iq_balance --verbose --freq_step 225000.
General background information about my environment:
Fedora 17 Linux; GNU C++ version 4.7.0 20120507 (Red Hat 4.7.0-5);
Boost_104800; UHD_003.007.001-0-unknown
N210 informationfrom uhd_usrp_probe:
| Device: USRP2 / N-Series Device
| _____________________________________________________
| /
| | Mboard: N210r4
| | hardware: 2577
| | mac-addr: 00:80:2f:0a:e6:15
| | ip-addr: 192.168.2.199
| | subnet: 255.255.255.255
| | gateway: 255.255.255.255
| | gpsdo: none
| | serial: F4A09C
| | FW Version: 12.4
| | FPGA Version: 10.1
What could the cause of this behaviour be? Are there only certain combination
of values that work? What do I need to do to make uhd_tx_iq_balance not hang
right before 790MHz?
Thanks for you consideration.
Regards,
Urban Hakansson
Senior Software Engineer
Tecore Networks
Phone: +1 410 872 6315
Fax: +1 410 872 6010
Email: [email protected]
Urban Hakansson Senior Software Engineer Tecore Networks Phone: +1 410 872 6315
Fax: +1 410 872 6010 Email: [email protected]
Urban Hakansson
Senior Software Engineer
Tecore Networks
Phone: +1 410 872 6315
Fax: +1 410 872 6010
Email: [email protected]
This e-mail may contain privileged, confidential, copyrighted or other legally
protected information, and is intended exclusively for the intended recipient.
If you are not the intended recipient (even if the e-mail address above is
yours), you may not review, store, use, copy, disclose or retransmit it in any
form. If you are not the intended recipient or otherwise have received this by
mistake, please immediately notify the sender by return e-mail (or
[email protected] ), then delete the message in its entirety. Thank you.
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
</blockquote>
This e-mail may contain privileged, confidential, copyrighted or other legally
protected information, and is intended exclusively for the intended recipient.
If you are not the intended recipient (even if the e-mail address above is
yours), you may not review, store, use, copy, disclose or retransmit it in any
form. If you are not the intended recipient or otherwise have received this by
mistake, please immediately notify the sender by return e-mail (or
[email protected] ), then delete the message in its entirety. Thank you.
</blockquote>
This e-mail may contain privileged, confidential, copyrighted or other legally
protected information, and is intended exclusively for the intended recipient.
If you are not the intended recipient (even if the e-mail address above is
yours), you may not review, store, use, copy, disclose or retransmit it in any
form. If you are not the intended recipient or otherwise have received this by
mistake, please immediately notify the sender by return e-mail (or
[email protected] ), then delete the message in its entirety. Thank you.
</blockquote>
This e-mail may contain privileged, confidential, copyrighted or other legally
protected information, and is intended exclusively for the intended recipient.
If you are not the intended recipient (even if the e-mail address above is
yours), you may not review, store, use, copy, disclose or retransmit it in any
form. If you are not the intended recipient or otherwise have received this by
mistake, please immediately notify the sender by return e-mail (or
[email protected] ), then delete the message in its entirety. Thank you.
_______________________________________________
USRP-users mailing list [email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
</blockquote>
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
This e-mail may contain privileged, confidential, copyrighted or other legally
protected information, and is intended exclusively for the intended recipient.
If you are not the intended recipient (even if the e-mail address above is
yours), you may not review, store, use, copy, disclose or retransmit it in any
form. If you are not the intended recipient or otherwise have received this by
mistake, please immediately notify the sender by return e-mail (or
[email protected] ), then delete the message in its entirety. Thank you.
</blockquote>
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
</blockquote>
This
e-mail may contain privileged, confidential, copyrighted or other legally
protected information, and is intended exclusively for the intended recipient.
If you are not the intended recipient (even if the e-mail address above is
yours), you may not review, store, use, copy, disclose or retransmit it in any
form. If you are not the intended recipient or otherwise have received this by
mistake, please immediately notify the sender by return e-mail (or
[email protected]), then delete the message in its entirety. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141023/0c9b5750/attachment-0001.html>
------------------------------
Message: 8
Date: Thu, 23 Oct 2014 14:09:37 -0700
From: Michael West <[email protected]>
To: Urban Hakansson <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] uhd_cal_tx_iq_balance skips wide frequency
range
Message-ID:
<CAM4xKrqcjKRA4XDen-mKwqhE94mh5Pq1dZc-Rf=ayabdnlm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Urban,
Yes, it looks like your SBX may be bad.
For frequencies under 2 GHz and an RX gain of 25, the RX signal was
saturating which resulted in incorrect phase and amplitude correction
values. That meant that for some frequencies the suppression would get
worse when the corrections were applied. I am filing a bug against UHD for
that, so it will hopefully be fixed very soon.
Regards,
Michael
On Thu, Oct 23, 2014 at 1:24 PM, Urban Hakansson <[email protected]>
wrote:
> Michael,
>
> That looks great. That is the result I had expected. I looks like I may
> just have to get a new SBX daughter board.
>
> Q. How does reducing the RX gain setting for the SBX board from 25 to 15
> in usrp_cal_utils.hpp help when calibrating the TX path?
>
> Urban
>
> ------------------------------
> *From: *"Michael West" <[email protected]>
> *To: *"Marcus D. Leech" <[email protected]>
> *Cc: *"Urban Hakansson" <[email protected]>, "
> [email protected]" <[email protected]>
> *Sent: *Thursday, October 23, 2014 3:35:55 PM
>
> *Subject: *Re: [USRP-users] uhd_cal_tx_iq_balance skips wide frequency
> range
>
> Thanks for the data sheet info, Marcus. Yes, it looks like the SBX board
> I grabbed was not so good. I grabbed another SBX and got much better
> results:
>
> P_(fc-f)/P_(fc+f)(dB)
> c(MHz) uncalibrated calibrated
> ------ ------------ ----------
> 700 -35 -50
> 800 -30 -50
> 900 -39 -52
> 1000 -40 -50
> 1100 -38 -52
> 1200 -35 -51
> 1300 -39 -50
> 1400 -40 -52
> 1500 -38 -49
> 1600 -32 -50
> 1700 -30 -50
> 1800 -28 -49
> 1900 -31 -50
> 2000 -34 -50
> 2100 -34 -48
> 2200 -33 -49
> 2300 -36 -47
> 2400 -36 -55
> 2500 -36 -52
> 2600 -37 -55
> 2700 -36 -53
> 2800 -36 -53
> 2900 -35 -53
> 3000 -36 -53
>
> So it looks like getting at least -40 dB of suppression is a very
> reasonable expectation after all.
>
> I did, however, find an issue in the calibration utility. At the lower
> frequencies (<2 GHz), the signal was saturated and the calibration was
> resulting bad correction values. To calibrate the board successfully, I
> changed the UHD code to reduce the RX gain setting for the SBX board from
> 25 to 15 in the calibration utilities (changed line 103 of
> host/utils/usrp_cal_utils.hpp to be "usrp->set_rx_gain(15)").
>
> Regards,
> Michael
>
> On Thu, Oct 23, 2014 at 11:00 AM, Marcus D. Leech via USRP-users <
> [email protected]> wrote:
>
>> On 10/23/2014 01:56 PM, Urban Hakansson wrote:
>>
>> I just read
>> http://www.analog.com/static/imported-files/application_notes/AN-1100.pdf
>> and from what I understand I/Q DAC gain/phase mismatch can also contribute
>> to the undesired sideband I am observing. So it may not be it is the SBX
>> daughter-board (the IQ modulator in particular) that alone creates the
>> undesired sideband, it could be that the N210 motherboard have a mismatched
>> pair of DACs. Is that correct or am I completely missing something?
>>
>> The DAC that is used is a dual synchronized DAC. I wouldn't expect
>> significant phase errors, but there could be very-small amplitude errors.
>>
>> But the calibration should null all components that are contributing,
>> regardless of their source.
>>
>>
>>
>>
>> ------------------------------
>> *From: *"Marcus D. Leech via USRP-users" <[email protected]>
>> <[email protected]>
>> *To: *[email protected]
>> *Sent: *Thursday, October 23, 2014 10:42:51 AM
>> *Subject: *Re: [USRP-users] uhd_cal_tx_iq_balance skips wide frequency
>> range
>>
>> On 10/23/2014 10:31 AM, Urban Hakansson via USRP-users wrote:
>>
>> Hi Michael,
>>
>> Thanks for running the test on your N210+SBX setup.
>>
>> Nothing was connected to the N210 when I did the calibration.
>>
>> mleech sent me a link to the mixer that is used on the SBX
>> daughter-board,
>> http://www.analog.com/static/imported-files/data_sheets/ADL5375.pdf
>>
>> Based on my understanding of the data sheet we should both expect better
>> performance than ~ 20dB suppression from the SBX daughter-board for all
>> bands.
>>
>> Considering your test results, My SBX is certainly much worse than yours,
>> so to conclude, it is likely I have a bad SBX daughter board, but you may
>> have one too.
>>
>> Regards,
>>
>> Urban
>>
>> There's a handy chart on page 5 of:
>>
>> http://www.analog.com/static/imported-files/application_notes/AN-1039.pdf
>>
>> Showing image-suppression characteristics for various phase/amplitude
>> errors
>>
>> The whole field of I/Q imbalance estimation (and the corrections that
>> proceed from those estimates) is one in which there isn't wide, solid,
>> agreement
>> on the approach, and the approaches vary depending on application.
>>
>> I do wonder whether sometimes the estimates are thrown-off by LO spurs
>> causing false responses that are unrelated to quadrature balance.
>>
>>
>> ------------------------------
>> *From: *"Michael West" <[email protected]> <[email protected]>
>> *To: *"Urban Hakansson" <[email protected]> <[email protected]>
>> *Cc: *"[email protected]" <[email protected]>
>> <[email protected]> <[email protected]>
>> *Sent: *Wednesday, October 22, 2014 10:51:27 PM
>> *Subject: *Re: [USRP-users] uhd_cal_tx_iq_balance skips wide frequency
>> range
>>
>> Hi Urban,
>>
>> Thanks for the information and the flow graph. I grabbed an N210+SBX
>> and a spectrum analyzer to reproduce your test. After running the
>> calibration, I observed the following on my set up:
>>
>> c(MHz) P_(fc-f)/P_(fc+f)(dB)
>> 700 -22
>> 800 -32
>> 900 -22
>> 1000 -27
>> 1100 -34
>> 1200 -23
>> 1300 -29
>> 1400 -23
>> 1500 -26
>> 1600 -27
>> 1700 -32
>> 1800 -47
>> 1900 -47
>> 2000 -47
>> 2100 -46
>> 2200 -45
>> 2300 -45
>> 2400 -44
>> 2500 -43
>> 2600 -43
>> 2700 -43
>> 2800 -42
>> 2900 -42
>> 3000 -42
>>
>> The bottom line is that it looks as to the -40 dB or better across all
>> bands is not realistic for an N210+SBX set up. But it does look like your
>> particular SBX is a bit worse off than the one I tested. I was able to get
>> at least -22 dB across the same range. The anomalies you are seeing at
>> 2100 and 2200 MHz are particularly strange. Just to be clear, the
>> calibration should be done with nothing connected to the SBX. If something
>> was connected, you should run calibration again. If you believe the board
>> to be bad, contact [email protected] and they will help you further.
>>
>> Best regards,
>> Michael
>>
>> On Wed, Oct 22, 2014 at 8:37 AM, Urban Hakansson <[email protected]>
>> wrote:
>>
>>> Micahel,
>>>
>>> Do you mean the if condition in for example uhd_cal_tx_iq_balance should
>>> be if ( best_suppression > initial_suppression ) ?
>>>
>>> To answer your questions. I am now focusing on calibrating the TX path.
>>>
>>> I generate x(t) = r*exp(j*2*pi*f*t) using a very simple Gnuradio
>>> flowgraph that I attach. As you can see in the flowgraph, I set r = 0.1
>>> and f = 1.25MHz. I set the sample rate to 6.25 MHz (100MHz/(2^4)) to make
>>> it as easy for the FPGA filters as possible when interpolating, and the
>>> analog tx gain to 0 dB. Given the amplitude and tx gain settings I should
>>> be operating well within the linear range of the amplifier.
>>>
>>> I sweep the center frequency fc from 700 MHz to 3GHz in 100MHz steps.
>>>
>>> I measure the IQ imbalance by connecting my N210 TX/RX port to a Rohde
>>> Schwarz FSP Spectrum Analyzer with 50 Ohm input load using a low loss
>>> Coaxial Cable (LMR-400 3/8").
>>>
>>> I measure the power of the desired signal x(t) = r*exp(j*2*pi*(fc+f)*t),
>>> and the undesired replica x'(t) = r'*exp(j*2*pi*(fc-f)*t), putting a
>>> spectrum analyzer marker on each peak, and see what the delta is.
>>>
>>> I tried running free without calibration script and the result was worse.
>>>
>>> with 200kHz calibration
>>> script without calibration scripts
>>> c (MHz) P_(fc-f)/P_(fc+f) (dB) P_(fc-f)/P_(fc+f) (dB)
>>> 700 -40 -18
>>> 800 -23 -14
>>> 900 -17 -11
>>> 1000 -22 -13
>>> 1100 -27 -15
>>> 1200 -40 -20
>>> 1300 -12 -16
>>> 1400 -15 -23
>>> 1500 -40 -18
>>> 1600 -40 -14
>>> 1700 -21 -11
>>> 1800 -13 -11
>>> 1900 -40 -20
>>> 2000 to small to measure (-infinity) -23
>>> 2100 -12 -15
>>> 2200 -14 -19
>>> 2300 to small to measure (-infinity) -21
>>> 2400 to small to measure (-infinity) -24
>>> 2500 to small to measure (-infinity) -27
>>> 2600 to small to measure (-infinity) -29
>>> 2700 to small to measure (-infinity) -35
>>> 2800 to small to measure (-infinity) to small to measure (-infinity)
>>> 2900 to small to measure (-infinity) to small to measure (-infinity)
>>> 3000 to small to measure (-infinity) -33
>>>
>>> So calibrating did improve the IQ balance but not enough it seems. I
>>> expected the suppression to be at least 40dB.
>>>
>>> I attach the tx calibration scripts for 200kHz step size, when using if
>>> (best_suppression > 15) as the criterion.
>>>
>>> Urban
>>> ------------------------------
>>> *From: *"Michael West" <[email protected]>
>>> *To: *"Urban Hakansson" <[email protected]>
>>> *Cc: *"[email protected]" <[email protected]>
>>> *Sent: *Tuesday, October 21, 2014 7:51:10 PM
>>>
>>> *Subject: *Re: [USRP-users] uhd_cal_tx_iq_balance skips wide frequency
>>> range
>>>
>>> Hi Urban,
>>>
>>> First, I honestly do not know why the value of 30 was hard coded. I
>>> believe the "initial_suppression" value should be used, which is the
>>> measured value with no correction applied.
>>>
>>> Regarding the IQ imbalance you are seeing, I have a few questions. Is
>>> it on TX or RX? How are you measuring it? What is your set up (are you
>>> looping back or connected to a signal generator and/or spectrum
>>> analyzer)? What gain level(s) are you using? Also, sharing the flowgraph
>>> you are using would help.
>>>
>>> Best regards,
>>> Michael
>>>
>>> On Tue, Oct 21, 2014 at 6:58 AM, Urban Hakansson <[email protected]>
>>> wrote:
>>>
>>>> Michael,
>>>>
>>>> Thanks for your reply.
>>>>
>>>> We changed the threshold to 15 and now we get calibration data written
>>>> to file for each freq step.
>>>>
>>>> Q: What is the reason the threshold is set to 30? Is there any reason
>>>> I should not set it to 15 or any other value? Is there is a reason this
>>>> parameter value is hard coded and is not something you can pass in as an
>>>> argument?
>>>>
>>>> Regardless, the original problem I wanted to solve by calibrating in
>>>> finer frequency steps still remains, namely, the residual IQ imbalance is
>>>> too large in certain bands.
>>>>
>>>> I calibrated the entire N210+SBX frequency range from 400 to 4400 MHz
>>>> in 200kHz steps, thinking that should do it.
>>>>
>>>> To check for any residual IQ imbalance I then generated a complex
>>>> exponential with amplitude 0.1 and frequency f = 1.25 MHz, sampled at Fs =
>>>> 6.25 MHz, and set tx gain to 0dB (using GnuRadio flowdiagram).
>>>>
>>>> I varied the center frequency fc (LO) in 100MHz steps from 700 MHz to
>>>> 3000 MHz, measured the power-ratio between fc+f and the undesired replica
>>>> at fc-f which is due to residual IQ imbalance.
>>>>
>>>> fc (MHz) P_(fc-f)/P_(fc+f) (dB)
>>>> 700
>>>> -40
>>>> 800
>>>> -23
>>>> 900 -17
>>>> 1000 -22
>>>> 1100 -27
>>>> 1200 -40
>>>> 1300 -12
>>>> 1400 -15
>>>> 1500 -40
>>>> 1600 -40
>>>> 1700 -21
>>>> 1800 -13
>>>> 1900 -40
>>>> 2000 to small to measure (-infinity)
>>>> 2100 -12
>>>> 2200 -14
>>>> 2300 to small to measure (-infinity)
>>>> ... ...
>>>> 3000 to small to measure (-infinity)
>>>>
>>>> I thought that by calibrating the residual IQ imbalance would result in
>>>> a power ratio of at least < -40dB between the undesired replica at fc-f and
>>>> the original signal at fc+f.
>>>>
>>>> Maybe my expectations are too high, or perhaps I have a bad SBX
>>>> daughterboard?
>>>>
>>>> Q: What results should I realistically be able to expect using the N210
>>>> + SBX combination?
>>>>
>>>> Regards,
>>>>
>>>> Urban
>>>>
>>>> ------------------------------
>>>> *From: *"Michael West" <[email protected]>
>>>> *To: *"Urban Hakansson" <[email protected]>
>>>> *Cc: *"[email protected]" <[email protected]>
>>>> *Sent: *Thursday, October 9, 2014 3:03:08 PM
>>>> *Subject: *Re: [USRP-users] uhd_cal_tx_iq_balance skips wide frequency
>>>> range
>>>>
>>>>
>>>> Hi Urban,
>>>>
>>>> If I am understanding you correctly, you are saying that there is no
>>>> calibration data for those frequencies in the resulting file. That does
>>>> not mean the frequencies are being skipped by the utility. That only means
>>>> that a suppression of over 30 dB could not be achieved for those
>>>> frequencies, so no correction data was saved. You can set a lower
>>>> threshold for the minimum suppression by changing the value in the
>>>> following line in each IQ calibration utility:
>>>>
>>>> if (best_suppression > 30){ //most likely valid, keep result
>>>>
>>>> Best regards,
>>>> Michael
>>>>
>>>> On Thu, Oct 9, 2014 at 8:57 AM, Urban Hakansson via USRP-users <
>>>> [email protected]> wrote:
>>>>
>>>>> Hi everybody,
>>>>>
>>>>> I am trying to calibrate my N210 SBX daughterboard using the three
>>>>> calibration scripts uhd_cal_rx_iq_balance, uhd_cal_tx_iq_balance,and
>>>>> uhd_cal_tx_dc_offset using different values for freq_start, freq_stop, and
>>>>> freq_step.
>>>>>
>>>>> uhd_cal_tx_iq_balance utility that is not behaving as I expected.
>>>>> (uhd_cal_rx_iq_balance and uhd_cal_tx_dc_offset give me no problems).
>>>>>
>>>>> If I run uhd_cal_tx_iq_balance with any other values besides the
>>>>> default values it will skip approximately 300MHz of frequencies from 790
>>>>> MHz to ~ 1100MHz.
>>>>>
>>>>> Here are a few of my attempts.
>>>>>
>>>>> uhd_cal_tx_iq_balance --freq_start 500000000
>>>>> uhd_cal_tx_iq_balance --freq_start 600000000
>>>>> uhd_cal_tx_iq_balance --freq_start 700000000
>>>>> uhd_cal_tx_iq_balance --freq_start 785000000
>>>>> uhd_cal_tx_iq_balance --verbose --freq_step 100000
>>>>> uhd_cal_tx_iq_balance --verbose --freq_step 110000
>>>>> uhd_cal_tx_iq_balance --verbose --freq_step 225000
>>>>> uhd_cal_tx_iq_balance --verbose --freq_step 900000
>>>>> uhd_cal_tx_iq_balance --verbose --freq_step 1000000
>>>>> uhd_cal_tx_iq_balance --verbose --freq_step 1100000
>>>>> uhd_cal_tx_iq_balance --verbose --freq_step 2000000
>>>>> ...
>>>>> uhd_cal_tx_iq_balance --verbose --freq_step 7300000
>>>>>
>>>>> uhd_cal_tx_iq_balance always stops just before 790MHz and just sits
>>>>> there, but does not abort, and after a really long time continues at ~
>>>>> 1100MHz and continues all the way to 4370MHz without any further gaps.
>>>>>
>>>>> I attach the calibration scripts I am using and the three csv files
>>>>> for one example, uhd_cal_tx_iq_balance --verbose --freq_step 225000.
>>>>>
>>>>> General background information about my environment:
>>>>> Fedora 17 Linux; GNU C++ version 4.7.0 20120507 (Red Hat 4.7.0-5);
>>>>> Boost_104800; UHD_003.007.001-0-unknown
>>>>>
>>>>> N210 informationfrom uhd_usrp_probe:
>>>>> | Device: USRP2 / N-Series Device
>>>>> | _____________________________________________________
>>>>> | /
>>>>> | | Mboard: N210r4
>>>>> | | hardware: 2577
>>>>> | | mac-addr: 00:80:2f:0a:e6:15
>>>>> | | ip-addr: 192.168.2.199
>>>>> | | subnet: 255.255.255.255
>>>>> | | gateway: 255.255.255.255
>>>>> | | gpsdo: none
>>>>> | | serial: F4A09C
>>>>> | | FW Version: 12.4
>>>>> | | FPGA Version: 10.1
>>>>>
>>>>> What could the cause of this behaviour be? Are there only certain
>>>>> combination of values that work? What do I need to do to make
>>>>> uhd_tx_iq_balance not hang right before 790MHz?
>>>>>
>>>>> Thanks for you consideration.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Urban Hakansson
>>>>> Senior Software Engineer
>>>>> Tecore Networks
>>>>> Phone: +1 410 872 6315
>>>>> Fax: +1 410 872 6010
>>>>> Email: [email protected]
>>>>>
>>>>>
>>>>> Urban Hakansson Senior Software Engineer Tecore Networks Phone: +1
>>>>> 410 872 6315 <%2B1%20410%20872%206315> Fax: +1 410 872 6010 Email:
>>>>> [email protected]
>>>>>
>>>>> Urban Hakansson
>>>>> Senior Software Engineer
>>>>> Tecore Networks
>>>>> Phone: +1 410 872 6315
>>>>> Fax: +1 410 872 6010
>>>>> Email: [email protected]
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> This e-mail may contain privileged, confidential, copyrighted or
>>>>> other legally protected information, and is intended exclusively for the
>>>>> intended recipient. If you are not the intended recipient (even if the
>>>>> e-mail address above is yours), you may not review, store, use, copy,
>>>>> disclose or retransmit it in any form. If you are not the intended
>>>>> recipient or otherwise have received this by mistake, please immediately
>>>>> notify the sender by return e-mail (or [email protected]), then
>>>>> delete the message in its entirety. Thank you.
>>>>> _______________________________________________
>>>>> USRP-users mailing list
>>>>> [email protected]
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> This e-mail may contain privileged, confidential, copyrighted or other
>>>> legally protected information, and is intended exclusively for the intended
>>>> recipient. If you are not the intended recipient (even if the e-mail
>>>> address above is yours), you may not review, store, use, copy, disclose or
>>>> retransmit it in any form. If you are not the intended recipient or
>>>> otherwise have received this by mistake, please immediately notify the
>>>> sender by return e-mail (or [email protected]), then delete the
>>>> message in its entirety. Thank you.
>>>>
>>>>
>>>
>>>
>>>
>>> This e-mail may contain privileged, confidential, copyrighted or other
>>> legally protected information, and is intended exclusively for the intended
>>> recipient. If you are not the intended recipient (even if the e-mail
>>> address above is yours), you may not review, store, use, copy, disclose or
>>> retransmit it in any form. If you are not the intended recipient or
>>> otherwise have received this by mistake, please immediately notify the
>>> sender by return e-mail (or [email protected]), then delete the
>>> message in its entirety. Thank you.
>>>
>>>
>>
>>
>>
>> This e-mail may contain privileged, confidential, copyrighted or other
>> legally protected information, and is intended exclusively for the intended
>> recipient. If you are not the intended recipient (even if the e-mail
>> address above is yours), you may not review, store, use, copy, disclose or
>> retransmit it in any form. If you are not the intended recipient or
>> otherwise have received this by mistake, please immediately notify the
>> sender by return e-mail (or [email protected]), then delete the
>> message in its entirety. Thank you.
>>
>>
>> _______________________________________________
>> USRP-users mailing
>> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>> --
>> Marcus Leech
>> Principal Investigator
>> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>> This e-mail may contain privileged, confidential, copyrighted or other
>> legally protected information, and is intended exclusively for the intended
>> recipient. If you are not the intended recipient (even if the e-mail
>> address above is yours), you may not review, store, use, copy, disclose or
>> retransmit it in any form. If you are not the intended recipient or
>> otherwise have received this by mistake, please immediately notify the
>> sender by return e-mail (or [email protected]), then delete the
>> message in its entirety. Thank you.
>>
>>
>>
>> --
>> Marcus Leech
>> Principal Investigator
>> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
>
>
> This e-mail may contain privileged, confidential, copyrighted or other
> legally protected information, and is intended exclusively for the intended
> recipient. If you are not the intended recipient (even if the e-mail
> address above is yours), you may not review, store, use, copy, disclose or
> retransmit it in any form. If you are not the intended recipient or
> otherwise have received this by mistake, please immediately notify the
> sender by return e-mail (or [email protected]), then delete the message
> in its entirety. Thank you.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141023/be0b94e4/attachment-0001.html>
------------------------------
Message: 9
Date: Thu, 23 Oct 2014 19:10:36 -0400
From: Radio User <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Full Duplex vs. Half Duplex operation?
Message-ID:
<CA+rmjiHrLk_2ZB8bBZhokOsUP=bzwh1ve6eefyc1raohqu5...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Fellow USRPers..
I recently saw this snippet in ...share/doc/uhd/manual/html/dboards.html
-------------------------------------------------
Receive Antennas: *TX/RX* or *RX2*
- *Frontend 0:* Complex baseband signal for selected antenna
- *Note:* The user may set the receive antenna to be TX/RX or RX2.
However, when using a WBX board in full-duplex mode, the receive antenna
will always be set to RX2, regardless of the settings.
------------------------------------------------
When SoDaRadio sets the RX ant to "TX/RX" (via a call to set_rx_antenna)
there is no effect
(get_rx_antenna() returns "TX/RX" but the actual connection is still to
RX2). Apparently
the USRP FPGA and/or libuhd believes that the radio is in "full duplex"
mode.
What condition of the radio determines that the radio is operating in full
duplex mode?
Note that I'm not asking what "full duplex mode" means -- I'm asking how
the USRP hardware/software
determines that it is in full duplex mode.
rg
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141023/dd36a9cc/attachment-0001.html>
------------------------------
Message: 10
Date: Thu, 23 Oct 2014 16:47:01 -0700
From: Ian Buckley <[email protected]>
To: Radio User <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Full Duplex vs. Half Duplex operation?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Inside the FPGA there are two different state machines implemented in H/W
logic, one each to control Tx and Rx?they each change state based on received
packets, VITA times, buffer fullness, error conditions etc.
Each of these state machines drives a signal that shows when TX and RX are
active (or not). (Active would be defined as samples passing through the DSP
pipeline and data packets being packed/unpacked).
The TX and RX signals are routed to a variety of places including the so called
ATR GPIO blocks. The ATR GPIO blocks drive signals that in the case of WBX
directly controls the state of the 2 analog RF switches that route signals to
and from the SMA's.
The ATR GPIO blocks work in the following way?..they are essentially a look up
table that is programmed by the Host (UHD) with values that are to be driven
out on the various GPIO lines (that are configured as outputs) in each of 4
states: IDLE, RX, TX, FULL-DUPLEX
Thus S/W pre-programs the ATR GPIO blocks during configuration before radio
operation commences and then, once operation has commenced the various switch
configurations are changed as a direct result of state changes within the FPGA.
The actual switches are on the Grand Daughter board that mounts to the WBX. I
note BTW that there is a documentation error on the WBX schematics where its
states that "io_rx_05" is the GPIO controlling which SMA is used by RX?it is
infact "io_rx_15"
The gist of this is that in your case either: a) For some reason the ATR-GPIO
has not been programmed by UHD to select the correct SMA or b) The USRP is not
in the state you think it is (RX vs Full-Duplex)
Make sense?
-Ian
On Oct 23, 2014, at 4:10 PM, Radio User via USRP-users
<[email protected]> wrote:
> Fellow USRPers..
>
> I recently saw this snippet in ...share/doc/uhd/manual/html/dboards.html
> -------------------------------------------------
> Receive Antennas: TX/RX or RX2
>
> Frontend 0: Complex baseband signal for selected antenna
> Note: The user may set the receive antenna to be TX/RX or RX2. However, when
> using a WBX board in full-duplex mode, the receive antenna will always be set
> to RX2, regardless of the settings.
> ------------------------------------------------
>
> When SoDaRadio sets the RX ant to "TX/RX" (via a call to set_rx_antenna)
> there is no effect
> (get_rx_antenna() returns "TX/RX" but the actual connection is still to RX2).
> Apparently
> the USRP FPGA and/or libuhd believes that the radio is in "full duplex" mode.
>
>
> What condition of the radio determines that the radio is operating in full
> duplex mode?
>
> Note that I'm not asking what "full duplex mode" means -- I'm asking how the
> USRP hardware/software
> determines that it is in full duplex mode.
>
> rg
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141023/a4b8a8c4/attachment-0001.html>
------------------------------
Message: 11
Date: Thu, 23 Oct 2014 20:32:53 -0400
From: Radio User <[email protected]>
To: Ian Buckley <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Full Duplex vs. Half Duplex operation?
Message-ID:
<ca+rmjiedb2m_jvck12fq7xtlntz8h5fhmdb-upj5l_ddcmj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Ian,
Thanks...
Posting to the list was the key to finding the solution.
Apparently, libuhd/FPGA determines that we are in "full duplex" mode when
there is an
active (that is to say, extant) tx_streamer alive at the same time we have
an extant rx_streamer.
It doesn't matter if anything is being set to the streamer, its mere
existence (along with
an rx_streamer) will trigger the condition.
As you said, the ATR (automatic-transmit-receive) switch in the GPIO
register is pretty
smart. If you are in full dux, it won't connect the RX input to the TX
output, because
bad things will happen. So, to build a transceiver that uses the TX/RX
port for the antenna,
one needs to destroy any active tx_streamers while in RX mode, and recreate
the streamer
before initiating a new transmission.
So, the rule is:
foo = usrp->get_tx_stream(stream_args);
creates a streamer. The radio will be in the ATR_REG_FULL_DUPLEX (if there
is
an rx_streamer in existence) or ATR_REG_TX_ONLY (if not.)
destroy the tx_streamer
(like this?) foo->~tx_streamer(); // I'm sure there is a better way
and the mode is either ATR_REG_RX_ONLY (if an rx_streamer is alive) or
ATR_REG_IDLE
(otherwise.)
-------------------
The key to finding something yourself is to ask someone else where it
is....
On Thu, Oct 23, 2014 at 7:47 PM, Ian Buckley <[email protected]> wrote:
> ---- snip -----
>
> The gist of this is that in your case either: a) For some reason the
> ATR-GPIO has not been programmed by UHD to select the correct SMA or b) The
> USRP is not in the state you think it is (RX vs Full-Duplex)
>
> Make sense?
> -Ian
>
>
> On Oct 23, 2014, at 4:10 PM, Radio User via USRP-users <
> [email protected]> wrote:
>
> Fellow USRPers..
>
> ---- snip ----
> rg
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141023/e8b15bee/attachment-0001.html>
------------------------------
Message: 12
Date: Thu, 23 Oct 2014 18:24:34 -0700
From: Ian Buckley <[email protected]>
To: Radio User <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Full Duplex vs. Half Duplex operation?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Quick side note: WBX is designed electrically so that (barring a user
connecting an external cable directly), the TX can never drive the RX LNA
directly?it will always be attenuated by the leakage between the 2 poles of the
switch?.bad programing alone can't fry it.
-Ian
On Oct 23, 2014, at 5:32 PM, Radio User <[email protected]> wrote:
>
> smart. If you are in full dux, it won't connect the RX input to the TX
> output, because
> bad things will happen.
------------------------------
Message: 13
Date: Fri, 24 Oct 2014 01:31:25 +0000 (GMT)
From: Louis Brown <[email protected]>
To: [email protected]
Subject: [USRP-users] X310 MTU frame size issue
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Operating my X310 from a UHD source in GRC via 10GE yields a low MTU at startup:
-----------------------------------------------
linux; GNU C++ version 4.8.3 20140911 (Red Hat 4.8.3-7); Boost_105400;
UHD_003.008.000-6-gbde8e9a3
-- X300 initialization sequence...
-- Determining maximum frame size... 2188 bytes.
UHD Warning:
For this connection, UHD recommends a send frame size of at least 8000 for
best
performance, but your system's MTU will only allow 2188.
This will negatively impact your maximum achievable sample rate.
-----------------------------------------------
My MTU for the 10GE interface is 9000 (verified with ifconfig), and when I run
benchmark_rate it finds the correct MTU:
------------------------------------------------
./benchmark_rate --rx_rate 200E6 --args "addr=192.168.40.2"
linux; GNU C++ version 4.8.3 20140911 (Red Hat 4.8.3-7); Boost_105400;
UHD_003.008.000-6-gbde8e9a3
Creating the usrp device with: addr=192.168.40.2...
-- X300 initialization sequence...
-- Determining maximum frame size... 8000 bytes.
-----------------------------------------------
So is this a GR issue or a UHD issue, or a combination?
?Thanks,
Lou
KD4HSO
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141024/6f64c7af/attachment-0001.html>
------------------------------
Message: 14
Date: Thu, 23 Oct 2014 19:40:39 -0700
From: Michael West <[email protected]>
To: Louis Brown <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310 MTU frame size issue
Message-ID:
<cam4xkrrp81xgs+3kygryq8f8ksryag6uvqiw0sp6abhzmo-...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Louis,
I noticed that for the benchmark_rate you are supplying the IP address and
for GRC you are not. Try supplying the same args ("addr=192.168.40.2") in
the "Device Addr" field of the UHD USRP Source/Sink block you are using.
Regards,
Michael E. West
On Thu, Oct 23, 2014 at 6:31 PM, Louis Brown via USRP-users <
[email protected]> wrote:
> Operating my X310 from a UHD source in GRC via 10GE yields a low MTU at
> startup:
>
> -----------------------------------------------
> linux; GNU C++ version 4.8.3 20140911 (Red Hat 4.8.3-7); Boost_105400;
> UHD_003.008.000-6-gbde8e9a3
> -- X300 initialization sequence...
> -- Determining maximum frame size... 2188 bytes.
> UHD Warning:
> For this connection, UHD recommends a send frame size of at least 8000
> for best
> performance, but your system's MTU will only allow 2188.
> This will negatively impact your maximum achievable sample rate.
> -----------------------------------------------
>
> My MTU for the 10GE interface is 9000 (verified with ifconfig), and when I
> run benchmark_rate it finds the correct MTU:
>
> ------------------------------------------------
> ./benchmark_rate --rx_rate 200E6 --args "addr=192.168.40.2"
> linux; GNU C++ version 4.8.3 20140911 (Red Hat 4.8.3-7); Boost_105400;
> UHD_003.008.000-6-gbde8e9a3
>
> Creating the usrp device with: addr=192.168.40.2...
> -- X300 initialization sequence...
> -- Determining maximum frame size... 8000 bytes.
> -----------------------------------------------
>
> So is this a GR issue or a UHD issue, or a combination?
>
> Thanks,
> Lou
> KD4HSO
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141023/2c690f40/attachment-0001.html>
------------------------------
Message: 15
Date: Fri, 24 Oct 2014 15:55:55 +0000 (GMT)
From: Louis Brown <[email protected]>
To: Michael West <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310 MTU frame size issue
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Now this morning, after a reboot, it's finding the correct MTU. I did have the
address entered into the UHD source.
Although now when I kill the GRC flowgraph (just a UHD source into a frequency
sink) it seems to hang the X310 (link light turns from yellow to red) and I
can't establish communication without power cycling the X310.
RuntimeError: LookupError: KeyError: No devices found for ----->
Device Address:
addr: 192.168.40.2
If I power cycle I can run benchmark_rate multiple times without issues, so it
seems halting it from GRC may be a problem.
Thanks,?
Lou
On Oct 23, 2014, at 08:40 PM, Michael West <[email protected]> wrote:
> Hi Louis,
>
> I noticed that for the benchmark_rate you are supplying the IP address and
> for GRC you are not. Try supplying the same args ("addr=192.168.40.2") in
> the "Device Addr" field of the UHD USRP Source/Sink block you are using.
>
> Regards,
> Michael E. West
>
> On Thu, Oct 23, 2014 at 6:31 PM, Louis Brown via USRP-users
> <[email protected]> wrote:
>
> Operating my X310 from a UHD source in GRC via 10GE yields a low MTU at
> startup:
>
> -----------------------------------------------
> linux; GNU C++ version 4.8.3 20140911 (Red Hat 4.8.3-7); Boost_105400;
> UHD_003.008.000-6-gbde8e9a3
> -- X300 initialization sequence...
> -- Determining maximum frame size... 2188 bytes.
> UHD Warning:
> For this connection, UHD recommends a send frame size of at least
> 8000 for best
> performance, but your system's MTU will only allow 2188.
> This will negatively impact your maximum achievable sample rate.
> -----------------------------------------------
>
> My MTU for the 10GE interface is 9000 (verified with ifconfig), and when
> I run benchmark_rate it finds the correct MTU:
>
> ------------------------------------------------
> ./benchmark_rate --rx_rate 200E6 --args "addr=192.168.40.2"
> linux; GNU C++ version 4.8.3 20140911 (Red Hat 4.8.3-7); Boost_105400;
> UHD_003.008.000-6-gbde8e9a3
>
> Creating the usrp device with: addr=192.168.40.2...
> -- X300 initialization sequence...
> -- Determining maximum frame size... 8000 bytes.
> -----------------------------------------------
>
> So is this a GR issue or a UHD issue, or a combination?
>
> Thanks,
> Lou
> KD4HSO
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141024/eb96b18e/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 50, Issue 23
******************************************
