ll the time on my B210, but at smaller sample rates and offsets (10 Msps,
> 4 MHz offset and 4X master clock rate).
>
> Maybe a test with 10 MHz LTE versus 20 MHz would be useful?
>
> Ron
> On 6/5/19 16:34, Dario Fertonani via USRP-users wrote:
>
> Sorry, I wrote "coheren
?
>
>
>
> On Wed, Jun 5, 2019 at 2:25 PM Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On 06/05/2019 05:20 PM, Dario Fertonani via USRP-users wrote:
>>
>> I'm trying to move the "DC offset" out of the main spect
> On 06/05/2019 05:20 PM, Dario Fertonani via USRP-users wrote:
>
> I'm trying to move the "DC offset" out of the main spectrum by using the
> dsp_freq field in uhd::tune_request_t. This doesn't seem to work on B210,
> meaning that the following code functions p
I'm trying to move the "DC offset" out of the main spectrum by using the
dsp_freq field in uhd::tune_request_t. This doesn't seem to work on B210,
meaning that the following code functions properly with DcOffset_Hz=0 but
not, for example, with DcOffset_Hz=10e6. In all these tests the master
clock r
Also, it seems that no implementation of zero-copy UDP is available yet,
and that udp_zero_copy_asio_impl (which isn't zero-copy) is the only
available implementation today.
Is this correct? If so, any ETA for true zero-copy UDP?
Thanks,
Dario
On Fri, Mar 29, 2019 at 9:15 AM Dario Fertonani
wrot
Any example available for udp_zero_copy? I wasn't able to find any in the
master branch.
Thanks,
Dario
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Hi Martin,
Do you know whether the recently-announced release "3.11.1.0 Release
Candidate 1" addresses the bug discussed in this thread? Or should we keep
all our machines on 3.10.3 for now?
Thanks,
On Thu, Apr 19, 2018 at 7:01 PM Dario Fertonani
wrote:
> Hi Martin,
>
> Thanks for looking into
Hi Martin,
Thanks for looking into it. Meanwhile I collected more information and it
does get weirder.
I'm attaching a basic C++ program that does nothing useful, it just RX
streams until CTRL+C kills it. Compiling instructions for Linux are in the
first lines of the code.
On Ubuntu 18.04, everyt
No comments on this? It's a major bug introduced in the new release, in my
opinion.
Anybody can replicate it by running the official test file linked below,
when compiled with UHD 3.11 from Ubuntu PPA.
https://github.com/manuts/uhd-examples/blob/master/rx_multi_samples.cpp
Just run it long enou
Thank you Martin, logging is fixed now.
However, something must have changes in the rx_streamer behavior.
Basic receive code that has compiled/worked since the 3.9.x days no longer
works. This is for B210 under Ubuntu 16.04, g++ 5.4, UHD fro 3.11 from PPA.
The receiver works the first time after B
Hi Martin,
Our code doesn't compile on Ubuntu 16.04 with UHD 3.11 from PPA (UHD 3.10.x
works well). This is on "amd64" ark, with g++ that dies out with a missing
header (copied below)
fatal error: uhd/utils/msg.hpp: No such file or directory
I can probably fix the headers with some trial and er
Jeff Long via USRP-users
> >> wrote:
> >>>
> >>> Try (int16_t) round( x * 32767 )
> >>>
> >>> On Wed, Jan 24, 2018 at 5:01 PM, Dario Fertonani via USRP-users
> >>> wrote:
> >>>>
> >>>> Any pointer to a
No luck. I'll look into these:
https://files.ettus.com/manual/convert__common_8hpp.html
On Wed, Jan 24, 2018 at 2:58 PM, Jeff Long via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Try (int16_t) round( x * 32767 )
>
> On Wed, Jan 24, 2018 at 5:01 PM, Dario Fertonani via
Any pointer to a C/C++ function (maybe in the UHD source code, or a doc)
that converts IQ samples from format fc32 to sc16? I'm referring to "CPU
sample format", not "wire sample format".
For C++ UHD, I know fc32 is complex< float > and sc16 is complex< int16_t
>. I'm tempted to assume that each c
are on the older 3.9 branch, but they have made some updates in 3.10
> that may have made the misses occur less frequently according to release
> notes...
>
> On November 21, 2017 at 10:36 PM Dario Fertonani via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Yes, bu
e, Nov 21, 2017 at 7:19 PM, Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:
> On 11/21/2017 10:12 PM, Dario Fertonani via USRP-users wrote:
>
>> From experiments it seems that the subject call blocks until the next GPS
>> whole second hits. Is that c
>From experiments it seems that the subject call blocks until the next GPS
whole second hits. Is that correct?
Thanks,
Dario
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
You may want to look at my messages in the thread "UHD command delay is
different in the first recv stream".
You'll see that: delays have been there for a long time, are still there in
UHD 3.10.x, delay values depend on sampling rate (and/or master clock
rate), and, more critically, the very first
On B210, the function
get_mboard_sensor_names( )
returns only "ref_locked" (output confirmed by "uhd_usrp_probe"), so it
seems the answer to the question in this thread is negative. Can anybody
please confirm whether this is correct? It would be very useful to know if
the PPS signal input is actu
I was wondering if it's possible to check via software API whether the PPS
reference input is connected. Something along the lines of the API that
checks whether the 10 MHz reference input is connected (see red part of the
snippet below).
Thanks,
Dario
rfBoardPtr->set_clock_source( "external" );
CU
>>
>>
>> there is another spec for clock - it's jitter. that one seems way more
>> important. jitter hurts you in a way that you are not just off freq, but
>> your freq is constantly jumping around in some kind of random-ish pattern.
>> I see the USRP spe
> your freq is constantly jumping around in some kind of random-ish pattern.
> I see the USRP spec for it - however I can't really comment on that.
>
>
> Thanks,
> Vladimir
>
>
> On Tue, Oct 3, 2017 at 8:44 AM, Dario Fertonani via USRP-users <
> usrp-users@lists.ettu
I'm testing the behavior of B210-based systems, comparing the performance
with "internal" and "external" (10 MHz) clock source. Expect for the
following "is the 10 MHz input actually present" check running when the app
starts, the two branches share the same code.
rfBoardPtr->set_clock_source( "ex
Hi Piotr,
Because of the problem you described, and other similar limitations for
stop-and-go usage of the tx_streamer (I'm referring to the C++ UHD API
here), I suggest keeping the tx_streamer always on and just feeding it with
IQ zeros when you don't want to transmit anything. This solution is a
24 matches
Mail list logo
