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: B210 channel-to-channel freq offset?
(Marcus M?ller via USRP-users)
2. Re: "Sensitivity" parameter in Freq Modulation block in GRC
(Marcus M?ller via USRP-users)
3. UHD from within linux vmware/windows host (Tech via USRP-users)
4. Re: UHD from within linux vmware/windows host
(Marcus M?ller via USRP-users)
5. Re: UHD from within linux vmware/windows host
(Marcus D. Leech via USRP-users)
6. Re: X310 FPGA Compile (Matt Ettus via USRP-users)
7. Re: UHD from within linux vmware/windows host
(Tech via USRP-users)
----------------------------------------------------------------------
Message: 1
Date: Tue, 29 Apr 2014 15:30:48 +0200
From: Marcus M?ller via USRP-users <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] B210 channel-to-channel freq offset?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hello Robert,
2Hz at an effective sampling rate of 25MHz is an relative error of 80
parts per billion; which, in most cases, is far above what you would
call coherent.
As a guess, I'd say the error occurs in the digital domain:
Can you tell us how large your FFT is? The error you get when measuring
the phase of a tone with sub-infinite SNR (including quantization noise)
might be in the same order of magnitude.
Greetings,
Marcus
On 29.04.2014 11:04, Matt Ettus via USRP-users wrote:
> Robert,
>
> Both receive frontends in a B210 share the same local oscillator, so this
> can't happen in the analog or RF parts. The only real possibility is in
> the digital tuning, but I think it is more likely that you have not aligned
> the sample acquisitions properly.
>
> Can you try a simple GRC flowgraph which feeds both signals to a scope
> sink? Then put a single tone into a splitter and into both inputs on the
> B210. You should see the two sinewaves with some arbitrary phase
> difference between them, but that phase difference should remain constant.
>
> Matt
>
>
>
> On Tue, Apr 29, 2014 at 3:46 AM, Robert Kossler via USRP-users <
> [email protected]> wrote:
>
>> I collected data from a test signal on both RX channels of a B210. After
>> analyzing the data, it appears that one of the channels has a 2 Hz offset
>> with respect to the other. I am wondering if this could be ?real? or if
>> perhaps I have some type of configuration / control error in setting up the
>> board with the required commands (which seems more likely to me).
>>
>>
>>
>> My test signal is a multi-tone signal (128 tones evenly spread over 20
>> MHz). This signal was split (1:2 splitter) to the 2 Rx inputs of the
>> B210. I collected both channels at 25 MS/s rate for a period of 5
>> seconds. For a given time segment, I compute the FFT to determine the
>> mag/phase of each of the 128 tones at that time. By repeating this process
>> for subsequent time segments, I determine the mag/phase versus time. What
>> I determined is that the phase rate of change is greater for one channel
>> with respect to the other by about 2 Hz.
>>
>>
>>
>> Regarding control, my program is a modification of the
>> ?rx_samples_to_file? example program which sets up the board, sets the
>> clock source (I?m using internal), sets the frequency, and checks the LO
>> Locked status prior to starting the streaming.
>>
>>
>>
>> Any ideas why I might see higher phase slope on one channel relative to
>> the other? This same 2 Hz offset occurred for every tone across the
>> bandwidth.
>>
>>
>>
>> Rob Kossler
>>
>> _______________________________________________
>> 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: 2
Date: Tue, 29 Apr 2014 17:28:38 +0200
From: Marcus M?ller via USRP-users <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] "Sensitivity" parameter in Freq Modulation
block in GRC
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Hello Touseef Ali,
this is a GNU Radio Block, which has its documentation in the GNU Radio
Doxygen [1].
For this particular block, [2] says:
"radians/sample = amplitude * sensitivity"
meaning that the sensitivity is what you'd expect of an FM modulater,
i.e. the frequency-change-to-input-amplitude factor.
Greetings,
Marcus
[1] http://gnuradio.org/doc/doxygen/
[2]
http://gnuradio.org/doc/doxygen/classgr_1_1analog_1_1frequency__modulator__fc.html#details
On 29.04.2014 16:37, Touseef Ali via USRP-users wrote:
> Hi
> I am trying to generate an LFM signal using GNU radio and USRP but I am not
> sure about the interpretation of "Sensitivity" parameter in "Freq Modulation"
> block that what are its units, what is the possible range of values and how
> does it effect the characteristics of modulated waveform/signal?
>
> Regards
> Touseef Ali
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 3
Date: Tue, 29 Apr 2014 11:00:35 -0400
From: Tech via USRP-users <[email protected]>
To: [email protected]
Subject: [USRP-users] UHD from within linux vmware/windows host
Message-ID:
<cao92p1pmhcossv3edcaduj8oi8p9ta1utbtqbqa1b_9csc9...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I've had a problem for several years across many versions of UHD and
gnuradio. I have a USB to gigE dongle that I use to attach to the N210. I
run gnuradio/uhd in vmware. If I connect the usb to gigE device in windows
and run apps like uhd_fft in the vmware it works as long as I specify the
IP address but it prints multiple Ds over ~30 seconds and then stops.
However, if I load the usb to gigE dongle inside vmware it also works
except that it stops after one O is printed.
So it must be something to do with the routing of the messages that cause
the stream to restart after an overload. Any ideas what this might be or
how to debug are appreciated.
Thanks,
Clark
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140429/59e99cf2/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 29 Apr 2014 21:38:39 +0200
From: Marcus M?ller via USRP-users <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] UHD from within linux vmware/windows host
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi Clark,
this setup sounds like something I would discourage people to use.
USB2.0 (I assuming you use that) has a bandwidth smaller than gigabit
Ethernet, so you're loosing available bandwidth (meaning that you will
get O's with lower sampling rates).
The behavior -- it works worse when directly attaching the USB device to
your VM -- is explained by the fact that network device drivers often
are quite optimized to provide low latency and reduced CPU usage. If you
do communication with the USB device in the VM, your VM has to do a lot
of small USB interactions with your hardware (which are quite hard to
virtualize, thus most probably come with considerable overhead) for
every ethernet packet, instead of just getting packets from the host OS.
I don't think this can be easily debugged or solved other than actually
utilizing a "real" network port (on a PCIexpress device or similar) and
letting the host OS do the low level network stuff. From an application
point of view, there is little reason to do it in the VM.
Also please note that, although virtualization is quite mature by now,
performance of algorithms may vary based on your CPU and the algorithm
itself; often in Software Radio, you'd like to squeeze the last out of
your PC, and thus avoid using virtualized guests. This really depends on
your application.
Greetings,
Marcus
On 29.04.2014 17:00, Tech via USRP-users wrote:
> I've had a problem for several years across many versions of UHD and
> gnuradio. I have a USB to gigE dongle that I use to attach to the N210. I
> run gnuradio/uhd in vmware. If I connect the usb to gigE device in windows
> and run apps like uhd_fft in the vmware it works as long as I specify the
> IP address but it prints multiple Ds over ~30 seconds and then stops.
> However, if I load the usb to gigE dongle inside vmware it also works
> except that it stops after one O is printed.
>
> So it must be something to do with the routing of the messages that cause
> the stream to restart after an overload. Any ideas what this might be or
> how to debug are appreciated.
>
> Thanks,
> Clark
>
>
>
> _______________________________________________
> 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/20140429/9774b4b2/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 29 Apr 2014 17:07:23 -0400
From: "Marcus D. Leech via USRP-users" <[email protected]>
To: Marcus M?ller <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] UHD from within linux vmware/windows host
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 04/29/2014 03:38 PM, Marcus M?ller via USRP-users wrote:
> Hi Clark,
>
> this setup sounds like something I would discourage people to use.
> USB2.0 (I assuming you use that) has a bandwidth smaller than gigabit
> Ethernet, so you're loosing available bandwidth (meaning that you will
> get O's with lower sampling rates).
> The behavior -- it works worse when directly attaching the USB device
> to your VM -- is explained by the fact that network device drivers
> often are quite optimized to provide low latency and reduced CPU
> usage. If you do communication with the USB device in the VM, your VM
> has to do a lot of small USB interactions with your hardware (which
> are quite hard to virtualize, thus most probably come with
> considerable overhead) for every ethernet packet, instead of just
> getting packets from the host OS.
>
> I don't think this can be easily debugged or solved other than
> actually utilizing a "real" network port (on a PCIexpress device or
> similar) and letting the host OS do the low level network stuff. From
> an application point of view, there is little reason to do it in the VM.
> Also please note that, although virtualization is quite mature by now,
> performance of algorithms may vary based on your CPU and the algorithm
> itself; often in Software Radio, you'd like to squeeze the last out of
> your PC, and thus avoid using virtualized guests. This really depends
> on your application.
>
> Greetings,
> Marcus
>
My experience with USB in VMs has been "spotty" at best. Even on
ordinary devices unrelated to SDRs. So, in this case, it's a
double-whammy--
USB performance out of VMs is not wonderul *AND* you're trying to
layer 1GiGe over 480Mbit USB-2.0. That sounds like a recipe for
dissatisfaction.
--
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/20140429/c5ba3715/attachment-0001.html>
------------------------------
Message: 6
Date: Wed, 30 Apr 2014 09:23:40 +0200
From: Matt Ettus via USRP-users <[email protected]>
To: Kevin Perry <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310 FPGA Compile
Message-ID:
<CAN=1kn9_-+djcdf5wqvsempg+trvqh8g+iqk_b_x95iru2q...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Kevin,
Those 4 timing failures can safely be ignored. We will are working to fix
those particular constraints so these don't pop up, as well as to ease the
timing closure for the rest of the device. Expect some changes in the
coming weeks, but be assured that everything works properly even with those
4 false failures.
Matt
On Tue, Apr 15, 2014 at 3:07 PM, Kevin Perry <[email protected]> wrote:
> We have not been sucessful compiling the baseline design with the make
> scripts in the repository. From previous posts we have seen that there are
> issues with getting the code to compile/place/route and that you have had
> to run the scripts multiple times before it completes successfully. We
> have not been able to replicate this with the baseline. We would like to
> add our modifications but prior to doing that we wanted to make sure we had
> a clean baseline.
>
> This is the environment we are running with:
> Linux - red hat 6.5, kernel version 2.6.32-431.el6.i686
>
> Xilinx 14.4
>
> We are running with 4/7/14 GIT repositry date.
>
> We have run this numerous times. We will see timing violations within the
> ZPU mostly, but we always see this timing error on the ADC_Clock paths.
>
>
> ----------------------------------------------------------------------------------------------------------
> Constraint | Check | Worst Case |
> Best Case | Timing | Timing
> | | Slack |
> Achievable | Errors | Score
>
> ----------------------------------------------------------------------------------------------------------
> * OFFSET = IN 0.75 ns VALID 1.5 ns BEFORE C | SETUP |
> 1.955ns| -1.205ns| 0| 0
> OMP "DB1_ADC_DCLK_P" "FALLING" | HOLD |
> -2.873ns| | 14| 39666
>
> ----------------------------------------------------------------------------------------------------------
> * OFFSET = IN 0.75 ns VALID 1.5 ns BEFORE C | SETUP |
> 1.955ns| -1.205ns| 0| 0
> OMP "DB1_ADC_DCLK_P" "RISING" | HOLD |
> -2.873ns| | 14| 39666
>
> ----------------------------------------------------------------------------------------------------------
> * OFFSET = IN 0.75 ns VALID 1.5 ns BEFORE C | SETUP |
> 1.968ns| -1.218ns| 0| 0
> OMP "DB0_ADC_DCLK_P" "FALLING" | HOLD |
> -2.842ns| | 14| 39388
>
> ----------------------------------------------------------------------------------------------------------
> * OFFSET = IN 0.75 ns VALID 1.5 ns BEFORE C | SETUP |
> 1.968ns| -1.218ns| 0| 0
> OMP "DB0_ADC_DCLK_P" "RISING" | HOLD |
> -2.842ns| | 14| 39388
>
> Attached is the build directory for one of the compiles.
>
> Please advise
>
> Kevin
>
> _______________________________________________
> 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/20140430/e2cd53fe/attachment-0001.html>
------------------------------
Message: 7
Date: Wed, 30 Apr 2014 08:08:34 -0400
From: Tech via USRP-users <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] UHD from within linux vmware/windows host
Message-ID:
<cao92p1rduutbkserv96hs4qc+crf64oaabbvzvg4--e-6_h...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Tue, Apr 29, 2014 at 11:00 AM, Tech <[email protected]> wrote:
> I've had a problem for several years across many versions of UHD and
> gnuradio. I have a USB to gigE dongle that I use to attach to the N210. I
> run gnuradio/uhd in vmware. If I connect the usb to gigE device in windows
> and run apps like uhd_fft in the vmware it works as long as I specify the IP
> address but it prints multiple Ds over ~30 seconds and then stops. However,
> if I load the usb to gigE dongle inside vmware it also works except that it
> stops after one O is printed.
>
> So it must be something to do with the routing of the messages that cause
> the stream to restart after an overload. Any ideas what this might be or how
> to debug are appreciated.
>
> Thanks,
> Clark
Some additional info: I found that if I put the USRP on the native
ethernet interface I get the same behavior so USB has a performance
penalty but it seems the root cause is something to do with how vmware
handles networking combined with what exactly happens when overruns
are detected. Maybe the restart stream message is at an odd port
number or something?
I did finally have some luck by using the native ethernet interface in
bridged mode. Formerly I was in NAT mode. It eventually stalled but
ran about half an hour.
Yes, I understand the performance penalty using VM but I'm mostly
doing narrowband stuff and most of my tools are windows based. I've
not had much luck with gnuradio/uhd in windows in the past plus I like
being able to lock down particular versions in a vm image. Thanks
------------------------------
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 44, Issue 30
******************************************
