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. Re: UBX-160 Performance < 500 MHz (Michael West)
   2. Cannot remove X310 image (David Miller)
   3. Re: Cannot remove X310 image (Paul David)
   4. E310 FPGA loading (Patel, Chintan)
   5. FPGA RAW ADC values on N210 (Matthias M?ller)
   6. best way to avoid dropped samples (Morgan Redfield)
   7. Re: best way to avoid dropped samples (Marcus D. Leech)
   8. Re: best way to avoid dropped samples (Morgan Redfield)
   9. Re: best way to avoid dropped samples (Marcus D. Leech)
  10. Re: best way to avoid dropped samples (Morgan Redfield)
  11. Re: best way to avoid dropped samples (Marcus D. Leech)
  12. Re: best way to avoid dropped samples (Anon Lister)
  13. Re: UBX-160 Performance < 500 MHz (Michael Wentz)
  14. Re: UBX-160 Performance < 500 MHz (Michael West)


----------------------------------------------------------------------

Message: 1
Date: Tue, 20 Sep 2016 10:05:13 -0700
From: Michael West <michael.w...@ettus.com>
To: Michael Wentz <mchlw...@gmail.com>
Cc: "Marcus D. Leech" <mle...@ripnet.com>,
        "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] UBX-160 Performance < 500 MHz
Message-ID:
        <cam4xkrr6bqysc9mvlzcr8csesgugaefmgmhl0xocorg5dvv...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi Michael,

I'm glad to hear that made a substantial improvement.

We need to update the documentation with the dboard_clock_rate parameter
information and we will do that.  The MAX2871 synthesizer used on the UBX
has proven to be a bit touchy and has required a lot of special settings to
perform properly.  The default dboard_clock_rate on the X310 is 50 MHz,
which is the ideal PFD frequency for the UBX.  For frequencies under 1 GHz,
we have found it necessary to reduce the dboard_clock_rate to 20 MHz due to
several limitations in the MAX2871.

We looked into setting the dboard_clock_rate automatically in UHD, but it
is a non-trivial exercise because it is dependent on the user's intended
use.  Changing the dboard_clock_rate dynamically whenever the user
application changes the frequency presents a host of other potential
problems, not to mention what to do if there are 2 different types of
daughterboards in the USRP.

Regards,
Michael



On Tue, Sep 20, 2016 at 4:55 AM, Michael Wentz <mchlw...@gmail.com> wrote:

> Hi Michael,
>
> Adding "dboard_clock_rate=20e6" made a significant difference - the spurs
> and odd shape in the noise floor are both gone, image attached. I did the
> same type of measurement and it was around 75 dB SFDR, almost a 20 dB
> improvement.
>
> I had never heard of the dboard_clock_rate argument before. Are there any
> implications of setting that to 20 MHz and using the default master clock
> rate of 200 MHz? Also, is there a reason that UHD wouldn't know to use that
> number by default (based on the fact that I'm using a UBX < 1 GHz)?
>
> Thanks,
> Michael
>
> On Mon, Sep 19, 2016 at 9:34 PM, Michael West <michael.w...@ettus.com>
> wrote:
>
>> Hi Michael,
>>
>> We do recommend a lower dboard clock rate for frequencies below 1 GHz on
>> the UBX (for better LO performance).  Can you try adding
>> 'dboard_clock_rate=20e6' to your device arguments and see if there is any
>> change?
>>
>> It is odd that introducing a signal causes the noise floor to rise.  I
>> will run this by the hardware engineer for the UBX and see if he has any
>> ideas.
>>
>> Regards,
>> Michael West
>>
>> On Mon, Sep 19, 2016 at 5:19 PM, Michael Wentz via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> I'm using the latest commit on rfnoc-devel, built today. I can also try
>>> without RFNoC but figured it would be identical since the master branch was
>>> merged in 10 days ago.
>>>
>>> On Mon, Sep 19, 2016 at 8:15 PM, Marcus D. Leech <mle...@ripnet.com>
>>> wrote:
>>>
>>>> On 09/19/2016 06:30 PM, Michael Wentz wrote:
>>>>
>>>> Hi Marcus,
>>>>
>>>> Thanks for the feedback. Yes, I've tried gain ranges 0 to 31.5 - I'm
>>>> intending to use an external LNA so was searching for settings where these
>>>> issues were minimized, but they were fairly consistent across the gain
>>>> range. I've also tried a variety of input signal strengths, usually around
>>>> 30-40 dB below IIP3.
>>>>
>>>> I'm aware of the two RF chains and there is a noticeable performance
>>>> difference < 500 MHz in the data on files.ettus.com, but nothing that
>>>> informed me about the spurious content and odd behavior of the noise floor
>>>> when there's a signal applied.
>>>>
>>>> Is the UBX design more optimized for higher frequencies? Wondering if I
>>>> should have gone with the WBX-120 here.
>>>>
>>>> -Michael
>>>>
>>>> The UBX design is optimized for its entire frequency range.
>>>>
>>>> What version of UHD are you using?
>>>>
>>>>
>>>>
>>>> On Mon, Sep 19, 2016 at 6:03 PM, Marcus D. Leech via USRP-users <
>>>> usrp-users@lists.ettus.com> wrote:
>>>>
>>>>> On 09/19/2016 02:58 PM, Michael Wentz via USRP-users wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I am working with an X310 and UBX-160 with the latest version of UHD.
>>>>>> I've started to characterize the performance a bit at frequencies I'm
>>>>>> interested in (< 500 MHz), and while trying to determine full range I
>>>>>> noticed strange behavior compared to the WBX and SBX. Attached are some
>>>>>> screen shots from measurements I made at 400 MHz with full gain (31.5) on
>>>>>> the WBX-40, SBX-120, and UBX-160. I'm just eye balling the SDFR and 
>>>>>> picking
>>>>>> the most noticeable spur away from the carrier, nothing really precise.
>>>>>>
>>>>>> WBX-40 : input power -15 dBm, SFDR around 76 dB
>>>>>> SBX-120: input power -34 dBm, SFDR around 82 dB
>>>>>> UBX-120: input power -32 dBm, SFDR around 56 dB
>>>>>>
>>>>>> I also noticed on the UBX that there is a significant increase in the
>>>>>> noise floor when an input signal is applied, even if that input is 20-30 
>>>>>> dB
>>>>>> below where the input would clip. I've verified with test equipment that
>>>>>> the noise floor is not from my signal source. Additionally, I did some
>>>>>> measurements at 600 MHz and 1 GHz and saw much better performance, in 
>>>>>> line
>>>>>> with the WBX/SBX.
>>>>>>
>>>>>> Is any of this expected? Is there anything I can do to improve the
>>>>>> performance?
>>>>>>
>>>>>> Thanks,
>>>>>> Michael
>>>>>>
>>>>>>
>>>>>> Two quick comments.
>>>>>
>>>>> The first is that the analog RF chain on UBX is *very* different from
>>>>> SBX/WBX (which are almost identical, BTW, except for mixers).
>>>>>
>>>>> The second is a question.  Have you tried dropping the gain on the
>>>>> UBX?  Have you tried lowering the signal level?  The UBX has two
>>>>>   different RF chains, with 500Mhz being the dividing line between the
>>>>> two.   So I would expect there to be not-subtle differences in things
>>>>>   like OIP3, p1dB, etc.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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/20160920/017d127c/attachment-0001.html>

------------------------------

Message: 2
Date: Tue, 20 Sep 2016 17:08:07 +0100
From: David Miller <david.zod.mil...@gmail.com>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] Cannot remove X310 image
Message-ID: <19f85908-945d-b2b9-f965-b37571acc...@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi,

I have acquired an X310 with an image based on the original uhd 3.8.2 
image, not sure what it does but doing a uhd_usrp_probe with uhd 3.8.2 
it works as expected, however no samples are emitted with the utilities, 
it's hosed!

Anyways, I have tried the 3.8.2 burn program (usrp_x3xx_fpga_burner) 
which fails, and currently tried the 3.9.4 uhd_image_loader.

uhd_image_loader fails (and similarly usrp_x3xx_fpga_burner) with:

Error: RunTimeError: Device reported an error during initialization.

I hacked the code in the x310_send_and_receive() function, somewhere in 
the code,  to see if there is any kind of status message generated that 
might help, the recv function returns a len of 4 (0 being a timeout), 
which fails a subsequent check function that masks this len value (with 
0x04, or whatever the def is) to determine that this is a failure. Sorry 
to be a bit vague, I don't have the setup in front of me at the moment.

So, the real question is: How do I recover the unit and burn back a 
working image, is it now only possible using Vivado/ISE/JTAG?

Hope you can help?

Thanks,
Dave






------------------------------

Message: 3
Date: Tue, 20 Sep 2016 11:07:44 -0700
From: Paul David <paul.da...@ettus.com>
To: David Miller <david.zod.mil...@gmail.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Cannot remove X310 image
Message-ID:
        <cacjvjtvj1c30ptgqgphvk4dxqe2bsxxxkd2aubcf2ni1eml...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi David,

To answer your question: you do need Vivado in order to configure the FPGA
over JTAG using the command: viv_jtag_program <bitfile path> .

Or you can use the hardware manager in Vivado. After you do that, you'll
need to use uhd_image_loader to burn the same FPGA image so that it
persists after a power cycle.

I would recommend upgrading UHD to a more recent tagged release as well.

-- Paul

On Tue, Sep 20, 2016 at 9:08 AM, David Miller via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
> I have acquired an X310 with an image based on the original uhd 3.8.2
> image, not sure what it does but doing a uhd_usrp_probe with uhd 3.8.2 it
> works as expected, however no samples are emitted with the utilities, it's
> hosed!
>
> Anyways, I have tried the 3.8.2 burn program (usrp_x3xx_fpga_burner) which
> fails, and currently tried the 3.9.4 uhd_image_loader.
>
> uhd_image_loader fails (and similarly usrp_x3xx_fpga_burner) with:
>
> Error: RunTimeError: Device reported an error during initialization.
>
> I hacked the code in the x310_send_and_receive() function, somewhere in
> the code,  to see if there is any kind of status message generated that
> might help, the recv function returns a len of 4 (0 being a timeout), which
> fails a subsequent check function that masks this len value (with 0x04, or
> whatever the def is) to determine that this is a failure. Sorry to be a bit
> vague, I don't have the setup in front of me at the moment.
>
> So, the real question is: How do I recover the unit and burn back a
> working image, is it now only possible using Vivado/ISE/JTAG?
>
> Hope you can help?
>
> Thanks,
> Dave
>
>
>
>
> _______________________________________________
> 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/20160920/be673228/attachment-0001.html>

------------------------------

Message: 4
Date: Tue, 20 Sep 2016 18:23:23 +0000
From: "Patel, Chintan" <chintan.pa...@commscope.com>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] E310 FPGA loading
Message-ID:
        
<mwhpr06mb249521a74ae8f8ceef3959d2e6...@mwhpr06mb2495.namprd06.prod.outlook.com>
        
Content-Type: text/plain; charset="us-ascii"

Hi,

I build the X310 FPGA code (from the master branch) using Vivado to create a 
.bit file. When I configure the FPGA using this .bit file using JTAG (hardware 
manager), the E310 powers off. If I take this same .bit file and put it under 
usr/share/uhd/images on the SD card the unit comes up correctly and behaves as 
expected. So I know the .bit file I am creating is not "bad". So while I have a 
workaround to get .bit file onto the system (by replacing the file on the 
filesystem), I would still like to understand why it didn't work using JTAG. 
Reading the Xilinx documentation, it seems that the right way to program the 
Zynq part over JTAG is to actually provide a boot.bin file which is the file 
used to boot up the PS which then configures the PL using a .bit file, if one 
is provided/linked to the boot.bin file. Not sure if that explains what I see.


Thanks
Chintan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160920/e8a5e20a/attachment-0001.html>

------------------------------

Message: 5
Date: Tue, 20 Sep 2016 23:17:24 +0200 (CEST)
From: Matthias M?ller <matthias.muel...@neratec.com>
To: <usrp-users@lists.ettus.com>
Subject: [USRP-users] FPGA RAW ADC values on N210
Message-ID: <003001d21384$4abd3390$e0379ab0$@muel...@neratec.com>
Content-Type: text/plain; charset="iso-8859-1"

Dear USRP users

I?m currently working on my master thesis where I will calculate a FFT on
a N210. I make my own I-Q mixer and filter in HW and I use the ADC of my
N210 only to sample the already mixed signals.
I?m now a little bit confused where to insert the FFT block in the FPGA.
As it is written in the description, I need to modify the
?custom_dsp_rx.v? and put my FFT block directly there.
I want to bypass the DDC, because I work directly with IF because I have
an external I-Q mixer. I want to use the FFT block instead of the DDC
block.

I have following issues:

1: I?m a little bit confused about the width of the frontend_i and
frontend_q signals. According to several internet resources, frontend_i
corresponds to the samples directly sampled from the ADC1 of the HW and
frontend_q to the ADC2. As far as I see it, each ADC channel of the dual
ADC has only a resolution of 14 bits. So why are frontend_i and frontend_q
24 bits wide? Or do I need to get the raw ADC values from elsewhere?

2: by using the makro in the makefile, I can specify two separate
channels, RX_DSP0_MODULE and  RX_DSP1_MODULE. It is correct, that those
channels are two parallel, independant DDC channels which have nothing to
do with each other and both use the same frontend_i and frontend_q samples
from the ADC? Is it correct that I need only one (e.g. RX_DSP0_MODULE),
put my FFT block in it and I could forget about the other?

3: Do I also need to specify a special frontend in the driver to make sure
that the ADC1 samples are on frontend_i and the ADC2 samples are on
frontend_q? Like A:AB? Are more driver settings needed?

I hope you could clear up a little bit of my confusion J
Thank you in advance
Cheers,
Matthias







-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160920/dfca67e5/attachment-0001.html>

------------------------------

Message: 6
Date: Tue, 20 Sep 2016 15:42:26 -0700
From: Morgan Redfield <mredfi...@m42tech.com>
To: usrp <usrp-users@lists.ettus.com>
Subject: [USRP-users] best way to avoid dropped samples
Message-ID:
        <CACv7tsGZukTuew=iruk2v+q8cntoupi1t7vfc5ofptfpo-k...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

We're using a USRP B200 to collect data for post processing. Our flowgraph
is just a USRP source connected to a filesink. We're using a 1MHz sample
rate. Ultimately, we'd like to be able to record data for 15 to 20 minutes
with no dropped samples.

Every once in a while, we see data overruns ('O's appear in the terminal
when we're sampling). To avoid this, we attempted to use sc12 for the otw
format in order to reduce the length of data being sent from the USRP.

When I have otw_format set to 'sc12', then I get this error after some time
recording:

UHD Error:
    The receive packet handler caught a value exception.
    ValueError: bad vrt header or packet fragment
WARN: USRP Source Block caught rx error code: 15
DO

So it looks like there's an overflow and a dropped packet.

So I have two questions:
1. What's the best way to avoid dropping samples?
2. Why are we getting VRT packet errors if we use 'sc12' as the OTW format?

Thanks for any help you can give,
Morgan

System details:
USRP B200 connected over USB3.0
Computer:
- SSD with 458MB/sec sequential write speeds
- 16GB swap space
- 16GB RAM
- 3.8GHz Intel I7 processor
- Ubuntu 16.04
- GNURadio version 3.7.10.1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160920/74f6a2a7/attachment-0001.html>

------------------------------

Message: 7
Date: Tue, 20 Sep 2016 19:09:15 -0400
From: "Marcus D. Leech" <mle...@ripnet.com>
To: Morgan Redfield <mredfi...@m42tech.com>,
        "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] best way to avoid dropped samples
Message-ID: <57e1c19b.5070...@ripnet.com>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"

On 09/20/2016 06:42 PM, Morgan Redfield via USRP-users wrote:
> We're using a USRP B200 to collect data for post processing. Our 
> flowgraph is just a USRP source connected to a filesink. We're using a 
> 1MHz sample rate. Ultimately, we'd like to be able to record data for 
> 15 to 20 minutes with no dropped samples.
>
> Every once in a while, we see data overruns ('O's appear in the 
> terminal when we're sampling). To avoid this, we attempted to use sc12 
> for the otw format in order to reduce the length of data being sent 
> from the USRP.
>
> When I have otw_format set to 'sc12', then I get this error after some 
> time recording:
>
> UHD Error:
>     The receive packet handler caught a value exception.
>     ValueError: bad vrt header or packet fragment
> WARN: USRP Source Block caught rx error code: 15
> DO
>
> So it looks like there's an overflow and a dropped packet.
>
> So I have two questions:
> 1. What's the best way to avoid dropping samples?
> 2. Why are we getting VRT packet errors if we use 'sc12' as the OTW 
> format?
VRT == Vita49 Radio Transport --- those headers are present regardless 
of the wire format.

With 1Msps, you shouldn't ever be experiencing overruns.  My guess is 
that your SSD doesn't actually perform at its rated speed.
   Also, are you running this on a real, or VM setup?


>
> Thanks for any help you can give,
> Morgan
>
> System details:
> USRP B200 connected over USB3.0
> Computer:
> - SSD with 458MB/sec sequential write speeds
> - 16GB swap space
> - 16GB RAM
> - 3.8GHz Intel I7 processor
> - Ubuntu 16.04
> - GNURadio version 3.7.10.1
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160920/1fc2eea6/attachment-0001.html>

------------------------------

Message: 8
Date: Tue, 20 Sep 2016 16:54:37 -0700
From: Morgan Redfield <mredfi...@m42tech.com>
To: "Marcus D. Leech" <mle...@ripnet.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] best way to avoid dropped samples
Message-ID:
        <cacv7tshlk95bj__2k++xpftwyvyu+r0ncyehvrcj4b__-93...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

There's no VM.

I realize that it's always VRT over USB, but I'm curious why we only get
VRT errors if we use sc12, and not if we use sc16.

Is there a standard way of optimizing linux to run with an SSD for gnuradio
or the USRP?

On Tue, Sep 20, 2016 at 4:09 PM, Marcus D. Leech <mle...@ripnet.com> wrote:

> On 09/20/2016 06:42 PM, Morgan Redfield via USRP-users wrote:
>
> We're using a USRP B200 to collect data for post processing. Our flowgraph
> is just a USRP source connected to a filesink. We're using a 1MHz sample
> rate. Ultimately, we'd like to be able to record data for 15 to 20 minutes
> with no dropped samples.
>
> Every once in a while, we see data overruns ('O's appear in the terminal
> when we're sampling). To avoid this, we attempted to use sc12 for the otw
> format in order to reduce the length of data being sent from the USRP.
>
> When I have otw_format set to 'sc12', then I get this error after some
> time recording:
>
> UHD Error:
>     The receive packet handler caught a value exception.
>     ValueError: bad vrt header or packet fragment
> WARN: USRP Source Block caught rx error code: 15
> DO
>
> So it looks like there's an overflow and a dropped packet.
>
> So I have two questions:
> 1. What's the best way to avoid dropping samples?
> 2. Why are we getting VRT packet errors if we use 'sc12' as the OTW format?
>
> VRT == Vita49 Radio Transport --- those headers are present regardless of
> the wire format.
>
> With 1Msps, you shouldn't ever be experiencing overruns.  My guess is that
> your SSD doesn't actually perform at its rated speed.
>   Also, are you running this on a real, or VM setup?
>
>
>
> Thanks for any help you can give,
> Morgan
>
> System details:
> USRP B200 connected over USB3.0
> Computer:
> - SSD with 458MB/sec sequential write speeds
> - 16GB swap space
> - 16GB RAM
> - 3.8GHz Intel I7 processor
> - Ubuntu 16.04
> - GNURadio version 3.7.10.1
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160920/e80cbdc2/attachment-0001.html>

------------------------------

Message: 9
Date: Tue, 20 Sep 2016 20:01:29 -0400
From: "Marcus D. Leech" <mle...@ripnet.com>
To: Morgan Redfield <mredfi...@m42tech.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] best way to avoid dropped samples
Message-ID: <57e1cdd9.2090...@ripnet.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

On 09/20/2016 07:54 PM, Morgan Redfield wrote:
> There's no VM.
>
> I realize that it's always VRT over USB, but I'm curious why we only 
> get VRT errors if we use sc12, and not if we use sc16.
That may just be because of the way SC12 are packed on the wire, with a 
dropped frame "slicing" one of these down the middle.

>
> Is there a standard way of optimizing linux to run with an SSD for 
> gnuradio or the USRP?
Have you tried uhd_rx_cfile, instead of your own flow-graph?

There's a write-behind cache configuration item for the kernel that 
controls how much of main memory gets used for the disk
   write-behind cache.  If this cache is large, it might take quite a 
while for it to flush it to disk all in one gulp, thus causing
   some scheduling difficulties.  I just can't off the top of my head 
remember what it's called :(

Have you actually tested the write performance of your filesystem 
outside of gnu radio?


>
> On Tue, Sep 20, 2016 at 4:09 PM, Marcus D. Leech <mle...@ripnet.com 
> <mailto:mle...@ripnet.com>> wrote:
>
>     On 09/20/2016 06:42 PM, Morgan Redfield via USRP-users wrote:
>>     We're using a USRP B200 to collect data for post processing. Our
>>     flowgraph is just a USRP source connected to a filesink. We're
>>     using a 1MHz sample rate. Ultimately, we'd like to be able to
>>     record data for 15 to 20 minutes with no dropped samples.
>>
>>     Every once in a while, we see data overruns ('O's appear in the
>>     terminal when we're sampling). To avoid this, we attempted to use
>>     sc12 for the otw format in order to reduce the length of data
>>     being sent from the USRP.
>>
>>     When I have otw_format set to 'sc12', then I get this error after
>>     some time recording:
>>
>>     UHD Error:
>>         The receive packet handler caught a value exception.
>>         ValueError: bad vrt header or packet fragment
>>     WARN: USRP Source Block caught rx error code: 15
>>     DO
>>
>>     So it looks like there's an overflow and a dropped packet.
>>
>>     So I have two questions:
>>     1. What's the best way to avoid dropping samples?
>>     2. Why are we getting VRT packet errors if we use 'sc12' as the
>>     OTW format?
>     VRT == Vita49 Radio Transport --- those headers are present
>     regardless of the wire format.
>
>     With 1Msps, you shouldn't ever be experiencing overruns. My guess
>     is that your SSD doesn't actually perform at its rated speed.
>       Also, are you running this on a real, or VM setup?
>
>
>>
>>     Thanks for any help you can give,
>>     Morgan
>>
>>     System details:
>>     USRP B200 connected over USB3.0
>>     Computer:
>>     - SSD with 458MB/sec sequential write speeds
>>     - 16GB swap space
>>     - 16GB RAM
>>     - 3.8GHz Intel I7 processor
>>     - Ubuntu 16.04
>>     - GNURadio version 3.7.10.1
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160920/2bc6deee/attachment-0001.html>

------------------------------

Message: 10
Date: Tue, 20 Sep 2016 17:59:42 -0700
From: Morgan Redfield <mredfi...@m42tech.com>
To: "Marcus D. Leech" <mle...@ripnet.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] best way to avoid dropped samples
Message-ID:
        <cacv7tsg2at1eusjobfqd34nqzahhrssixuyhqkebvkg9zqs...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

I just tested the write performance of my filesystem, and I got sequential
write speeds of 434MB/s.

After that I tried uhd_rx_cfile for a 10min collect, and I did get one 'O'
during that collection. We based our rx script on the uhd_rx_cfile and just
added some switches for timed receive, so I'm not surprised we're getting
the same behavior with the original.

Are the write-behind configurations related to these?
/proc/sys/vm/dirty_ratio
/proc/sys/vm/dirty_background_ratio

Do you have a suggestion for where they should be set?


On Tue, Sep 20, 2016 at 5:01 PM, Marcus D. Leech <mle...@ripnet.com> wrote:

> On 09/20/2016 07:54 PM, Morgan Redfield wrote:
>
> There's no VM.
>
> I realize that it's always VRT over USB, but I'm curious why we only get
> VRT errors if we use sc12, and not if we use sc16.
>
> That may just be because of the way SC12 are packed on the wire, with a
> dropped frame "slicing" one of these down the middle.
>
>
> Is there a standard way of optimizing linux to run with an SSD for
> gnuradio or the USRP?
>
> Have you tried uhd_rx_cfile, instead of your own flow-graph?
>
> There's a write-behind cache configuration item for the kernel that
> controls how much of main memory gets used for the disk
>   write-behind cache.  If this cache is large, it might take quite a while
> for it to flush it to disk all in one gulp, thus causing
>   some scheduling difficulties.  I just can't off the top of my head
> remember what it's called :(
>
> Have you actually tested the write performance of your filesystem outside
> of gnu radio?
>
>
>
>
> On Tue, Sep 20, 2016 at 4:09 PM, Marcus D. Leech <mle...@ripnet.com>
> wrote:
>
>> On 09/20/2016 06:42 PM, Morgan Redfield via USRP-users wrote:
>>
>> We're using a USRP B200 to collect data for post processing. Our
>> flowgraph is just a USRP source connected to a filesink. We're using a 1MHz
>> sample rate. Ultimately, we'd like to be able to record data for 15 to 20
>> minutes with no dropped samples.
>>
>> Every once in a while, we see data overruns ('O's appear in the terminal
>> when we're sampling). To avoid this, we attempted to use sc12 for the otw
>> format in order to reduce the length of data being sent from the USRP.
>>
>> When I have otw_format set to 'sc12', then I get this error after some
>> time recording:
>>
>> UHD Error:
>>     The receive packet handler caught a value exception.
>>     ValueError: bad vrt header or packet fragment
>> WARN: USRP Source Block caught rx error code: 15
>> DO
>>
>> So it looks like there's an overflow and a dropped packet.
>>
>> So I have two questions:
>> 1. What's the best way to avoid dropping samples?
>> 2. Why are we getting VRT packet errors if we use 'sc12' as the OTW
>> format?
>>
>> VRT == Vita49 Radio Transport --- those headers are present regardless of
>> the wire format.
>>
>> With 1Msps, you shouldn't ever be experiencing overruns.  My guess is
>> that your SSD doesn't actually perform at its rated speed.
>>   Also, are you running this on a real, or VM setup?
>>
>>
>>
>> Thanks for any help you can give,
>> Morgan
>>
>> System details:
>> USRP B200 connected over USB3.0
>> Computer:
>> - SSD with 458MB/sec sequential write speeds
>> - 16GB swap space
>> - 16GB RAM
>> - 3.8GHz Intel I7 processor
>> - Ubuntu 16.04
>> - GNURadio version 3.7.10.1
>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160920/670741ae/attachment-0001.html>

------------------------------

Message: 11
Date: Tue, 20 Sep 2016 21:19:49 -0400
From: "Marcus D. Leech" <mle...@ripnet.com>
To: Morgan Redfield <mredfi...@m42tech.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] best way to avoid dropped samples
Message-ID: <57e1e035.20...@ripnet.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

On 09/20/2016 08:59 PM, Morgan Redfield wrote:
> I just tested the write performance of my filesystem, and I 
> got sequential write speeds of 434MB/s.
>
> After that I tried uhd_rx_cfile for a 10min collect, and I did get one 
> 'O' during that collection. We based our rx script on the uhd_rx_cfile 
> and just added some switches for timed receive, so I'm not surprised 
> we're getting the same behavior with the original.
>
> Are the write-behind configurations related to these?
> /proc/sys/vm/dirty_ratio
> /proc/sys/vm/dirty_background_ratio
>
> Do you have a suggestion for where they should be set?
>
https://lonesysadmin.net/2013/12/22/better-linux-disk-caching-performance-vm-dirty_ratio/

>
> On Tue, Sep 20, 2016 at 5:01 PM, Marcus D. Leech <mle...@ripnet.com 
> <mailto:mle...@ripnet.com>> wrote:
>
>     On 09/20/2016 07:54 PM, Morgan Redfield wrote:
>>     There's no VM.
>>
>>     I realize that it's always VRT over USB, but I'm curious why we
>>     only get VRT errors if we use sc12, and not if we use sc16.
>     That may just be because of the way SC12 are packed on the wire,
>     with a dropped frame "slicing" one of these down the middle.
>
>>
>>     Is there a standard way of optimizing linux to run with an SSD
>>     for gnuradio or the USRP?
>     Have you tried uhd_rx_cfile, instead of your own flow-graph?
>
>     There's a write-behind cache configuration item for the kernel
>     that controls how much of main memory gets used for the disk
>       write-behind cache.  If this cache is large, it might take quite
>     a while for it to flush it to disk all in one gulp, thus causing
>       some scheduling difficulties.  I just can't off the top of my
>     head remember what it's called :(
>
>     Have you actually tested the write performance of your filesystem
>     outside of gnu radio?
>
>
>
>>
>>     On Tue, Sep 20, 2016 at 4:09 PM, Marcus D. Leech
>>     <mle...@ripnet.com <mailto:mle...@ripnet.com>> wrote:
>>
>>         On 09/20/2016 06:42 PM, Morgan Redfield via USRP-users wrote:
>>>         We're using a USRP B200 to collect data for post processing.
>>>         Our flowgraph is just a USRP source connected to a filesink.
>>>         We're using a 1MHz sample rate. Ultimately, we'd like to be
>>>         able to record data for 15 to 20 minutes with no dropped
>>>         samples.
>>>
>>>         Every once in a while, we see data overruns ('O's appear in
>>>         the terminal when we're sampling). To avoid this, we
>>>         attempted to use sc12 for the otw format in order to reduce
>>>         the length of data being sent from the USRP.
>>>
>>>         When I have otw_format set to 'sc12', then I get this error
>>>         after some time recording:
>>>
>>>         UHD Error:
>>>             The receive packet handler caught a value exception.
>>>             ValueError: bad vrt header or packet fragment
>>>         WARN: USRP Source Block caught rx error code: 15
>>>         DO
>>>
>>>         So it looks like there's an overflow and a dropped packet.
>>>
>>>         So I have two questions:
>>>         1. What's the best way to avoid dropping samples?
>>>         2. Why are we getting VRT packet errors if we use 'sc12' as
>>>         the OTW format?
>>         VRT == Vita49 Radio Transport --- those headers are present
>>         regardless of the wire format.
>>
>>         With 1Msps, you shouldn't ever be experiencing overruns.  My
>>         guess is that your SSD doesn't actually perform at its rated
>>         speed.
>>           Also, are you running this on a real, or VM setup?
>>
>>
>>>
>>>         Thanks for any help you can give,
>>>         Morgan
>>>
>>>         System details:
>>>         USRP B200 connected over USB3.0
>>>         Computer:
>>>         - SSD with 458MB/sec sequential write speeds
>>>         - 16GB swap space
>>>         - 16GB RAM
>>>         - 3.8GHz Intel I7 processor
>>>         - Ubuntu 16.04
>>>         - GNURadio version 3.7.10.1
>>>
>>>
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160920/7ff836b4/attachment-0001.html>

------------------------------

Message: 12
Date: Wed, 21 Sep 2016 01:56:52 -0400
From: Anon Lister <listera...@gmail.com>
To: Morgan Redfield <mredfi...@m42tech.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] best way to avoid dropped samples
Message-ID:
        <camp204tkx3_bk+akeqhr3h-ypvoj_-xs6ymetacmn+z4t_g...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Have you seen this[1] 2015 GRCon presentation? They go over their tool,
specrec[2], which basically uses synchronous writes to stream data to disk
to avoid writing a big buffer from memory to disk at once.

I've has very good luck with it as opposed to the rx_cfile example app.
With rx cfile I can do 20Meg sample rate saves with very infrequent dropped
samples. With specrec, I can do 50Meg sample rate captures with no samples
dropped for as long as I've tried on my laptop.

Could be something to try before you go tweaking your OS (even if you could
achieve a similar result playing with OS buffer sizes.)

[1] http://www.trondeau.com/s/5-lincoln_orin-gr_analysis-2015-08-26.pdf
[2] https://github.com/garverp/gr-analysis

On Sep 20, 2016 9:00 PM, "Morgan Redfield via USRP-users" <
usrp-users@lists.ettus.com> wrote:

> I just tested the write performance of my filesystem, and I got sequential
> write speeds of 434MB/s.
>
> After that I tried uhd_rx_cfile for a 10min collect, and I did get one 'O'
> during that collection. We based our rx script on the uhd_rx_cfile and just
> added some switches for timed receive, so I'm not surprised we're getting
> the same behavior with the original.
>
> Are the write-behind configurations related to these?
> /proc/sys/vm/dirty_ratio
> /proc/sys/vm/dirty_background_ratio
>
> Do you have a suggestion for where they should be set?
>
>
> On Tue, Sep 20, 2016 at 5:01 PM, Marcus D. Leech <mle...@ripnet.com>
> wrote:
>
>> On 09/20/2016 07:54 PM, Morgan Redfield wrote:
>>
>> There's no VM.
>>
>> I realize that it's always VRT over USB, but I'm curious why we only get
>> VRT errors if we use sc12, and not if we use sc16.
>>
>> That may just be because of the way SC12 are packed on the wire, with a
>> dropped frame "slicing" one of these down the middle.
>>
>>
>> Is there a standard way of optimizing linux to run with an SSD for
>> gnuradio or the USRP?
>>
>> Have you tried uhd_rx_cfile, instead of your own flow-graph?
>>
>> There's a write-behind cache configuration item for the kernel that
>> controls how much of main memory gets used for the disk
>>   write-behind cache.  If this cache is large, it might take quite a
>> while for it to flush it to disk all in one gulp, thus causing
>>   some scheduling difficulties.  I just can't off the top of my head
>> remember what it's called :(
>>
>> Have you actually tested the write performance of your filesystem outside
>> of gnu radio?
>>
>>
>>
>>
>> On Tue, Sep 20, 2016 at 4:09 PM, Marcus D. Leech <mle...@ripnet.com>
>> wrote:
>>
>>> On 09/20/2016 06:42 PM, Morgan Redfield via USRP-users wrote:
>>>
>>> We're using a USRP B200 to collect data for post processing. Our
>>> flowgraph is just a USRP source connected to a filesink. We're using a 1MHz
>>> sample rate. Ultimately, we'd like to be able to record data for 15 to 20
>>> minutes with no dropped samples.
>>>
>>> Every once in a while, we see data overruns ('O's appear in the terminal
>>> when we're sampling). To avoid this, we attempted to use sc12 for the otw
>>> format in order to reduce the length of data being sent from the USRP.
>>>
>>> When I have otw_format set to 'sc12', then I get this error after some
>>> time recording:
>>>
>>> UHD Error:
>>>     The receive packet handler caught a value exception.
>>>     ValueError: bad vrt header or packet fragment
>>> WARN: USRP Source Block caught rx error code: 15
>>> DO
>>>
>>> So it looks like there's an overflow and a dropped packet.
>>>
>>> So I have two questions:
>>> 1. What's the best way to avoid dropping samples?
>>> 2. Why are we getting VRT packet errors if we use 'sc12' as the OTW
>>> format?
>>>
>>> VRT == Vita49 Radio Transport --- those headers are present regardless
>>> of the wire format.
>>>
>>> With 1Msps, you shouldn't ever be experiencing overruns.  My guess is
>>> that your SSD doesn't actually perform at its rated speed.
>>>   Also, are you running this on a real, or VM setup?
>>>
>>>
>>>
>>> Thanks for any help you can give,
>>> Morgan
>>>
>>> System details:
>>> USRP B200 connected over USB3.0
>>> Computer:
>>> - SSD with 458MB/sec sequential write speeds
>>> - 16GB swap space
>>> - 16GB RAM
>>> - 3.8GHz Intel I7 processor
>>> - Ubuntu 16.04
>>> - GNURadio version 3.7.10.1
>>>
>>>
>>>
>>>
>>
>>
>
> _______________________________________________
> 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/20160921/0b207a0c/attachment-0001.html>

------------------------------

Message: 13
Date: Wed, 21 Sep 2016 10:16:09 -0400
From: Michael Wentz <mchlw...@gmail.com>
To: Michael West <michael.w...@ettus.com>
Cc: "Marcus D. Leech" <mle...@ripnet.com>,
        "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] UBX-160 Performance < 500 MHz
Message-ID:
        <caftrpl1ydfsuqx2hc-sdu2cw48bbbvk8oyhbzcriyrq1z9h...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Michael,

Thanks again for the feedback. The testing I was doing was with the latest
version of UHD, and when I went back to the version I'm developing on I
noticed the dboard_clock_rate argument did not exist. It looks like I can
just change X300_DEFAULT_DBOARD_CLK_RATE from 50e6 to 20e6
in x300_clock_ctrl.cpp, but am wondering if that could have any unintended
side effects and/or there were also respective FPGA modifications to make
the 20 MHz rate a possibility? I'm only planning on using the UBX and
frequencies < 500 MHz.

-Michael

On Tue, Sep 20, 2016 at 1:05 PM, Michael West <michael.w...@ettus.com>
wrote:

> Hi Michael,
>
> I'm glad to hear that made a substantial improvement.
>
> We need to update the documentation with the dboard_clock_rate parameter
> information and we will do that.  The MAX2871 synthesizer used on the UBX
> has proven to be a bit touchy and has required a lot of special settings to
> perform properly.  The default dboard_clock_rate on the X310 is 50 MHz,
> which is the ideal PFD frequency for the UBX.  For frequencies under 1 GHz,
> we have found it necessary to reduce the dboard_clock_rate to 20 MHz due to
> several limitations in the MAX2871.
>
> We looked into setting the dboard_clock_rate automatically in UHD, but it
> is a non-trivial exercise because it is dependent on the user's intended
> use.  Changing the dboard_clock_rate dynamically whenever the user
> application changes the frequency presents a host of other potential
> problems, not to mention what to do if there are 2 different types of
> daughterboards in the USRP.
>
> Regards,
> Michael
>
>
>
> On Tue, Sep 20, 2016 at 4:55 AM, Michael Wentz <mchlw...@gmail.com> wrote:
>
>> Hi Michael,
>>
>> Adding "dboard_clock_rate=20e6" made a significant difference - the
>> spurs and odd shape in the noise floor are both gone, image attached. I did
>> the same type of measurement and it was around 75 dB SFDR, almost a 20 dB
>> improvement.
>>
>> I had never heard of the dboard_clock_rate argument before. Are there
>> any implications of setting that to 20 MHz and using the default master
>> clock rate of 200 MHz? Also, is there a reason that UHD wouldn't know to
>> use that number by default (based on the fact that I'm using a UBX < 1 GHz)?
>>
>> Thanks,
>> Michael
>>
>> On Mon, Sep 19, 2016 at 9:34 PM, Michael West <michael.w...@ettus.com>
>> wrote:
>>
>>> Hi Michael,
>>>
>>> We do recommend a lower dboard clock rate for frequencies below 1 GHz on
>>> the UBX (for better LO performance).  Can you try adding
>>> 'dboard_clock_rate=20e6' to your device arguments and see if there is any
>>> change?
>>>
>>> It is odd that introducing a signal causes the noise floor to rise.  I
>>> will run this by the hardware engineer for the UBX and see if he has any
>>> ideas.
>>>
>>> Regards,
>>> Michael West
>>>
>>> On Mon, Sep 19, 2016 at 5:19 PM, Michael Wentz via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
>>>> I'm using the latest commit on rfnoc-devel, built today. I can also try
>>>> without RFNoC but figured it would be identical since the master branch was
>>>> merged in 10 days ago.
>>>>
>>>> On Mon, Sep 19, 2016 at 8:15 PM, Marcus D. Leech <mle...@ripnet.com>
>>>> wrote:
>>>>
>>>>> On 09/19/2016 06:30 PM, Michael Wentz wrote:
>>>>>
>>>>> Hi Marcus,
>>>>>
>>>>> Thanks for the feedback. Yes, I've tried gain ranges 0 to 31.5 - I'm
>>>>> intending to use an external LNA so was searching for settings where these
>>>>> issues were minimized, but they were fairly consistent across the gain
>>>>> range. I've also tried a variety of input signal strengths, usually around
>>>>> 30-40 dB below IIP3.
>>>>>
>>>>> I'm aware of the two RF chains and there is a noticeable performance
>>>>> difference < 500 MHz in the data on files.ettus.com, but nothing that
>>>>> informed me about the spurious content and odd behavior of the noise floor
>>>>> when there's a signal applied.
>>>>>
>>>>> Is the UBX design more optimized for higher frequencies? Wondering if
>>>>> I should have gone with the WBX-120 here.
>>>>>
>>>>> -Michael
>>>>>
>>>>> The UBX design is optimized for its entire frequency range.
>>>>>
>>>>> What version of UHD are you using?
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Sep 19, 2016 at 6:03 PM, Marcus D. Leech via USRP-users <
>>>>> usrp-users@lists.ettus.com> wrote:
>>>>>
>>>>>> On 09/19/2016 02:58 PM, Michael Wentz via USRP-users wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I am working with an X310 and UBX-160 with the latest version of
>>>>>>> UHD. I've started to characterize the performance a bit at frequencies 
>>>>>>> I'm
>>>>>>> interested in (< 500 MHz), and while trying to determine full range I
>>>>>>> noticed strange behavior compared to the WBX and SBX. Attached are some
>>>>>>> screen shots from measurements I made at 400 MHz with full gain (31.5) 
>>>>>>> on
>>>>>>> the WBX-40, SBX-120, and UBX-160. I'm just eye balling the SDFR and 
>>>>>>> picking
>>>>>>> the most noticeable spur away from the carrier, nothing really precise.
>>>>>>>
>>>>>>> WBX-40 : input power -15 dBm, SFDR around 76 dB
>>>>>>> SBX-120: input power -34 dBm, SFDR around 82 dB
>>>>>>> UBX-120: input power -32 dBm, SFDR around 56 dB
>>>>>>>
>>>>>>> I also noticed on the UBX that there is a significant increase in
>>>>>>> the noise floor when an input signal is applied, even if that input is
>>>>>>> 20-30 dB below where the input would clip. I've verified with test
>>>>>>> equipment that the noise floor is not from my signal source. 
>>>>>>> Additionally,
>>>>>>> I did some measurements at 600 MHz and 1 GHz and saw much better
>>>>>>> performance, in line with the WBX/SBX.
>>>>>>>
>>>>>>> Is any of this expected? Is there anything I can do to improve the
>>>>>>> performance?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Michael
>>>>>>>
>>>>>>>
>>>>>>> Two quick comments.
>>>>>>
>>>>>> The first is that the analog RF chain on UBX is *very* different from
>>>>>> SBX/WBX (which are almost identical, BTW, except for mixers).
>>>>>>
>>>>>> The second is a question.  Have you tried dropping the gain on the
>>>>>> UBX?  Have you tried lowering the signal level?  The UBX has two
>>>>>>   different RF chains, with 500Mhz being the dividing line between
>>>>>> the two.   So I would expect there to be not-subtle differences in things
>>>>>>   like OIP3, p1dB, etc.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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/20160921/bc0740bb/attachment-0001.html>

------------------------------

Message: 14
Date: Wed, 21 Sep 2016 07:23:41 -0700
From: Michael West <michael.w...@ettus.com>
To: Michael Wentz <mchlw...@gmail.com>
Cc: "Marcus D. Leech" <mle...@ripnet.com>,
        "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] UBX-160 Performance < 500 MHz
Message-ID:
        <CAM4xKrrDn9iDGn+KoMMuwNrwGikh5ZZUJEyiukyEGTU=na6...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi Michael,

There were no FPGA modifications to change the clock rate.  And yes, you
can just change the X300_DEFAULT_DBOARD_CLK_RATE to suit your needs in the
earlier version of UHD.  There should be no unintended side effects because
the clock configured by that parameter only goes to the LOs on the
daughterboards.

Regards,
Michael

On Wed, Sep 21, 2016 at 7:16 AM, Michael Wentz <mchlw...@gmail.com> wrote:

> Michael,
>
> Thanks again for the feedback. The testing I was doing was with the latest
> version of UHD, and when I went back to the version I'm developing on I
> noticed the dboard_clock_rate argument did not exist. It looks like I can
> just change X300_DEFAULT_DBOARD_CLK_RATE from 50e6 to 20e6
> in x300_clock_ctrl.cpp, but am wondering if that could have any unintended
> side effects and/or there were also respective FPGA modifications to make
> the 20 MHz rate a possibility? I'm only planning on using the UBX and
> frequencies < 500 MHz.
>
> -Michael
>
> On Tue, Sep 20, 2016 at 1:05 PM, Michael West <michael.w...@ettus.com>
> wrote:
>
>> Hi Michael,
>>
>> I'm glad to hear that made a substantial improvement.
>>
>> We need to update the documentation with the dboard_clock_rate parameter
>> information and we will do that.  The MAX2871 synthesizer used on the UBX
>> has proven to be a bit touchy and has required a lot of special settings to
>> perform properly.  The default dboard_clock_rate on the X310 is 50 MHz,
>> which is the ideal PFD frequency for the UBX.  For frequencies under 1 GHz,
>> we have found it necessary to reduce the dboard_clock_rate to 20 MHz due to
>> several limitations in the MAX2871.
>>
>> We looked into setting the dboard_clock_rate automatically in UHD, but it
>> is a non-trivial exercise because it is dependent on the user's intended
>> use.  Changing the dboard_clock_rate dynamically whenever the user
>> application changes the frequency presents a host of other potential
>> problems, not to mention what to do if there are 2 different types of
>> daughterboards in the USRP.
>>
>> Regards,
>> Michael
>>
>>
>>
>> On Tue, Sep 20, 2016 at 4:55 AM, Michael Wentz <mchlw...@gmail.com>
>> wrote:
>>
>>> Hi Michael,
>>>
>>> Adding "dboard_clock_rate=20e6" made a significant difference - the
>>> spurs and odd shape in the noise floor are both gone, image attached. I did
>>> the same type of measurement and it was around 75 dB SFDR, almost a 20 dB
>>> improvement.
>>>
>>> I had never heard of the dboard_clock_rate argument before. Are there
>>> any implications of setting that to 20 MHz and using the default master
>>> clock rate of 200 MHz? Also, is there a reason that UHD wouldn't know to
>>> use that number by default (based on the fact that I'm using a UBX < 1 GHz)?
>>>
>>> Thanks,
>>> Michael
>>>
>>> On Mon, Sep 19, 2016 at 9:34 PM, Michael West <michael.w...@ettus.com>
>>> wrote:
>>>
>>>> Hi Michael,
>>>>
>>>> We do recommend a lower dboard clock rate for frequencies below 1 GHz
>>>> on the UBX (for better LO performance).  Can you try adding
>>>> 'dboard_clock_rate=20e6' to your device arguments and see if there is any
>>>> change?
>>>>
>>>> It is odd that introducing a signal causes the noise floor to rise.  I
>>>> will run this by the hardware engineer for the UBX and see if he has any
>>>> ideas.
>>>>
>>>> Regards,
>>>> Michael West
>>>>
>>>> On Mon, Sep 19, 2016 at 5:19 PM, Michael Wentz via USRP-users <
>>>> usrp-users@lists.ettus.com> wrote:
>>>>
>>>>> I'm using the latest commit on rfnoc-devel, built today. I can also
>>>>> try without RFNoC but figured it would be identical since the master 
>>>>> branch
>>>>> was merged in 10 days ago.
>>>>>
>>>>> On Mon, Sep 19, 2016 at 8:15 PM, Marcus D. Leech <mle...@ripnet.com>
>>>>> wrote:
>>>>>
>>>>>> On 09/19/2016 06:30 PM, Michael Wentz wrote:
>>>>>>
>>>>>> Hi Marcus,
>>>>>>
>>>>>> Thanks for the feedback. Yes, I've tried gain ranges 0 to 31.5 - I'm
>>>>>> intending to use an external LNA so was searching for settings where 
>>>>>> these
>>>>>> issues were minimized, but they were fairly consistent across the gain
>>>>>> range. I've also tried a variety of input signal strengths, usually 
>>>>>> around
>>>>>> 30-40 dB below IIP3.
>>>>>>
>>>>>> I'm aware of the two RF chains and there is a noticeable performance
>>>>>> difference < 500 MHz in the data on files.ettus.com, but nothing
>>>>>> that informed me about the spurious content and odd behavior of the noise
>>>>>> floor when there's a signal applied.
>>>>>>
>>>>>> Is the UBX design more optimized for higher frequencies? Wondering if
>>>>>> I should have gone with the WBX-120 here.
>>>>>>
>>>>>> -Michael
>>>>>>
>>>>>> The UBX design is optimized for its entire frequency range.
>>>>>>
>>>>>> What version of UHD are you using?
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Sep 19, 2016 at 6:03 PM, Marcus D. Leech via USRP-users <
>>>>>> usrp-users@lists.ettus.com> wrote:
>>>>>>
>>>>>>> On 09/19/2016 02:58 PM, Michael Wentz via USRP-users wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I am working with an X310 and UBX-160 with the latest version of
>>>>>>>> UHD. I've started to characterize the performance a bit at frequencies 
>>>>>>>> I'm
>>>>>>>> interested in (< 500 MHz), and while trying to determine full range I
>>>>>>>> noticed strange behavior compared to the WBX and SBX. Attached are some
>>>>>>>> screen shots from measurements I made at 400 MHz with full gain (31.5) 
>>>>>>>> on
>>>>>>>> the WBX-40, SBX-120, and UBX-160. I'm just eye balling the SDFR and 
>>>>>>>> picking
>>>>>>>> the most noticeable spur away from the carrier, nothing really precise.
>>>>>>>>
>>>>>>>> WBX-40 : input power -15 dBm, SFDR around 76 dB
>>>>>>>> SBX-120: input power -34 dBm, SFDR around 82 dB
>>>>>>>> UBX-120: input power -32 dBm, SFDR around 56 dB
>>>>>>>>
>>>>>>>> I also noticed on the UBX that there is a significant increase in
>>>>>>>> the noise floor when an input signal is applied, even if that input is
>>>>>>>> 20-30 dB below where the input would clip. I've verified with test
>>>>>>>> equipment that the noise floor is not from my signal source. 
>>>>>>>> Additionally,
>>>>>>>> I did some measurements at 600 MHz and 1 GHz and saw much better
>>>>>>>> performance, in line with the WBX/SBX.
>>>>>>>>
>>>>>>>> Is any of this expected? Is there anything I can do to improve the
>>>>>>>> performance?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Michael
>>>>>>>>
>>>>>>>>
>>>>>>>> Two quick comments.
>>>>>>>
>>>>>>> The first is that the analog RF chain on UBX is *very* different
>>>>>>> from SBX/WBX (which are almost identical, BTW, except for mixers).
>>>>>>>
>>>>>>> The second is a question.  Have you tried dropping the gain on the
>>>>>>> UBX?  Have you tried lowering the signal level?  The UBX has two
>>>>>>>   different RF chains, with 500Mhz being the dividing line between
>>>>>>> the two.   So I would expect there to be not-subtle differences in 
>>>>>>> things
>>>>>>>   like OIP3, p1dB, etc.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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/20160921/7f889b8a/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 73, Issue 19
******************************************

Reply via email to