Send USRP-users mailing list submissions to
usrp-users@lists.ettus.com
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
usrp-users-requ...@lists.ettus.com
You can reach the person managing the list at
usrp-users-ow...@lists.ettus.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. E310: a circular buffer to save rx samples to SD Card
(Crozzoli Maurizio)
2. Rfnoc UHD processor load on E310 increased with recent update
(EJ Kreinar)
3. UHD E312 - get_rx_stream multiple times (Bobby Zovsky)
4. NI-USRP 15.0 driver is not working on Ubuntu 16.04 (Dennis Stroh)
5. Re: E310 filter configuration (Ian Buckley)
6. uhd_rx_streamer_recv function keeps returning 0 as the number
of received samples (Felipe Augusto Pereira de Figueiredo)
7. Re: E310 filter configuration (Yake Li)
8. Re: Rfnoc UHD processor load on E310 increased with recent
update (EJ Kreinar)
9. Re: E310 filter configuration (Rob Kossler)
10. E310 cross compilation issues (deepa kumar)
----------------------------------------------------------------------
Message: 1
Date: Thu, 11 May 2017 16:22:33 +0000
From: Crozzoli Maurizio <maurizio.crozz...@telecomitalia.it>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] E310: a circular buffer to save rx samples to SD
Card
Message-ID:
<dd716bb378b044fca8c1e788b167dcbf@TELMBXD10BA020.telecomitalia.local>
Content-Type: text/plain; charset="ISO-8859-1"
Hi!
We working on an E310.
We are trying to implement a receiver operating at 1.92 Msps which is able to
store data directly to the SD card of the E310 (a partitioned space with
optimized ext4 performance).
Our implementation is base do two threads:
1. the main one receives samples from the E310 RX stages and stores them in a
sort of circular buffer" in order to try and extend the total acquisition time
frame (if we do not use the "circular buffer" approach we can save up to 84
million samples from two channels but we would like to get more if feasible);
2. another one is in charge of getting data out of the "circular buffer" and
save them to a file in the SD Card.
A skeleton of our source code based on " rx_multi_samples.cpp" example provided
by Ettus is given below.
As a matter of fact the code runs and it can save about 17 million samples
(8800*(1016*2)) from two channels with a buffer really small (samps_per_buff =
1016 elements; vect_size = samps_per_buff * 2) which would lead us to conclude
that the activity related to writing data to SD is not as slow as we would have
expected.
If we can get such result with such a small buffer we would expect to be able
to get more interesting with a much larger buffer (1016*N, N>>2) but, in
practice, we found out that our idea is not true. We tried to use a buffer
large enough to store 84 million (N=82000) samples (as we could do before
implementing current "circular buffer" approach), but no way to save to SD more
than the 17 million samples we could get with N=2.
Is there anyone in the list who could help us to understand what is going on
and, if possible, to find a solution?
TIA!
BR,
Maurizio.
/// GLOBAL VARIABLES //////////////////////////////////////////
const size_t samps_per_buff = 1016;
size_t vect_size = samps_per_buff * 2; // Vector dimension
size_t iRead = 0; // Index of read item
size_t iWrite = 0; // Index of written item
vector<vector<complex<short> > > buffs(2, vector<complex<short> >(vect_size));
///////////////////////////////////////////////////////////////
/// THREAD ////////////////////////////////////////////////////
void* writeData(void* param)
{
[...]
do
{
if(iRead > iWrite)
{
buf_ptr[0] = &buffs[0].at(iWrite%vect_size);
buf_ptr[1] = &buffs[1].at(iWrite%vect_size);
if(iRead%vect_size == iWrite%vect_size) pthread_mutex_lock(&mtx);
fwrite(buf_ptr[0],4,samps_per_buff,OutRXA);
fwrite(buf_ptr[1],4,samps_per_buff,OutRXB);
if(iRead%vect_size == iWrite%vect_size) pthread_mutex_unlock(&mtx);
iWrite += samps_per_buff;
}
}
while (!done);
return NULL;
}
///////////////////////////////////////////////////////////////
/// START MAIN ////////////////////////////////////////////////
//create a usrp device
//always select the subdevice first, the channel mapping affects the other
settings
//set the rx sample rate (sets across all channels)
//detect which channels to use
//create a receive streamer
//linearly map channels (index0 = channel0, index1 = channel1, ...)
//meta-data will be filled in by recv()
//create a vector of pointers to point to each of the channel buffers
//setup streaming
//issue stream command
///////////////////////////////////////////////////////////////////////
// Start Thread to enable "parallel" writing activity to SD (see above)
///////////////////////////////////////////////////////////////////////
int iLoopMax = total_num_samps/samps_per_buff;
for(int iLoop = 0; iLoop < iLoopMax; iLoop++)
{
if ( (iRead-iWrite) >= vect_size )
break;
// E310 reads bursts of size_t samps_per_buff = 1016 elements
size_t num_rx_samps = rx_stream->recv(buff_ptrs, samps_per_buff, md,
timeout);
iRead += num_rx_samps;
//use a small timeout for subsequent packets (large enough to receive
all samples)
timeout = ((double)samps_per_buff / rate) +0.1;
if(iRead < total_num_samps)
{
//advance pointers
}
}
///////////////////////////////////////////////////////////////
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone
indicate. La diffusione, copia o qualsiasi altra azione derivante dalla
conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate
ricevuto questo documento per errore siete cortesemente pregati di darne
immediata comunicazione al mittente e di provvedere alla sua distruzione,
Grazie.
This e-mail and any attachments is confidential and may contain privileged
information intended for the addressee(s) only. Dissemination, copying,
printing or use by anybody else is unauthorised. If you are not the intended
recipient, please delete this message and any attachments and advise the sender
by return e-mail, Thanks.
Rispetta l'ambiente. Non stampare questa mail se non ? necessario.
------------------------------
Message: 2
Date: Thu, 11 May 2017 12:37:33 -0400
From: EJ Kreinar <ejkrei...@gmail.com>
To: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] Rfnoc UHD processor load on E310 increased with
recent update
Message-ID:
<cadrnh23qc8crypjpzxypr+akwppybszbs1ownbtsyjr20dd...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi All,
I want to bring up a potential UHD regression on the E310 and see if anyone
has seen the same behavior or knows of a solution.
I recently upgraded uhd/rfnoc-devel to the current head. I found that some
of my test cases took extra processing load than I remembered before, so I
put together a regression test to figure out if this is really an issue.
The idea is to run an "FPGA loopback" mode, which is doing nothing except
pushing data from the PS to the PL and back. I added a throttle which lets
me run at a specific sample rate (I used 500 kHz) so I can observe the
processor load. I ran "htop" on the E310 and recorded the processing load
on each core during the test.
I tested two flowgraphs to evaluate the performance with and without rfnoc.
a. Non-RFNoC flowgraph: File Source -> Throttle -> File Sink
b. RFNoC flowgraph: File Source -> Throttle -> RFNoC FIFO -> RFNoC FIFO
-> File Sink
Here's my test results:
1. UHD as of 2/7/2017, SHA 2cf80a6
a. Non-rfnoc flowgraph: 4% - 8% processing load on each core
b. RFNoC flowgraph: 12% - 14% processing load on each core
2. UHD as of 4/15/2017, SHA 24b9857 (plus a minor patch to fix an
initialization problem-- shouldnt impact the performance test)
a. Non-rfnoc flowgraph: 4% - 7% processing load on each core
b. RFNoC flowgraph: One core is pegged at 100% for the duration of the
test. The other core is around 25%-30%
I was hopeful the extra processing was my imagination, but I've found the
result is repeatable for this unit test and for other flowgraphs where I'm
crossing PS/PL domain this way. I havent dug TOO far into it, but I've
tested RFNoC Radio -> PS on the updated UHD without seeing the dramatic
processing increase-- so I suspect it may have something to do with the PS
-> PL interface.
Any thoughts??
Thanks!
EJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170511/68e507d2/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 11 May 2017 08:13:45 +0000 (UTC)
From: Bobby Zovsky <bobbyzov...@yahoo.fr>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] UHD E312 - get_rx_stream multiple times
Message-ID: <357941838.5104049.1494490425...@mail.yahoo.com>
Content-Type: text/plain; charset="utf-8"
Hello,
I am currently testing the USRP E312 to use it as a receiver.I want to be able
to trigger some RX process according specified tuning given as parameters.
My problem is that I am able to get a rx_streamer only once in my program.
You will find below an example on how I am using the UHD and the error returned
by the program.
int main(void){??? device_addrs_t dev_addrs = device::find(device_addr_t());
??? usrp::mulit_usrp::sptr ettus_e312 = usrp::multi_usrp::make(dev_addrs[0]);
????uhd::stream_args_t stream_args(std::string("sc16"), std::string("sc16"));
??? std::cout << "getting rx streamer once... ";
??? rx_streamer::sptr rx_stream = ettus_e312->get_rx_stream(stream_args);???
std::cout << " OK" << std::endl;
??? usleep(1000000);
??? std::cout << "Reset" << std::endl;
??? rx_stream.reset();
??? usleep(1000000);
??? std::cout << "getting rx streamer twice... ";??? rx_stream =
ettus_e312->get_rx_stream(stream_args);??? std::cout << " OK" << std::endl;
??? return EXIT_SUCCESS;
}
This program compile properly, but during the second call to get_rx_stream()
the following assertion error is thrown:
terminate called after throwing an instance of 'uhd::assertion_error'???
what(): AssertionError: _send_entries_in_use.at(which_stream? <=
H2S_NUM_CMDS??? in uhd::transport::zero_copy_if::sptr
e300_fifo_interface_impl::_make_xport(size_t, const
uhd::transport::zero_copy_xport_params&, bool)??? at
/home/balister/release-4/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-arm-gnueabi/uhd/3.9.2-r0/uhd-3.9.2/lib/usrp/e300/e300_fifo_config.cpp:395Aborted
What am I doing wrong ? And how can I use rx_streamer multiple times ?
Thanks in advance.
Benjamin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170511/8e00a757/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 11 May 2017 10:15:37 +0000
From: Dennis Stroh <dennis.st...@hs-owl.de>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] NI-USRP 15.0 driver is not working on Ubuntu
16.04
Message-ID:
<45e73ab1f0df714caf91ff312ed898ad350bd...@raven01.svc.hs-owl.de>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
I want to connect a USRP X300 via PCIe to achieve high data throughput.
I installed and updated the NI-USRP 15.0 driver by following the steps of the
description in the USRP Manual.
However, the update failed and the driver is not properly working.
What should I do to make this configuration work?
Kind regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170511/d144f71f/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 11 May 2017 11:15:21 -0700
From: Ian Buckley <i...@ionconcepts.com>
To: "USRP-users@lists.ettus.com USRP-users"
<usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] E310 filter configuration
Message-ID: <2ff8ac24-4cd2-42da-abf7-83d55f4e7...@ionconcepts.com>
Content-Type: text/plain; charset="utf-8"
Yake,
In principle your approach is a good one, however there are some H/W
constraints of the E310 that will prevent you from using the frequencies and
bandwidths you describe.
The radio it?s self has baseband analog RX filters that can not be opened wider
than 56MHz (at 3dB loss).
Whilst the max sample rate supported is 61.44MHz, that is only in a SISO
configuration. In a MIMO configuration such as you describe the sample rate is
limited to 30.72MHz (due to the FPGA/PCB design).
Since you need 60 + 2/2 + 2/2 = 62MHz bandwidth as currently described you are
going to have to move those 2 carriers closer together (30.72 -(2/2) -(2/2) =
28.72MHz max carrier separation).
An alternate approach *might* be to use RFNoC to place two DDC?s on one radio
channel, but I?m years out of date with progress on that so I don?t know if
that is a supported configuration.
That would give you 61.44 - (2/2) - (2/2)= 59.44 max carrier separation, so you
would be limited by the 56MHz analog baseband filter constraint in that
configuration.
Regards
-Ian
> On May 11, 2017, at 5:25 AM, Yake Li via USRP-users
> <usrp-users@lists.ettus.com> wrote:
>
> I had an Ettus E310 sampling problem. After some talk with Rob, I know what
> direction I should try but I am still a little bit confused. Please see below
> our discussion and thanks for Rob's help.
>
> My question is as follows: I can only do 6 MS/s sampling for a short while
> because E310 tells me overflow after 40 seconds of data transmission using
> GigE (USRP to UDP). But I can live with it for proof of concept. I have two
> pulses (1 us length which roughly equals to a bandwidth of 2 MHz) with
> different carriers (one is 2030 MHz and the other is 1970 MHz) that I want to
> capture and measure the leading edge (phase is not important). As the two Rx
> channels of E310 share one Rx LO, I cannot do baseband sampling for both. So
> I want to configure the Rx channels to 2000 MHz so that I get 30 MHz IF, and
> then do passband smapling for both using 6 MS/s. But the test results show
> that the passband sampling is not working. I still see the pulses, but the
> amplitude is significantly attenuated and huge artificials appear. I guess
> the filters in E310 is not correctly configured. Can anybody help me for the
> filter configuration?
>
> I prefer gnuradio python solution but UHD is also ok if it solves the problem.
>
> Regards,
>
> Yake
>
>
> ---------- Forwarded message ----------
> From: Rob Kossler <rkoss...@nd.edu <mailto:rkoss...@nd.edu>>
> Date: 2017-05-10 23:36 GMT-02:30
> Subject: Re: [USRP-users] E310 filter configuration
> To: Yake Li <liyak...@gmail.com <mailto:liyak...@gmail.com>>
>
>
> Yake,
> If you contact the list again, explain that you are trying to receive 2
> signals, one at 1.97 and one at 2.03 GHz, each with 3 MHz bandwidth using an
> E310. With this information, I think that someone can help explain how to do
> it. Also, explain if you are using UHD directly from C++ or if you are using
> gnuradio.
> Rob
>
> On Wed, May 10, 2017 at 9:24 PM, Rob Kossler <rkoss...@nd.edu
> <mailto:rkoss...@nd.edu>> wrote:
> Yake,
> It is possible with the USRP to have the analog LO at one frequency and then
> a digital LO at another frequency. Perhaps my explanation is not great, but
> the point is that you can have the FPGA center its decimation filter at a
> different location than the analog LO. In the Ettus UHD manual, the
> "set_rx_freq" function has an argument that is a "tune_request" and this can
> have both a "rf_freq" and a "dsp_freq". Actually the rf_freq should be set
> to the freq that you want (in your case 2.03 GHz) and the dsp_freq should be
> set to 30 MHz. This will automatically cause the analog LO to be at 2.0
> GHz.For your other signal, you can set rf_freq=1.97 GHz and dsp_freq=-30MHz.
> Then, you should get both of the signals you wanted and they will be at
> baseband.
>
> The only trouble that I see with this is that perhaps there is an analog
> anti-aliasing filter of around 56 MHz. But, maybe this would be OK as the
> filter roll-off might be slow enough. The other trouble I see is that
> perhaps you will need to run the master clock at 61.44 MHz or something like
> that in order that you have this kind of bandwidth for both of your signals.
> I really don't know if that is possible with 2 channel. But, my suggestion
> is to play around with this and if you still have trouble, maybe contact the
> list again. If you have trouble, maybe try a test case with signals at 1.99
> and 2.01 GHz and try this method to receive both signals. This should be
> easily possible.
>
> Let me know how it goes.
> Rob
>
> On Wed, May 10, 2017 at 3:04 PM, Yake Li <liyak...@gmail.com
> <mailto:liyak...@gmail.com>> wrote:
> Rob,
>
> Now I understand. Yes, I am trying to use the aliased version near DC to
> reconstruct the pusles. So the master clock rate is for ADC and FPGA, and the
> sampling rate is the decmiated rate. In my original setting, I use 48 MHz as
> my masker clock rate and this will sample the 30 MHz without aliasing. Then
> the FPGA applies a low pass filter before decimating the sampling rate to 6
> MHz, so the IF is attenuated in this process.
>
> The reason I was trying to do bandpass sampling is because we have another
> signal comes at 1970 MHz. As the two Rx of E310 share the same LO, we cannot
> sample the two signals both at the baseband. That is how the passband IF
> requirement comes up.
>
> I did another test, though. I set the master clock to be 10 MHz (I guess both
> ADC and FPGA work at this 10 MHz?) and sampling rate to be 5 MHz (still using
> 30 MHz IF). In this configuration, I will actually sample the aliased
> spectrum at DC. However, the same problem happens. I guess somewhere else in
> E310 is still preventing the 30 MHz IF signal to go through. Maybe the AD9361
> is not capable of doing passband sampling.
>
> Is there any possible way in E310 that could allow me to do the bandpass
> sampling?
>
> Regards,
>
> Yake
>
> 2017-05-10 12:08 GMT-02:30 Rob Kossler <rkoss...@nd.edu
> <mailto:rkoss...@nd.edu>>:
> Yake,
> So, you are trying to "undersample" the 30 MHz IF signal with the knowledge
> that the aliased version near DC will suffice? If so, this is not a method
> that can work with the USRP. At least not with the existing FPGA code. The
> USRP does not actually sample at the rate you specify in the sample rate.
> The USRP A/D typically operates at a higher rate and then the FPGA implements
> digital filtering and downconversion to provide the samples at the specified
> sample rate.
>
> So, in your case, I think that the analog filtering is not even relevant.
> This filtering is intended to reject large out-of-band signals that can cause
> problems at the RF front end. This filtering will not impact any signal that
> is only 30 MHz from the LO. The problem for you is the digital filtering &
> downconversion DSP that is implemented in the FPGA. This is the filtering
> that is rejecting your 30 MHz signal. But, I'm not as familiar with the E310
> as I am with the X310 so it is possible that the "master clock rate" is also
> relevant.
>
> In any event, can you explain why you need to have the LO at 2 GHz for your
> application. Why not have the LO at 2.03 GHz?
> Rob
>
> On Wed, May 10, 2017 at 8:50 AM, Yake Li <liyak...@gmail.com
> <mailto:liyak...@gmail.com>> wrote:
> Hi Rob,
>
>
>
> Thanks for your reply.
>
>
>
> I think I did not explain my problem well. Our application needs us to use
> 2GHz to demodulate the 2.03 GHz pulses, which means we have to deal with the
> 30 MHz IF signal. However, we do not need the phase information of the IF
> signal. We only care about the leading edge of the pulse, that is why we are
> only interested in the 2.5 MHz bandwidth but not the 30 MHz center frequency.
> If we use 6 MHz to sample the 2.5 MHz bandwidth IF signal centered at 30 MHz,
> we are actually sampling the spectrum copy of the IF signal that is centered
> at zero frequency. The result should approximately be rectangular pulses in
> time domain.
>
>
>
> Therefore, theoretically, if the 30 MHz IF signal can pass the filters before
> ADC without distortion and attenuation, we should be able get the same result
> as shown in fig1 of my last email. But now it is not the case (we actually
> got fig2).
>
>
>
> I do not know if my theory was wrong or my settings of E310 were wrong.
>
>
>
> Yake
>
>
>
>
>
>
>
> From: Rob Kossler [mailto:rkoss...@nd.edu <mailto:rkoss...@nd.edu>]
> Sent: May 9, 2017 3:09 PM
> To: Yake Li <liyak...@gmail.com <mailto:liyak...@gmail.com>>
>
>
> Subject: Re: [USRP-users] E310 filter configuration
>
>
>
> Hi Yake,
>
> I think that perhaps you do not understand how the USRP provides baseband
> complex samples (not real, IF samples). If you want to measure a signal at
> 2.03 GHz with a bandwidth of 2.5 MHz, you can simply set the RF center
> frequency to 2.03 GHz and the sample rate to about 3 MS/s. With complex
> samples, the bandwidth is essentially the sample rate.
>
> Rob
>
>
>
> On Tue, May 9, 2017 at 12:51 PM, Yake Li <liyak...@gmail.com
> <mailto:liyak...@gmail.com>> wrote:
>
> Please see attached the results. I sent two identical pulses (1 us width in
> time and roughly 2.5 MHz bandwidth in freq domain) which have 2.03 GHz center
> frequency. The sampling rate is 6 MS/s. Fig1 is the result when I tuned the
> Rx LO to 2.028 GHz (I notice the filter before ADC passes signal above 1 MHz,
> so I set IF to be 2 MHz). Fig2 is the result if I tune the Rx LO to be 2.0
> GHZ (30MHz IF). I did not use set_bandwidth() command in both cases. In my
> understanding, if the 30 MHz IF signal passed the filter before ADC, I should
> be able to sample it using 6 MHz because the bandwidth is only 2.5MHz. But as
> shown by the figure, the amplitude is suppressed, unbalanced and artificial
> is presented. I guess the problem could be the filters.
>
>
>
> From: Rob Kossler [mailto:rkoss...@nd.edu <mailto:rkoss...@nd.edu>]
> Sent: May 9, 2017 1:23 PM
> To: Marcus D. Leech <mle...@ripnet.com <mailto:mle...@ripnet.com>>
> Cc: Yake Li <liyak...@gmail.com <mailto:liyak...@gmail.com>>;
> usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>
> Subject: Re: [USRP-users] E310 filter configuration
>
>
>
> Typo in my message. I meant to say set the sample rate to 6e6 as you
> indicated originally...
>
>
>
>
>
> On Tue, May 9, 2017 at 11:14 AM, Rob Kossler <rkoss...@nd.edu
> <mailto:rkoss...@nd.edu>> wrote:
>
> Ignoring the set_bandwidth() command, if you set the center freq to 2e9 and
> the sample rate to 3e6, your results will show signals in the range
> 1.997-2.003 GHz. This does not include your desired signal at 2.03 GHz,
> which is 30 MHz away from 2 GHz.
>
>
>
> Rob
>
>
>
>
>
> On Tue, May 9, 2017 at 11:05 AM, Marcus D. Leech via USRP-users
> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote:
>
> The "set_bandwidth" method sets the analog bandwidth in front of the ADC.
>
> The RF filters are selected automatically based on your desired tuning
> frequency.
>
> It would help us if you describe how the result is "incorrect" -- perhaps an
> FFT plot?
>
>
>
>
>
>
>
> On 2017-05-09 10:50, Yake Li via USRP-users wrote:
>
> Hello,
>
>
>
> My question is could I set the filters separately in Ettus E310? I noticed
> there are different filters in E310. First, there are filter banks right
> after the receiving antenna. Second, the AD9361 has Rx low pass filters
> before ADC (please refer to ?Rx SIGNAL PATH? of
> http://www.farnell.com/datasheets/2007082.pdf
> <http://www.farnell.com/datasheets/2007082.pdf>). I noticed there is only one
> command ?set_bandwidth? in gnuradio (or ?set_rx_bandwidth? in UHD) to set the
> RF bandwidth of front end. What is the response of each filters mentioned
> above after using this command? Could I set separately the response of
> different filters?
>
>
>
> I am asking because I want to, for example, sample a signal centered at 2.03
> GHz with 3M Hz bandwidth. I tune the LO of Rx to 2 GHz, and I want to sample
> this signal with 6 MHz sampling rate. What I did is that I use
> ?set_center_freq (2e9,0)?, ?set_bandwidth (3e6,0)? and ?set_samp_rate
> (6e6,0)?. The result seems to be incorrect. I tried different bandwidth, and
> under no settings I got the right result. Is there something wrong with my
> settings?
>
>
>
> Thanks!
>
>
>
> Yake
>
>
>
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>
> Virus-free. www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> 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/20170511/f20db947/attachment-0001.html>
------------------------------
Message: 6
Date: Fri, 12 May 2017 13:33:05 +0200
From: Felipe Augusto Pereira de Figueiredo <zz4...@gmail.com>
To: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] uhd_rx_streamer_recv function keeps returning 0
as the number of received samples
Message-ID:
<ca+abmwksagd+cumdvhroi5kutet9jbczeznpcnlick0z0ra...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear GNU Radio group,
I'm playing around with UHD and I've got a problem you might be able to
help me with. It basically reads samples from UHD. Below, for the sake of
clarity and conciseness, you will find a pseud-code of what I have running
right now.
//----------------------------------------------------------------------------------------------------
do_initial_configuration() // master clock, sampling rate, RX frequency,
open radio, etc.
while(1) {
// stream mode is set to: UHD_STREAM_MODE_START_CONTINUOUS
// stream now set to true
open_rx_stream()
// read sample from UHD
uhd_error error = uhd_rx_streamer_recv(rx_stream, buffs_ptr,
rx_samples, md, 5, false, &rxd_samples);
// Process samples.
do_some_processing()
// stream mode is set to: UHD_STREAM_MODE_START_CONTINUOUS
// stream now set to true
close_rx_stream()
}
// Free memory, etc.
release_resources();
//----------------------------------------------------------------------------------------------------
What happens is that after some time (it is random, it can happen after
minutes or after seconds) the function "uhd_rx_streamer_recv" starts
returning 0 as the number of received (read) samples, i.e., the variable
"rxd_samples" returns 0. After the function starts returning 0 as the
number of read samples it never returns to the normal operation, i.e., read
a number of samples different from 0. With an x310 it keeps in that state
indefinitely and to get my program running back again I need to power
off/on the x310, however, with a b200 (USB) after a little while I've got
that error message: "recv packet demuxer unexpected sid ".
My question is, could this problem be related to the open/close of the rx
stream inside the infinite loop? If not, what could be the problem?
Thanks and Kind Regards,
Felipe Augusto
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170512/712cd509/attachment-0001.html>
------------------------------
Message: 7
Date: Fri, 12 May 2017 09:35:04 -0230
From: Yake Li <liyak...@gmail.com>
To: Ian Buckley <i...@ianbuckley.net>
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] E310 filter configuration
Message-ID:
<cadxwyqcs_in0hqigo9af8kc4c_yaket_5j6ih-nn+xqofs4...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Ian,
Thanks for your help! I think the one Rx channel is the only possible
solution. I can accept several dB loss of the signal and some distortion.
Where is the 56 MHz analog RX filter? Is it the one in AD9361 before ADC or
a filter outside? How can I set the 56 MHz RX filters you mentioned and to
configuration the DDC in FPGA. With gnuradio, it seems I have very limited
access to the basic level of E310.
Regards,
Yake
2017-05-11 15:18 GMT-02:30 Ian Buckley <i...@ianbuckley.net>:
> Yake,
> In principle your approach is a good one, however there are some H/W
> constraints of the E310 that will prevent you from using the frequencies
> and bandwidths you describe.
>
> The radio it?s self has baseband analog RX filters that can not be opened
> wider than 56MHz (at 3dB loss).
> Whilst the max sample rate supported is 61.44MHz, that is only in a SISO
> configuration. In a MIMO configuration such as you describe the sample rate
> is limited to 30.72MHz (due to the FPGA/PCB design).
> Since you need 60 + 2/2 + 2/2 = 62MHz bandwidth as currently described you
> are going to have to move those 2 carriers closer together (30.72 -(2/2)
> -(2/2) = 28.72MHz max carrier separation).
>
> An alternate approach *might* be to use RFNoC to place two DDC?s on one
> radio channel, but I?m years out of date with progress on that so I don?t
> know if that is a supported configuration.
> That would give you 61.44 - (2/2) - (2/2)= 59.44 max carrier separation,
> so you would be limited by the 56MHz analog baseband filter constraint in
> that configuration.
>
> Regards
> -Ian
>
>
> On May 11, 2017, at 5:25 AM, Yake Li via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> I had an Ettus E310 sampling problem. After some talk with Rob, I know
> what direction I should try but I am still a little bit confused. Please
> see below our discussion and thanks for Rob's help.
>
> My question is as follows: I can only do 6 MS/s sampling for a short while
> because E310 tells me overflow after 40 seconds of data transmission using
> GigE (USRP to UDP). But I can live with it for proof of concept. I have two
> pulses (1 us length which roughly equals to a bandwidth of 2 MHz) with
> different carriers (one is 2030 MHz and the other is 1970 MHz) that I want
> to capture and measure the leading edge (phase is not important). As the
> two Rx channels of E310 share one Rx LO, I cannot do baseband sampling for
> both. So I want to configure the Rx channels to 2000 MHz so that I get 30
> MHz IF, and then do passband smapling for both using 6 MS/s. But the test
> results show that the passband sampling is not working. I still see the
> pulses, but the amplitude is significantly attenuated and huge artificials
> appear. I guess the filters in E310 is not correctly configured. Can
> anybody help me for the filter configuration?
>
> I prefer gnuradio python solution but UHD is also ok if it solves the
> problem.
>
> Regards,
>
> Yake
>
>
> ---------- Forwarded message ----------
> From: Rob Kossler <rkoss...@nd.edu>
> Date: 2017-05-10 23:36 GMT-02:30
> Subject: Re: [USRP-users] E310 filter configuration
> To: Yake Li <liyak...@gmail.com>
>
>
> Yake,
> If you contact the list again, explain that you are trying to receive 2
> signals, one at 1.97 and one at 2.03 GHz, each with 3 MHz bandwidth using
> an E310. With this information, I think that someone can help explain how
> to do it. Also, explain if you are using UHD directly from C++ or if you
> are using gnuradio.
> Rob
>
> On Wed, May 10, 2017 at 9:24 PM, Rob Kossler <rkoss...@nd.edu> wrote:
>
>> Yake,
>> It is possible with the USRP to have the analog LO at one frequency and
>> then a digital LO at another frequency. Perhaps my explanation is not
>> great, but the point is that you can have the FPGA center its decimation
>> filter at a different location than the analog LO. In the Ettus UHD
>> manual, the "set_rx_freq" function has an argument that is a "tune_request"
>> and this can have both a "rf_freq" and a "dsp_freq". Actually the rf_freq
>> should be set to the freq that you want (in your case 2.03 GHz) and the
>> dsp_freq should be set to 30 MHz. This will automatically cause the analog
>> LO to be at 2.0 GHz.For your other signal, you can set rf_freq=1.97 GHz and
>> dsp_freq=-30MHz. Then, you should get both of the signals you wanted and
>> they will be at baseband.
>>
>> The only trouble that I see with this is that perhaps there is an analog
>> anti-aliasing filter of around 56 MHz. But, maybe this would be OK as the
>> filter roll-off might be slow enough. The other trouble I see is that
>> perhaps you will need to run the master clock at 61.44 MHz or something
>> like that in order that you have this kind of bandwidth for both of your
>> signals. I really don't know if that is possible with 2 channel. But, my
>> suggestion is to play around with this and if you still have trouble, maybe
>> contact the list again. If you have trouble, maybe try a test case with
>> signals at 1.99 and 2.01 GHz and try this method to receive both signals.
>> This should be easily possible.
>>
>> Let me know how it goes.
>> Rob
>>
>> On Wed, May 10, 2017 at 3:04 PM, Yake Li <liyak...@gmail.com> wrote:
>>
>>> Rob,
>>>
>>> Now I understand. Yes, I am trying to use the aliased version near DC to
>>> reconstruct the pusles. So the master clock rate is for ADC and FPGA, and
>>> the sampling rate is the decmiated rate. In my original setting, I use 48
>>> MHz as my masker clock rate and this will sample the 30 MHz without
>>> aliasing. Then the FPGA applies a low pass filter before decimating the
>>> sampling rate to 6 MHz, so the IF is attenuated in this process.
>>>
>>> The reason I was trying to do bandpass sampling is because we have
>>> another signal comes at 1970 MHz. As the two Rx of E310 share the same LO,
>>> we cannot sample the two signals both at the baseband. That is how the
>>> passband IF requirement comes up.
>>>
>>> I did another test, though. I set the master clock to be 10 MHz (I guess
>>> both ADC and FPGA work at this 10 MHz?) and sampling rate to be 5 MHz
>>> (still using 30 MHz IF). In this configuration, I will actually sample the
>>> aliased spectrum at DC. However, the same problem happens. I guess
>>> somewhere else in E310 is still preventing the 30 MHz IF signal to go
>>> through. Maybe the AD9361 is not capable of doing passband sampling.
>>>
>>> Is there any possible way in E310 that could allow me to do the bandpass
>>> sampling?
>>>
>>> Regards,
>>>
>>> Yake
>>>
>>> 2017-05-10 12:08 GMT-02:30 Rob Kossler <rkoss...@nd.edu>:
>>>
>>>> Yake,
>>>> So, you are trying to "undersample" the 30 MHz IF signal with the
>>>> knowledge that the aliased version near DC will suffice? If so, this is
>>>> not a method that can work with the USRP. At least not with the existing
>>>> FPGA code. The USRP does not actually sample at the rate you specify in
>>>> the sample rate. The USRP A/D typically operates at a higher rate and then
>>>> the FPGA implements digital filtering and downconversion to provide the
>>>> samples at the specified sample rate.
>>>>
>>>> So, in your case, I think that the analog filtering is not even
>>>> relevant. This filtering is intended to reject large out-of-band signals
>>>> that can cause problems at the RF front end. This filtering will not
>>>> impact any signal that is only 30 MHz from the LO. The problem for you is
>>>> the digital filtering & downconversion DSP that is implemented in the
>>>> FPGA. This is the filtering that is rejecting your 30 MHz signal. But, I'm
>>>> not as familiar with the E310 as I am with the X310 so it is possible that
>>>> the "master clock rate" is also relevant.
>>>>
>>>> In any event, can you explain why you need to have the LO at 2 GHz for
>>>> your application. Why not have the LO at 2.03 GHz?
>>>> Rob
>>>>
>>>> On Wed, May 10, 2017 at 8:50 AM, Yake Li <liyak...@gmail.com> wrote:
>>>>
>>>>> Hi Rob,
>>>>>
>>>>>
>>>>>
>>>>> Thanks for your reply.
>>>>>
>>>>>
>>>>>
>>>>> I think I did not explain my problem well. Our application needs us to
>>>>> use 2GHz to demodulate the 2.03 GHz pulses, which means we have to deal
>>>>> with the 30 MHz IF signal. However, we do not need the phase information
>>>>> of
>>>>> the IF signal. We only care about the leading edge of the pulse, that is
>>>>> why we are only interested in the 2.5 MHz bandwidth but not the 30 MHz
>>>>> center frequency. If we use 6 MHz to sample the 2.5 MHz bandwidth IF
>>>>> signal
>>>>> centered at 30 MHz, we are actually sampling the spectrum copy of the IF
>>>>> signal that is centered at zero frequency. The result should approximately
>>>>> be rectangular pulses in time domain.
>>>>>
>>>>>
>>>>>
>>>>> Therefore, theoretically, if the 30 MHz IF signal can pass the filters
>>>>> before ADC without distortion and attenuation, we should be able get the
>>>>> same result as shown in fig1 of my last email. But now it is not the case
>>>>> (we actually got fig2).
>>>>>
>>>>>
>>>>>
>>>>> I do not know if my theory was wrong or my settings of E310 were
>>>>> wrong.
>>>>>
>>>>>
>>>>>
>>>>> Yake
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *From:* Rob Kossler [mailto:rkoss...@nd.edu]
>>>>> *Sent:* May 9, 2017 3:09 PM
>>>>> *To:* Yake Li <liyak...@gmail.com>
>>>>>
>>>>> *Subject:* Re: [USRP-users] E310 filter configuration
>>>>>
>>>>>
>>>>>
>>>>> Hi Yake,
>>>>>
>>>>> I think that perhaps you do not understand how the USRP provides
>>>>> baseband complex samples (not real, IF samples). If you want to measure a
>>>>> signal at 2.03 GHz with a bandwidth of 2.5 MHz, you can simply set the RF
>>>>> center frequency to 2.03 GHz and the sample rate to about 3 MS/s. With
>>>>> complex samples, the bandwidth is essentially the sample rate.
>>>>>
>>>>> Rob
>>>>>
>>>>>
>>>>>
>>>>> On Tue, May 9, 2017 at 12:51 PM, Yake Li <liyak...@gmail.com> wrote:
>>>>>
>>>>> Please see attached the results. I sent two identical pulses (1 us
>>>>> width in time and roughly 2.5 MHz bandwidth in freq domain) which have
>>>>> 2.03
>>>>> GHz center frequency. The sampling rate is 6 MS/s. Fig1 is the result when
>>>>> I tuned the Rx LO to 2.028 GHz (I notice the filter before ADC passes
>>>>> signal above 1 MHz, so I set IF to be 2 MHz). Fig2 is the result if I
>>>>> tune
>>>>> the Rx LO to be 2.0 GHZ (30MHz IF). I did not use set_bandwidth() command
>>>>> in both cases. In my understanding, if the 30 MHz IF signal passed the
>>>>> filter before ADC, I should be able to sample it using 6 MHz because the
>>>>> bandwidth is only 2.5MHz. But as shown by the figure, the amplitude is
>>>>> suppressed, unbalanced and artificial is presented. I guess the problem
>>>>> could be the filters.
>>>>>
>>>>>
>>>>>
>>>>> *From:* Rob Kossler [mailto:rkoss...@nd.edu]
>>>>> *Sent:* May 9, 2017 1:23 PM
>>>>> *To:* Marcus D. Leech <mle...@ripnet.com>
>>>>> *Cc:* Yake Li <liyak...@gmail.com>; usrp-users@lists.ettus.com
>>>>> *Subject:* Re: [USRP-users] E310 filter configuration
>>>>>
>>>>>
>>>>>
>>>>> Typo in my message. I meant to say set the sample rate to 6e6 as you
>>>>> indicated originally...
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, May 9, 2017 at 11:14 AM, Rob Kossler <rkoss...@nd.edu> wrote:
>>>>>
>>>>> Ignoring the set_bandwidth() command, if you set the center freq to
>>>>> 2e9 and the sample rate to 3e6, your results will show signals in the
>>>>> range
>>>>> 1.997-2.003 GHz. This does not include your desired signal at 2.03 GHz,
>>>>> which is 30 MHz away from 2 GHz.
>>>>>
>>>>>
>>>>>
>>>>> Rob
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, May 9, 2017 at 11:05 AM, Marcus D. Leech via USRP-users <
>>>>> usrp-users@lists.ettus.com> wrote:
>>>>>
>>>>> The "set_bandwidth" method sets the analog bandwidth in front of the
>>>>> ADC.
>>>>>
>>>>> The RF filters are selected automatically based on your desired tuning
>>>>> frequency.
>>>>>
>>>>> It would help us if you describe how the result is "incorrect" --
>>>>> perhaps an FFT plot?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 2017-05-09 10:50, Yake Li via USRP-users wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>>
>>>>>
>>>>> My question is could I set the filters separately in Ettus E310? I
>>>>> noticed there are different filters in E310. First, there are filter banks
>>>>> right after the receiving antenna. Second, the AD9361 has Rx low pass
>>>>> filters before ADC (please refer to ?*Rx SIGNAL PATH*? of
>>>>> http://www.farnell.com/datasheets/2007082.pdf). I noticed there is
>>>>> only one command ?set_bandwidth? in gnuradio (or ?set_rx_bandwidth? in
>>>>> UHD)
>>>>> to set the RF bandwidth of front end. What is the response of each filters
>>>>> mentioned above after using this command? Could I set separately the
>>>>> response of different filters?
>>>>>
>>>>>
>>>>>
>>>>> I am asking because I want to, for example, sample a signal centered
>>>>> at 2.03 GHz with 3M Hz bandwidth. I tune the LO of Rx to 2 GHz, and I want
>>>>> to sample this signal with 6 MHz sampling rate. What I did is that I use
>>>>> ?set_center_freq (2e9,0)?, ?set_bandwidth (3e6,0)? and ?set_samp_rate
>>>>> (6e6,0)?. The result seems to be incorrect. I tried different bandwidth,
>>>>> and under no settings I got the right result. Is there something wrong
>>>>> with
>>>>> my settings?
>>>>>
>>>>>
>>>>>
>>>>> Thanks!
>>>>>
>>>>>
>>>>>
>>>>> Yake
>>>>>
>>>>>
>>>>>
>>>>> [image:
>>>>> https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]
>>>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>>>>>
>>>>> Virus-free. www.avast.com
>>>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> USRP-users mailing list
>>>>> USRP-users@lists.ettus.com
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> USRP-users mailing list
>>>>> USRP-users@lists.ettus.com
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> 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/20170512/4751800b/attachment-0001.html>
------------------------------
Message: 8
Date: Fri, 12 May 2017 09:42:28 -0400
From: EJ Kreinar <ejkrei...@gmail.com>
To: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Rfnoc UHD processor load on E310 increased
with recent update
Message-ID:
<CADRnH23h4wro8YFbagG8bOmhh=igd-ul0m1f_8r9kg9d_a3...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi again,
I have a follow-up test to evaluate if the processing overhead is due to PS
-> PL communication in the new UHD. It looks like this PS -> PL
communication is getting bogged down somewhere in the recent UHD release.
In my rfnoc image, I now have the following blocks on the device:
| | | RFNoC blocks on this device:
| | |
| | | * Radio_0
| | | * FIFO_0
| | | * SplitStream_0
| | | * SigGen_0
| | | * DUC_0
My test is to simply run UHD's uhd_siggen application from the command
line. Here's the explicit command I used:
uhd_siggen --args "fpga=/images/2017-05-11-siggen.bit" -s 200000 -g 60 -f
1000000000 --sine
And the results:
1. UHD as of 2/7/2017, SHA 2cf80a6:
a. 3%-5% processing load on each core
2. UHD as of 4/15/2017, SHA 24b9857 (plus a minor patch to fix an
initialization problem-- shouldnt impact the performance test)
a. 95% - 100% processor load on each core, plus underflows.
Here's the full log with the updated UHD:
/test# uhd_siggen --args "fpga=/images/2017-05-11-siggen.bit" -s 200000 -g
60 -f 1000000000 --sine
[INFO] [UHD] linux; GNU C++ version 4.9.2; Boost_105700;
UHD_4.0.0.update-uhd-109-g5107d983
[DEBUG] [NIRIO] rpc_client connection request cancelled/aborted.
[DEBUG] [E300] e300_make with args Device Address:
type: e3x0
node: /dev/axi_fpga
name:
serial: 30CD167
product: 30675
fpga: /images/2017-05-11-siggen.bit
[INFO] [E300] Loading FPGA image: /images/2017-05-11-siggen.bit...
[INFO] [E300] FPGA image loaded
[INFO] [E300] Detecting internal GPSDO
.... [INFO] [E300] GPSDO found
[INFO] [E300] Initializing core control (global registers)...
[INFO] [E300] Performing register loopback test...
[INFO] [E300] Register loopback test passed
[DEBUG] [E300] Initializing AD9361 using hard SPI core...
[DEBUG] [E300] OK
[DEBUG] [E300] [E300] Setting up dest map for host ep 0 to be stream 0
[DEBUG] [E300] [E300] Setting up dest map for host ep 1 to be stream 1
[INFO] [RFNOC RADIO] Register loopback test passed
[INFO] [RFNOC RADIO] Register loopback test passed
[DEBUG] [E300] Setting time source to internal
[DEBUG] [E300] [E300] Setting up dest map for host ep 2 to be stream 2
[DEBUG] [E300] [E300] Setting up dest map for host ep 3 to be stream 3
[DEBUG] [E300] [E300] Setting up dest map for host ep 4 to be stream 4
[WARNING] [RFNOC] [0/SplitStream_0] defines 2 input buffer sizes, but 1
input ports
[DEBUG] [E300] [E300] Setting up dest map for host ep 5 to be stream 5
[DEBUG] [E300] [E300] Setting up dest map for host ep 6 to be stream 6
[DEBUG] [E300] Initializing Radio Block...
[INFO] [AD936X] Performing CODEC loopback test...
[INFO] [AD936X] CODEC loopback test passed
[INFO] [AD936X] Performing CODEC loopback test...
[INFO] [AD936X] CODEC loopback test passed
[DEBUG] [E300] Asking for clock rate 16 MHz
[DEBUG] [E300] Actually got clock rate 16 MHz
[INFO] [CORES] Performing timer loopback test...
[INFO] [CORES] Timer loopback test passed
[DEBUG] [E300] end of e300_impl()
[WARNING] [RFNOC] [legacy_compat] No DDCs detected. You will only be able
to receive at the radio frontend rate.
[WARNING] [RFNOC] [legacy_compat] No DMA FIFO detected. You will only be
able to transmit at slow rates.
[DEBUG] [E300] Asking for clock rate 16 MHz
[DEBUG] [E300] Actually got clock rate 16 MHz
[INFO] [CORES] Performing timer loopback test...
[INFO] [CORES] Timer loopback test passed
[DEBUG] [UHD] gain_left_to_distribute 0
[DEBUG] [UHD] 0: 60
[UHD-SIGGEN] UHD Signal Generator
[UHD-SIGGEN] UHD Version: 4.0.0.update-uhd-109-g5107d983
[UHD-SIGGEN] Using USRP configuration:
[UHD-SIGGEN] Motherboard: E3XX (30CD167)
[UHD-SIGGEN] Daughterboard: FE-TX2, 30CBB66
[UHD-SIGGEN] Subdev: A:A A:B
[UHD-SIGGEN] Antenna: TX/RX
[DEBUG] [UHD] gain_left_to_distribute 0
[DEBUG] [UHD] 0: 60
[DEBUG] [E300] [E300] Setting up dest map for host ep 7 to be stream 7
[DEBUG] [CONVERT] get_converter: For converter ID: conversion ID
Input format: fc32
Num inputs: 1
Output format: sc16_item32_le
Num outputs: 1
Using prio: 2
[UHD-SIGGEN] Press Enter to quit:
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
UUUUUUUUUUUUUUUUUUUUUUUS[INFO] [E300] Loading FPGA image:
/images/usrp_e3xx_fpga_idle_sg3.bit...
[INFO] [E300] FPGA image loaded
[ERROR] [UHD] Exception caught in safe-call.
in virtual ctrl_iface_impl::~ctrl_iface_impl()
at /gnuradio_target/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
this->peek32(0); -> AssertionError: (sts >> 7) & 0x1
in typename T::sptr e300_transport::get_buff(double) [with T =
uhd::transport::managed_send_buffer; typename T::sptr =
boost::intrusive_ptr<uhd::transport::managed_send_buffer>]
at /gnuradio_target/src/uhd/host/lib/usrp/e300/e300_fifo_config.cpp:250
[ERROR] [UHD] Exception caught in safe-call.
in virtual ctrl_iface_impl::~ctrl_iface_impl()
at /gnuradio_target/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
this->peek32(0); -> AssertionError: (sts >> 7) & 0x1
in typename T::sptr e300_transport::get_buff(double) [with T =
uhd::transport::managed_send_buffer; typename T::sptr =
boost::intrusive_ptr<uhd::transport::managed_send_buffer>]
at /gnuradio_target/src/uhd/host/lib/usrp/e300/e300_fifo_config.cpp:250
[ERROR] [UHD] Exception caught in safe-call.
in virtual ctrl_iface_impl::~ctrl_iface_impl()
at /gnuradio_target/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
this->peek32(0); -> AssertionError: (sts >> 7) & 0x1
in typename T::sptr e300_transport::get_buff(double) [with T =
uhd::transport::managed_send_buffer; typename T::sptr =
boost::intrusive_ptr<uhd::transport::managed_send_buffer>]
at /gnuradio_target/src/uhd/host/lib/usrp/e300/e300_fifo_config.cpp:250
[ERROR] [UHD] Exception caught in safe-call.
in virtual ctrl_iface_impl::~ctrl_iface_impl()
at /gnuradio_target/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
this->peek32(0); -> AssertionError: (sts >> 7) & 0x1
in typename T::sptr e300_transport::get_buff(double) [with T =
uhd::transport::managed_send_buffer; typename T::sptr =
boost::intrusive_ptr<uhd::transport::managed_send_buffer>]
at /gnuradio_target/src/uhd/host/lib/usrp/e300/e300_fifo_config.cpp:250
[ERROR] [UHD] Exception caught in safe-call.
in virtual ctrl_iface_impl::~ctrl_iface_impl()
at /gnuradio_target/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
this->peek32(0); -> AssertionError: (sts >> 7) & 0x1
in typename T::sptr e300_transport::get_buff(double) [with T =
uhd::transport::managed_send_buffer; typename T::sptr =
boost::intrusive_ptr<uhd::transport::managed_send_buffer>]
at /gnuradio_target/src/uhd/host/lib/usrp/e300/e300_fifo_config.cpp:250
/test#
Thanks again for any feedback,
EJ
On Thu, May 11, 2017 at 12:37 PM, EJ Kreinar <ejkrei...@gmail.com> wrote:
> Hi All,
>
> I want to bring up a potential UHD regression on the E310 and see if
> anyone has seen the same behavior or knows of a solution.
>
> I recently upgraded uhd/rfnoc-devel to the current head. I found that some
> of my test cases took extra processing load than I remembered before, so I
> put together a regression test to figure out if this is really an issue.
>
> The idea is to run an "FPGA loopback" mode, which is doing nothing except
> pushing data from the PS to the PL and back. I added a throttle which lets
> me run at a specific sample rate (I used 500 kHz) so I can observe the
> processor load. I ran "htop" on the E310 and recorded the processing load
> on each core during the test.
>
> I tested two flowgraphs to evaluate the performance with and without
> rfnoc.
> a. Non-RFNoC flowgraph: File Source -> Throttle -> File Sink
> b. RFNoC flowgraph: File Source -> Throttle -> RFNoC FIFO -> RFNoC FIFO
> -> File Sink
>
> Here's my test results:
>
> 1. UHD as of 2/7/2017, SHA 2cf80a6
> a. Non-rfnoc flowgraph: 4% - 8% processing load on each core
> b. RFNoC flowgraph: 12% - 14% processing load on each core
>
> 2. UHD as of 4/15/2017, SHA 24b9857 (plus a minor patch to fix an
> initialization problem-- shouldnt impact the performance test)
> a. Non-rfnoc flowgraph: 4% - 7% processing load on each core
> b. RFNoC flowgraph: One core is pegged at 100% for the duration of the
> test. The other core is around 25%-30%
>
> I was hopeful the extra processing was my imagination, but I've found the
> result is repeatable for this unit test and for other flowgraphs where I'm
> crossing PS/PL domain this way. I havent dug TOO far into it, but I've
> tested RFNoC Radio -> PS on the updated UHD without seeing the dramatic
> processing increase-- so I suspect it may have something to do with the PS
> -> PL interface.
>
> Any thoughts??
>
> Thanks!
> EJ
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170512/53e095f6/attachment-0001.html>
------------------------------
Message: 9
Date: Fri, 12 May 2017 10:08:15 -0400
From: Rob Kossler <rkoss...@nd.edu>
To: Yake Li <liyak...@gmail.com>
Cc: Ian Buckley <i...@ianbuckley.net>, "usrp-users@lists.ettus.com"
<usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] E310 filter configuration
Message-ID:
<cab__htrqnczf0elpb1tuebw6t-s6uegxaczywe713pkv4gr...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Yake,
Ian mentioned the possibility of using RFNoC to provide two DDC channels
for your single RF input. I have not tried something like this so I don't
know the details, but it seems reasonable. However, if you get this working
with RFNoC, you still have an issue with selecting the clock rate.
I "think" that the selection of the clock rate affects the bandwidth of the
anti-aliasing filter. If you choose 61.44 MHz, I believe this will cause
the device to automatically use the 56 MHz filter. But, if you choose a
lower rate, I think that the bandwidth will be reduced accordingly. For
example, if you choose 55 MHz as the clock rate, perhaps the anti-aliasing
filter will only be 50 MHz.
This is a problem for you because you cannot use 61.44 MHz as the clock
rate. Such a rate will cause your two signals (which are separated by
exactly 60 MHz) to fold on top of one another. You will need to select a
lower rate that "undersamples" and causes your higher frequency signal to
fold into the lower frequency spectrum and vice versa for the lower
frequency signal. So, if you choose a clock rate of 55 MHz, your +30 MHz
IF folds to -25MHz and your -30MHz folds to +25 MHz. If your signals are
truly pulses with sin x/x spectra, this may not even provide enough
separation between your true signal at +30 and your folded signal at +25.
And, with your clock rate at 55 Mhz, your anti-aliasing filter is probably
at 50 MHz thus attenuating your signals further.
If you have no option to change the frequencies of your signals and if you
have no option to change from using the E310 (to a different USRP with
wider instantaneous bandwidth), perhaps it is worth attempting this
approach. But, I'm not sure how hard it is to create an RFNoC-based
solution for your particular needs.
Rob
On Fri, May 12, 2017 at 8:05 AM, Yake Li via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi Ian,
>
> Thanks for your help! I think the one Rx channel is the only possible
> solution. I can accept several dB loss of the signal and some distortion.
> Where is the 56 MHz analog RX filter? Is it the one in AD9361 before ADC or
> a filter outside? How can I set the 56 MHz RX filters you mentioned and to
> configuration the DDC in FPGA. With gnuradio, it seems I have very limited
> access to the basic level of E310.
>
> Regards,
>
> Yake
>
> 2017-05-11 15:18 GMT-02:30 Ian Buckley <i...@ianbuckley.net>:
>
>> Yake,
>> In principle your approach is a good one, however there are some H/W
>> constraints of the E310 that will prevent you from using the frequencies
>> and bandwidths you describe.
>>
>> The radio it?s self has baseband analog RX filters that can not be opened
>> wider than 56MHz (at 3dB loss).
>> Whilst the max sample rate supported is 61.44MHz, that is only in a SISO
>> configuration. In a MIMO configuration such as you describe the sample rate
>> is limited to 30.72MHz (due to the FPGA/PCB design).
>> Since you need 60 + 2/2 + 2/2 = 62MHz bandwidth as currently described
>> you are going to have to move those 2 carriers closer together (30.72
>> -(2/2) -(2/2) = 28.72MHz max carrier separation).
>>
>> An alternate approach *might* be to use RFNoC to place two DDC?s on one
>> radio channel, but I?m years out of date with progress on that so I don?t
>> know if that is a supported configuration.
>> That would give you 61.44 - (2/2) - (2/2)= 59.44 max carrier separation,
>> so you would be limited by the 56MHz analog baseband filter constraint in
>> that configuration.
>>
>> Regards
>> -Ian
>>
>>
>> On May 11, 2017, at 5:25 AM, Yake Li via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>> I had an Ettus E310 sampling problem. After some talk with Rob, I know
>> what direction I should try but I am still a little bit confused. Please
>> see below our discussion and thanks for Rob's help.
>>
>> My question is as follows: I can only do 6 MS/s sampling for a short
>> while because E310 tells me overflow after 40 seconds of data transmission
>> using GigE (USRP to UDP). But I can live with it for proof of concept. I
>> have two pulses (1 us length which roughly equals to a bandwidth of 2 MHz)
>> with different carriers (one is 2030 MHz and the other is 1970 MHz) that I
>> want to capture and measure the leading edge (phase is not important). As
>> the two Rx channels of E310 share one Rx LO, I cannot do baseband sampling
>> for both. So I want to configure the Rx channels to 2000 MHz so that I get
>> 30 MHz IF, and then do passband smapling for both using 6 MS/s. But the
>> test results show that the passband sampling is not working. I still see
>> the pulses, but the amplitude is significantly attenuated and huge
>> artificials appear. I guess the filters in E310 is not correctly
>> configured. Can anybody help me for the filter configuration?
>>
>> I prefer gnuradio python solution but UHD is also ok if it solves the
>> problem.
>>
>> Regards,
>>
>> Yake
>>
>>
>> ---------- Forwarded message ----------
>> From: Rob Kossler <rkoss...@nd.edu>
>> Date: 2017-05-10 23:36 GMT-02:30
>> Subject: Re: [USRP-users] E310 filter configuration
>> To: Yake Li <liyak...@gmail.com>
>>
>>
>> Yake,
>> If you contact the list again, explain that you are trying to receive 2
>> signals, one at 1.97 and one at 2.03 GHz, each with 3 MHz bandwidth using
>> an E310. With this information, I think that someone can help explain how
>> to do it. Also, explain if you are using UHD directly from C++ or if you
>> are using gnuradio.
>> Rob
>>
>> On Wed, May 10, 2017 at 9:24 PM, Rob Kossler <rkoss...@nd.edu> wrote:
>>
>>> Yake,
>>> It is possible with the USRP to have the analog LO at one frequency and
>>> then a digital LO at another frequency. Perhaps my explanation is not
>>> great, but the point is that you can have the FPGA center its decimation
>>> filter at a different location than the analog LO. In the Ettus UHD
>>> manual, the "set_rx_freq" function has an argument that is a "tune_request"
>>> and this can have both a "rf_freq" and a "dsp_freq". Actually the rf_freq
>>> should be set to the freq that you want (in your case 2.03 GHz) and the
>>> dsp_freq should be set to 30 MHz. This will automatically cause the analog
>>> LO to be at 2.0 GHz.For your other signal, you can set rf_freq=1.97 GHz and
>>> dsp_freq=-30MHz. Then, you should get both of the signals you wanted and
>>> they will be at baseband.
>>>
>>> The only trouble that I see with this is that perhaps there is an analog
>>> anti-aliasing filter of around 56 MHz. But, maybe this would be OK as the
>>> filter roll-off might be slow enough. The other trouble I see is that
>>> perhaps you will need to run the master clock at 61.44 MHz or something
>>> like that in order that you have this kind of bandwidth for both of your
>>> signals. I really don't know if that is possible with 2 channel. But, my
>>> suggestion is to play around with this and if you still have trouble, maybe
>>> contact the list again. If you have trouble, maybe try a test case with
>>> signals at 1.99 and 2.01 GHz and try this method to receive both signals.
>>> This should be easily possible.
>>>
>>> Let me know how it goes.
>>> Rob
>>>
>>> On Wed, May 10, 2017 at 3:04 PM, Yake Li <liyak...@gmail.com> wrote:
>>>
>>>> Rob,
>>>>
>>>> Now I understand. Yes, I am trying to use the aliased version near DC
>>>> to reconstruct the pusles. So the master clock rate is for ADC and FPGA,
>>>> and the sampling rate is the decmiated rate. In my original setting, I use
>>>> 48 MHz as my masker clock rate and this will sample the 30 MHz without
>>>> aliasing. Then the FPGA applies a low pass filter before decimating the
>>>> sampling rate to 6 MHz, so the IF is attenuated in this process.
>>>>
>>>> The reason I was trying to do bandpass sampling is because we have
>>>> another signal comes at 1970 MHz. As the two Rx of E310 share the same LO,
>>>> we cannot sample the two signals both at the baseband. That is how the
>>>> passband IF requirement comes up.
>>>>
>>>> I did another test, though. I set the master clock to be 10 MHz (I
>>>> guess both ADC and FPGA work at this 10 MHz?) and sampling rate to be 5 MHz
>>>> (still using 30 MHz IF). In this configuration, I will actually sample the
>>>> aliased spectrum at DC. However, the same problem happens. I guess
>>>> somewhere else in E310 is still preventing the 30 MHz IF signal to go
>>>> through. Maybe the AD9361 is not capable of doing passband sampling.
>>>>
>>>> Is there any possible way in E310 that could allow me to do the
>>>> bandpass sampling?
>>>>
>>>> Regards,
>>>>
>>>> Yake
>>>>
>>>> 2017-05-10 12:08 GMT-02:30 Rob Kossler <rkoss...@nd.edu>:
>>>>
>>>>> Yake,
>>>>> So, you are trying to "undersample" the 30 MHz IF signal with the
>>>>> knowledge that the aliased version near DC will suffice? If so, this is
>>>>> not a method that can work with the USRP. At least not with the existing
>>>>> FPGA code. The USRP does not actually sample at the rate you specify in
>>>>> the sample rate. The USRP A/D typically operates at a higher rate and
>>>>> then
>>>>> the FPGA implements digital filtering and downconversion to provide the
>>>>> samples at the specified sample rate.
>>>>>
>>>>> So, in your case, I think that the analog filtering is not even
>>>>> relevant. This filtering is intended to reject large out-of-band signals
>>>>> that can cause problems at the RF front end. This filtering will not
>>>>> impact any signal that is only 30 MHz from the LO. The problem for you is
>>>>> the digital filtering & downconversion DSP that is implemented in the
>>>>> FPGA. This is the filtering that is rejecting your 30 MHz signal. But,
>>>>> I'm
>>>>> not as familiar with the E310 as I am with the X310 so it is possible that
>>>>> the "master clock rate" is also relevant.
>>>>>
>>>>> In any event, can you explain why you need to have the LO at 2 GHz for
>>>>> your application. Why not have the LO at 2.03 GHz?
>>>>> Rob
>>>>>
>>>>> On Wed, May 10, 2017 at 8:50 AM, Yake Li <liyak...@gmail.com> wrote:
>>>>>
>>>>>> Hi Rob,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks for your reply.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I think I did not explain my problem well. Our application needs us
>>>>>> to use 2GHz to demodulate the 2.03 GHz pulses, which means we have to
>>>>>> deal
>>>>>> with the 30 MHz IF signal. However, we do not need the phase information
>>>>>> of
>>>>>> the IF signal. We only care about the leading edge of the pulse, that is
>>>>>> why we are only interested in the 2.5 MHz bandwidth but not the 30 MHz
>>>>>> center frequency. If we use 6 MHz to sample the 2.5 MHz bandwidth IF
>>>>>> signal
>>>>>> centered at 30 MHz, we are actually sampling the spectrum copy of the IF
>>>>>> signal that is centered at zero frequency. The result should
>>>>>> approximately
>>>>>> be rectangular pulses in time domain.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Therefore, theoretically, if the 30 MHz IF signal can pass the
>>>>>> filters before ADC without distortion and attenuation, we should be able
>>>>>> get the same result as shown in fig1 of my last email. But now it is not
>>>>>> the case (we actually got fig2).
>>>>>>
>>>>>>
>>>>>>
>>>>>> I do not know if my theory was wrong or my settings of E310 were
>>>>>> wrong.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Yake
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* Rob Kossler [mailto:rkoss...@nd.edu]
>>>>>> *Sent:* May 9, 2017 3:09 PM
>>>>>> *To:* Yake Li <liyak...@gmail.com>
>>>>>>
>>>>>> *Subject:* Re: [USRP-users] E310 filter configuration
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi Yake,
>>>>>>
>>>>>> I think that perhaps you do not understand how the USRP provides
>>>>>> baseband complex samples (not real, IF samples). If you want to measure
>>>>>> a
>>>>>> signal at 2.03 GHz with a bandwidth of 2.5 MHz, you can simply set the RF
>>>>>> center frequency to 2.03 GHz and the sample rate to about 3 MS/s. With
>>>>>> complex samples, the bandwidth is essentially the sample rate.
>>>>>>
>>>>>> Rob
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, May 9, 2017 at 12:51 PM, Yake Li <liyak...@gmail.com> wrote:
>>>>>>
>>>>>> Please see attached the results. I sent two identical pulses (1 us
>>>>>> width in time and roughly 2.5 MHz bandwidth in freq domain) which have
>>>>>> 2.03
>>>>>> GHz center frequency. The sampling rate is 6 MS/s. Fig1 is the result
>>>>>> when
>>>>>> I tuned the Rx LO to 2.028 GHz (I notice the filter before ADC passes
>>>>>> signal above 1 MHz, so I set IF to be 2 MHz). Fig2 is the result if I
>>>>>> tune
>>>>>> the Rx LO to be 2.0 GHZ (30MHz IF). I did not use set_bandwidth() command
>>>>>> in both cases. In my understanding, if the 30 MHz IF signal passed the
>>>>>> filter before ADC, I should be able to sample it using 6 MHz because the
>>>>>> bandwidth is only 2.5MHz. But as shown by the figure, the amplitude is
>>>>>> suppressed, unbalanced and artificial is presented. I guess the problem
>>>>>> could be the filters.
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* Rob Kossler [mailto:rkoss...@nd.edu]
>>>>>> *Sent:* May 9, 2017 1:23 PM
>>>>>> *To:* Marcus D. Leech <mle...@ripnet.com>
>>>>>> *Cc:* Yake Li <liyak...@gmail.com>; usrp-users@lists.ettus.com
>>>>>> *Subject:* Re: [USRP-users] E310 filter configuration
>>>>>>
>>>>>>
>>>>>>
>>>>>> Typo in my message. I meant to say set the sample rate to 6e6 as you
>>>>>> indicated originally...
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, May 9, 2017 at 11:14 AM, Rob Kossler <rkoss...@nd.edu> wrote:
>>>>>>
>>>>>> Ignoring the set_bandwidth() command, if you set the center freq to
>>>>>> 2e9 and the sample rate to 3e6, your results will show signals in the
>>>>>> range
>>>>>> 1.997-2.003 GHz. This does not include your desired signal at 2.03 GHz,
>>>>>> which is 30 MHz away from 2 GHz.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Rob
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, May 9, 2017 at 11:05 AM, Marcus D. Leech via USRP-users <
>>>>>> usrp-users@lists.ettus.com> wrote:
>>>>>>
>>>>>> The "set_bandwidth" method sets the analog bandwidth in front of the
>>>>>> ADC.
>>>>>>
>>>>>> The RF filters are selected automatically based on your desired
>>>>>> tuning frequency.
>>>>>>
>>>>>> It would help us if you describe how the result is "incorrect" --
>>>>>> perhaps an FFT plot?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 2017-05-09 10:50, Yake Li via USRP-users wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>>
>>>>>>
>>>>>> My question is could I set the filters separately in Ettus E310? I
>>>>>> noticed there are different filters in E310. First, there are filter
>>>>>> banks
>>>>>> right after the receiving antenna. Second, the AD9361 has Rx low pass
>>>>>> filters before ADC (please refer to ?*Rx SIGNAL PATH*? of
>>>>>> http://www.farnell.com/datasheets/2007082.pdf). I noticed there is
>>>>>> only one command ?set_bandwidth? in gnuradio (or ?set_rx_bandwidth? in
>>>>>> UHD)
>>>>>> to set the RF bandwidth of front end. What is the response of each
>>>>>> filters
>>>>>> mentioned above after using this command? Could I set separately the
>>>>>> response of different filters?
>>>>>>
>>>>>>
>>>>>>
>>>>>> I am asking because I want to, for example, sample a signal centered
>>>>>> at 2.03 GHz with 3M Hz bandwidth. I tune the LO of Rx to 2 GHz, and I
>>>>>> want
>>>>>> to sample this signal with 6 MHz sampling rate. What I did is that I use
>>>>>> ?set_center_freq (2e9,0)?, ?set_bandwidth (3e6,0)? and ?set_samp_rate
>>>>>> (6e6,0)?. The result seems to be incorrect. I tried different bandwidth,
>>>>>> and under no settings I got the right result. Is there something wrong
>>>>>> with
>>>>>> my settings?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>>
>>>>>>
>>>>>> Yake
>>>>>>
>>>>>>
>>>>>>
>>>>>> [image:
>>>>>> https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]
>>>>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>>>>>>
>>>>>> Virus-free. www.avast.com
>>>>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> USRP-users mailing list
>>>>>> USRP-users@lists.ettus.com
>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> USRP-users mailing list
>>>>>> USRP-users@lists.ettus.com
>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> 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/20170512/6b00e27e/attachment-0001.html>
------------------------------
Message: 10
Date: Fri, 12 May 2017 11:35:30 -0400
From: deepa kumar <deepakumar2...@gmail.com>
To: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] E310 cross compilation issues
Message-ID:
<caoge1bdt60-amqhrcxmrtdtnqx_+yb5bqzd430n7c4yssef...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi ,
I am doing new development on UHD on a vm machine. I followed all steps as
mentioned in docs.
I downloaded and installed the cross compiler and built the UHD. I then
mounted the folder on to E310 board . I set the paths using set_env file.
Now when I do a which uhd_find_devices , I get the mounted folder path
But when I try to run uhd_find_devices , I get the error
error while loading shared libraries: libboost_program_options.so.1.56.0:
cannot open shared object file: No such file or directory
Has anybody come across this . I am stuck with this for a long while.
Please help to overcome this issue.
Thanks and Regards,
Olivani
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170512/c14d4895/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 81, Issue 12
******************************************
