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: FPGA code (Jonathon Pendlum)
2. UBX-160 Performance < 500 MHz (Michael Wentz)
3. Re: UHD 3.10.0.0 bugs with X310/UBX-160 (Michael West)
4. Re: UHD 3.10.0.0 bugs with X310/UBX-160 (Rob Kossler)
5. Re: UBX-160 Performance < 500 MHz (Marcus D. Leech)
6. Re: UBX-160 Performance < 500 MHz (Michael Wentz)
7. Re: UHD 3.10.0.0 bugs with X310/UBX-160 (Michael West)
8. Re: UBX-160 Performance < 500 MHz (Marcus D. Leech)
9. Re: UBX-160 Performance < 500 MHz (Michael Wentz)
10. Re: UBX-160 Performance < 500 MHz (Michael West)
11. Re: Example code for a pair of TwinRXs (Derek Kozel)
12. Re: Example code for a pair of TwinRXs (Marcus D. Leech)
13. Building UHD for USRP E310 Without Radio (Walter Maguire)
14. Re: USRP-users Digest, Vol 73, Issue 7 (Walter Maguire)
15. Re: UBX-160 Performance < 500 MHz (Michael Wentz)
16. Re: Example code for a pair of TwinRXs (d.des)
17. Re: Example code for a pair of TwinRXs (d.des)
18. Re: Example code for a pair of TwinRXs (ti...@comcast.net)
----------------------------------------------------------------------
Message: 1
Date: Mon, 19 Sep 2016 11:53:23 -0500
From: Jonathon Pendlum <jonathon.pend...@ettus.com>
To: Lihua Ren <anything...@163.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] FPGA code
Message-ID:
<CAGdo0uSdQkTGpnd3y_3tAXXsy8rA3nhBi97Z2bkCaQ9=gl2...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
Did you try running 'make GUI=1 X310_HG_RFNOC' in usrp3_rfnoc/top/x300 and
then saving the project file in the Vivado GUI after the project finishes
building?
Jonathon
On Mon, Sep 19, 2016 at 4:24 AM, Lihua Ren via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi,
>
> I will creat a usrp3_rfnoc Vivado project for building the X310 FPGA using
> the source files provided in Git.I am able to build ,but there are had
> erros,which have many top-level. using the command line or adding files
> directly. I have tried these methods but have a problem.Can you tell me how
> to creat the project?
>
> Thanks
>
>
>
>
>
> _______________________________________________
> 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/20160919/48376bc5/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 19 Sep 2016 14:58:27 -0400
From: Michael Wentz <mchlw...@gmail.com>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] UBX-160 Performance < 500 MHz
Message-ID:
<caftrpl2hdtu+8z9uqgts38kzpnj+x9jxoz1vjjzwtjq7s9c...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160919/e2b324e4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sbx.png
Type: image/png
Size: 36142 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160919/e2b324e4/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ubx.png
Type: image/png
Size: 36661 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160919/e2b324e4/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wbx.png
Type: image/png
Size: 36034 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160919/e2b324e4/attachment-0005.png>
------------------------------
Message: 3
Date: Mon, 19 Sep 2016 12:52:40 -0700
From: Michael West <michael.w...@ettus.com>
To: Rob Kossler <rkoss...@nd.edu>
Cc: Martin Braun <martin.br...@ettus.com>,
"usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] UHD 3.10.0.0 bugs with X310/UBX-160
Message-ID:
<CAM4xKrpogE3=bmynmyozn-knqs5ztx4lokrki3w2f2guhbg...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Rob,
We are back in full force this week and looking into the issues you
raised. I have reproduced the first issue and we are looking into it now.
We have an idea of what may be happening, but we need to confirm. I will
try to reproduce the second issue later today. Thanks for the detailed
description and sample code!
Regards,
Michael
On Wed, Sep 14, 2016 at 6:13 PM, Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Thanks Martin,
> I agree with the FIFO explanation and that is what I was trying to
> indicate in my most recent post. But, that issue was really just a side
> issue and is not what is holding me up. The issues with the tx_streamer
> and the tuning issues that I described are my true issues.
>
> Rob
>
> On Wed, Sep 14, 2016 at 1:03 PM, Martin Braun via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On 09/12/2016 01:21 PM, Marcus D. Leech via USRP-users wrote:
>> > On 09/12/2016 11:58 AM, Rob Kossler via USRP-users wrote:
>> >> Yes, it appears that there are timing differences. I inserted a few
>> >> lines of code in my application software to query the PC clock before
>> >> and after streaming in order to estimate the data rate. In my example
>> >> the transmission duration was ~10 secs and the specified TX sample
>> >> rate was 25 MS/s (X310/UBX160, default MCR, internal ref). For UHD
>> >> 3.9.5, I ran 3 tests and the estimated sample rate was approx 25.039
>> >> MS/s in all cases. For UHD 3.10.0, I ran 3 tests and the estimated
>> >> sample rate was approx 25.853 MS/s in all cases. Thus, in my
>> >> experiments, UHD 3.10.0 is sending about 3.25% more samples in the
>> >> same amount of time.
>> > I'm having a hard time understanding how the apparent sample-rate could
>> > be "out" by 3.25%. I wonder if this is just a measurement anomaly,
>> > and that if you measure for longer periods, whether it converges on
>> > the expect ~10.0Msps ? You are using the standard master-clock
>> > rate, with standard firmware?
>>
>> In 3.10, the X310 has a huge FIFO on the Tx side (32 MB, compared to < 1
>> MB for 3.9.5). If you want to send one second worth of data, you have
>> two choices: 1) Send 25e6 samples, which is pretty exact, or stop
>> sending data after 1 second, which is what benchmark_rate does.
>>
>> Now, if you send data for 1 second, you're relying on backpressure to
>> get the sample numbers right, but your FIFO will only backpressure once
>> it's full.
>> Here's a more extreme example: Say I transmit at 1 Msps, and I want to
>> transmit for one second. I will instruct my software to send as many
>> samples as possible for one second, then stop. What you will see is
>> approx. 9 Million samples going out (a bit less than that over 1 GigE).
>> That's because the DUC will consume 1e6 samples during one second, and
>> the DRAM will consume another 8e6 samples (== 32 MB). This is possible
>> because we can actually physically send data to the device at a rate
>> that's much higher than 1e6.
>>
>> This is not new -- only the size of the FIFO is much bigger now.
>> I think this is what you're seeing.
>>
>> Cheers,
>> Martin
>>
>> _______________________________________________
>> 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/20160919/7f20afd3/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 19 Sep 2016 17:43:52 -0400
From: Rob Kossler <rkoss...@nd.edu>
To: Michael West <michael.w...@ettus.com>
Cc: Martin Braun <martin.br...@ettus.com>,
"usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] UHD 3.10.0.0 bugs with X310/UBX-160
Message-ID:
<CAB__hTTzmhJ=b-cse6ygfnzkffyg3oi7yljqoafwrg6wxv8...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks Michael,
Regarding issue #2, I just took another look at the "terminal_output.txt"
attachment I sent. It appears that I mistakenly copy-and-pasted the
terminal output representing 3 successive runs rather than only 2 run as I
had intended. Thus, you can ignore the first run and only look at the
latter 2 runs. Of the latter 2 runs, the first produces the correct
spectrum while the second produces the incorrect spectrum. The terminal
output shows the exact command line parameters that I used. And, one other
thing, ignore the "UUUU". These are produced at the start of the transmit
but are not relevant to my issue.
Rob
On Mon, Sep 19, 2016 at 3:52 PM, Michael West <michael.w...@ettus.com>
wrote:
> Hi Rob,
>
> We are back in full force this week and looking into the issues you
> raised. I have reproduced the first issue and we are looking into it now.
> We have an idea of what may be happening, but we need to confirm. I will
> try to reproduce the second issue later today. Thanks for the detailed
> description and sample code!
>
> Regards,
> Michael
>
> On Wed, Sep 14, 2016 at 6:13 PM, Rob Kossler via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Thanks Martin,
>> I agree with the FIFO explanation and that is what I was trying to
>> indicate in my most recent post. But, that issue was really just a side
>> issue and is not what is holding me up. The issues with the tx_streamer
>> and the tuning issues that I described are my true issues.
>>
>> Rob
>>
>> On Wed, Sep 14, 2016 at 1:03 PM, Martin Braun via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> On 09/12/2016 01:21 PM, Marcus D. Leech via USRP-users wrote:
>>> > On 09/12/2016 11:58 AM, Rob Kossler via USRP-users wrote:
>>> >> Yes, it appears that there are timing differences. I inserted a few
>>> >> lines of code in my application software to query the PC clock before
>>> >> and after streaming in order to estimate the data rate. In my example
>>> >> the transmission duration was ~10 secs and the specified TX sample
>>> >> rate was 25 MS/s (X310/UBX160, default MCR, internal ref). For UHD
>>> >> 3.9.5, I ran 3 tests and the estimated sample rate was approx 25.039
>>> >> MS/s in all cases. For UHD 3.10.0, I ran 3 tests and the estimated
>>> >> sample rate was approx 25.853 MS/s in all cases. Thus, in my
>>> >> experiments, UHD 3.10.0 is sending about 3.25% more samples in the
>>> >> same amount of time.
>>> > I'm having a hard time understanding how the apparent sample-rate could
>>> > be "out" by 3.25%. I wonder if this is just a measurement anomaly,
>>> > and that if you measure for longer periods, whether it converges on
>>> > the expect ~10.0Msps ? You are using the standard master-clock
>>> > rate, with standard firmware?
>>>
>>> In 3.10, the X310 has a huge FIFO on the Tx side (32 MB, compared to < 1
>>> MB for 3.9.5). If you want to send one second worth of data, you have
>>> two choices: 1) Send 25e6 samples, which is pretty exact, or stop
>>> sending data after 1 second, which is what benchmark_rate does.
>>>
>>> Now, if you send data for 1 second, you're relying on backpressure to
>>> get the sample numbers right, but your FIFO will only backpressure once
>>> it's full.
>>> Here's a more extreme example: Say I transmit at 1 Msps, and I want to
>>> transmit for one second. I will instruct my software to send as many
>>> samples as possible for one second, then stop. What you will see is
>>> approx. 9 Million samples going out (a bit less than that over 1 GigE).
>>> That's because the DUC will consume 1e6 samples during one second, and
>>> the DRAM will consume another 8e6 samples (== 32 MB). This is possible
>>> because we can actually physically send data to the device at a rate
>>> that's much higher than 1e6.
>>>
>>> This is not new -- only the size of the FIFO is much bigger now.
>>> I think this is what you're seeing.
>>>
>>> Cheers,
>>> Martin
>>>
>>> _______________________________________________
>>> 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/20160919/2dbc108b/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 19 Sep 2016 18:03:18 -0400
From: "Marcus D. Leech" <mle...@ripnet.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] UBX-160 Performance < 500 MHz
Message-ID: <57e060a6.3090...@ripnet.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
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.
------------------------------
Message: 6
Date: Mon, 19 Sep 2016 18:30:10 -0400
From: Michael Wentz <mchlw...@gmail.com>
To: "Marcus D. Leech" <mle...@ripnet.com>
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] UBX-160 Performance < 500 MHz
Message-ID:
<caftrpl0vzyutp2dwyoqvgohhndpgrz5cueuw++s4fg0b5dd...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160919/5fd81878/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 19 Sep 2016 16:59:09 -0700
From: Michael West <michael.w...@ettus.com>
To: Rob Kossler <rkoss...@nd.edu>
Cc: Martin Braun <martin.br...@ettus.com>,
"usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] UHD 3.10.0.0 bugs with X310/UBX-160
Message-ID:
<cam4xkrpeza-hofap0st0zycxvnj8pmk7cfhpkzf77kmbxo1...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks, Rob. The short burst of U's at the beginning of transmission is a
known issue. We are ignoring that for now.
Issue #1 has to do with the destruction and recreation of the tx_streamer.
We are working on a permanent fix. In the meantime, you can work around
the issue by creating the tx_streamer once and re-using it. For the
tx_samples_from_file example, just make the stream_args and tx_stream
variables static (lines 44 and 45). That did the trick for me.
I have reproduced issue #2. It seems to be a combination of setting an LO
offset and a command time that causes it. It's as though the CORDIC
frequency does not gets set when a command time is set. We are digging
into it now.
Regards,
Michael
On Mon, Sep 19, 2016 at 2:43 PM, Rob Kossler <rkoss...@nd.edu> wrote:
> Thanks Michael,
> Regarding issue #2, I just took another look at the "terminal_output.txt"
> attachment I sent. It appears that I mistakenly copy-and-pasted the
> terminal output representing 3 successive runs rather than only 2 run as I
> had intended. Thus, you can ignore the first run and only look at the
> latter 2 runs. Of the latter 2 runs, the first produces the correct
> spectrum while the second produces the incorrect spectrum. The terminal
> output shows the exact command line parameters that I used. And, one other
> thing, ignore the "UUUU". These are produced at the start of the transmit
> but are not relevant to my issue.
>
> Rob
>
>
>
> On Mon, Sep 19, 2016 at 3:52 PM, Michael West <michael.w...@ettus.com>
> wrote:
>
>> Hi Rob,
>>
>> We are back in full force this week and looking into the issues you
>> raised. I have reproduced the first issue and we are looking into it now.
>> We have an idea of what may be happening, but we need to confirm. I will
>> try to reproduce the second issue later today. Thanks for the detailed
>> description and sample code!
>>
>> Regards,
>> Michael
>>
>> On Wed, Sep 14, 2016 at 6:13 PM, Rob Kossler via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Thanks Martin,
>>> I agree with the FIFO explanation and that is what I was trying to
>>> indicate in my most recent post. But, that issue was really just a side
>>> issue and is not what is holding me up. The issues with the tx_streamer
>>> and the tuning issues that I described are my true issues.
>>>
>>> Rob
>>>
>>> On Wed, Sep 14, 2016 at 1:03 PM, Martin Braun via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
>>>> On 09/12/2016 01:21 PM, Marcus D. Leech via USRP-users wrote:
>>>> > On 09/12/2016 11:58 AM, Rob Kossler via USRP-users wrote:
>>>> >> Yes, it appears that there are timing differences. I inserted a few
>>>> >> lines of code in my application software to query the PC clock before
>>>> >> and after streaming in order to estimate the data rate. In my
>>>> example
>>>> >> the transmission duration was ~10 secs and the specified TX sample
>>>> >> rate was 25 MS/s (X310/UBX160, default MCR, internal ref). For UHD
>>>> >> 3.9.5, I ran 3 tests and the estimated sample rate was approx 25.039
>>>> >> MS/s in all cases. For UHD 3.10.0, I ran 3 tests and the estimated
>>>> >> sample rate was approx 25.853 MS/s in all cases. Thus, in my
>>>> >> experiments, UHD 3.10.0 is sending about 3.25% more samples in the
>>>> >> same amount of time.
>>>> > I'm having a hard time understanding how the apparent sample-rate
>>>> could
>>>> > be "out" by 3.25%. I wonder if this is just a measurement anomaly,
>>>> > and that if you measure for longer periods, whether it converges on
>>>> > the expect ~10.0Msps ? You are using the standard master-clock
>>>> > rate, with standard firmware?
>>>>
>>>> In 3.10, the X310 has a huge FIFO on the Tx side (32 MB, compared to < 1
>>>> MB for 3.9.5). If you want to send one second worth of data, you have
>>>> two choices: 1) Send 25e6 samples, which is pretty exact, or stop
>>>> sending data after 1 second, which is what benchmark_rate does.
>>>>
>>>> Now, if you send data for 1 second, you're relying on backpressure to
>>>> get the sample numbers right, but your FIFO will only backpressure once
>>>> it's full.
>>>> Here's a more extreme example: Say I transmit at 1 Msps, and I want to
>>>> transmit for one second. I will instruct my software to send as many
>>>> samples as possible for one second, then stop. What you will see is
>>>> approx. 9 Million samples going out (a bit less than that over 1 GigE).
>>>> That's because the DUC will consume 1e6 samples during one second, and
>>>> the DRAM will consume another 8e6 samples (== 32 MB). This is possible
>>>> because we can actually physically send data to the device at a rate
>>>> that's much higher than 1e6.
>>>>
>>>> This is not new -- only the size of the FIFO is much bigger now.
>>>> I think this is what you're seeing.
>>>>
>>>> Cheers,
>>>> Martin
>>>>
>>>> _______________________________________________
>>>> 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/20160919/f52a0d7a/attachment-0001.html>
------------------------------
Message: 8
Date: Mon, 19 Sep 2016 20:15:45 -0400
From: "Marcus D. Leech" <mle...@ripnet.com>
To: Michael Wentz <mchlw...@gmail.com>
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] UBX-160 Performance < 500 MHz
Message-ID: <57e07fb1.30...@ripnet.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
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
> <http://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 <mailto: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 <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>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160919/8b158264/attachment-0001.html>
------------------------------
Message: 9
Date: Mon, 19 Sep 2016 20:19:31 -0400
From: Michael Wentz <mchlw...@gmail.com>
To: "Marcus D. Leech" <mle...@ripnet.com>
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] UBX-160 Performance < 500 MHz
Message-ID:
<caftrpl2c9vfdqg83f0sk+1tq-hczskdxosihscdh4aojvqb...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160919/ddb07a52/attachment-0001.html>
------------------------------
Message: 10
Date: Mon, 19 Sep 2016 18:34:03 -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:
<cam4xkrrpg55qskaudwiex_xsucr2lkcnfhokkk6ykt4t4m6...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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/20160919/204b11fd/attachment-0001.html>
------------------------------
Message: 11
Date: Mon, 19 Sep 2016 20:01:48 -0700
From: Derek Kozel <derek.ko...@ettus.com>
To: Samuel Dudley <dudley.sam...@gmail.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Example code for a pair of TwinRXs
Message-ID:
<CAA+K=tvhbztemm0wgoyiezu6ry3zvz0kkzogn6ybk+ofain...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Sam and Dave,
As Marcus mentioned I was at the GNU Radio conference last week. I have
several flowgraphs and a C++ example of using TwinRX. There have been some
improvements since the last time I posted examples and I will share those
to the list in the next few days as they are reviewed.
Two TwinRXs in an X300 series will provide repeatable, stable phase offsets
for a given frequency and gain when using the LO sharing. I looked at
Marcus' post and he was mistaken that TwinRX would have a zero degree phase
offset between channels. There will be a non zero phase offset between
channels due to the different electrical lengths the LOs must travel,
differences between the two channels on a single TwinRX, and normal
manufacturing variations in all the RF components. Once the boards reach
stable operating temperatures we observe very consistent phase offsets with
close to 0 drift. This means that you can calibrate your system once and
then apply that correction in the future without need for recalibration.
There have been several changes since the UHD 3.10.0.0 release which fix
situations where the phase offset could be non repeatable. These are
resolved and available at the head of maint. One of the changes was in the
FPGA so new images are required. I have them available and can send them to
you along with the reference examples. We will soon have a new release
incorporating the changes which will have the updated FPGA images included.
At GNU Radio Conference we demonstrated a direction finding system using
the MUSIC algorithm. The phase offsets were calibrated once at the start of
the week and then used for the next five days with good results. This code
will be available in the next few weeks.
Regards,
Derek
On Sun, Sep 18, 2016 at 8:23 PM, Samuel Dudley via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi,
> To add to the above request, I'm in the same situation (single X310 with
> 2 x TwinRX) but would prefer a gnuradio flow-graph demonstrating the 4
> channel phase coherent receive.
> Thanks,
> Sam
>
> On Sun, Sep 18, 2016 at 4:47 AM, d.des via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> > Derek Kozel is your "man" on this, and he and most of the Ettus R&D
>> team have been away this week at GRCon.
>>
>> > You should be able to use independent-LO+timed-commands to achieve
>> phase synchronization, but better is shared-LO mode, which is somewhat
>> complicated, and Derek can probably provide an example flow-graph when
>> he gets back from GRCon.
>>
>> Shared-LO seems like the right answer, so specific instructions for
>> setting that up would be good. I use the uhd API without Gnuradio but
>> could probably pull what I need from a flow graph if that's easiest.
>>
>>
>> >What type of interferometer? For astronomy, or something else?
>>
>> It's for angle of arrival logging of pulsed signals.
>>
>> _______________________________________________
>> 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/20160919/c7a2edb7/attachment-0001.html>
------------------------------
Message: 12
Date: Mon, 19 Sep 2016 23:24:35 -0400
From: "Marcus D. Leech" <mle...@ripnet.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Example code for a pair of TwinRXs
Message-ID: <57e0abf3.80...@ripnet.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 09/19/2016 11:01 PM, Derek Kozel via USRP-users wrote:
> Hello Sam and Dave,
>
> As Marcus mentioned I was at the GNU Radio conference last week. I
> have several flowgraphs and a C++ example of using TwinRX. There have
> been some improvements since the last time I posted examples and I
> will share those to the list in the next few days as they are reviewed.
>
> Two TwinRXs in an X300 series will provide repeatable, stable phase
> offsets for a given frequency and gain when using the LO sharing. I
> looked at Marcus' post and he was mistaken that TwinRX would have a
> zero degree phase offset between channels. There will be a non zero
> phase offset between channels due to the different electrical lengths
> the LOs must travel, differences between the two channels on a single
> TwinRX, and normal manufacturing variations in all the RF components.
> Once the boards reach stable operating temperatures we observe very
> consistent phase offsets with close to 0 drift. This means that you
> can calibrate your system once and then apply that correction in the
> future without need for recalibration.
I should have said, "except for repeatable phase-length differences".
Which there will always be, some of which will have receiver-hardware
contributions, and some will have external contributions. In any
phase-sensitive array, one has to calibrate the "systemic phase center".
In radio astronomy arrays, for example, it's very typical to calibrate
the current phase center of the array before every observation,
because cable lengths can change due to temperature, often
differentially, since cable runs are usually long, and therefore don't
have precisely the same thermal environment.
------------------------------
Message: 13
Date: Tue, 20 Sep 2016 15:01:38 +1000
From: Walter Maguire <wmagu...@iinet.net.au>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Building UHD for USRP E310 Without Radio
Message-ID: <b96f83b3-82f8-57a8-a51f-35b726725...@iinet.net.au>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi all,
I have been using the latest UHD rfnoc-devel release with the associated
uhd-fpga source. Having studied the FPGA design and UHD library
software it appears to me that the Radio Core is not treated like a
standard CE. It looks like the E3xx UHD driver always expects the Radio
to be present as per the checks to control the associated AD9361 part.
If the CE approach was fully adopted for the radio block then I would
assume that not building the radio block in the FPGA would result in the
enumeration of the RFNoC bus not finding the radio block with its
associated block id. Therefore the associated configuration of the
related AD9361 would not be run.
I would be grateful if someone would clarify that in order for the UHD
device driver to work with RFNoC that the associated radio block needs
to be present in the FPGA design. If this is case, are there any plans
to make the Radio block control and implementation to be the same as a
standard CE, such that if it is not present the driver still works.
Regards
Walter
------------------------------
Message: 14
Date: Tue, 20 Sep 2016 15:10:25 +1000
From: Walter Maguire <wmagu...@iinet.net.au>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP-users Digest, Vol 73, Issue 7
Message-ID: <cd538f6b-4616-486f-76e1-e8bbe98ae...@iinet.net.au>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi all,
As a follow-up to my question concerning using the Eclipse platform to
build and debug usrp I managed to do it by following the flow described
in this link.
https://cmake.org/Wiki/Eclipse_CDT4_Generator#In-Source_Builds
Whilst the project will build using this method, several references will
be missing. These can be fixed by altering the settings in the build
properties Processor Include PAths, Macros etc and adding CDT GCC
Built-in Compiler Settings [shared].
Regards
Walter
On 9/09/2016 2:00 AM, usrp-users-requ...@lists.ettus.com wrote:
> 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. Building init_usrp example with Eclipse. (Walter Maguire)
> 2. Processing on the FPGA (Wouter Kayser)
> 3. E310 FPGA build (Patel, Chintan)
> 4. Tx_time Tag (arled.p...@dlr.de)
> 5. trying to run make.py rfnoc command (Jason Matusiak)
> 6. Re: Building init_usrp example with Eclipse. (Martin Braun)
> 7. Re: Tx_time Tag (Steven Knudsen)
> 8. make.py include path bug (Jason Matusiak)
> 9. Re: trying to run make.py rfnoc command (Nicolas Cuervo)
> 10. Re: make.py include path bug (Nicolas Cuervo)
> 11. Re: trying to run make.py rfnoc command (Jason Matusiak)
> 12. UHD 3.10.0.0 bugs with X310/UBX-160 (Rob Kossler)
> 13. Re: UHD 3.10.0.0 bugs with X310/UBX-160 (mle...@ripnet.com)
> 14. get_stat(): unsupported GPS or no GPS detected (devin kelly)
> 15. Re: get_stat(): unsupported GPS or no GPS detected (Michael West)
> 16. Re: UHD 3.10.0 w/ USRP1 segfault (Paul David)
> 17. Re: E310 FPGA build (Marcus D. Leech)
> 18. Half Duplex RX toggling issue (Mitchell Overdick)
> 19. Re: Demuxer Error : Bad Frames (My Solution So Far)
> (Kevin McGuire)
> 20. Re: Demuxer Error : Bad Frames (My Solution So Far)
> (Kevin McGuire)
> 21. Re: Demuxer Error : Bad Frames (My Solution So Far)
> (Marcus D. Leech)
> 22. How would I change the the gain or low speed mode register in
> the RFNOC radio for the X310 or E310? (Swanson, Craig)
> 23. E310 filter banks frequency response (Crozzoli Maurizio)
> 24. Re: Tx_time Tag (arled.p...@dlr.de)
> 25. Re: E310 filter banks frequency response (Marcus D. Leech)
> 26. Re: Tx_time Tag (Steven Knudsen)
> 27. Re: Tx_time Tag (arled.p...@dlr.de)
> 28. newcomer problems with ettus n200 unit (Rolf Ragnarsson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 7 Sep 2016 19:21:38 +1000
> From: Walter Maguire <wmagu...@iinet.net.au>
> To: usrp-users@lists.ettus.com
> Subject: [USRP-users] Building init_usrp example with Eclipse.
> Message-ID: <060b3bea-fe70-3009-63ac-4307ac9c4...@iinet.net.au>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi all,
>
> I am experiencing some odd behavior when I try to build the init_usrp
> example in Eclipse.
>
> as can be seen from the Ubuntu console output there is no problem
> building the project using the cmake, make method.
>
> ~/prefix/rfnoc/src/uhd/host/examples/init_usrp/build$ cmake ../
> -- The C compiler identification is GNU 4.8.4
> -- The CXX compiler identification is GNU 4.8.4
> -- Check for working C compiler: /usr/bin/cc
> -- Check for working C compiler: /usr/bin/cc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Boost version: 1.54.0
> -- Found the following Boost libraries:
> -- program_options
> -- system
> -- thread
> -- Found PkgConfig: /usr/bin/pkg-config (found version "0.28")
> -- Found UHD: /usr/local/lib/libuhd.so (Required is at least version
> "3.8.0")
------------------------------
Message: 15
Date: Tue, 20 Sep 2016 07:55:20 -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:
<caftrpl3zvkapkgq-typeghncch6degc89qf+rtyg02tn_jv...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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/03022c50/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ubx_2.png
Type: image/png
Size: 38800 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160920/03022c50/attachment-0001.png>
------------------------------
Message: 16
Date: Tue, 20 Sep 2016 13:33:58 +0000
From: "d.des" <d....@sbcglobal.net>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Example code for a pair of TwinRXs
Message-ID: <1474378438.5449.30.ca...@sbcglobal.net>
Content-Type: text/plain; charset="UTF-8"
Marcus Leach said:
>I should have said, "except for repeatable phase-length
differences".??
>Which there will always be, some of which will have receiver-hardware
contributions, and some will have external contributions.??In any?
> phase-sensitive array, one has to calibrate the "systemic phase
center".
I'm expecting to see something like what I see with the B210, only with
four channels and lower phase noise. ?I haven't been able to evaluate
phase bias, though, since I still can't get four channels of time-
synced data. ?if I set stream_cmd.stream_now = true it records all of
the channels just fine but the second pair of channels seems to start
later than the first pair. ?If I set stream_cmd.stream_now = false and
give it a start time a few seconds in the future (as recommended) the
recv call won't return before timeout even though igot==iget indicating
that it's received all of the requested samples. ?Here's what I've
tried while waiting for a recommendation, ?Am I missing something?
BTW the same code works fine on the B210 if I remove the LO stuff and
change the subdev and the number of channels. ?Phase bias is minimal,
maybe because both channels are in one tiny chip.
///////////////////////////////
string args("");
string ref("internal");
string subdev("A:0 A:1 B:0 B:1");
uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args);
usrp->set_clock_source(ref);
usrp->set_rx_subdev_spec(subdev);
usrp->set_rx_lo_export_enabled(true,"all",0);
usrp->set_rx_lo_source("internal","all",0);
usrp->set_rx_lo_source("companion","all",1);
usrp->set_rx_lo_source("external","all",2);
usrp->set_rx_lo_source("external","all",3);
cout<<"Using Device "<<usrp->get_pp_string()<<" "<<nChans<<"
channels\n";
{
uhd::time_spec_t cmd_time = usrp->get_time_now() +
uhd::time_spec_t(0.1);
usrp->set_command_time(cmd_time);
for(int nChan=0;nChan<nChans;++nChan) {
usrp->set_rx_rate(rate, nChan);
}
usrp->clear_command_time();
}
{
uhd::time_spec_t cmd_time = usrp->get_time_now() +
uhd::time_spec_t(0.1);
usrp->set_command_time(cmd_time);
for(int nChan=0;nChan<nChans;++nChan) {
usrp->set_rx_gain(gain, nChan);
}
usrp->clear_command_time();
}
{
uhd::time_spec_t cmd_time = usrp->get_time_now() +
uhd::time_spec_t(0.1);
usrp->set_command_time(cmd_time);
for(int nChan=0;nChan<nChans;++nChan) {
usrp->set_rx_freq(freq, nChan);
}
usrp->clear_command_time();
}
usleep(1000000);
//TODO: check locked sensor
//create a receive streamer
uhd::stream_args_t stream_args("sc16","sc16");
std::vector<size_t> channel_nums;
channel_nums.push_back(0);
channel_nums.push_back(1);
channel_nums.push_back(2);
channel_nums.push_back(3);
stream_args.channels = channel_nums;
uhd::rx_streamer::sptr rx_stream = usrp->get_rx_stream(stream_args);
//setup streaming
uhd::stream_cmd_t
stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
stream_cmd.stream_now = false;
stream_cmd.time_spec = uhd::time_spec_t(usrp-
>get_time_now().get_full_secs()+3.0);
rx_stream->issue_stream_cmd(stream_cmd);
while(!done) {
igot = rx_stream->recv(IF, iget, md, 3.0, false);
//process four blocks of IF data
}
stream_cmd.stream_mode =
uhd::stream_cmd_t::STREAM_MODE_STOP_CONTINUOUS;
rx_stream->issue_stream_cmd(stream_cmd);
///////////////////////////////
------------------------------
Message: 17
Date: Tue, 20 Sep 2016 14:21:36 +0000
From: "d.des" <d....@sbcglobal.net>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Example code for a pair of TwinRXs
Message-ID: <1474381296.7204.8.ca...@sbcglobal.net>
Content-Type: text/plain; charset="UTF-8"
>There have been some
improvements since the last time I posted examples and I will share
those
to the list in the next few days as they are reviewed.
please do!
>There have been several changes since the UHD 3.10.0.0 release which
fix
situations where the phase offset could be non repeatable. These are
resolved and available at the head of maint. One of the changes was in
the
FPGA so new images are required. I have them available and can send
them to
you along with the reference examples. We will soon have a new release
incorporating the changes which will have the updated FPGA images
included.
again, please do! ?I just 'git'ed the latest maint. ?How do I get the
FPGA image?
>At GNU Radio Conference we demonstrated a direction finding system
using
the MUSIC algorithm.
Is there anything available from the presentations such as video or
charts?
------------------------------
Message: 18
Date: Tue, 20 Sep 2016 15:00:45 +0000 (UTC)
From: ti...@comcast.net
To: "d.des" <d....@sbcglobal.net>
Cc: usrp-users <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Example code for a pair of TwinRXs
Message-ID:
<1625063023.26382095.1474383645610.javamail.zim...@comcast.net>
Content-Type: text/plain; charset="utf-8"
Not sure if this will help you, but when we do timed receives in the near
future (+10 seconds) and then stream constantly for an extended period, we set
the timeout for the first receive to be based on the scheduled future start
time (+15 seconds) and for subsequent receives, use a more traditional timeout
parameter value (0.1 seconds)...
----- Original Message -----
From: "d.des via USRP-users" <usrp-users@lists.ettus.com>
To: "usrp-users" <usrp-users@lists.ettus.com>
Sent: Tuesday, September 20, 2016 9:33:58 AM
Subject: Re: [USRP-users] Example code for a pair of TwinRXs
Marcus Leach said:
>I should have said, "except for repeatable phase-length
differences".
>Which there will always be, some of which will have receiver-hardware
contributions, and some will have external contributions. In any
> phase-sensitive array, one has to calibrate the "systemic phase
center".
I'm expecting to see something like what I see with the B210, only with
four channels and lower phase noise. I haven't been able to evaluate
phase bias, though, since I still can't get four channels of time-
synced data. if I set stream_cmd.stream_now = true it records all of
the channels just fine but the second pair of channels seems to start
later than the first pair. If I set stream_cmd.stream_now = false and
give it a start time a few seconds in the future (as recommended) the
recv call won't return before timeout even though igot==iget indicating
that it's received all of the requested samples. Here's what I've
tried while waiting for a recommendation, Am I missing something?
BTW the same code works fine on the B210 if I remove the LO stuff and
change the subdev and the number of channels. Phase bias is minimal,
maybe because both channels are in one tiny chip.
///////////////////////////////
string args("");
string ref("internal");
string subdev("A:0 A:1 B:0 B:1");
uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args);
usrp->set_clock_source(ref);
usrp->set_rx_subdev_spec(subdev);
usrp->set_rx_lo_export_enabled(true,"all",0);
usrp->set_rx_lo_source("internal","all",0);
usrp->set_rx_lo_source("companion","all",1);
usrp->set_rx_lo_source("external","all",2);
usrp->set_rx_lo_source("external","all",3);
cout<<"Using Device "<<usrp->get_pp_string()<<" "<<nChans<<"
channels\n";
{
uhd::time_spec_t cmd_time = usrp->get_time_now() +
uhd::time_spec_t(0.1);
usrp->set_command_time(cmd_time);
for(int nChan=0;nChan<nChans;++nChan) {
usrp->set_rx_rate(rate, nChan);
}
usrp->clear_command_time();
}
{
uhd::time_spec_t cmd_time = usrp->get_time_now() +
uhd::time_spec_t(0.1);
usrp->set_command_time(cmd_time);
for(int nChan=0;nChan<nChans;++nChan) {
usrp->set_rx_gain(gain, nChan);
}
usrp->clear_command_time();
}
{
uhd::time_spec_t cmd_time = usrp->get_time_now() +
uhd::time_spec_t(0.1);
usrp->set_command_time(cmd_time);
for(int nChan=0;nChan<nChans;++nChan) {
usrp->set_rx_freq(freq, nChan);
}
usrp->clear_command_time();
}
usleep(1000000);
//TODO: check locked sensor
//create a receive streamer
uhd::stream_args_t stream_args("sc16","sc16");
std::vector<size_t> channel_nums;
channel_nums.push_back(0);
channel_nums.push_back(1);
channel_nums.push_back(2);
channel_nums.push_back(3);
stream_args.channels = channel_nums;
uhd::rx_streamer::sptr rx_stream = usrp->get_rx_stream(stream_args);
//setup streaming
uhd::stream_cmd_t
stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
stream_cmd.stream_now = false;
stream_cmd.time_spec = uhd::time_spec_t(usrp-
>get_time_now().get_full_secs()+3.0);
rx_stream->issue_stream_cmd(stream_cmd);
while(!done) {
igot = rx_stream->recv(IF, iget, md, 3.0, false);
//process four blocks of IF data
}
stream_cmd.stream_mode =
uhd::stream_cmd_t::STREAM_MODE_STOP_CONTINUOUS;
rx_stream->issue_stream_cmd(stream_cmd);
///////////////////////////////
_______________________________________________
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/1ff83afd/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 18
******************************************
