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: N210 WBX annoying spurs while switching (Matt Ettus)
2. WiMAX scanner (Sebastian Komorowski)
3. problems with UHD and Visual Studio Express 2013
(massimo zampetti)
4. Re: uhd_cal_tx_iq_balance skips wide frequency range
(Urban Hakansson)
5. problem with USRP example on X310 with CBX-120 (Jim Hunziker)
6. documented memory-map and streaming interfaces (David Watt)
7. Re: UBX daughter board (Matt Ettus)
8. Re: N210 WBX annoying spurs while switching (Marcus D. Leech)
9. Storing signals with full bandwidth of USRP x300/x310 (Perper)
10. Re: WiMAX scanner (Mike McLernon)
11. Re: problem with USRP example on X310 with CBX-120 (Jim Hunziker)
12. TX and RX phase compensation on B210
(Eleftherios(Lef) Kampianakis)
13. Re: Storing signals with full bandwidth of USRP x300/x310
(Matt Ettus)
14. Re: problems with UHD and Visual Studio Express 2013
(Michael West)
15. Re: uhd_cal_tx_iq_balance skips wide frequency range
(Michael West)
16. Re: N210 WBX annoying spurs while switching (bob wole)
17. Re: N210 WBX annoying spurs while switching (Ian Buckley)
18. Re: N210 WBX annoying spurs while switching (Matt Ettus)
19. Re: N210 WBX annoying spurs while switching (bob wole)
20. Re: N210 WBX annoying spurs while switching (Matt Ettus)
21. Re: N210 WBX annoying spurs while switching (bob wole)
22. Re: [Openlte-discuss] uhd Error? (Ralph A. Schmid, dk5ras)
23. Re: N210 WBX annoying spurs while switching (Dan CaJacob)
24. Re: N210 WBX annoying spurs while switching
(Ralph A. Schmid, dk5ras)
25. Re: Connect USRP to OSMO board (Carlos Alberto Ruiz Naranjo)
26. Re: Storing signals with full bandwidth of USRP x300/x310 (Perper)
27. Re: N210 WBX annoying spurs while switching (Andy Walls)
28. Re: uhd_cal_tx_iq_balance skips wide frequency range
(Urban Hakansson)
29. Re: uhd_cal_tx_iq_balance skips wide frequency range
(Marcus D. Leech)
----------------------------------------------------------------------
Message: 1
Date: Wed, 22 Oct 2014 09:16:43 -0700
From: Matt Ettus <[email protected]>
To: bob wole <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] N210 WBX annoying spurs while switching
Message-ID:
<CAN=1kn-d2Z7i75y4r3Z_coYYbpwg_y-Qz-Vzeg=ra5pa3tw...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
When you start and stop transmission without smoothly ramping the signal to
zero at the beginning and end, you will create wideband spurs. Just think
about it as amplitude modulation. Even if you are transmitting a pure sine
wave, if you turn it on and off quickly, it will create out of band spurs.
Hams call this keyclicks.
Matt
On Wed, Oct 22, 2014 at 1:25 AM, bob wole via USRP-users <
[email protected]> wrote:
> I noticed that there are a lot of significant spurs generated in the
> output of WBX, on different frequencies randomly, when I use tx_time,
> tx_sob_tx_eob tags. I do not see these spurs if I transmit continuously.
> These spurs appears only when I start and stop transmission using stream
> tags.
> How can I get rid of these spurs and what is the cause?
>
> -
> Bob
>
> _______________________________________________
> 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/20141022/529f1350/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 22 Oct 2014 08:53:39 +0200
From: Sebastian Komorowski <[email protected]>
To: [email protected]
Subject: [USRP-users] WiMAX scanner
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
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
------------------------------
Message: 3
Date: Wed, 22 Oct 2014 13:01:50 +0200
From: massimo zampetti <[email protected]>
To: [email protected]
Subject: [USRP-users] problems with UHD and Visual Studio Express 2013
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-15"; Format="flowed"
Dear Sir,
I'm writing to you regarding a problem with uhd.
I have an *Ettus B200* connected to the *USB 3.0* port (*Intel Z7*7) of
my PC.
The main features of my PC are:
- motherboard: *ASRock Z77 Extreme 11*.
- operating system: *Microsoft Windows 7 (64 bit)*.
I downloaded the UHD software installer from
http://code.ettus.com/redmine/ettus/projects/uhd/wiki/UHD_Windows:
*uhd-stable-debug_Win64.exe*.
I tried to execute *uhd_find_devices* (UHD\bin) and *uhd_usrp_proble*
(UHD\bin) and both worked successfully.
Then I created a simple GNURadio project and also in this case it worked
without any problem.
Now I'm using *Visual Studio Express 2013* and I'm trying to modify the
code of '*tx_waveforms.exe*' (UHD\lib\uhd\utils). I'm trying to do this
because I want to learn how can I write C++ code to communicate with my
ETTUS B200.
I installed boost (1.56) libraries on my PC and I set all required paths
in the project properties.
I tried to run the project but it crashed. So I commented all lines of
the code and I tried to uncomment line by line to find instruction that
causes the error.
In attachment there is the code.
If I uncomment line 110 (*uhd::usrp::multi_usrp::sptr usrp =
uhd::usrp::multi_usrp::make(args);*), there's no problem with the
compiler but if I run debug I obtain the following error:
First of all, the path doesn't exist. 'xstring' is in the directory
'Microsoft Visual Studio *12.0*\VC\include'. In any case it seems that
xstring is found but something in it that crashes the program.
I'm looking for this error on internet but I don't find a solution.
Would you send me any suggestions to solve my problem?
Thank you for your help
Yours sincerely
Massimo Zampetti
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141022/553446ce/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 19142 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141022/553446ce/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 26610 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141022/553446ce/attachment-0003.png>
-------------- next part --------------
#include <uhd/utils/thread_priority.hpp>
#include <uhd/utils/safe_main.hpp>
#include <uhd/utils/static.hpp>
#include <uhd/usrp/multi_usrp.hpp>
#include <uhd/exception.hpp>
#include <boost/program_options.hpp>
#include <boost/math/special_functions/round.hpp>
#include <boost/foreach.hpp>
#include <boost/format.hpp>
#include <boost/thread.hpp>
#include <boost/lexical_cast.hpp>
#include <boost/algorithm/string.hpp>
#include <iostream>
#include <complex>
#include <csignal>
#include <cmath>
namespace po = boost::program_options;
/***********************************************************************
* Signal handlers
**********************************************************************/
static bool stop_signal_called = false;
void sig_int_handler(int){stop_signal_called = true;}
/***********************************************************************
* Waveform generators
**********************************************************************/
static const size_t wave_table_len = 8192;
class wave_table_class{
public:
wave_table_class(const std::string &wave_type, const float ampl):
_wave_table(wave_table_len)
{
//compute real wave table with 1.0 amplitude
std::vector<double> real_wave_table(wave_table_len);
if (wave_type == "CONST"){
for (size_t i = 0; i < wave_table_len; i++)
real_wave_table[i] = 1.0;
}
else if (wave_type == "SQUARE"){
for (size_t i = 0; i < wave_table_len; i++)
real_wave_table[i] = (i < wave_table_len/2)? 0.0 : 1.0;
}
else if (wave_type == "RAMP"){
for (size_t i = 0; i < wave_table_len; i++)
real_wave_table[i] = 2.0*i/(wave_table_len-1) - 1.0;
}
else if (wave_type == "SINE"){
static const double tau = 2*std::acos(-1.0);
for (size_t i = 0; i < wave_table_len; i++)
real_wave_table[i] = std::sin((tau*i)/wave_table_len);
}
else throw std::runtime_error("unknown waveform type: " + wave_type);
//compute i and q pairs with 90% offset and scale to amplitude
for (size_t i = 0; i < wave_table_len; i++){
const size_t q = (i+(3*wave_table_len)/4)%wave_table_len;
_wave_table[i] = std::complex<float>(ampl*real_wave_table[i],
ampl*real_wave_table[q]);
}
}
inline std::complex<float> operator()(const size_t index) const{
return _wave_table[index % wave_table_len];
}
private:
std::vector<std::complex<float> > _wave_table;
};
/***********************************************************************
* Main function
**********************************************************************/
int UHD_SAFE_MAIN(int argc, char *argv[])
{
uhd::set_thread_priority_safe();
//variables to be set by po
std::string args, wave_type, ant, subdev, ref, otw, channel_list;
size_t spb;
double rate, freq, gain, wave_freq, bw;
float ampl;
//setup the program options
po::options_description desc("Allowed options");
desc.add_options()
("help", "help message")
("args", po::value<std::string>(&args)->default_value(""), "single uhd
device address args")
("spb", po::value<size_t>(&spb)->default_value(0), "samples per buffer,
0 for default")
("rate", po::value<double>(&rate), "rate of outgoing samples")
("freq", po::value<double>(&freq), "RF center frequency in Hz")
("ampl", po::value<float>(&l)->default_value(float(0.3)), "amplitude
of the waveform [0 to 0.7]")
("gain", po::value<double>(&gain), "gain for the RF chain")
("ant", po::value<std::string>(&ant), "daughterboard antenna selection")
("subdev", po::value<std::string>(&subdev), "daughterboard subdevice
specification")
("bw", po::value<double>(&bw), "daughterboard IF filter bandwidth in
Hz")
("wave-type",
po::value<std::string>(&wave_type)->default_value("CONST"), "waveform type
(CONST, SQUARE, RAMP, SINE)")
("wave-freq", po::value<double>(&wave_freq)->default_value(0),
"waveform frequency in Hz")
("ref", po::value<std::string>(&ref)->default_value("internal"), "clock
reference (internal, external, mimo)")
("otw", po::value<std::string>(&otw)->default_value("sc16"), "specify
the over-the-wire sample mode")
("channels", po::value<std::string>(&channel_list)->default_value("0"),
"which channels to use (specify \"0\", \"1\", \"0,1\", etc)")
("int-n", "tune USRP with integer-N tuning")
;
po::variables_map vm;
po::store(po::parse_command_line(argc, argv, desc), vm);
po::notify(vm);
//print the help message
if (vm.count("help"))
{
std::cout << boost::format("UHD TX Waveforms %s") % desc <<
std::endl;
return ~0;
}
//create a usrp device
std::cout << std::endl;
std::cout << boost::format("Creating the usrp device with: %s...") %
args << std::endl;
uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args);
////detect which channels to use
//std::vector<std::string> channel_strings;
//std::vector<size_t> channel_nums;
//boost::split(channel_strings, channel_list, boost::is_any_of("\"',"));
//for(size_t ch = 0; ch < channel_strings.size(); ch++)
//{
// size_t chan = boost::lexical_cast<int>(channel_strings[ch]);
// if(chan >= usrp->get_tx_num_channels())
// throw std::runtime_error("Invalid channel(s) specified.");
// else
//
channel_nums.push_back(boost::lexical_cast<int>(channel_strings[ch]));
//}
//
////Lock mboard clocks
//usrp->set_clock_source(ref);
////always select the subdevice first, the channel mapping affects the
other settings
//if (vm.count("subdev")) usrp->set_tx_subdev_spec(subdev);
//std::cout << boost::format("Using Device: %s") %
usrp->get_pp_string() << std::endl;
//
// //set the sample rate
//if (not vm.count("rate"))
//{
// std::cerr << "Please specify the sample rate with --rate" <<
std::endl;
// return ~0;
//}
//std::cout << boost::format("Setting TX Rate: %f Msps...") %
(rate/1e6) << std::endl;
////usrp->set_tx_rate(rate); //sm
////std::cout << boost::format("Actual TX Rate: %f Msps...") %
(usrp->get_tx_rate()/1e6) << std::endl << std::endl; //sm
////set the center frequency
//if (not vm.count("freq"))
//{
// std::cerr << "Please specify the center frequency with --freq"
<< std::endl;
// return ~0;
//}
//
//for(size_t ch = 0; ch < channel_nums.size(); ch++)
//{
// std::cout << boost::format("Setting TX Freq: %f MHz...") %
(freq/1e6) << std::endl;
// //uhd::tune_request_t tune_request(freq); //sm
// //if(vm.count("int-n")) tune_request.args =
uhd::device_addr_t("mode_n=integer"); //sm
// //usrp->set_tx_freq(tune_request, channel_nums[ch]); //sm
// //std::cout << boost::format("Actual TX Freq: %f MHz...") %
(usrp->get_tx_freq(channel_nums[ch])/1e6) << std::endl << std::endl; //sm
//
// //set the rf gain
// if (vm.count("gain"))
// {
// std::cout << boost::format("Setting TX Gain: %f dB...") % gain
<< std::endl;
// //usrp->set_tx_gain(gain, channel_nums[ch]); //sm
// //std::cout << boost::format("Actual TX Gain: %f dB...") %
usrp->get_tx_gain(channel_nums[ch]) << std::endl << std::endl; //sm
// }
// //set the IF filter bandwidth
// if (vm.count("bw"))
// {
// std::cout << boost::format("Setting TX Bandwidth: %f
MHz...") % bw << std::endl;
// //usrp->set_tx_bandwidth(bw, channel_nums[ch]); //sm
// //std::cout << boost::format("Actual TX Bandwidth: %f
MHz...") % usrp->get_tx_bandwidth(channel_nums[ch]) << std::endl << std::endl;
//sm
// }
////set the antenna
////if (vm.count("ant")) usrp->set_tx_antenna(ant, channel_nums[ch]);
//sm
//}
//boost::this_thread::sleep(boost::posix_time::seconds(1)); //allow for
some setup time
////for the const wave, set the wave freq for small samples per period
//if (wave_freq == 0 and wave_type == "CONST")
//{
// //wave_freq = usrp->get_tx_rate()/2; //sm
//}
////error when the waveform is not possible to generate
////if (std::abs(wave_freq) > usrp->get_tx_rate()/2) // sm
//{
// //throw std::runtime_error("wave freq out of Nyquist zone");
//sm
//}
////if (usrp->get_tx_rate()/std::abs(wave_freq) > wave_table_len/2)
//{
// //throw std::runtime_error("wave freq too small for table");
//sm
//}
////pre-compute the waveform values
//const wave_table_class wave_table(wave_type, ampl);
////const size_t step =
boost::math::iround(wave_freq/usrp->get_tx_rate() * wave_table_len); //sm
//size_t index = 0;
////create a transmit streamer
////linearly map channels (index0 = channel0, index1 = channel1, ...)
////uhd::stream_args_t stream_args("fc32", otw); //sm
////stream_args.channels = channel_nums; //sm
//// uhd::tx_streamer::sptr tx_stream =
usrp->get_tx_stream(stream_args); //sm
////allocate a buffer which we re-use for each channel
////if (spb == 0) spb = tx_stream->get_max_num_samps()*10; //sm
//std::vector<std::complex<float> > buff(spb);
//std::vector<std::complex<float> *> buffs(channel_nums.size(),
&buff.front());
////setup the metadata flags
////uhd::tx_metadata_t md; //sm
////md.start_of_burst = true; //sm
//// md.end_of_burst = false; //sm
////md.has_time_spec = true; //sm
////md.time_spec = uhd::time_spec_t(0.1);
//std::cout << boost::format("Setting device timestamp to 0...") <<
std::endl;
////usrp->set_time_now(uhd::time_spec_t(0.0)); //sm
////Check Ref and LO Lock detect
//std::vector<std::string> sensor_names;
////sensor_names = usrp->get_tx_sensor_names(0); //sm
//if (std::find(sensor_names.begin(), sensor_names.end(), "lo_locked")
!= sensor_names.end())
//{
// //uhd::sensor_value_t lo_locked =
usrp->get_tx_sensor("lo_locked",0); //sm
// //std::cout << boost::format("Checking TX: %s ...") %
lo_locked.to_pp_string() << std::endl; //sm
// //UHD_ASSERT_THROW(lo_locked.to_bool()); //sm
//}
////sensor_names = usrp->get_mboard_sensor_names(0); //sm
//if ((ref == "mimo") and (std::find(sensor_names.begin(),
sensor_names.end(), "mimo_locked") != sensor_names.end()))
//{
// //uhd::sensor_value_t mimo_locked =
usrp->get_mboard_sensor("mimo_locked",0); //sm
// //std::cout << boost::format("Checking TX: %s ...") %
mimo_locked.to_pp_string() << std::endl; //sm
// //UHD_ASSERT_THROW(mimo_locked.to_bool()); //sm
//}
//if ((ref == "external") and (std::find(sensor_names.begin(),
sensor_names.end(), "ref_locked") != sensor_names.end()))
//{
// //uhd::sensor_value_t ref_locked =
usrp->get_mboard_sensor("ref_locked",0); //sm
// //std::cout << boost::format("Checking TX: %s ...") %
ref_locked.to_pp_string() << std::endl; //sm
// //UHD_ASSERT_THROW(ref_locked.to_bool()); //sm
//}
//std::signal(SIGINT, &sig_int_handler);
//std::cout << "Press Ctrl + C to stop streaming..." << std::endl;
////send data until the signal handler gets called
//while(not stop_signal_called)
//{
// //fill the buffer with the waveform
// for (size_t n = 0; n < buff.size(); n++)
// {
// //buff[n] = wave_table(index += step); //sm
// }
//
// //send the entire contents of the buffer
////tx_stream->send(buffs, buff.size(), md); //sm
////md.start_of_burst = false; //sm
////md.has_time_spec = false; //sm
//}
////send a mini EOB packet
////md.end_of_burst = true; //sm
////tx_stream->send("", 0, md); //sm
//finished
std::cout << std::endl << "Done!" << std::endl << std::endl;
system("pause");
return EXIT_SUCCESS;
}
------------------------------
Message: 4
Date: Wed, 22 Oct 2014 11:37:39 -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"
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
----- Original Message -----
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:
<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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141022/7de2aa46/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tx_dc_cal_v0.2_F4D354.csv
Type: text/csv
Size: 917203 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141022/7de2aa46/attachment-0002.csv>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tx_iq_cal_v0.2_F4D354.csv
Type: text/csv
Size: 970947 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141022/7de2aa46/attachment-0003.csv>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: complex_exp.grc
Type: application/xml
Size: 35796 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141022/7de2aa46/attachment-0001.grc>
------------------------------
Message: 5
Date: Wed, 22 Oct 2014 12:15:24 -0400
From: Jim Hunziker <[email protected]>
To: [email protected]
Subject: [USRP-users] problem with USRP example on X310 with CBX-120
Message-ID:
<cagh06jvbbs0mznxztfjjaywzfadnpdc9xqn1brzemgayspd...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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/20141022/e8d58356/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zoomedIn.png
Type: image/png
Size: 8671 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141022/e8d58356/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zoomedOut.png
Type: image/png
Size: 5769 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141022/e8d58356/attachment-0003.png>
------------------------------
Message: 6
Date: Wed, 22 Oct 2014 17:02:13 +0000
From: David Watt <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] documented memory-map and streaming interfaces
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
We need to run the Ettus X310 in a mode that's quite a bit different than the
I&Q samples to & from software mode. Our mode can't really be implemented by
putting a DSP block in either the Tx or Rx streaming paths.
Is there a more general way to interface between software and the FPGA
internals? There's a wishbone bus inside - is there a C API that can read/write
from this directly without all the other UHD layers? Is there an API for
uploading a stream data packet and a documented timing protocol on the FPGA
side for how it would ingress into the FPGA? And vice versa for packetizing a
data stream from FPGA to software? Any pointers are appreciated.
Thank you, David Watt
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141022/7093ae58/attachment-0001.html>
------------------------------
Message: 7
Date: Wed, 22 Oct 2014 10:22:09 -0700
From: Matt Ettus <[email protected]>
To: Luong Tan Phong <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] UBX daughter board
Message-ID:
<CAN=1kn_iusisc4q22zq34uy-e7f2rkch4hntcho1bsaycxu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Luong,
We hope to be releasing the UBX board around the end of the year.
For those who were not at GRCon, UBX is a new transceiver daughterboard
which covers 10 MHz to 6 GHz. It will be available in a 40 MHz BW version
for N200-series, B100, E100-series, and a 160 MHz BW version for
X300-series motherboards.
Its architecture is similar to the WBX, SBX, and CBX, and performance is
the same or better across the frequency range. It also has a full machined
shield for better isolation and heat sinking.
Matt
On Tue, Oct 21, 2014 at 2:08 AM, Luong Tan Phong via USRP-users <
[email protected]> wrote:
> Hi List,
>
> I've read GRCON14 documents and found that Ettus will release UBX daughter
> board.
>
> Could you tell me when I can buy it, please?
>
> BRs.
>
> LTP
>
>
>
> _______________________________________________
> 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/20141022/2478155b/attachment-0001.html>
------------------------------
Message: 8
Date: Wed, 22 Oct 2014 14:03:57 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] N210 WBX annoying spurs while switching
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 10/22/2014 12:16 PM, Matt Ettus via USRP-users wrote:
>
> When you start and stop transmission without smoothly ramping the
> signal to zero at the beginning and end, you will create wideband
> spurs. Just think about it as amplitude modulation. Even if you are
> transmitting a pure sine wave, if you turn it on and off quickly, it
> will create out of band spurs. Hams call this keyclicks.
>
> Matt
>
>
Even ignoring the digital bits (ramp-up/ramp-down), when you turn a TX
on/off abruptly, there'll be some spectral anomalies, for the same
reason, but
in the analog domain, and usually weaker. In commercial
for-a-particular-purpose radio, there are TX filters to prevent such
transients from
being too strong out-of-band. In a not-for-a-particular-purpose
radio, such as an SDR, no such filtering can be provided.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
Message: 9
Date: Wed, 22 Oct 2014 21:06:46 +0200
From: Perper <[email protected]>
To: USRP List <[email protected]>
Subject: [USRP-users] Storing signals with full bandwidth of USRP
x300/x310
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
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
------------------------------
Message: 10
Date: Wed, 22 Oct 2014 19:25:58 +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,
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]
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]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 11
Date: Wed, 22 Oct 2014 16:42:49 -0400
From: Jim Hunziker <[email protected]>
To: usrp-users <[email protected]>
Cc: support <[email protected]>, Timothy Maese <[email protected]>
Subject: Re: [USRP-users] problem with USRP example on X310 with
CBX-120
Message-ID:
<CAGH06JteRa=QoxatZ8aFik6wrtkZJ=-xkcq75m7qgxpoy-m...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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/20141022/4a989170/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zoomedIn.png
Type: image/png
Size: 9157 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141022/4a989170/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zoomedOut.png
Type: image/png
Size: 8135 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141022/4a989170/attachment-0003.png>
------------------------------
Message: 12
Date: Wed, 22 Oct 2014 13:50:22 -0700
From: "Eleftherios(Lef) Kampianakis" <[email protected]>
To: [email protected]
Subject: [USRP-users] TX and RX phase compensation on B210
Message-ID:
<CAG8c0fWsTXViuhzH=puorjhrg3ddek9awkapmjzxvaybbkf...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello everyone,
I have a project that requires knowledge of the phase difference that is
introduced between TX and RX.
I started with a simple GRC block diagram (im1) with two file sinks
attached to a UHD_source and UHD sink respectively. I connected tx/rx1 and
rx1 with coax cable and I used MATLAB to send and get samples. However,
every received vector of samples had different phase compared to the rx
vector.
Subsequently, I developed a simple GRC block diagram (im2) that just sends
and receives a constant carrier and plotted the time domain transmitted and
received signals using scope. The signals exhibit a constant phase
difference but when I restart the scrip this phase difference changes.
Finally I developed a python script that has a vector sink and source,
generated a carrier in python and plotted the samples I send vs the samples
I received. The phase, again wasnt the same in every execution.
Do you have any suggestions on how can I implement a script that either
phase is constant everytime I execute it or I can have knowledge of it
everytime? I have already started looking at UHD code examples but I dont
want to dig that deep without eliminating all other easier tools.
Thank you
--
Eleftherios(Lef) Kampianakis
Electronics and Computer Engineer
PHD Candidate and Researcher at Sensing Computing Communications Group
(SGCC)
Department of Electrical Engineering
University of Washington
3927 Adams Lane, NE, Mercer Court D805B, 98105
website: http://staff.washington.edu/ekampian
mail:[email protected]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141022/214a4d8f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: im1.png
Type: image/png
Size: 22473 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141022/214a4d8f/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: im2.png
Type: image/png
Size: 26637 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141022/214a4d8f/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: im3.png
Type: image/png
Size: 23642 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141022/214a4d8f/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: im4.png
Type: image/png
Size: 18446 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141022/214a4d8f/attachment-0007.png>
------------------------------
Message: 13
Date: Wed, 22 Oct 2014 15:57:28 -0700
From: Matt Ettus <[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:
<CAN=1kn9qsKsFpPGK5DrPQbrxZjsi=ddsymcr94wbu8-fxrm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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]> 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]
> 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/20141022/004df35a/attachment-0001.html>
------------------------------
Message: 14
Date: Wed, 22 Oct 2014 16:45:03 -0700
From: Michael West <[email protected]>
To: massimo zampetti <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] problems with UHD and Visual Studio Express
2013
Message-ID:
<CAM4xKrrb3Ve+0FVXb1jd0-vTx63P1qr=ukyMdSBMPYgd-=q...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Massimo,
The problem is that you are using header files from VC12 and linking to the
UHD library from the installer, which appears to be built using VC10.
There is a VS2013 installer available, but I would recommend that you just
build UHD locally and make sure you link your executable to that version.
Regards,
Michael
On Wed, Oct 22, 2014 at 4:01 AM, massimo zampetti via USRP-users <
[email protected]> wrote:
> Dear Sir,
> I'm writing to you regarding a problem with uhd.
> I have an *Ettus B200* connected to the *USB 3.0* port (*Intel Z7*7) of
> my PC.
> The main features of my PC are:
> - motherboard: *ASRock Z77 Extreme 11*.
> - operating system: *Microsoft Windows 7 (64 bit)*.
>
> I downloaded the UHD software installer from
> http://code.ettus.com/redmine/ettus/projects/uhd/wiki/UHD_Windows:
> *uhd-stable-debug_Win64.exe*.
>
> I tried to execute *uhd_find_devices* (UHD\bin) and *uhd_usrp_proble*
> (UHD\bin) and both worked successfully.
> Then I created a simple GNURadio project and also in this case it worked
> without any problem.
>
> Now I'm using *Visual Studio Express 2013* and I'm trying to modify the
> code of '*tx_waveforms.exe*' (UHD\lib\uhd\utils). I'm trying to do this
> because I want to learn how can I write C++ code to communicate with my
> ETTUS B200.
>
> I installed boost (1.56) libraries on my PC and I set all required paths
> in the project properties.
> I tried to run the project but it crashed. So I commented all lines of the
> code and I tried to uncomment line by line to find instruction that causes
> the error.
>
> In attachment there is the code.
> If I uncomment line 110 (*uhd::usrp::multi_usrp::sptr usrp =
> uhd::usrp::multi_usrp::make(args);*), there's no problem with the
> compiler but if I run debug I obtain the following error:
>
>
>
> First of all, the path doesn't exist. 'xstring' is in the directory
> 'Microsoft Visual Studio *12.0*\VC\include'. In any case it seems that
> xstring is found but something in it that crashes the program.
>
> I'm looking for this error on internet but I don't find a solution.
>
> Would you send me any suggestions to solve my problem?
>
> Thank you for your help
> Yours sincerely
>
> Massimo Zampetti
>
> _______________________________________________
> 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/20141022/0b7311bf/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 26610 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141022/0b7311bf/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 19142 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141022/0b7311bf/attachment-0003.png>
------------------------------
Message: 15
Date: Wed, 22 Oct 2014 19:51:27 -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:
<cam4xkrrnnuypgrxt8j9af2zsbdfhqdsvzpk_50txbjywmzf...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141022/9edb1a29/attachment-0001.html>
------------------------------
Message: 16
Date: Thu, 23 Oct 2014 10:08:43 +0500
From: bob wole <[email protected]>
To: Matt Ettus <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] N210 WBX annoying spurs while switching
Message-ID:
<CAGd3OzzRhRHpavzEHy-SrEh6=jtXLy37f=r7hentjlqjwau...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
So you are suggesting that I should zero pad samples at start and end of my
burst to avoid this ?
On Wed, Oct 22, 2014 at 9:16 PM, Matt Ettus <[email protected]> wrote:
>
> When you start and stop transmission without smoothly ramping the signal
> to zero at the beginning and end, you will create wideband spurs. Just
> think about it as amplitude modulation. Even if you are transmitting a
> pure sine wave, if you turn it on and off quickly, it will create out of
> band spurs. Hams call this keyclicks.
>
> Matt
>
>
> On Wed, Oct 22, 2014 at 1:25 AM, bob wole via USRP-users <
> [email protected]> wrote:
>
>> I noticed that there are a lot of significant spurs generated in the
>> output of WBX, on different frequencies randomly, when I use tx_time,
>> tx_sob_tx_eob tags. I do not see these spurs if I transmit continuously.
>> These spurs appears only when I start and stop transmission using stream
>> tags.
>> How can I get rid of these spurs and what is the cause?
>>
>> -
>> Bob
>>
>> _______________________________________________
>> 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/45222dad/attachment-0001.html>
------------------------------
Message: 17
Date: Wed, 22 Oct 2014 22:19:08 -0700
From: Ian Buckley <[email protected]>
To: bob wole <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] N210 WBX annoying spurs while switching
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
It's more than just padding your signal with zero's?you need to ramp the
amplitude of your signal to/from zero over a period of time in a fashion that
minimizes the spectral artifacts otherwise created.
On Oct 22, 2014, at 10:08 PM, bob wole via USRP-users
<[email protected]> wrote:
> So you are suggesting that I should zero pad samples at start and end of my
> burst to avoid this ?
>
> On Wed, Oct 22, 2014 at 9:16 PM, Matt Ettus <[email protected]> wrote:
>
> When you start and stop transmission without smoothly ramping the signal to
> zero at the beginning and end, you will create wideband spurs. Just think
> about it as amplitude modulation. Even if you are transmitting a pure sine
> wave, if you turn it on and off quickly, it will create out of band spurs.
> Hams call this keyclicks.
>
> Matt
>
>
> On Wed, Oct 22, 2014 at 1:25 AM, bob wole via USRP-users
> <[email protected]> wrote:
> I noticed that there are a lot of significant spurs generated in the output
> of WBX, on different frequencies randomly, when I use tx_time, tx_sob_tx_eob
> tags. I do not see these spurs if I transmit continuously. These spurs
> appears only when I start and stop transmission using stream tags.
> How can I get rid of these spurs and what is the cause?
>
> -
> Bob
>
> _______________________________________________
> USRP-users mailing list
> [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/20141022/1267374e/attachment-0001.html>
------------------------------
Message: 18
Date: Wed, 22 Oct 2014 22:25:51 -0700
From: Matt Ettus <[email protected]>
To: bob wole <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] N210 WBX annoying spurs while switching
Message-ID:
<CAN=1kn9mx34jivbbx8x5ulus8qdgiuffye4xnwobqdd0s52...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Yes, but it is even better to ramp up at the beginning and down at the end,
and then pad a little bit with zeros. If you ramp up and down smoothly
for 1us, you'll confine the emissions to about 1 MHz on either side. All
bursty communication systems will do this, like Bluetooth, Wifi, even morse
code, and most newer standards even specify the ramping rate.
Matt
On Wed, Oct 22, 2014 at 10:08 PM, bob wole <[email protected]> wrote:
> So you are suggesting that I should zero pad samples at start and end of
> my burst to avoid this ?
>
> On Wed, Oct 22, 2014 at 9:16 PM, Matt Ettus <[email protected]> wrote:
>
>>
>> When you start and stop transmission without smoothly ramping the signal
>> to zero at the beginning and end, you will create wideband spurs. Just
>> think about it as amplitude modulation. Even if you are transmitting a
>> pure sine wave, if you turn it on and off quickly, it will create out of
>> band spurs. Hams call this keyclicks.
>>
>> Matt
>>
>>
>> On Wed, Oct 22, 2014 at 1:25 AM, bob wole via USRP-users <
>> [email protected]> wrote:
>>
>>> I noticed that there are a lot of significant spurs generated in the
>>> output of WBX, on different frequencies randomly, when I use tx_time,
>>> tx_sob_tx_eob tags. I do not see these spurs if I transmit continuously.
>>> These spurs appears only when I start and stop transmission using stream
>>> tags.
>>> How can I get rid of these spurs and what is the cause?
>>>
>>> -
>>> Bob
>>>
>>> _______________________________________________
>>> 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/20141022/85006afb/attachment-0001.html>
------------------------------
Message: 19
Date: Thu, 23 Oct 2014 10:46:00 +0500
From: bob wole <[email protected]>
To: Matt Ettus <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] N210 WBX annoying spurs while switching
Message-ID:
<CAGd3Ozzf8HWvbjMOkybpkfe-eGb0=pw5fl66h-cbwtfuwwm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks Matt for your response, that is the exact answer I was looking for.
Actually I am using USRPs for TDMA and I do not want my time slot to
increase very much. I wanted to know the ramping duration because this will
affect the time slot duration. Second option could be that I can add an RF
filter at the output of USRPs.
On Thu, Oct 23, 2014 at 10:25 AM, Matt Ettus <[email protected]> wrote:
>
> Yes, but it is even better to ramp up at the beginning and down at the
> end, and then pad a little bit with zeros. If you ramp up and down
> smoothly for 1us, you'll confine the emissions to about 1 MHz on either
> side. All bursty communication systems will do this, like Bluetooth, Wifi,
> even morse code, and most newer standards even specify the ramping rate.
>
> Matt
>
>
> On Wed, Oct 22, 2014 at 10:08 PM, bob wole <[email protected]> wrote:
>
>> So you are suggesting that I should zero pad samples at start and end of
>> my burst to avoid this ?
>>
>> On Wed, Oct 22, 2014 at 9:16 PM, Matt Ettus <[email protected]> wrote:
>>
>>>
>>> When you start and stop transmission without smoothly ramping the signal
>>> to zero at the beginning and end, you will create wideband spurs. Just
>>> think about it as amplitude modulation. Even if you are transmitting a
>>> pure sine wave, if you turn it on and off quickly, it will create out of
>>> band spurs. Hams call this keyclicks.
>>>
>>> Matt
>>>
>>>
>>> On Wed, Oct 22, 2014 at 1:25 AM, bob wole via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> I noticed that there are a lot of significant spurs generated in the
>>>> output of WBX, on different frequencies randomly, when I use tx_time,
>>>> tx_sob_tx_eob tags. I do not see these spurs if I transmit continuously.
>>>> These spurs appears only when I start and stop transmission using stream
>>>> tags.
>>>> How can I get rid of these spurs and what is the cause?
>>>>
>>>> -
>>>> Bob
>>>>
>>>> _______________________________________________
>>>> 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/862d33c3/attachment-0001.html>
------------------------------
Message: 20
Date: Wed, 22 Oct 2014 22:52:10 -0700
From: Matt Ettus <[email protected]>
To: bob wole <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] N210 WBX annoying spurs while switching
Message-ID:
<CAN=1kn_p-ep9w6wlstqbgna7ulxfu3oafe5d+dnw44pgshx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
No problem. The RF filter at the output really isn't the proper way to
solve this problem, it will just keep the noise within a band. What you
really want is to avoid putting out energy outside of your channel, and
that can only be done with ramping.
Matt
On Wed, Oct 22, 2014 at 10:46 PM, bob wole <[email protected]> wrote:
> Thanks Matt for your response, that is the exact answer I was looking for.
> Actually I am using USRPs for TDMA and I do not want my time slot to
> increase very much. I wanted to know the ramping duration because this will
> affect the time slot duration. Second option could be that I can add an RF
> filter at the output of USRPs.
>
> On Thu, Oct 23, 2014 at 10:25 AM, Matt Ettus <[email protected]> wrote:
>
>>
>> Yes, but it is even better to ramp up at the beginning and down at the
>> end, and then pad a little bit with zeros. If you ramp up and down
>> smoothly for 1us, you'll confine the emissions to about 1 MHz on either
>> side. All bursty communication systems will do this, like Bluetooth, Wifi,
>> even morse code, and most newer standards even specify the ramping rate.
>>
>> Matt
>>
>>
>> On Wed, Oct 22, 2014 at 10:08 PM, bob wole <[email protected]> wrote:
>>
>>> So you are suggesting that I should zero pad samples at start and end of
>>> my burst to avoid this ?
>>>
>>> On Wed, Oct 22, 2014 at 9:16 PM, Matt Ettus <[email protected]> wrote:
>>>
>>>>
>>>> When you start and stop transmission without smoothly ramping the
>>>> signal to zero at the beginning and end, you will create wideband spurs.
>>>> Just think about it as amplitude modulation. Even if you are transmitting
>>>> a pure sine wave, if you turn it on and off quickly, it will create out of
>>>> band spurs. Hams call this keyclicks.
>>>>
>>>> Matt
>>>>
>>>>
>>>> On Wed, Oct 22, 2014 at 1:25 AM, bob wole via USRP-users <
>>>> [email protected]> wrote:
>>>>
>>>>> I noticed that there are a lot of significant spurs generated in the
>>>>> output of WBX, on different frequencies randomly, when I use tx_time,
>>>>> tx_sob_tx_eob tags. I do not see these spurs if I transmit continuously.
>>>>> These spurs appears only when I start and stop transmission using stream
>>>>> tags.
>>>>> How can I get rid of these spurs and what is the cause?
>>>>>
>>>>> -
>>>>> Bob
>>>>>
>>>>> _______________________________________________
>>>>> 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/20141022/217be91e/attachment-0001.html>
------------------------------
Message: 21
Date: Thu, 23 Oct 2014 11:06:49 +0500
From: bob wole <[email protected]>
To: Matt Ettus <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] N210 WBX annoying spurs while switching
Message-ID:
<CAGd3Ozxc73hUmNLCJjuewDeu=fhromc4aayjugcq_pevwzl...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Okay, I'll make a custom block in gnruadio to achieve ramp up/down for FSK
waveform to avoid "keyclicks" .
On Thu, Oct 23, 2014 at 10:52 AM, Matt Ettus <[email protected]> wrote:
>
> No problem. The RF filter at the output really isn't the proper way to
> solve this problem, it will just keep the noise within a band. What you
> really want is to avoid putting out energy outside of your channel, and
> that can only be done with ramping.
>
> Matt
>
> On Wed, Oct 22, 2014 at 10:46 PM, bob wole <[email protected]> wrote:
>
>> Thanks Matt for your response, that is the exact answer I was looking
>> for. Actually I am using USRPs for TDMA and I do not want my time slot to
>> increase very much. I wanted to know the ramping duration because this will
>> affect the time slot duration. Second option could be that I can add an RF
>> filter at the output of USRPs.
>>
>> On Thu, Oct 23, 2014 at 10:25 AM, Matt Ettus <[email protected]> wrote:
>>
>>>
>>> Yes, but it is even better to ramp up at the beginning and down at the
>>> end, and then pad a little bit with zeros. If you ramp up and down
>>> smoothly for 1us, you'll confine the emissions to about 1 MHz on either
>>> side. All bursty communication systems will do this, like Bluetooth, Wifi,
>>> even morse code, and most newer standards even specify the ramping rate.
>>>
>>> Matt
>>>
>>>
>>> On Wed, Oct 22, 2014 at 10:08 PM, bob wole <[email protected]> wrote:
>>>
>>>> So you are suggesting that I should zero pad samples at start and end
>>>> of my burst to avoid this ?
>>>>
>>>> On Wed, Oct 22, 2014 at 9:16 PM, Matt Ettus <[email protected]> wrote:
>>>>
>>>>>
>>>>> When you start and stop transmission without smoothly ramping the
>>>>> signal to zero at the beginning and end, you will create wideband spurs.
>>>>> Just think about it as amplitude modulation. Even if you are transmitting
>>>>> a pure sine wave, if you turn it on and off quickly, it will create out of
>>>>> band spurs. Hams call this keyclicks.
>>>>>
>>>>> Matt
>>>>>
>>>>>
>>>>> On Wed, Oct 22, 2014 at 1:25 AM, bob wole via USRP-users <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> I noticed that there are a lot of significant spurs generated in the
>>>>>> output of WBX, on different frequencies randomly, when I use tx_time,
>>>>>> tx_sob_tx_eob tags. I do not see these spurs if I transmit continuously.
>>>>>> These spurs appears only when I start and stop transmission using stream
>>>>>> tags.
>>>>>> How can I get rid of these spurs and what is the cause?
>>>>>>
>>>>>> -
>>>>>> Bob
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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/44b7a8d4/attachment-0001.html>
------------------------------
Message: 22
Date: Thu, 23 Oct 2014 08:11:36 +0200
From: "Ralph A. Schmid, dk5ras" <[email protected]>
To: "'Ben Wojtowicz'" <[email protected]>, "'Lin HUANG'"
<[email protected]>
Cc: [email protected], [email protected]
Subject: Re: [USRP-users] [Openlte-discuss] uhd Error?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Sounds great!
The Ettus guys seem to have no really good idea at the moment, and I hesitate
bugging them when I do not really have the time to do some deeper research, not
to mention my bad knowledge about Linux, logfiles and all that crazy stuff
under the hood.
At least I know that something in the framework of uhd and gnuradio goes wrong,
and I know that similar hardware from Nuand, the BladeRF with identical USB
chip (Cypress FX3) and similar sampling rates works on the same virtual machine
flawlessly, and that the B210 hardware must be OK, as it works on the same PC
with Windows without any issues for hours.
At the moment I am trying setting up a Kubuntu 12.04 VM to see any possible OS
influence.
Ralph.
From: Ben Wojtowicz [mailto:[email protected]]
Sent: Thursday, October 23, 2014 1:00 AM
To: Lin HUANG
Cc: Ralph A. Schmid, dk5ras; [email protected]
Subject: Re: [Openlte-discuss] uhd Error?
All,
Configuration file is coming. Coding is done, I'm just testing it now and it
will be included in the next release.
Ralph,
I have not seen the uhd fault that you included. It may be worth bringing the
Ettus folks into the mix to help resolve the issue. Glad your making progress!
Thanks,
Ben
On Tue, Oct 21, 2014 at 2:03 AM, Lin HUANG <[email protected]
<mailto:[email protected]> > wrote:
Yep. 'Typing commands' every-time also makes me crazy. Configuration file is
needed. -Lin
2014-10-19 20:06 GMT+08:00 Ralph A. Schmid, dk5ras <[email protected]
<mailto:[email protected]> >:
Hi,
I only get RF at 1.4 MHz bandwidth, no output at all with 3 or 5 MHz. At 1.4
within some minutes I get errors like this at the bottom:
-- Tune Request: 1775.000000 MHz
-- The RF LO does not support the requested frequency:
-- Requested LO Frequency: 1775.000000 MHz
-- RF LO Result: 1774.999998 MHz
-- Attempted to use the DSP to reach the requested frequency:
-- Desired DSP Frequency: -0.000002 MHz
-- DSP Result: -0.000002 MHz
-- Successfully tuned to 1775.000000 MHz
--
OO
UHD Error:
recv packet demuxer unexpected sid 0x50
DUOOOSegmentation fault (core dumped)
It is not the same each time, but always something uhd related.
Kubuntu 14.04 32bit lowlatency in a VM, latest UHD master, and a B210.
Still the ?typing commands orgy? after every crash or change drives me crazy, I
really need to script configuring the thing :)
When transmission lasts long enough to complete a search with a phone, 00101 is
found, so basic functionality looks OK.
Ralph.
--
Ralph A. Schmid
Mondstr. 10
90762 F?rth
+49-171-3631223 <tel:%2B49-171-3631223>
[email protected] <mailto:[email protected]>
http://www.bclog.de/
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
Openlte-discuss mailing list
[email protected]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/openlte-discuss
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
Openlte-discuss mailing list
[email protected]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/openlte-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141023/c90fb5f2/attachment-0001.html>
------------------------------
Message: 23
Date: Thu, 23 Oct 2014 02:27:03 -0400
From: Dan CaJacob <[email protected]>
To: bob wole <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] N210 WBX annoying spurs while switching
Message-ID:
<CAMOmJOCLW5gu0AD=y8e=brhwxauamwvmvrm5kposqrcsbrm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I've never used this, but it looks like the Power Squelch block in GR will
do what you want. Others who know better will correct me if I am wrong.
Very Respectfully,
Dan CaJacob
On Thu, Oct 23, 2014 at 2:06 AM, bob wole via USRP-users <
[email protected]> wrote:
> Okay, I'll make a custom block in gnruadio to achieve ramp up/down for FSK
> waveform to avoid "keyclicks" .
>
> On Thu, Oct 23, 2014 at 10:52 AM, Matt Ettus <[email protected]> wrote:
>
>>
>> No problem. The RF filter at the output really isn't the proper way to
>> solve this problem, it will just keep the noise within a band. What you
>> really want is to avoid putting out energy outside of your channel, and
>> that can only be done with ramping.
>>
>> Matt
>>
>> On Wed, Oct 22, 2014 at 10:46 PM, bob wole <[email protected]> wrote:
>>
>>> Thanks Matt for your response, that is the exact answer I was looking
>>> for. Actually I am using USRPs for TDMA and I do not want my time slot to
>>> increase very much. I wanted to know the ramping duration because this will
>>> affect the time slot duration. Second option could be that I can add an RF
>>> filter at the output of USRPs.
>>>
>>> On Thu, Oct 23, 2014 at 10:25 AM, Matt Ettus <[email protected]> wrote:
>>>
>>>>
>>>> Yes, but it is even better to ramp up at the beginning and down at the
>>>> end, and then pad a little bit with zeros. If you ramp up and down
>>>> smoothly for 1us, you'll confine the emissions to about 1 MHz on either
>>>> side. All bursty communication systems will do this, like Bluetooth, Wifi,
>>>> even morse code, and most newer standards even specify the ramping rate.
>>>>
>>>> Matt
>>>>
>>>>
>>>> On Wed, Oct 22, 2014 at 10:08 PM, bob wole <[email protected]> wrote:
>>>>
>>>>> So you are suggesting that I should zero pad samples at start and end
>>>>> of my burst to avoid this ?
>>>>>
>>>>> On Wed, Oct 22, 2014 at 9:16 PM, Matt Ettus <[email protected]> wrote:
>>>>>
>>>>>>
>>>>>> When you start and stop transmission without smoothly ramping the
>>>>>> signal to zero at the beginning and end, you will create wideband spurs.
>>>>>> Just think about it as amplitude modulation. Even if you are
>>>>>> transmitting
>>>>>> a pure sine wave, if you turn it on and off quickly, it will create out
>>>>>> of
>>>>>> band spurs. Hams call this keyclicks.
>>>>>>
>>>>>> Matt
>>>>>>
>>>>>>
>>>>>> On Wed, Oct 22, 2014 at 1:25 AM, bob wole via USRP-users <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> I noticed that there are a lot of significant spurs generated in the
>>>>>>> output of WBX, on different frequencies randomly, when I use tx_time,
>>>>>>> tx_sob_tx_eob tags. I do not see these spurs if I transmit continuously.
>>>>>>> These spurs appears only when I start and stop transmission using stream
>>>>>>> tags.
>>>>>>> How can I get rid of these spurs and what is the cause?
>>>>>>>
>>>>>>> -
>>>>>>> Bob
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> USRP-users mailing list
>>>>>>> [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/dfd9fefe/attachment-0001.html>
------------------------------
Message: 24
Date: Thu, 23 Oct 2014 08:56:39 +0200
From: "Ralph A. Schmid, dk5ras" <[email protected]>
To: "'bob wole'" <[email protected]>, <[email protected]>
Subject: Re: [USRP-users] N210 WBX annoying spurs while switching
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
The signal theory behind is that a perfect steep rise (100% vertical on the
scope screen) produces a signal peak of infinite bandwidth. Google for Dirac
pulse, that makes it clear. Thus it is essential to do some ramping, to avoid
interference to the neighbor channels.
A real world example where exactly this (almost) infinite bandwidth is the
dedicated goal would be UWB, wireless USB and related stuff.
Ralph.
From: USRP-users [mailto:[email protected]] On Behalf Of bob
wole via USRP-users
Sent: Thursday, October 23, 2014 8:07 AM
To: Matt Ettus
Cc: [email protected]
Subject: Re: [USRP-users] N210 WBX annoying spurs while switching
Okay, I'll make a custom block in gnruadio to achieve ramp up/down for FSK
waveform to avoid "keyclicks" .
On Thu, Oct 23, 2014 at 10:52 AM, Matt Ettus <[email protected]
<mailto:[email protected]> > wrote:
No problem. The RF filter at the output really isn't the proper way to solve
this problem, it will just keep the noise within a band. What you really want
is to avoid putting out energy outside of your channel, and that can only be
done with ramping.
Matt
On Wed, Oct 22, 2014 at 10:46 PM, bob wole <[email protected]> wrote:
Thanks Matt for your response, that is the exact answer I was looking for.
Actually I am using USRPs for TDMA and I do not want my time slot to increase
very much. I wanted to know the ramping duration because this will affect the
time slot duration. Second option could be that I can add an RF filter at the
output of USRPs.
On Thu, Oct 23, 2014 at 10:25 AM, Matt Ettus <[email protected]
<mailto:[email protected]> > wrote:
Yes, but it is even better to ramp up at the beginning and down at the end, and
then pad a little bit with zeros. If you ramp up and down smoothly for 1us,
you'll confine the emissions to about 1 MHz on either side. All bursty
communication systems will do this, like Bluetooth, Wifi, even morse code, and
most newer standards even specify the ramping rate.
Matt
On Wed, Oct 22, 2014 at 10:08 PM, bob wole <[email protected]
<mailto:[email protected]> > wrote:
So you are suggesting that I should zero pad samples at start and end of my
burst to avoid this ?
On Wed, Oct 22, 2014 at 9:16 PM, Matt Ettus <[email protected]
<mailto:[email protected]> > wrote:
When you start and stop transmission without smoothly ramping the signal to
zero at the beginning and end, you will create wideband spurs. Just think
about it as amplitude modulation. Even if you are transmitting a pure sine
wave, if you turn it on and off quickly, it will create out of band spurs.
Hams call this keyclicks.
Matt
On Wed, Oct 22, 2014 at 1:25 AM, bob wole via USRP-users
<[email protected] <mailto:[email protected]> > wrote:
I noticed that there are a lot of significant spurs generated in the output of
WBX, on different frequencies randomly, when I use tx_time, tx_sob_tx_eob tags.
I do not see these spurs if I transmit continuously. These spurs appears only
when I start and stop transmission using stream tags.
How can I get rid of these spurs and what is the cause?
-
Bob
_______________________________________________
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/f2529247/attachment-0001.html>
------------------------------
Message: 25
Date: Thu, 23 Oct 2014 09:57:41 +0200
From: Carlos Alberto Ruiz Naranjo <[email protected]>
To: Ian Buckley <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Connect USRP to OSMO board
Message-ID:
<CAP2eGPje39G935CByt-3W6z9Zx+B_9jCxv6=y4-jx8ragvc...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
OK! Thank you ;)
2014-10-20 20:06 GMT+02:00 Ian Buckley <[email protected]>:
> Why not just throw in an off the shelf bias-T to act as a DC block in the
> RF path? For example http://www.minicircuits.com/pdfs/ZFBT-4R2G+.pdf
> That way you don't have to worry about what WBX or any other signal source
> might tolerate.
> -Ian
>
> On Oct 20, 2014, at 5:17 AM, Carlos Alberto Ruiz Naranjo via USRP-users <
> [email protected]> wrote:
>
> I have a GPS receiver (
> http://u-blox.com/images/downloads/Product_Docs/LEA-NEO-6T_ProductSummary_%28GPS.G6-HW-09020%29.pdf
> ) with a Osmo board ( http://openbsc.osmocom.org/trac/wiki/osmo-lea6t-gps
> )
>
>
> Can I directly connect the USRP (WBX) to the GPS receiver? (RF USRP --->
> RF receiver)
> Can I damage the WBX board with the antenna power supply (of RF port)?
>
> Thank you.
> _______________________________________________
> 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/164c168a/attachment-0001.html>
------------------------------
Message: 26
Date: Thu, 23 Oct 2014 12:16:42 +0200
From: Perper <[email protected]>
Cc: USRP List <[email protected]>
Subject: Re: [USRP-users] Storing signals with full bandwidth of USRP
x300/x310
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
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
>
>
------------------------------
Message: 27
Date: Thu, 23 Oct 2014 07:49:58 -0400
From: Andy Walls <[email protected]>
To: bob wole <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] N210 WBX annoying spurs while switching
Message-ID: <1414064998.2541.4.camel@localhost>
Content-Type: text/plain; charset="UTF-8"
FWIW, this paper investigates using a Tukey window around an AIS GMSK
TDMA burst to ramp up and down, optionally followed by a LPF:
http://www.univ-brest.fr/lest/tst/publications/pdf/0506itstAis.pdf
Figures 5 and 8 show the spectral difference between Rectangular (R),
Exponentional (E), and Tukey Window (W) ramps.
Regards,
Andy
On Thu, 2014-10-23 at 11:06 +0500, bob wole via USRP-users wrote:
> Okay, I'll make a custom block in gnruadio to achieve ramp up/down for
> FSK waveform to avoid "keyclicks" .
>
> On Thu, Oct 23, 2014 at 10:52 AM, Matt Ettus <[email protected]> wrote:
>
> No problem. The RF filter at the output really isn't the
> proper way to solve this problem, it will just keep the noise
> within a band. What you really want is to avoid putting out
> energy outside of your channel, and that can only be done with
> ramping.
>
>
> Matt
>
> On Wed, Oct 22, 2014 at 10:46 PM, bob wole <[email protected]>
> wrote:
> Thanks Matt for your response, that is the exact
> answer I was looking for. Actually I am using USRPs
> for TDMA and I do not want my time slot to increase
> very much. I wanted to know the ramping duration
> because this will affect the time slot duration.
> Second option could be that I can add an RF filter at
> the output of USRPs.
>
> On Thu, Oct 23, 2014 at 10:25 AM, Matt Ettus
> <[email protected]> wrote:
>
> Yes, but it is even better to ramp up at the
> beginning and down at the end, and then pad a
> little bit with zeros. If you ramp up and
> down smoothly for 1us, you'll confine the
> emissions to about 1 MHz on either side. All
> bursty communication systems will do this,
> like Bluetooth, Wifi, even morse code, and
> most newer standards even specify the ramping
> rate.
>
>
> Matt
>
>
>
> On Wed, Oct 22, 2014 at 10:08 PM, bob wole
> <[email protected]> wrote:
> So you are suggesting that I should
> zero pad samples at start and end of
> my burst to avoid this ?
>
>
> On Wed, Oct 22, 2014 at 9:16 PM, Matt
> Ettus <[email protected]> wrote:
>
> When you start and stop
> transmission without smoothly
> ramping the signal to zero at
> the beginning and end, you
> will create wideband spurs.
> Just think about it as
> amplitude modulation. Even if
> you are transmitting a pure
> sine wave, if you turn it on
> and off quickly, it will
> create out of band spurs.
> Hams call this keyclicks.
>
>
> Matt
>
>
>
> On Wed, Oct 22, 2014 at 1:25
> AM, bob wole via USRP-users
> <[email protected]>
> wrote:
>
> I noticed that there
> are a lot of
> significant spurs
> generated in the
> output of WBX, on
> different frequencies
> randomly, when I use
> tx_time, tx_sob_tx_eob
> tags. I do not see
> these spurs if I
> transmit continuously.
> These spurs appears
> only when I start and
> stop transmission
> using stream tags.
>
> How can I get rid of
> these spurs and what
> is the cause?
>
> -
>
> Bob
>
>
>
>
> _______________________________________________
> USRP-users mailing
> list
> [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
------------------------------
Message: 28
Date: Thu, 23 Oct 2014 10:31:09 -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"
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
----- 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:
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141023/d1752c72/attachment-0001.html>
------------------------------
Message: 29
Date: Thu, 23 Oct 2014 10:42:51 -0400
From: "Marcus D. Leech" <[email protected]>
To: [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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141023/b241a56b/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 22
******************************************
