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. Function Probe: USRP1 vs N210 (Kathy Hertzog)
2. Re: UBX-160 Performance < 500 MHz (Michael West)
3. Re: Function Probe: USRP1 vs N210 (mle...@ripnet.com)
4. Re: Function Probe: USRP1 vs N210 (Kathy Hertzog)
5. Re: Function Probe: USRP1 vs N210 (Martin Braun)
6. Re: Example code for a pair of TwinRXs (d.des)
7. Re: Example code for a pair of TwinRXs (Derek Kozel)
8. Re: UHD loses GPS lock with "no GPRMC message found" - N210
and GPSDO (Martin Braun)
9. Re: Confirmation of ce_clk in rfnoc running in actual
hardware on the X310 (Swanson, Craig)
10. Re: Does time.sleep() affect PPS sync in E310? (Michael West)
11. Re: Does time.sleep() affect PPS sync in E310? (Lakshay Narula)
12. Re: Does time.sleep() affect PPS sync in E310? (Michael West)
13. Re: USRP-users Digest, Vol 73, Issue 20 (Walter Maguire)
14. USRP X310 connection problem (Kavyashree Tm)
15. Ignoring buffer overflows (Frank Liu)
16. Re: USRP X310 connection problem (Nate Temple)
17. Implementing design on FPGA in X310 (Nives Novkovi?)
----------------------------------------------------------------------
Message: 1
Date: Thu, 22 Sep 2016 09:33:40 -0700
From: Kathy Hertzog <kqhert...@gmail.com>
To: usrp-users <usrp-users@lists.ettus.com>
Subject: [USRP-users] Function Probe: USRP1 vs N210
Message-ID:
<cac9e-nf5_mo+cokgwq0gpptu6lw9tgmhsbmgyevsvdp6q4n...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I had a project working w/ two N210s (4 receivers) that used Function
Probes to access OOT methods to update a label in the GUI. For cost reasons
I'm going back to my USRP1 with two receiver boards, therefore 4 receivers.
Here's the UHD info:
Device Address: fpga=usrp1_fpga_4rx.rbf
Num Mboards = 1
Num Channels = 4
Mb0 Subdev Spec = B:A B:B A:A A:B
A simple GNURadio project with this UHD and my OOT block going directly
into 4 QT GUI function sinks (just to show that the outputs are valid)
works fine. With the N210 I also had function probes that called methods in
an OOT block. When I try to add this into a project with the USRP1 I'm
getting this error:
--------------------------------------------
-- Opening a USRP1 device...
-- Using FPGA clock rate of 64.000000MHz...
Traceback (most recent call last):
File "/home/superuser/MyGNURadio/Practice/function_block_test.py", line
377, in <module>
main()
File "/home/superuser/MyGNURadio/Practice/function_block_test.py", line
365, in main
tb = top_block_cls()
File "/home/superuser/MyGNURadio/Practice/function_block_test.py", line
94, in __init__
self.uhd_usrp_source_0.set_subdev_spec("B:A B:B A:A A:B", 0)
File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
line 2787, in set_subdev_spec
return _uhd_swig.usrp_source_sptr_set_subdev_spec(self, *args, **kwargs)
RuntimeError: ValueError: The subdevice specification "B:A B:B A:A A:B" is
too long.
The user specified 4 channels, but there are only 2 rx dsps on mboard 0.
--------------------------------------------------
If I disable the Function Probes then the project runs and the 4 outputs
are correct.
Also if I change the Num Channels in the UHD to 2 then it does work and the
Function Probe also does work.
Only with the function probe in the project does it complain about the
number of rx dsps on mboard 0.
Any help appreciated!
Kathy Hertzog
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160922/dc00664a/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 22 Sep 2016 09:39:55 -0700
From: Michael West <michael.w...@ettus.com>
To: "Perelman, Nathan" <nperel...@lgsinnovations.com>
Cc: Ben Hilburn via USRP-users <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] UBX-160 Performance < 500 MHz
Message-ID:
<cam4xkrruikkkcfspbecet6mgga2tt_oa1y9bvs8w7exw23c...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Nathan,
Yes. Both UBX-40 and UBX-160 are affected.
Regards,
Michael
On Thu, Sep 22, 2016 at 7:09 AM, Perelman, Nathan via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Does this affect the UBX-40 as well?
>
>
>
> *From:* USRP-users [mailto:usrp-users-boun...@lists.ettus.com] *On Behalf
> Of *Michael West via USRP-users
> *Sent:* Tuesday, September 20, 2016 1:05 PM
> *To:* Michael Wentz
> *Cc:* USRP-users@lists.ettus.com
> *Subject:* Re: [USRP-users] UBX-160 Performance < 500 MHz
>
>
>
> 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
>
>
>
>
>
>
>
> _______________________________________________
> 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/20160922/206366bb/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 22 Sep 2016 12:47:12 -0400
From: mle...@ripnet.com
To: Kathy Hertzog <kqhert...@gmail.com>
Cc: usrp-users <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Function Probe: USRP1 vs N210
Message-ID: <6a744041dbfe12d6fa8971d0f3a63...@ripnet.com>
Content-Type: text/plain; charset="us-ascii"
Could you simplify?
A simple graph with just the USRP1 source (with the 4rx FPGA image),
going to 4 NULL SINK ?
What happens then?
On 2016-09-22 12:33, Kathy Hertzog via USRP-users wrote:
> Hi, I had a project working w/ two N210s (4 receivers) that used Function
> Probes to access OOT methods to update a label in the GUI. For cost reasons
> I'm going back to my USRP1 with two receiver boards, therefore 4 receivers.
> Here's the UHD info:
>
> Device Address: fpga=usrp1_fpga_4rx.rbf
> Num Mboards = 1
> Num Channels = 4
> Mb0 Subdev Spec = B:A B:B A:A A:B
>
> A simple GNURadio project with this UHD and my OOT block going directly into
> 4 QT GUI function sinks (just to show that the outputs are valid) works fine.
> With the N210 I also had function probes that called methods in an OOT block.
> When I try to add this into a project with the USRP1 I'm getting this error:
>
> --------------------------------------------
>
> -- Opening a USRP1 device...
> -- Using FPGA clock rate of 64.000000MHz...
> Traceback (most recent call last):
> File "/home/superuser/MyGNURadio/Practice/function_block_test.py", line 377,
> in <module>
> main()
> File "/home/superuser/MyGNURadio/Practice/function_block_test.py", line 365,
> in main
> tb = top_block_cls()
> File "/home/superuser/MyGNURadio/Practice/function_block_test.py", line 94,
> in __init__
> self.uhd_usrp_source_0.set_subdev_spec("B:A B:B A:A A:B", 0)
> File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line
> 2787, in set_subdev_spec
> return _uhd_swig.usrp_source_sptr_set_subdev_spec(self, *args, **kwargs)
> RuntimeError: ValueError: The subdevice specification "B:A B:B A:A A:B" is
> too long.
> The user specified 4 channels, but there are only 2 rx dsps on mboard 0.
> --------------------------------------------------
>
> If I disable the Function Probes then the project runs and the 4 outputs are
> correct.
>
> Also if I change the Num Channels in the UHD to 2 then it does work and the
> Function Probe also does work.
>
> Only with the function probe in the project does it complain about the number
> of rx dsps on mboard 0.
>
> Any help appreciated!
>
> Kathy Hertzog
> _______________________________________________
> 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/20160922/427b73ee/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 22 Sep 2016 10:18:59 -0700
From: Kathy Hertzog <kqhert...@gmail.com>
To: mle...@ripnet.com
Cc: usrp-users <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Function Probe: USRP1 vs N210
Message-ID:
<CAC9E-nGk3VY55qXRrOtcPy59K3Xdqw2z1pS=sVo2=kw1kye...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Martin,
I replaced the QT GUI with Null Sinks - same error message as before.
"Runtime Error: ValueError: The subdevice specification "B:A B:B A:A A:B"
is too long.
The user specified 4 channels, but there are only 2 rx dsps on mboard 0."
If I disable the OOT then it runs with no error.
I switched back to the USRP1 from the N210 without changing anything in my
libraries. I'm using libuhd.so.003.009 with a patch for a GPS Locking
issue.
Thanks
Kathy Hertzog
On Thu, Sep 22, 2016 at 9:47 AM, <mle...@ripnet.com> wrote:
> Could you simplify?
>
> A simple graph with just the USRP1 source (with the 4rx FPGA image), going
> to 4 NULL SINK ?
>
> What happens then?
>
>
>
>
>
>
> On 2016-09-22 12:33, Kathy Hertzog via USRP-users wrote:
>
> Hi,
> I had a project working w/ two N210s (4 receivers) that used Function
> Probes to access OOT methods to update a label in the GUI. For cost reasons
> I'm going back to my USRP1 with two receiver boards, therefore 4 receivers.
> Here's the UHD info:
>
> Device Address: fpga=usrp1_fpga_4rx.rbf
> Num Mboards = 1
> Num Channels = 4
> Mb0 Subdev Spec = B:A B:B A:A A:B
>
> A simple GNURadio project with this UHD and my OOT block going directly
> into 4 QT GUI function sinks (just to show that the outputs are valid)
> works fine. With the N210 I also had function probes that called methods in
> an OOT block. When I try to add this into a project with the USRP1 I'm
> getting this error:
>
> --------------------------------------------
> -- Opening a USRP1 device...
> -- Using FPGA clock rate of 64.000000MHz...
> Traceback (most recent call last):
> File "/home/superuser/MyGNURadio/Practice/function_block_test.py", line
> 377, in <module>
> main()
> File "/home/superuser/MyGNURadio/Practice/function_block_test.py", line
> 365, in main
> tb = top_block_cls()
> File "/home/superuser/MyGNURadio/Practice/function_block_test.py", line
> 94, in __init__
> self.uhd_usrp_source_0.set_subdev_spec("B:A B:B A:A A:B", 0)
> File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
> line 2787, in set_subdev_spec
> return _uhd_swig.usrp_source_sptr_set_subdev_spec(self, *args,
> **kwargs)
> RuntimeError: ValueError: The subdevice specification "B:A B:B A:A A:B" is
> too long.
> The user specified 4 channels, but there are only 2 rx dsps on mboard 0.
> --------------------------------------------------
>
> If I disable the Function Probes then the project runs and the 4 outputs
> are correct.
>
> Also if I change the Num Channels in the UHD to 2 then it does work and
> the Function Probe also does work.
>
> Only with the function probe in the project does it complain about the
> number of rx dsps on mboard 0.
>
> Any help appreciated!
>
> Kathy Hertzog
>
> _______________________________________________
> 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/20160922/8ac3fe6a/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 22 Sep 2016 10:27:03 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Function Probe: USRP1 vs N210
Message-ID: <88a4a8fd-7c49-cc38-72f1-588b59baa...@ettus.com>
Content-Type: text/plain; charset=windows-1252
Are you specifying the 4rx image?
M
On 09/22/2016 10:18 AM, Kathy Hertzog via USRP-users wrote:
> Hi Martin,
> I replaced the QT GUI with Null Sinks - same error message as before.
>
> "Runtime Error: ValueError: The subdevice specification "B:A B:B A:A
> A:B" is too long.
> The user specified 4 channels, but there are only 2 rx dsps on mboard 0."
>
> If I disable the OOT then it runs with no error.
>
> I switched back to the USRP1 from the N210 without changing anything in
> my libraries. I'm using libuhd.so.003.009 with a patch for a GPS Locking
> issue.
>
> Thanks
> Kathy Hertzog
>
> On Thu, Sep 22, 2016 at 9:47 AM, <mle...@ripnet.com
> <mailto:mle...@ripnet.com>> wrote:
>
> Could you simplify?
>
> A simple graph with just the USRP1 source (with the 4rx FPGA image),
> going to 4 NULL SINK ?
>
> What happens then?
>
>
>
>
>
>
>
> On 2016-09-22 12:33, Kathy Hertzog via USRP-users wrote:
>
>> Hi,
>> I had a project working w/ two N210s (4 receivers) that used
>> Function Probes to access OOT methods to update a label in the
>> GUI. For cost reasons I'm going back to my USRP1 with two receiver
>> boards, therefore 4 receivers. Here's the UHD info:
>>
>> Device Address: fpga=usrp1_fpga_4rx.rbf
>> Num Mboards = 1
>> Num Channels = 4
>> Mb0 Subdev Spec = B:A B:B A:A A:B
>>
>> A simple GNURadio project with this UHD and my OOT block going
>> directly into 4 QT GUI function sinks (just to show that the
>> outputs are valid) works fine. With the N210 I also had function
>> probes that called methods in an OOT block. When I try to add this
>> into a project with the USRP1 I'm getting this error:
>>
>> --------------------------------------------
>> -- Opening a USRP1 device...
>> -- Using FPGA clock rate of 64.000000MHz...
>> Traceback (most recent call last):
>> File
>> "/home/superuser/MyGNURadio/Practice/function_block_test.py", line
>> 377, in <module>
>> main()
>> File
>> "/home/superuser/MyGNURadio/Practice/function_block_test.py", line
>> 365, in main
>> tb = top_block_cls()
>> File
>> "/home/superuser/MyGNURadio/Practice/function_block_test.py", line
>> 94, in __init__
>> self.uhd_usrp_source_0.set_subdev_spec("B:A B:B A:A A:B", 0)
>> File
>> "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
>> line 2787, in set_subdev_spec
>> return _uhd_swig.usrp_source_sptr_set_subdev_spec(self, *args,
>> **kwargs)
>> RuntimeError: ValueError: The subdevice specification "B:A B:B A:A
>> A:B" is too long.
>> The user specified 4 channels, but there are only 2 rx dsps on
>> mboard 0.
>> --------------------------------------------------
>>
>> If I disable the Function Probes then the project runs and the 4
>> outputs are correct.
>>
>> Also if I change the Num Channels in the UHD to 2 then it does
>> work and the Function Probe also does work.
>>
>> Only with the function probe in the project does it complain about
>> the number of rx dsps on mboard 0.
>>
>> Any help appreciated!
>>
>> Kathy Hertzog
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 6
Date: Thu, 22 Sep 2016 18:39:13 +0000
From: "d.des" <d....@sbcglobal.net>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Example code for a pair of TwinRXs
Message-ID: <1474569553.4173.27.ca...@sbcglobal.net>
Content-Type: text/plain; charset="UTF-8"
Derek wrote:
>I've sent you emails directly with the FPGA image attached.
>I am publicly posting the GNU Radio flowgraph which I use to spot
check phase offset repeatability in case it is useful to others.
Thanks! ?The flow graph was extremely helpful. ?I duplicated as much as
I could with the c++ API (see below). ?I skipped the set_auto_dc_offset
since that looks like a Gnuradio thing. ?Seemingly simple things
matter: at first I tried to use set_rx_freq(freq,nChan) but there was
about a quarter-Hertz offset in the frequencies. ?I was surprised at
the need to use the tune_request attributes.
The phases aren't nominally close to zero they way they are on the B210
but they do seem repeatable after restarts and power cycles.
The 10-microsecond offset between channel pairs was due to my use of
the set_time_now, setting from PPS removes the error. ?I wonder if
there's a way to get in sync for multiple boards in one X310 without
GPS.
Thanks for all the help!
///////////////////////////////////////////////////////////
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_rate(rate);?
//4 MHz tried so far, works well using single 1 GB Ethernet line
rate = usrp->get_rx_rate(0);
cout<<"Actual RX Rate: "<<rate/1.e6<<" MHz\n";
usrp->set_time_unknown_pps(uhd::time_spec_t());
usrp->set_rx_gain(gain,0);
gain = usrp->get_rx_gain(0);
cout<<"Actual RX Gain for channel 0: "<<gain<<" dB\n";
usrp->set_rx_lo_export_enabled(true,"all",0);
usrp->set_rx_lo_source("internal","all",0);
usrp->set_rx_gain(gain,1);
gain = usrp->get_rx_gain(1);
cout<<"Actual RX Gain for channel 1: "<<gain<<" dB\n";
usrp->set_rx_lo_source("companion","all",1);
usrp->set_rx_gain(gain,2);
gain = usrp->get_rx_gain(2);
cout<<"Actual RX Gain for channel 2: "<<gain<<" dB\n";
usrp->set_rx_lo_source("external","all",2);
usrp->set_rx_gain(gain,3);
gain = usrp->get_rx_gain(3);
cout<<"Actual RX Gain for channel 3: "<<gain<<" dB\n";
usrp->set_rx_lo_source("external","all",3);
uhd::tune_request_t trbad(freq+1.e6,0);
trbad.rf_freq_policy =
uhd::tune_request_t::POLICY_MANUAL;
trbad.dsp_freq_policy =
uhd::tune_request_t::POLICY_MANUAL;
uhd::time_spec_t cmd_time = usrp->get_time_now() +
uhd::time_spec_t(0.5);
usrp->set_command_time(cmd_time);
for(int nChan=0;nChan<nChans;++nChan) {
usrp->set_rx_freq(trbad, nChan);
}
usrp->clear_command_time();
}
usleep(1000000);
uhd::tune_request_t tune_request(freq,0);
tune_request.rf_freq_policy = uhd::tune_request_t::POLICY_MANUAL;
tune_request.dsp_freq_policy = uhd::tune_request_t::POLICY_MANUAL;
uhd::time_spec_t cmd_time = usrp->get_time_now() +
uhd::time_spec_t(0.75);
usrp->set_command_time(cmd_time);
for(int nChan=0;nChan<nChans;++nChan) {
usrp->set_rx_freq(tune_request, nChan);
}
usrp->clear_command_time();
usleep(1000000);
for(int nChan=0;nChan<nChans;++nChan) {
freq = usrp->get_rx_freq(nChan);
cout<<"Actual RX freq on Channel "<<nChan<<" is "<<freq/1.e6<<"
MHz\n";
}
//Check Ref and LO Lock detect
std::vector<std::string> sensor_names;
sensor_names = usrp->get_rx_sensor_names(0);
if (std::find(sensor_names.begin(), sensor_names.end(), "lo_locked") !=
sensor_names.end()) {
uhd::sensor_value_t lo_locked = usrp-
>get_rx_sensor("lo_locked",0);
std::cout << boost::format("Checking RX: %s ...") %
lo_locked.to_pp_string() << std::endl;
UHD_ASSERT_THROW(lo_locked.to_bool());
}
//create a receive streamer
uhd::stream_args_t stream_args("sc16","sc16");
std::vector<size_t> channel_nums;
channel_nums.push_back(0);
if(nChans>1) channel_nums.push_back(1);
if(nChans>2) channel_nums.push_back(2);
if(nChans>3) 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;
const uhd::time_spec_t stream_time = usrp->get_time_now() +
uhd::time_spec_t(0.1);
stream_cmd.time_spec = stream_time;
rx_stream->issue_stream_cmd(stream_cmd);
while(!done) {
// recv call, detect and process events
}
stream_cmd.stream_mode =
uhd::stream_cmd_t::STREAM_MODE_STOP_CONTINUOUS;
rx_stream->issue_stream_cmd(stream_cmd);
------------------------------
Message: 7
Date: Thu, 22 Sep 2016 12:00:21 -0700
From: Derek Kozel <derek.ko...@ettus.com>
To: "d.des" <d....@sbcglobal.net>
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=ttNOw_wZD5w2eMrhxHNJTrzZQ=abaibet+exqtxpsh...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Dave,
I'm glad that the flowgraph has been helpful.
A GPS is not required. Sam mentioned this to me last night and I realized
that my code sets the source to external, just change the call to
set_clock_source to internal. This will not affect the phase offsets. The
X310 will create an internal PPS if an external or GPSDO is not supplied as
the time source.
The tune request structure is also not necessary, but deals with a side
issue which would otherwise require additional code. This flow graph has
been for quick spot checking as I said. We will have a better reference
showing the use of a basic set_rx_freq for the primary (LO Source) channel
and then reading back the true RF and DSP frequencies when an app note is
released. The underlying issue is that the second daughterboard has no way
of knowing that the LOs being supplied to it are imperfect so cannot
automatically calculate the appropriate DSP correction to use. With a few
extra steps this is possible, but not necessary for a spot check.
Regards,
Derek
On Thu, Sep 22, 2016 at 11:39 AM, d.des via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Derek wrote:
> >I've sent you emails directly with the FPGA image attached.
> >I am publicly posting the GNU Radio flowgraph which I use to spot
> check phase offset repeatability in case it is useful to others.
>
> Thanks! The flow graph was extremely helpful. I duplicated as much as
> I could with the c++ API (see below). I skipped the set_auto_dc_offset
> since that looks like a Gnuradio thing. Seemingly simple things
> matter: at first I tried to use set_rx_freq(freq,nChan) but there was
> about a quarter-Hertz offset in the frequencies. I was surprised at
> the need to use the tune_request attributes.
>
> The phases aren't nominally close to zero they way they are on the B210
> but they do seem repeatable after restarts and power cycles.
>
> The 10-microsecond offset between channel pairs was due to my use of
> the set_time_now, setting from PPS removes the error. I wonder if
> there's a way to get in sync for multiple boards in one X310 without
> GPS.
>
> Thanks for all the help!
>
> ///////////////////////////////////////////////////////////
> 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_rate(rate);
> //4 MHz tried so far, works well using single 1 GB Ethernet line
> rate = usrp->get_rx_rate(0);
> cout<<"Actual RX Rate: "<<rate/1.e6<<" MHz\n";
>
> usrp->set_time_unknown_pps(uhd::time_spec_t());
>
> usrp->set_rx_gain(gain,0);
> gain = usrp->get_rx_gain(0);
> cout<<"Actual RX Gain for channel 0: "<<gain<<" dB\n";
>
> usrp->set_rx_lo_export_enabled(true,"all",0);
> usrp->set_rx_lo_source("internal","all",0);
> usrp->set_rx_gain(gain,1);
> gain = usrp->get_rx_gain(1);
> cout<<"Actual RX Gain for channel 1: "<<gain<<" dB\n";
> usrp->set_rx_lo_source("companion","all",1);
> usrp->set_rx_gain(gain,2);
> gain = usrp->get_rx_gain(2);
> cout<<"Actual RX Gain for channel 2: "<<gain<<" dB\n";
> usrp->set_rx_lo_source("external","all",2);
> usrp->set_rx_gain(gain,3);
> gain = usrp->get_rx_gain(3);
> cout<<"Actual RX Gain for channel 3: "<<gain<<" dB\n";
> usrp->set_rx_lo_source("external","all",3);
> uhd::tune_request_t trbad(freq+1.e6,0);
> trbad.rf_freq_policy =
> uhd::tune_request_t::POLICY_MANUAL;
> trbad.dsp_freq_policy =
> uhd::tune_request_t::POLICY_MANUAL;
> uhd::time_spec_t cmd_time = usrp->get_time_now() +
> uhd::time_spec_t(0.5);
> usrp->set_command_time(cmd_time);
> for(int nChan=0;nChan<nChans;++nChan) {
> usrp->set_rx_freq(trbad, nChan);
> }
> usrp->clear_command_time();
> }
> usleep(1000000);
> uhd::tune_request_t tune_request(freq,0);
> tune_request.rf_freq_policy = uhd::tune_request_t::POLICY_MANUAL;
> tune_request.dsp_freq_policy = uhd::tune_request_t::POLICY_MANUAL;
> uhd::time_spec_t cmd_time = usrp->get_time_now() +
> uhd::time_spec_t(0.75);
> usrp->set_command_time(cmd_time);
> for(int nChan=0;nChan<nChans;++nChan) {
> usrp->set_rx_freq(tune_request, nChan);
> }
> usrp->clear_command_time();
> usleep(1000000);
>
> for(int nChan=0;nChan<nChans;++nChan) {
> freq = usrp->get_rx_freq(nChan);
> cout<<"Actual RX freq on Channel "<<nChan<<" is "<<freq/1.e6<<"
> MHz\n";
> }
>
> //Check Ref and LO Lock detect
> std::vector<std::string> sensor_names;
> sensor_names = usrp->get_rx_sensor_names(0);
> if (std::find(sensor_names.begin(), sensor_names.end(), "lo_locked") !=
> sensor_names.end()) {
> uhd::sensor_value_t lo_locked = usrp-
> >get_rx_sensor("lo_locked",0);
> std::cout << boost::format("Checking RX: %s ...") %
> lo_locked.to_pp_string() << std::endl;
> UHD_ASSERT_THROW(lo_locked.to_bool());
> }
> //create a receive streamer
> uhd::stream_args_t stream_args("sc16","sc16");
> std::vector<size_t> channel_nums;
> channel_nums.push_back(0);
> if(nChans>1) channel_nums.push_back(1);
> if(nChans>2) channel_nums.push_back(2);
> if(nChans>3) 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;
> const uhd::time_spec_t stream_time = usrp->get_time_now() +
> uhd::time_spec_t(0.1);
> stream_cmd.time_spec = stream_time;
>
> rx_stream->issue_stream_cmd(stream_cmd);
>
> while(!done) {
> // recv call, detect and process events
> }
>
> 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/20160922/ae465c66/attachment-0001.html>
------------------------------
Message: 8
Date: Thu, 22 Sep 2016 12:26:30 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] UHD loses GPS lock with "no GPRMC message
found" - N210 and GPSDO
Message-ID: <7def6cff-d732-c741-74d8-00414149e...@ettus.com>
Content-Type: text/plain; charset=windows-1252
To close the loop for the records, we have a fix on maint and LTS
branches for this.
Cheers,
Martin
On 05/05/2016 11:34 AM, Kathy Hertzog via USRP-users wrote:
> Hi,
>
> I have a very simple GRC project with a UHD:USRP Source Block, a QT GUI
> Frequency Sink Block and two function probes into the UHD's function
> "get_mboard_sensor". When it works, two QT GUI Labels are filled with
> the output from calls to get the "gps_time" and "gps_lock".
>
> I'm connected to an N210 with GPSDO.
>
> GNURadio 3.7.9.1, UHD 3.09.02, Ubuntu 14.04.4 trusty
>
> Even with very slow (once every 4 seconds) access to the "gps_time" and
> "gps_lock" sensor values this example eventually loses lock and stops
> reporting time. The rest of the flowgraph keeps running.
>
> At first there are UHD Warnings: "get_time: ValueError: get_nmea(): no
> GPRMC message found". Then it throws a "RuntimeError: ValueError:
> Timeout after no valid message found" from the
> "get_mboard_sensor('gps_time')" which halts writing to the QT GUI
> Labels. The spectrum keeps updating.
>
> If I add a try/except for the RuntimeError in the Python code for the
> get_time function probe I eventually still get continuous UHD Warnings
> about "no GPRMC message found" but, of course, the exception is caught.
> Just adding a pass doesn't fix it though. Right now this is an
> unrecoverable error - the system never gets lock back and the time is
> never updated again.
>
> Is there anything I can do in the "except" that will allow the GPS to
> lock again?
>
> I do have a good GPS antenna and signal with re-radiators by the puck as
> well as other equipment on the same antenna that is not having a problem
> staying locked.
>
> UHD Setup:
> Device Address: addr0=192.168.10.2
> Sync: unknown PPS
> Mb0 Clock Source: O/B GPSDO
> Mb0 Time Source: O/B GPSDO
> Mb0 Subdev Spec: A:A A:B
> Num Channels: 2
>
> Thanks for any suggestions.
>
> Kathy Hertzog
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 9
Date: Thu, 22 Sep 2016 20:59:14 +0000
From: "Swanson, Craig" <craig.swan...@gtri.gatech.edu>
To: Jonathon Pendlum <jonathon.pend...@ettus.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Confirmation of ce_clk in rfnoc running in
actual hardware on the X310
Message-ID: <1474577954461.56...@gtri.gatech.edu>
Content-Type: text/plain; charset="iso-8859-1"
Jonathon,
For the E310,
To be specific, if I want to run ce_clk at 50 MHz, I would
ce_clk = bus_clk;
If I want to run ce_clk at the radio clock, I would
ce_clk = radio_clk;
How do I know what the clock frequency is of the radio_clk? You mention below
that radio_clk = sample rate (SISO) or 2x sample rate (MIMO).?
How do I know whether the radio_clk is running at SISO and MIMO, and what is
the specific frequency?
Thanks,
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
________________________________
From: Jonathon Pendlum <jonathon.pend...@ettus.com>
Sent: Tuesday, August 9, 2016 5:57 PM
To: Swanson, Craig
Cc: usrp-users@lists.ettus.com; Brothers, Timothy
Subject: Re: Confirmation of ce_clk in rfnoc running in actual hardware on the
X310
Hi Craig,
The speed of ce_clk in hardware depends both on device and which clock you use
for ce_clk. You can use bus_clk or radio_clk or generate your own. On the X310,
bus_clk = 166.67 MHz, radio_clk = 200 MHz. On E310, bus_clk = 50 MHz, radio_clk
= sample rate (SISO) or 2x sample rate (MIMO).
Jonathon
On Tue, Aug 9, 2016 at 2:31 PM, Swanson, Craig
<craig.swan...@gtri.gatech.edu<mailto:craig.swan...@gtri.gatech.edu>> wrote:
?Jonathon,
In running RFNoC simulations, the ce_clk is 10 MHz. Is that what the speed is
of the ce_clk in the real hardware?
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156<tel:770.298.9156>
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160922/0ff238ff/attachment-0001.html>
------------------------------
Message: 10
Date: Thu, 22 Sep 2016 17:42:04 -0700
From: Michael West <michael.w...@ettus.com>
To: Lakshay Narula <lakshay.nar...@gmail.com>
Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Does time.sleep() affect PPS sync in E310?
Message-ID:
<cam4xkrrfsktedqomrwvweib4st+q61jnnwniguhqntqbusc...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Lakshay,
Thanks for the information and the debugging effort. Is the 10ms delay
only on the first burst or does it happen every burst when the sleep is
used?
This type of issue is a bit involved, so it may take some time to find the
root cause and resolve completely. Is resolving this issue critical for
your application or do you have a way to work around it and proceed?
Regards,
Michael
On Fri, Sep 16, 2016 at 10:01 PM, Lakshay Narula via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hello,
>
> I am seeing something interesting with my E310 when I try to use an
> external PPS on the SYNC connector. Here is what I am trying to do: Lock
> the internal reference clock to external PPS and generate a burst output
> every second using tx_time tags. Feed this output to an oscilloscope, where
> I also feed the reference PPS. I just want to check if the E310 can
> generate bursts accurately (within a clock cycle).
>
> Here is my procedure:
> 1. Set time source to "external", and poll the "ref_locked" sensor. I
> observe that the sensor indicates lock in about 12 seconds most of the time.
> 2. Monitor the time_last_pps till a change is seen. Then set the time to
> zero at next PPS.
> 3. Wait for another PPS so that new time is updated.
> 4. Generate a burst with an integer seconds time tag, for example 10
> seconds.
> 5. Observe what happens on the oscilloscope.
>
> On the oscilloscope, I see the required pulse is about 10.109 ms later
> than the reference PPS. I could live with the delay, but this delay varies
> from run to run within 10 microseconds. Then I came across another thread
> about the E310 PPS sync (http://lists.ettus.com/piperm
> ail/usrp-users_lists.ettus.com/2015-November/016936.html). This user also
> saw delay of 10.108 ms, which should definitely not be a coincidence.
>
> I did some more debugging, and I observed the following. If I skip step 3,
> that is, I do not put the GNU Radio flowgraph to sleep for 1 sec for the
> time to set to zerp, the 10 ms delay disappears, and there is no
> microsecond-level variability in the output time of the pulse. Moreover,
> even if I increase that sleep duration to as large as 60 secs, the delay
> remains close to 10 ms and does not increase. I have repeated this test
> multiple times and I can confirm that there is no other change except
> removing that time.sleep() call. (Here I would like to point out that
> without this sleep call some of my initial bursts arrive late, since the
> tx_time tag is 10 secs and the reset to zero has not happened till the next
> PPS.)
>
> So the question is that does putting the flowgraph to sleep affect PPS
> sync in some way? It is strange in that increasing the sleep interval has
> no effect. But I do not see any other reason for this strange behavior.
>
> Best,
> Lakshay.
>
> _______________________________________________
> 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/20160922/e8e2f1c7/attachment-0001.html>
------------------------------
Message: 11
Date: Thu, 22 Sep 2016 19:51:40 -0500
From: Lakshay Narula <lakshay.nar...@gmail.com>
To: Michael West <michael.w...@ettus.com>
Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Does time.sleep() affect PPS sync in E310?
Message-ID:
<CAKMRQ1r8wr+six5+dg8a_Hth=5q9zqndnze_mvth5urszsa...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Michael,
The 10ms delay is on all bursts, and not just the first one. I can deal
with the delay if it were constant, but the problem is that the delay
varies in the range of about 10 microseconds (around the 10ms average) from
run to run. I should point out the following more explicitly:
1. With the time.sleep() command, the delay is about 10 ms, but varies at
the 10 microsecond level from run to run. That is, in a given run, two
consecutive pulses are exactly 1 sec apart with no variation.
2. The microsecond level variability from run to run disappears, along with
the 10 ms delay, when the time.sleep() command is removed, as required.
I'll share my code and setup on the list tomorrow, if that helps.
-Lakshay.
On Thu, Sep 22, 2016 at 7:42 PM, Michael West <michael.w...@ettus.com>
wrote:
> Hi Lakshay,
>
> Thanks for the information and the debugging effort. Is the 10ms delay
> only on the first burst or does it happen every burst when the sleep is
> used?
>
> This type of issue is a bit involved, so it may take some time to find the
> root cause and resolve completely. Is resolving this issue critical for
> your application or do you have a way to work around it and proceed?
>
> Regards,
> Michael
>
> On Fri, Sep 16, 2016 at 10:01 PM, Lakshay Narula via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hello,
>>
>> I am seeing something interesting with my E310 when I try to use an
>> external PPS on the SYNC connector. Here is what I am trying to do: Lock
>> the internal reference clock to external PPS and generate a burst output
>> every second using tx_time tags. Feed this output to an oscilloscope, where
>> I also feed the reference PPS. I just want to check if the E310 can
>> generate bursts accurately (within a clock cycle).
>>
>> Here is my procedure:
>> 1. Set time source to "external", and poll the "ref_locked" sensor. I
>> observe that the sensor indicates lock in about 12 seconds most of the time.
>> 2. Monitor the time_last_pps till a change is seen. Then set the time to
>> zero at next PPS.
>> 3. Wait for another PPS so that new time is updated.
>> 4. Generate a burst with an integer seconds time tag, for example 10
>> seconds.
>> 5. Observe what happens on the oscilloscope.
>>
>> On the oscilloscope, I see the required pulse is about 10.109 ms later
>> than the reference PPS. I could live with the delay, but this delay varies
>> from run to run within 10 microseconds. Then I came across another thread
>> about the E310 PPS sync (http://lists.ettus.com/piperm
>> ail/usrp-users_lists.ettus.com/2015-November/016936.html). This user
>> also saw delay of 10.108 ms, which should definitely not be a coincidence.
>>
>> I did some more debugging, and I observed the following. If I skip step
>> 3, that is, I do not put the GNU Radio flowgraph to sleep for 1 sec for the
>> time to set to zerp, the 10 ms delay disappears, and there is no
>> microsecond-level variability in the output time of the pulse. Moreover,
>> even if I increase that sleep duration to as large as 60 secs, the delay
>> remains close to 10 ms and does not increase. I have repeated this test
>> multiple times and I can confirm that there is no other change except
>> removing that time.sleep() call. (Here I would like to point out that
>> without this sleep call some of my initial bursts arrive late, since the
>> tx_time tag is 10 secs and the reset to zero has not happened till the next
>> PPS.)
>>
>> So the question is that does putting the flowgraph to sleep affect PPS
>> sync in some way? It is strange in that increasing the sleep interval has
>> no effect. But I do not see any other reason for this strange behavior.
>>
>> Best,
>> Lakshay.
>>
>> _______________________________________________
>> 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/20160922/d4ef96e3/attachment-0001.html>
------------------------------
Message: 12
Date: Thu, 22 Sep 2016 18:09:44 -0700
From: Michael West <michael.w...@ettus.com>
To: Lakshay Narula <lakshay.nar...@gmail.com>
Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Does time.sleep() affect PPS sync in E310?
Message-ID:
<cam4xkrqaye84qzmfzpafypyg4yehjbeor6xgpxpzj-_izhr...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Lakshay,
Thanks for the clarification. Anything you can provide will be a big
help. Thanks.
Regards,
Michael
On Thu, Sep 22, 2016 at 5:51 PM, Lakshay Narula <lakshay.nar...@gmail.com>
wrote:
> Hi Michael,
>
> The 10ms delay is on all bursts, and not just the first one. I can deal
> with the delay if it were constant, but the problem is that the delay
> varies in the range of about 10 microseconds (around the 10ms average) from
> run to run. I should point out the following more explicitly:
> 1. With the time.sleep() command, the delay is about 10 ms, but varies at
> the 10 microsecond level from run to run. That is, in a given run, two
> consecutive pulses are exactly 1 sec apart with no variation.
> 2. The microsecond level variability from run to run disappears, along
> with the 10 ms delay, when the time.sleep() command is removed, as required.
>
> I'll share my code and setup on the list tomorrow, if that helps.
>
> -Lakshay.
>
> On Thu, Sep 22, 2016 at 7:42 PM, Michael West <michael.w...@ettus.com>
> wrote:
>
>> Hi Lakshay,
>>
>> Thanks for the information and the debugging effort. Is the 10ms delay
>> only on the first burst or does it happen every burst when the sleep is
>> used?
>>
>> This type of issue is a bit involved, so it may take some time to find
>> the root cause and resolve completely. Is resolving this issue critical
>> for your application or do you have a way to work around it and proceed?
>>
>> Regards,
>> Michael
>>
>> On Fri, Sep 16, 2016 at 10:01 PM, Lakshay Narula via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hello,
>>>
>>> I am seeing something interesting with my E310 when I try to use an
>>> external PPS on the SYNC connector. Here is what I am trying to do: Lock
>>> the internal reference clock to external PPS and generate a burst output
>>> every second using tx_time tags. Feed this output to an oscilloscope, where
>>> I also feed the reference PPS. I just want to check if the E310 can
>>> generate bursts accurately (within a clock cycle).
>>>
>>> Here is my procedure:
>>> 1. Set time source to "external", and poll the "ref_locked" sensor. I
>>> observe that the sensor indicates lock in about 12 seconds most of the time.
>>> 2. Monitor the time_last_pps till a change is seen. Then set the time to
>>> zero at next PPS.
>>> 3. Wait for another PPS so that new time is updated.
>>> 4. Generate a burst with an integer seconds time tag, for example 10
>>> seconds.
>>> 5. Observe what happens on the oscilloscope.
>>>
>>> On the oscilloscope, I see the required pulse is about 10.109 ms later
>>> than the reference PPS. I could live with the delay, but this delay varies
>>> from run to run within 10 microseconds. Then I came across another thread
>>> about the E310 PPS sync (http://lists.ettus.com/piperm
>>> ail/usrp-users_lists.ettus.com/2015-November/016936.html). This user
>>> also saw delay of 10.108 ms, which should definitely not be a coincidence.
>>>
>>> I did some more debugging, and I observed the following. If I skip step
>>> 3, that is, I do not put the GNU Radio flowgraph to sleep for 1 sec for the
>>> time to set to zerp, the 10 ms delay disappears, and there is no
>>> microsecond-level variability in the output time of the pulse. Moreover,
>>> even if I increase that sleep duration to as large as 60 secs, the delay
>>> remains close to 10 ms and does not increase. I have repeated this test
>>> multiple times and I can confirm that there is no other change except
>>> removing that time.sleep() call. (Here I would like to point out that
>>> without this sleep call some of my initial bursts arrive late, since the
>>> tx_time tag is 10 secs and the reset to zero has not happened till the next
>>> PPS.)
>>>
>>> So the question is that does putting the flowgraph to sleep affect PPS
>>> sync in some way? It is strange in that increasing the sleep interval has
>>> no effect. But I do not see any other reason for this strange behavior.
>>>
>>> Best,
>>> Lakshay.
>>>
>>> _______________________________________________
>>> 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/20160922/4737e508/attachment-0001.html>
------------------------------
Message: 13
Date: Fri, 23 Sep 2016 13:30:51 +1000
From: Walter Maguire <wmagu...@iinet.net.au>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP-users Digest, Vol 73, Issue 20
Message-ID: <e3d0467d-f53b-8bfa-10e5-c261885be...@iinet.net.au>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Hi Martin,
I am not sure I understand what is taking place.
If I leave the Radio CE Block in the FPGA the program
uhd_usrp_probe --init-only works
The first few lines of the output are
Creating the usrp device with: ...
-- Loading FPGA image: /usr/share/uhd/images/usrp_e310_fpga.bit... done
-- Initializing core control (global registers)...
-- Performing register loopback test... pass
-- Initializing AD9361 using hard SPI core...OK
-- [RFNOC] ------- Block Setup -----------
-- [E300] Setting up dest map for host ep 0 to be stream 0
-- Setting up NoC-Shell Control for port #0 (SID: 00:00>02:10)...OK
-- Port 16: Found NoC-Block with ID 12AD100000000000.
-- Reading XML file: /usr/share/uhd/rfnoc/blocks/radio_e3xx.xml
-- [E300] Setting up dest map for host ep 1 to be stream 1
-- Setting up NoC-Shell Control for port #1 (SID: 00:01>02:11)...OK
-- [RFNoC Factory] block_ctrl_base::make()
-- Reading XML file: /usr/share/uhd/rfnoc/blocks/radio_e3xx.xml
-- [RFNoC Factory] Using controller key 'E3XXRadio' and block name 'Radio'
-- block_ctrl_base()
-- Reading XML file: /usr/share/uhd/rfnoc/blocks/radio_e3xx.xml
-- Found valid blockdef
-- NOC ID: 0x12AD100000000000 Block ID: 0/Radio_0
-- [0/Radio_0] block_ctrl_base::clear()
-- [0/Radio_0] node_ctrl_base::clear()
-- [0/Radio_0] block_ctrl_base::_clear()
-- [0/Radio_0] block_ctrl_base::_clear()
-- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/in/0: type =
'sc16' pkt_size = '0' vlen = '0'
-- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/in/1: type =
'sc16' pkt_size = '0' vlen = '0'
-- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/out/0: type
= 'sc16' pkt_size = '0' vlen = '0'
-- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/out/1: type
= 'sc16' pkt_size = '0' vlen = '0'
Now if I change the FPGA code as follows
cd ~/prefix/rfnoc/src/uhd-fpga/usrp3_rfnoc/top/e300$
source setupenv.sh
edit e310_core.v
change line 186 from RB32_CORE_NUMCE : rb_data <= {28'h0,
NUM_CE+4'd1}; // +1 for radio core
to RB32_CORE_NUMCE : rb_data <= {28'h0, NUM_CE+4'd0}; // +0 for
no radio core
Next I remove the instantiation of the noc_block_radio_core
as per
changing lines 325 to 348 to
// noc_block_radio_core #(
// .NUM_CHANNELS(NUM_CHANNELS),
// .STR_SINK_FIFOSIZE({8'd13,8'd13}),
// .MTU(10), // Tuned value
// .USE_SPI_CLK(1))
// noc_block_radio_core (
// .bus_clk(bus_clk), .bus_rst(bus_rst),
// .ce_clk(radio_clk), .ce_rst(radio_rst),
// .i_tdata(ro_tdata), .i_tlast(ro_tlast), .i_tvalid(ro_tvalid),
.i_tready(ro_tready),
// .o_tdata(ri_tdata), .o_tlast(ri_tlast), .o_tvalid(ri_tvalid),
.o_tready(ri_tready),
// // Output timed settings bus, one per radio
// .ext_set_stb(), .ext_set_addr(), .ext_set_data(),
// // Ports connected to radio front end
// .rx({rx_data1,rx_data0}), .rx_stb({rx_stb1,rx_stb0}),
// .tx({tx_data1,tx_data0}), .tx_stb({tx_stb1,tx_stb0}),
// // Interfaces to front panel and daughter board
// .pps(pps), .sync_out(),
// .misc_ins('d0), .misc_outs(),
// .fp_gpio_in({fp_gpio_in[1],fp_gpio_in[0]}),
.fp_gpio_out({fp_gpio_out[1],fp_gpio_out[0]}),
.fp_gpio_ddr({fp_gpio_ddr[1],fp_gpio_ddr[0]}),
// .db_gpio_in('d0), .db_gpio_out({db_gpio_out[1],db_gpio_out[0]}),
.db_gpio_ddr(),
// .leds({leds[1],leds[0]}),
// .spi_clk(bus_clk), .spi_rst(bus_rst),
// .sen({sen[1],sen[0]}), .sclk({sclk[1],sclk[0]}),
.mosi({mosi[1],mosi[0]}), .miso({miso[1],miso[0]}),
// .debug());
exit out of editor
next I build the FPGA using
make GUI=1 E310_RFNOC
it builds a new e300.bit (without radio) in the directory as per screen
shot below
~/prefix/rfnoc/src/uhd-fpga/usrp3_rfnoc/top/e300/build-E310_RFNOC
I then rename this file to uhd_e310_fpga.bit and overwrite the one in
the E310 units directory
/usr/share/images/
When I run
uhd_usrp_probe --init-only I get this error output.
Creating the usrp device with: ...
Loading FPGA image: /usr/share/uhd/images/usrp_e310_fpga.bit... done
Error: RuntimeError: [ad9361_device_t] AD9361 not in ALERT during cal
As I understand it if the Radio is not in the FPGA bit file then the UHD
will not read its NOC_ID and therefore should not try to initialize any
of the associated Radio devices such as the AD9361 .
So I think the UHD driver still expects to see a AD9361 device. Assuming
my method of removing the Radio block from the FPGA is incorrect please
advise how it is done.
Regards
Walter
root@ettus-e3xx-sg1:~/testHP#
On 23/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. Re: Example code for a pair of TwinRXs (d.des)
> 2. Re: Cannot remove X310 image (David Miller)
> 3. Re: Example code for a pair of TwinRXs (Marcus D. Leech)
> 4. Re: Building UHD for USRP E310 Without Radio (Martin Braun)
> 5. Re: best way to avoid dropped samples (Garver, Paul W)
> 6. Re: Cannot remove X310 image (Paul David)
> 7. Re: B200mini and low-freq modulation of tx'd signal (Martin Braun)
> 8. Re: error Hardware too new for software in USRP RIO (Martin Braun)
> 9. Re: B200mini and low-freq modulation of tx'd signal
> (Steven Knudsen)
> 10. Fwd: Example code for a pair of TwinRXs (ti...@comcast.net)
> 11. Re: Example code for a pair of TwinRXs (d.des)
> 12. Re: N210 'benchmark_rate' interpretation in a Docker
> container (Martin Braun)
> 13. How to periodically re-output CVITA time tag (EJ Kreinar)
> 14. Re: Example code for a pair of TwinRXs (Derek Kozel)
> 15. Re: How to periodically re-output CVITA time tag (Martin Braun)
> 16. RFNoC without a Radio Core (Walter Maguire)
> 17. Re: RFNoC without a Radio Core (Marcus D. Leech)
> 18. Volk / UHD / GR on macOS 10.12 Sierra (Michael Dickens)
> 19. Re: UBX-160 Performance < 500 MHz (Perelman, Nathan)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 21 Sep 2016 16:15:48 +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: <1474474548.4934.11.ca...@sbcglobal.net>
> Content-Type: text/plain; charset="UTF-8"
>
> Well I've got some more information on why uhd is not returning from
> recv. ?I looked at the recorded data that I got when I set the rate
> using timed commands as in:
>
> 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(4.e6, nChan);
> }
> usrp->clear_command_time();
>
> get_rx_rate returns the 4 MHz value I set but the radio seems to sample
> at 100000 Hz instead. ?It wasn't timing out, it was just taking ten
> seconds to return the million samples that I was requesting. ?If I use
> non-timed commands the rate gets set correctly and it runs fine except
> that the last two channels are out of time sync with the first two.
> ?Timed commands seem to work fine with frequency and gain setting. ?I
> can even get it to run at the correct rate by first using non-timed
> commands to set rate and then re-setting them using timed commands.
> ?The time sync is still off, though so the system is not usabe as is.
>
> I'm using uhd_003.011.000 pulled from git about a week ago. ?I also
> tried UHD_003.010.000.000-61-g23cd2754 from the maint branch (but still
> using the same firmware as before -- I think I heard that I need
> different firmware but don't know where to get it...)
>
> You guys had a working configuration last week for the MUSIC demo,
> right? ?Could you please make it available?
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 21 Sep 2016 16:22:26 +0100
> From: David Miller <david.zod.mil...@gmail.com>
> To: Paul David <paul.da...@ettus.com>
> Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
> Subject: Re: [USRP-users] Cannot remove X310 image
> Message-ID: <96c16bc4-22c0-e363-fe7d-6b374296e...@gmail.com>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> Thanks Paul,
> I was able to get access to a machine with Vivado today and used the
> Hardware Manager to program the latest bitfile. I'll update the flash
> sometime later when I get UHD installed (the machine is RHEL5, too old
> for UHD).
> The viv_jtag_program utility was not there (does it also use the jtag
> server?).
> I was also surprised to see the XADC component/IP? on the FPGA. Is there
> a way to access the environment data from it with a simple command line
> utility?
> Thanks again,
> Dave
>
>
> On 20/09/2016 19:07, Paul David wrote:
>> 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 <mailto: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 <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/20160921/3d10f419/attachment-0001.html>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 21 Sep 2016 12:23:23 -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: <57e2b3fb.3070...@ripnet.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 09/21/2016 12:15 PM, d.des via USRP-users wrote:
>> Well I've got some more information on why uhd is not returning from
>> recv. I looked at the recorded data that I got when I set the rate
>> using timed commands as in:
>>
>> 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(4.e6, nChan);
>> }
>> usrp->clear_command_time();
> Timed commands are largely designed for daughterboard commands, and
> setting the sample rate isn't a daughterboard command.
> Further, setting sample-rate doesn't need to be made precisely
> synchronous, neither, strictly-speaking, does gain.
>
> The only part of it where timed-commands are crucial is in tuning, where
> the timed-commands will arrange for phase-syncrhonization.
>
>
>> get_rx_rate returns the 4 MHz value I set but the radio seems to sample
>> at 100000 Hz instead. It wasn't timing out, it was just taking ten
>> seconds to return the million samples that I was requesting. If I use
>> non-timed commands the rate gets set correctly and it runs fine except
>> that the last two channels are out of time sync with the first two.
>> Timed commands seem to work fine with frequency and gain setting. I
>> can even get it to run at the correct rate by first using non-timed
>> commands to set rate and then re-setting them using timed commands.
>> The time sync is still off, though so the system is not usabe as is.
>>
>> I'm using uhd_003.011.000 pulled from git about a week ago. I also
>> tried UHD_003.010.000.000-61-g23cd2754 from the maint branch (but still
>> using the same firmware as before -- I think I heard that I need
>> different firmware but don't know where to get it...)
>>
>> You guys had a working configuration last week for the MUSIC demo,
>> right? Could you please make it available?
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 21 Sep 2016 09:45:38 -0700
> From: Martin Braun <martin.br...@ettus.com>
> To: usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] Building UHD for USRP E310 Without Radio
> Message-ID: <f2e6cb27-3957-4b60-9a41-1615bbbc3...@ettus.com>
> Content-Type: text/plain; charset=windows-1252
>
> On 09/19/2016 10:01 PM, Walter Maguire via USRP-users wrote:
>> 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.
> Walter,
>
> the radio blocks are not special in an RFNoC sense (they are only
> differently connected in the FPGA, as they have more I/Os than other
> blocks).
> If you have no radios, you will see a warning ("No Radio Block found.
> Assuming radio-less operation."), but it's really not a critical warning.
>
>
>> 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.
> As said before, radios are regular blocks, and taking them out will not
> break anything. The AD9361 will not be activated in that case, either.
>
> Martin
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 21 Sep 2016 16:47:08 +0000
> From: "Garver, Paul W" <garv...@gatech.edu>
> To: "mredfi...@m42tech.com" <mredfi...@m42tech.com>,
> "listera...@gmail.com" <listera...@gmail.com>
> Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
> Subject: Re: [USRP-users] best way to avoid dropped samples
> Message-ID: <70fcd40f-4d80-4ccc-b22d-049200e60...@gatech.edu>
> Content-Type: text/plain; charset="utf-8"
>
> Glad to hear specrec is working well for you, Anon! Also, that data point is
> useful about your particular record speeds between uhd_rx_cfile and specrec.
> That aligns with our results that specrec is about 2x faster than
> uhd_rx_cfile.
>
> Some other folks have discussed a ramdisk-based solution to this problem as
> well. I can?t remember but I think it is on the discuss-gnuradio mailing
> list. That?s a valid approach too, but I will echo that specrec doesn?t
> require any OS-level configuration.
>
> In my experience with recording samples to disk, you really can?t trust the
> vendor provided write speeds for real time streaming. I think the continuous
> write over 10s of seconds, minutes, even hours is much more challenging on
> the SSD than the typical bursty load.
>
> Honestly, with any decent SSD and PC, you should not have any trouble
> recording 1 MSPS using sc16. That?s only 4MBytes/sec.
>
> PWG
>
>
>
>
> From: Anon Lister <listera...@gmail.com<mailto:listera...@gmail.com>>
> Subject: Re: [USRP-users] best way to avoid dropped samples
> Date: September 21, 2016 at 1:56:52 AM EDT
> To: Morgan Redfield <mredfi...@m42tech.com<mailto:mredfi...@m42tech.com>>
> Cc: "usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>"
> <usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>>
>
>
>
> 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<mailto: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<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
>
>
>
>
>
>
>
> _______________________________________________
> 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
>
>
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160921/ddad52a6/attachment-0001.html>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 21 Sep 2016 09:50:56 -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:
> <cacjvjtwsgzp8esufcodfcofccpylkt4kezwdm7e3tfawmve...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi David,
>
> You should be able to tab complete viv_jtag_program once you run the
> following:
> source <path to uhd/fpga-src>/usrp3_rfnoc/top/x300/setupenv.sh
>
> Assuming you're on the latest 3.10.0 release. That will load all the
> environment variables/data.
>
> -- Paul
>
> On Wed, Sep 21, 2016 at 8:22 AM, David Miller <david.zod.mil...@gmail.com>
> wrote:
>
>> Thanks Paul,
>> I was able to get access to a machine with Vivado today and used the
>> Hardware Manager to program the latest bitfile. I'll update the flash
>> sometime later when I get UHD installed (the machine is RHEL5, too old for
>> UHD).
>> The viv_jtag_program utility was not there (does it also use the jtag
>> server?).
>> I was also surprised to see the XADC component/IP? on the FPGA. Is there
>> a way to access the environment data from it with a simple command line
>> utility?
>> Thanks again,
>> Dave
>>
>>
>>
>> On 20/09/2016 19:07, Paul David wrote:
>>
>> 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/20160921/35e2df1d/attachment-0001.html>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 21 Sep 2016 09:55:49 -0700
> From: Martin Braun <martin.br...@ettus.com>
> To: usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] B200mini and low-freq modulation of tx'd
> signal
> Message-ID: <6347265c-d305-0a67-4fce-6799daf41...@ettus.com>
> Content-Type: text/plain; charset=windows-1252
>
> You will need to recover the carrier frequency at the receiver. For
> small errors, you can simply use a PLL for this.
>
> Cheers,
> Martin
>
> On 09/15/2016 10:54 AM, Steven Knudsen via USRP-users wrote:
>> Ah, excellent. I believe you are correct. If I up the frequency, the
>> period reduces, so I can see more of the imposed modulation.
>>
>> So, forgive my ignorance, but how does one correct this?
>>
>> thanks very much!
>>
>>
>> Steven Knudsen, Ph.D., P.Eng.
>> www. techconficio.ca <http://techconficio.ca>
>> www.linkedin.com/in/knudstevenknudsen
>> <http://www.linkedin.com/in/knudstevenknudsen>
>>
>> /Von einem gewissen Punkt an gibt es keine R?ckkehr mehr. Dieser Punkt
>> ist zu erreichen. - Franz Kafka/
>>
>>> On Sep 15, 2016, at 10:57, Torell, Kent <kent.tor...@gd-ms.com
>>> <mailto:kent.tor...@gd-ms.com>> wrote:
>>>
>>> It?s a low frequency carrier error, so you are seeing the bpsk roll
>>> into the other quadrature, then invert data.
>>>
>>> *From:* USRP-users [mailto:usrp-users-boun...@lists.ettus.com] *On
>>> Behalf Of *Steven Knudsen via USRP-users
>>> *Sent:* Thursday, September 15, 2016 9:50 AM
>>> *To:* USRP-users
>>> *Cc:* Knud
>>> *Subject:* [USRP-users] B200mini and low-freq modulation of tx'd signal
>>>
>>> Hi,
>>>
>>> I have a TDMA flowgraph that defines packets using tx_time and tx_sob
>>> + tx_eob. Packets are sent to a B200mini every 10 ms (which is not
>>> important). Below I have the packet format from GRC followed by 3
>>> oscilloscope captures that show the effect I?m seeing.
>>>
>>> The B200mini is connected to an Octoclock 1 PPS reference.
>>>
>>> The modulation is BPSK, 2x oversampled, RRC.
>>>
>>> Image 1 - the GRC waveform that is input to the USRP sink
>>> Image 2 - this time the transmitted signal looks pretty good. Note the
>>> leading zeros so that the transmit power rises to full before samples
>>> are applied.
>>> Image 3 - it appears that some form of slow modulation has been applied
>>> Image 4 - same again, but obviously at a different offset
>>>
>>> (oops, forgot to turn off stupid network config menu in scope caps)
>>>
>>> I am a bit stumped. A ?theory? is that maybe I?m seeing a window of
>>> some kind being convolved with the signal.
>>>
>>> <image001.png>
>>>
>>> <image002.jpg>
>>>
>>> <image003.jpg>
>>>
>>> <image004.jpg>
>>>
>>>
>>> Steven Knudsen, Ph.D., P.Eng.
>>> www. techconficio.ca <http://techconficio.ca/>
>>> www.linkedin.com/in/knudstevenknudsen
>>> <http://www.linkedin.com/in/knudstevenknudsen>
>>>
>>> /Der entscheidende Augenblick der menschlichen Entwicklung
>>> ist immerw?hrend. Darum sind die revolution?ren geistigen Bewegungen,
>>> welche alles Fr?here f?r nichtig erkl?ren, im Recht, denn es ist
>>> noch nichts geschehen. - Franz Kafka/
>>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
>
> ------------------------------
>
> Message: 8
> Date: Wed, 21 Sep 2016 10:02:01 -0700
> From: Martin Braun <martin.br...@ettus.com>
> To: usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] error Hardware too new for software in USRP
> RIO
> Message-ID: <337b5058-2d3b-43f5-e226-b418bc575...@ettus.com>
> Content-Type: text/plain; charset=windows-1252
>
> You will also need to set the 'revision_compat' eeprom value. It looks
> like your EEPROM content was somehow corrupted -- there's a sticker on
> your motherboard with the serial number, and a letter at the end of that
> -- can you tell us what that is?
>
> Cheers,
> Martin
>
> On 09/09/2016 01:07 AM, Nikita Airee via USRP-users wrote:
>> Hello everybody,
>>
>> I have only started working on my *USRP **NI 2953R* CBX, 40 MHz
>> BW(connected via PCI express card)
>>
>> When I tried to run my flowgraphs, it showed an error that said unknown
>> product code in EEPROM: 160. So I changed the code to 30513(0x7731)
>> following the procedure mentioned here.
>> <https://kb.ettus.com/About_the_Motherboard_and_Daughtercard_EEPROM_on_USRP_Devices#Restore_X300.2F310_EEPROM_Product_Code>
>>
>> But now when I run uhd_usrp_probe or even my flowgraph in gnuradio, it
>> throws up the following error:
>>
>> *Error: RuntimeError: Hardware is too new for this software. Please
>> upgrade to a driver that supports hardware revision 65308.*
>>
>> I have updated the UHD driver using the steps mentioned here
>> <https://files.ettus.com/manual/page_install.html#install_linux>. But
>> the error persists.I have also attached a shot of the command.
>>
>> //I'm only a novice when it comes to dealing with USRPs. Could you all
>> help me with this?
>>
>> Nikita
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
>
> ------------------------------
>
> Message: 9
> Date: Wed, 21 Sep 2016 11:12:57 -0600
> From: Steven Knudsen <ee.k...@gmail.com>
> To: Martin Braun <martin.br...@ettus.com>
> Cc: USRP-users <usrp-users@lists.ettus.com>
> Subject: Re: [USRP-users] B200mini and low-freq modulation of tx'd
> signal
> Message-ID: <b938cbcf-4765-4c22-b6c6-8bccb4065...@gmail.com>
> Content-Type: text/plain; charset="windows-1252"
>
> Thanks for the response.
>
> I was having an off day, seeing issues that I should have understood.
>
> The Correlation Estimator Block works fine for my purposes, giving a
> phase_est that I use to correct the frequency offset.
>
> What I?m finding (and this should not be part of this list I know), is the
> usual problem with a multi-radio, packet-based system. Many GNU Radio blocks
> are meant to deal with non-idealities for stream-based transmissions from a
> single transmitter. So, for example, the Polyphase Clock Sync tracking breaks
> down in this circumstance. I should know better and am busy adding algorithms
> that use my packet preamble to do various estimations and corrections.
>
> Sorry to waste the ?list?s? time?
>
> steven
>
>
> Steven Knudsen, Ph.D., P.Eng.
> www. techconficio.ca
> www.linkedin.com/in/knudstevenknudsen
>
> All the wires are cut, my friends
> Live beyond the severed ends. Louis MacNeice
>
>> On Sep 21, 2016, at 10:55, Martin Braun via USRP-users
>> <usrp-users@lists.ettus.com> wrote:
>>
>> You will need to recover the carrier frequency at the receiver. For
>> small errors, you can simply use a PLL for this.
>>
>> Cheers,
>> Martin
>>
>> On 09/15/2016 10:54 AM, Steven Knudsen via USRP-users wrote:
>>> Ah, excellent. I believe you are correct. If I up the frequency, the
>>> period reduces, so I can see more of the imposed modulation.
>>>
>>> So, forgive my ignorance, but how does one correct this?
>>>
>>> thanks very much!
>>>
>>>
>>> Steven Knudsen, Ph.D., P.Eng.
>>> www. techconficio.ca <http://techconficio.ca/> <http://techconficio.ca
>>> <http://techconficio.ca/>>
>>> www.linkedin.com/in/knudstevenknudsen
>>> <http://www.linkedin.com/in/knudstevenknudsen>
>>> <http://www.linkedin.com/in/knudstevenknudsen
>>> <http://www.linkedin.com/in/knudstevenknudsen>>
>>>
>>> /Von einem gewissen Punkt an gibt es keine R?ckkehr mehr. Dieser Punkt
>>> ist zu erreichen. - Franz Kafka/
>>>
>>>> On Sep 15, 2016, at 10:57, Torell, Kent <kent.tor...@gd-ms.com
>>>> <mailto:kent.tor...@gd-ms.com>
>>>> <mailto:kent.tor...@gd-ms.com <mailto:kent.tor...@gd-ms.com>>> wrote:
>>>>
>>>> It?s a low frequency carrier error, so you are seeing the bpsk roll
>>>> into the other quadrature, then invert data.
>>>>
>>>> *From:* USRP-users [mailto:usrp-users-boun...@lists.ettus.com] *On
>>>> Behalf Of *Steven Knudsen via USRP-users
>>>> *Sent:* Thursday, September 15, 2016 9:50 AM
>>>> *To:* USRP-users
>>>> *Cc:* Knud
>>>> *Subject:* [USRP-users] B200mini and low-freq modulation of tx'd signal
>>>>
>>>> Hi,
>>>>
>>>> I have a TDMA flowgraph that defines packets using tx_time and tx_sob
>>>> + tx_eob. Packets are sent to a B200mini every 10 ms (which is not
>>>> important). Below I have the packet format from GRC followed by 3
>>>> oscilloscope captures that show the effect I?m seeing.
>>>>
>>>> The B200mini is connected to an Octoclock 1 PPS reference.
>>>>
>>>> The modulation is BPSK, 2x oversampled, RRC.
>>>>
>>>> Image 1 - the GRC waveform that is input to the USRP sink
>>>> Image 2 - this time the transmitted signal looks pretty good. Note the
>>>> leading zeros so that the transmit power rises to full before samples
>>>> are applied.
>>>> Image 3 - it appears that some form of slow modulation has been applied
>>>> Image 4 - same again, but obviously at a different offset
>>>>
>>>> (oops, forgot to turn off stupid network config menu in scope caps)
>>>>
>>>> I am a bit stumped. A ?theory? is that maybe I?m seeing a window of
>>>> some kind being convolved with the signal.
>>>>
>>>> <image001.png>
>>>>
>>>> <image002.jpg>
>>>>
>>>> <image003.jpg>
>>>>
>>>> <image004.jpg>
>>>>
>>>>
>>>> Steven Knudsen, Ph.D., P.Eng.
>>>> www. techconficio.ca <http://techconficio.ca/> <http://techconficio.ca/
>>>> <http://techconficio.ca/>>
>>>> www.linkedin.com/in/knudstevenknudsen
>>>> <http://www.linkedin.com/in/knudstevenknudsen>
>>>> <http://www.linkedin.com/in/knudstevenknudsen
>>>> <http://www.linkedin.com/in/knudstevenknudsen>>
>>>>
>>>> /Der entscheidende Augenblick der menschlichen Entwicklung
>>>> ist immerw?hrend. Darum sind die revolution?ren geistigen Bewegungen,
>>>> welche alles Fr?here f?r nichtig erkl?ren, im Recht, denn es ist
>>>> noch nichts geschehen. - Franz Kafka/
>>>>
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160921/d450827c/attachment-0001.html>
>
> ------------------------------
>
> Message: 10
> Date: Wed, 21 Sep 2016 18:39:15 +0000 (UTC)
> From: ti...@comcast.net
> To: usrp-users <usrp-users@lists.ettus.com>
> Subject: [USRP-users] Fwd: Example code for a pair of TwinRXs
> Message-ID:
> <944259256.27355223.1474483155933.javamail.zim...@comcast.net>
> Content-Type: text/plain; charset="utf-8"
>
> Ahhh, I see what you are saying...
>
> AFIK, the only thing that requires timed commands is freq tuning...
>
> I never use timed commands to set gain or sample rate, and thinking about it,
> I am not sure what it would mean to set the sample rate across all channels
> at the same time...
>
> Try just using timed commands for freq tuning and use time spec for initial
> sample recv...
>
> ----- Original Message -----
>
> From: "d.des" <d....@sbcglobal.net>
> To: ti...@comcast.net
> Sent: Wednesday, September 21, 2016 12:19:58 PM
> Subject: Re: [USRP-users] Example code for a pair of TwinRXs
>
> Thanks for the note. The issue seems to be related to uhd not honoring
> the requested sample rate when submitted with a timed command (at least
> the way I'm doing it). If I don't use a time command the channels are
> out of sync. Somehow these radios aren't getting created at the same
> time, it's not much use as a multi-channel system as is.
>
> On Tue, 2016-09-20 at 15:00 +0000, ti...@comcast.net wrote:
>> 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)...
>>
>> 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/20160921/c946423f/attachment-0001.html>
>
> ------------------------------
>
> Message: 11
> Date: Wed, 21 Sep 2016 20:07:54 +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: <1474488474.10655.11.ca...@sbcglobal.net>
> Content-Type: text/plain; charset="UTF-8"
>
>> .Timed commands are largely designed for daughterboard commands, and?
> setting the sample rate isn't a daughterboard command.
> ???Further, setting sample-rate doesn't need to be made precisely?
> synchronous, neither, strictly-speaking, does gain.
>
>> The only part of it where timed-commands are crucial is in tuning,
> where?
> the timed-commands will arrange for phase-syncrhonization.
>
> OK, that's fine.??I switched to non-timed versions of gain and rate,
> trying them first before and then after the timed set_rx_freq call.??I
> also tried setting freq twice to avoid the error mentioned a while back
> about frequencies not being compatible with shared LO mode.??No matter
> what I try with any of the UHD host and image sets that I have the
> second pair of receivers starts 8-20 microseconds after the first pair
> and the phase differences between channels are not constant.??Have the
> changes mentioned in the September 5th message on phase offset been
> introduced into a version of UHD that I have access to???It seems that
> at that point someone had created a custom patch by missing bits from
> master and maint branches.??There was talk about a new X300_HG image
> being posted "tomorrow" but I can't figure out where it and the
> corresponding host code would be (github? files.ettus.com?).
>
>
>
> ------------------------------
>
> Message: 12
> Date: Wed, 21 Sep 2016 14:52:01 -0600
> From: Martin Braun <martin.br...@ettus.com>
> To: usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] N210 'benchmark_rate' interpretation in a
> Docker container
> Message-ID: <57e2f2f1.4070...@ettus.com>
> Content-Type: text/plain; charset=windows-1252
>
>
>
>
> ------------------------------
>
> Message: 13
> Date: Wed, 21 Sep 2016 16:54:13 -0400
> From: EJ Kreinar <ejkrei...@gmail.com>
> To: usrp-users@lists.ettus.com
> Subject: [USRP-users] How to periodically re-output CVITA time tag
> Message-ID:
> <cadrnh23rc4tsodgocszkrfa7fwyuwdpyuqvjdo17wx30s2+...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi all,
>
> I'm working on a TDOA application where I need to maintain time
> synchronization between two (or more) USRPs within the timing accuracies of
> a GPS receiver. For background information, we are currently testing both
> E310 and B200 hardware. In the future, we would like to move towards the
> E310 platform running the RFNoC architecture. A few timing related
> questions here:
>
>
> 1. We see a failure case where occasionally the GPSDO loses lock and causes
> tens of microseconds of error before re-locking, particularly on the B200.
> We would like to be able to handle this error gracefully by periodically
> propagating a new, correct time tag from the FPGA to our flowgraph (say
> once every 10 seconds or so). Is this operation supported? If so, how do I
> generate a new time tag?
>
> I assume I also need to reset the FPGA's cvita_time based on the GPS PPS
> timestamp, which I can currently do successfully, but I cannot find a
> process (yet) to cause this time to propagate into the flowgraph as a new
> time tag without restarting the data flow or dropping a sample.
>
>
> 2. Is the FPGA's cvita_time expressed in units of "ticks" of the radio
> master clock rate? (I was confused by some documentation indicating the
> cvita_time is a "fractional time"
> http://files.ettus.com/manual/page_rtp.html) How is this radio master clock
> rate set?
>
>
> Thanks!
> EJ
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160921/3074ef5a/attachment-0001.html>
>
> ------------------------------
>
> Message: 14
> Date: Wed, 21 Sep 2016 14:00:53 -0700
> From: Derek Kozel <derek.ko...@ettus.com>
> To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
> Cc: "d.des" <d....@sbcglobal.net>, Samuel Dudley
> <dudley.sam...@gmail.com>
> Subject: Re: [USRP-users] Example code for a pair of TwinRXs
> Message-ID:
> <CAA+K=ttx+_HMk=rz8kgpwc1vtzwfa-bdqqefmyyl-cct3cm...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello Sam and Dave,
>
> I've sent you emails directly with the FPGA image attached. It is too big
> to fit on the mailing list so if anyone else needs it please let me know.
>
> I am publicly posting the GNU Radio flowgraph which I use to spot check
> phase offset repeatability in case it is useful to others. It uses timed
> commands so is in Python rather than GRC. It would be possible to use the
> controlport of the USRP Source to do a pure GRC version.
>
> There is an example of tuning using controlport messages included in gr-uhd.
> https://github.com/gnuradio/gnuradio/blob/master/gr-uhd/
> examples/grc/uhd_msg_tune.grc
>
> The MUSIC demo was not shown as a talk during the conference so there is no
> video or slidedeck from it. The code is undergoing some final cleanup,
> testing, and documentation before being made available as a GNU Radio out
> of tree module. There will be an application note discussing it on the
> Ettus Knowledge Base as well.
>
> The C++ example and GRC only flowgraphs are not yet ready and I will post
> to this thread when they are.
>
> Regards,
> Derek
>
>
>
> On Wed, Sep 21, 2016 at 1:07 PM, d.des via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>>> .Timed commands are largely designed for daughterboard commands, and
>> setting the sample rate isn't a daughterboard command.
>> Further, setting sample-rate doesn't need to be made precisely
>> synchronous, neither, strictly-speaking, does gain.
>>
>>> The only part of it where timed-commands are crucial is in tuning,
>> where
>> the timed-commands will arrange for phase-syncrhonization.
>>
>> OK, that's fine. I switched to non-timed versions of gain and rate,
>> trying them first before and then after the timed set_rx_freq call. I
>> also tried setting freq twice to avoid the error mentioned a while back
>> about frequencies not being compatible with shared LO mode. No matter
>> what I try with any of the UHD host and image sets that I have the
>> second pair of receivers starts 8-20 microseconds after the first pair
>> and the phase differences between channels are not constant. Have the
>> changes mentioned in the September 5th message on phase offset been
>> introduced into a version of UHD that I have access to? It seems that
>> at that point someone had created a custom patch by missing bits from
>> master and maint branches. There was talk about a new X300_HG image
>> being posted "tomorrow" but I can't figure out where it and the
>> corresponding host code would be (github? files.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/e4bddf61/attachment-0001.html>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: twinrx_four_channel_phase_check.py
> Type: text/x-python
> Size: 19356 bytes
> Desc: not available
> URL:
> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160921/e4bddf61/attachment-0001.py>
>
> ------------------------------
>
> Message: 15
> Date: Wed, 21 Sep 2016 16:03:17 -0600
> From: Martin Braun <martin.br...@ettus.com>
> To: usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] How to periodically re-output CVITA time tag
> Message-ID: <57e303a5.30...@ettus.com>
> Content-Type: text/plain; charset=windows-1252
>
> On 09/21/2016 02:54 PM, EJ Kreinar via USRP-users wrote:
>> Hi all,
>>
>> I'm working on a TDOA application where I need to maintain time
>> synchronization between two (or more) USRPs within the timing accuracies
>> of a GPS receiver. For background information, we are currently testing
>> both E310 and B200 hardware. In the future, we would like to move
>> towards the E310 platform running the RFNoC architecture. A few timing
>> related questions here:
>>
>>
>> 1. We see a failure case where occasionally the GPSDO loses lock and
>> causes tens of microseconds of error before re-locking, particularly on
>> the B200. We would like to be able to handle this error gracefully by
>> periodically propagating a new, correct time tag from the FPGA to our
>> flowgraph (say once every 10 seconds or so). Is this operation
>> supported? If so, how do I generate a new time tag?
> EJ,
>
> every data packet coming from the radio is timestamped. Your recv() call
> will also return the metadata, which in turn includes the timestamp.
>
>> I assume I also need to reset the FPGA's cvita_time based on the GPS PPS
>> timestamp, which I can currently do successfully, but I cannot find a
>> process (yet) to cause this time to propagate into the flowgraph as a
>> new time tag without restarting the data flow or dropping a sample.
> Ah, you want to inject it into a GNU Radio flow graph? There's no option
> to do that right now, but it's something that we'll need to add at some
> point. However, you can modify the rfnoc_block_impl.cc to parse the
> metadata and generate CVITA times. Look for the recv() calls, and you
> can then poke the rx_metadata_t object that's returned from there.
>
>
>> 2. Is the FPGA's cvita_time expressed in units of "ticks" of the radio
>> master clock rate? (I was confused by some documentation indicating the
> Yes.
>
>> cvita_time is a "fractional
>> time" http://files.ettus.com/manual/page_rtp.html) How is this radio
>> master clock rate set?
> On the E310, it's what you pass in with the master_clock_rate device
> arg, or the value of the sampling rate you set on the RFNoC block.
>
> Cheers,
> Martin
>
>
>
> ------------------------------
>
> Message: 16
> Date: Thu, 22 Sep 2016 09:16:39 +1000
> From: Walter Maguire <wmagu...@iinet.net.au>
> To: usrp-users@lists.ettus.com
> Subject: [USRP-users] RFNoC without a Radio Core
> Message-ID: <54359327-0e6f-dd1a-de2a-398e9ccbd...@iinet.net.au>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> Hi all,
>
> I didn't seem to get a response that my submission was successful so I
> though I might send it again.
>
> "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
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160922/93a2edf0/attachment-0001.html>
>
> ------------------------------
>
> Message: 17
> Date: Wed, 21 Sep 2016 19:24:38 -0400
> From: "Marcus D. Leech" <mle...@ripnet.com>
> To: usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] RFNoC without a Radio Core
> Message-ID: <57e316b6.7050...@ripnet.com>
> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>
> On 09/21/2016 07:16 PM, Walter Maguire via USRP-users wrote:
>> Hi all,
>>
>> I didn't seem to get a response that my submission was successful so I
>> though I might send it again.
>>
>> "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
>>
>>
> Martin Braun answered this on the list earlier today:
>
> On 09/19/2016 10:01 PM, Walter Maguire via USRP-users wrote:
>
>> 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.
> Walter,
>
> the radio blocks are not special in an RFNoC sense (they are only
> differently connected in the FPGA, as they have more I/Os than other
> blocks).
> If you have no radios, you will see a warning ("No Radio Block found.
> Assuming radio-less operation."), but it's really not a critical warning.
>
>
>> 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.
> As said before, radios are regular blocks, and taking them out will not
> break anything. The AD9361 will not be activated in that case, either.
>
> Martin
>
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160921/47795bdc/attachment-0001.html>
>
> ------------------------------
>
> Message: 18
> Date: Thu, 22 Sep 2016 09:31:05 -0400
> From: Michael Dickens <michael.dick...@ettus.com>
> To: discuss-gnura...@gnu.org, usrp-users@lists.ettus.com
> Subject: [USRP-users] Volk / UHD / GR on macOS 10.12 Sierra
> Message-ID:
> <1474551065.2587209.733765089.59cd4...@webmail.messagingengine.com>
> Content-Type: text/plain
>
> Apple released its latest OS earlier this week, now called "macOS" (was
> Mac OS X): 10.12.0, codename "Sierra". The vast majority of projects
> that built for 10.11 and prior continue to work with 10.12, including
> Volk, UHD, and GNU Radio. In MacPorts, I committed changes to Qt4
> (qt4-mac) to allow it to build on 10.5 through 10.12, so the gr-QtGui
> and related Qt features all seem to work properly. All of Volk, UHD, and
> GNU Radio and their dependencies all seem to build, test, and install
> cleanly in Sierra. As a -notable- benefit: 10.12 also includes updated
> graphics drivers that allow gr-fosphor to work out of the box again; the
> graphics drivers in 10.11 were broken for some computers, and required a
> non-Apple sanctioned update from NVIDIA that many people (including me)
> were hesitant to try. I'm not usually a proponent of adopting a new
> major Apple OS before the ".2" release, but thus far Sierra is working
> very nicely and contains some useful fixes under the hood -- hence, I'm
> cautiously endorsing updating if you have a Mac and want to do so.
> Cheers! - MLD
>
> ps> If you are running Mac OS X 10.11 or prior: DO NOT update to Xcode
> 8! Keep using Xcode 7 or prior. The best work-around if you have updated
> is to reinstall Xcode 7 or prior. Xcode 8 defaults to using the build
> SDK for 10.12, which is fine if you're running 10.12 but NOT fine if
> you're running 10.11 or prior. There are supposedly wants to coerce
> Xcode 8 into working in this situation, but the results are not
> guaranteed. Hence, my advice is to just not update, or revert back if
> you have already updated.
>
>
>
> ------------------------------
>
> Message: 19
> Date: Thu, 22 Sep 2016 14:09:35 +0000
> From: "Perelman, Nathan" <nperel...@lgsinnovations.com>
> To: Ben Hilburn via USRP-users <usrp-users@lists.ettus.com>
> Subject: Re: [USRP-users] UBX-160 Performance < 500 MHz
> Message-ID: <3bd90cac6a5d4065b6743ddd48f35...@lgs-ex01.lgsdirect.com>
> Content-Type: text/plain; charset="utf-8"
>
> Does this affect the UBX-40 as well?
>
>
>
> From: USRP-users [mailto:usrp-users-boun...@lists.ettus.com] On Behalf Of
> Michael West via USRP-users
> Sent: Tuesday, September 20, 2016 1:05 PM
> To: Michael Wentz
> Cc: USRP-users@lists.ettus.com
> Subject: Re: [USRP-users] UBX-160 Performance < 500 MHz
>
>
>
> 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/20160922/7fdc9c70/attachment-0001.html>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/pkcs7-signature
> Size: 4353 bytes
> Desc: not available
> URL:
> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160922/7fdc9c70/attachment-0001.p7s>
>
> ------------------------------
>
> 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 20
> ******************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160923/de012917/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ehckakflekhamghj.png
Type: image/png
Size: 230943 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160923/de012917/attachment-0001.png>
------------------------------
Message: 14
Date: Thu, 22 Sep 2016 17:39:26 +0530
From: Kavyashree Tm <tmkavyash...@gmail.com>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] USRP X310 connection problem
Message-ID:
<cadmjwmxwnq7phrbuhkwfok1e9zb81obpljh1qldreme4aex...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I am using USRP x310. But when i connect the device via Ethernet cable to
the PC. i am not able to switch my Host address to 192.168.10.1. however
some days back i got a successful result with uhd_find_devices. but now
facing this problem. is there any issue with the device i am using?
please help me out
thanking you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160922/2b97d582/attachment-0001.html>
------------------------------
Message: 15
Date: Thu, 22 Sep 2016 23:45:18 -0700
From: Frank Liu <frank.zi...@gmail.com>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Ignoring buffer overflows
Message-ID:
<CAMZy46ZvNhsxJO8ar=jwdeawywyvq6v3w2b_59bvjdg_udr...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
We're currently developing a demo around 4 USRP X310s, each of which is
connected to a host PC through a gigabit ethernet switch. The host PC is
using the GNU Radio interface to UHD installed via apt-get. Through a bit
of trail and error, we've been able to receive ~9000 contiguous samples @
100M samples/second from one USRP at a time before an overflow occurs.
We're assuming that the overflows are due to limitations in the connection
capacity.
Despite this, large chunks of dropped samples are a non-issue for our
application. We're more concerned about maintaining an extremely high
sampling rate and acquiring short bursts of contiguous samples. However, we
noticed that overflows cause the radio to re-initialize the RF front-end
boards, which results in a rather undesirable transient behavior (see
attachment). Is there any way to "ignore" these buffer overflows?
If this requires us to modify and recompile any host-side UHD code, we're
happy to do it.
Thanks in advance!
Best,
Frank Liu
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160922/0f226378/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: figure_0.png
Type: image/png
Size: 111466 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160922/0f226378/attachment-0001.png>
------------------------------
Message: 16
Date: Fri, 23 Sep 2016 00:09:55 -0700
From: Nate Temple <nate.tem...@ettus.com>
To: Kavyashree Tm <tmkavyash...@gmail.com>
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP X310 connection problem
Message-ID: <5b7f425a-a0b2-413c-9c17-93e164591...@ettus.com>
Content-Type: text/plain; charset=us-ascii
Hello Kavyashree:
What do you mean by "you are not able to switch the host address to
192.168.10.1" ? You will need the host computer on the same subnet as the X310
in order to ping/connect to it.
Regards,
Nate
> On Sep 22, 2016, at 5:09 AM, Kavyashree Tm via USRP-users
> <usrp-users@lists.ettus.com> wrote:
>
> I am using USRP x310. But when i connect the device via Ethernet cable to the
> PC. i am not able to switch my Host address to 192.168.10.1. however some
> days back i got a successful result with uhd_find_devices. but now facing
> this problem. is there any issue with the device i am using?
> please help me out
>
>
>
> thanking you.
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 17
Date: Fri, 23 Sep 2016 10:57:07 +0200
From: Nives Novkovi? <novkovic.ni...@gmail.com>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Implementing design on FPGA in X310
Message-ID:
<calutkdbsscy7qbhqb6y58j8gjlpudye7tnfr66ngztrxvlu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello again,
I was wondering about implementing new functionalities on the FPGA in X310.
If I would like the FPGA to maintain its current funcionality and I want to
add something new but without erasing the pre-existing one, how do I do
that? Thank you in advance.
Kind regards,
Nives
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160923/f5536830/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 21
******************************************
