Send USRP-users mailing list submissions to
        [email protected]

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
        [email protected]

You can reach the person managing the list at
        [email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."


Today's Topics:

   1. Re: External power to the B200 (Marcus M?ller)
   2. Problem about LiveUSB SDR installation (Yan Huang)
   3. Re: Problem about LiveUSB SDR installation (Derek Kozel)
   4. Re: Unable to create Vivado projekt or to build clean     repo
      (James Wagner)
   5. Is there an easy way to create a timestamp in a read only
      register in rfnoc to verify the .bit file is what we just
      generated? (Swanson, Craig)
   6. Re: Unable to create Vivado projekt or to build clean     repo
      (Jonathon Pendlum)
   7. Re: Is there an easy way to create a timestamp in a read only
      register in rfnoc to verify the .bit file is what we just
      generated? (Ian Buckley)
   8. Re: E310 Clock Synchronization with internal GPS (Ian Buckley)
   9. Re: Frequency synchronization problem (Marc Bauduin)
  10. switching between TX/RX and RX2 for SBX-120 (Sanjoy Basak)
  11. Re: switching between TX/RX and RX2 for SBX-120 (Derek Kozel)
  12. Adding list of files to RFNoC build (Jason Matusiak)


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

Message: 1
Date: Wed, 27 Apr 2016 18:09:39 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] External power to the B200
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"

Yes, that's the case; there's an automatic switchover if external
voltage is supplied; the LTC4412 is a dedicated chip for this:
b200 power switching circuit

Best regards,
Marcus
On 04/27/2016 05:38 PM, John Petrich via USRP-users wrote:
>
>  
>
> Are there any things that I need to consider to power the B200 from an
> external 6 volt power supply?  Am cautious about the combination of
> the powered USB 3 data link and external power supply.  Not sure if
> that combination will cause problems.  It is likely that the power
> switching is likely accomplished automatically and internal to the
> B200 but want to be sure.
>
>  
>
> Regards,
>
> John Petrich
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160427/ce13077e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: b200_power.png
Type: image/png
Size: 12094 bytes
Desc: not available
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160427/ce13077e/attachment-0001.png>

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

Message: 2
Date: Wed, 27 Apr 2016 17:45:29 +0000
From: Yan Huang <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Problem about LiveUSB SDR installation
Message-ID:
        
<13e785ad7846974289da28b82fc109be0528e...@uiwexmbx07.ad.nottingham.ac.uk>
        
Content-Type: text/plain; charset="us-ascii"

Hi all,

I want to install a LiveUSB follow the instruction on the Ettus 
website:http://files.ettus.com/liveusb/3.0/How_To_Install.txt

I use a 64G USB which I have installed as a LiveUSB SDR, but after I upgraded 
UHD , it is incompatible with GRC. So I formatting the USB and reinstall the 
LiveUSB SDR.

But after I install I cannot boost it as before. when I insert it in windows 
computer I cannot open it and shows 'you need to format the disk in 
friveE:before you can use it' and
'E:\is not accessible.The volume does not contain a recognized file system'.

Do I miss anything important? Hoping you give me some advice.

Many thanks,
Yan




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.

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

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

Message: 3
Date: Wed, 27 Apr 2016 11:09:02 -0700
From: Derek Kozel <[email protected]>
To: Yan Huang <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Problem about LiveUSB SDR installation
Message-ID:
        <CAA+K=tvtjdyum4s4-n1rrcgbccbwfgnddtsa_fzzvwo56yc...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hello Yan,

The Ettus Live USB has not updated in some time. We recommend using the GNU
Radio Live SDR Environment instead.
http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD

Regards,
Derek

On Wed, Apr 27, 2016 at 10:45 AM, Yan Huang via USRP-users <
[email protected]> wrote:

> Hi all,
>
>
>
> I want to install a LiveUSB follow the instruction on the Ettus website:
> http://files.ettus.com/liveusb/3.0/How_To_Install.txt
>
>
>
> I use a 64G USB which I have installed as a LiveUSB SDR, but after I
> upgraded UHD , it is incompatible with GRC. So I formatting the USB and
> reinstall the LiveUSB SDR.
>
>
>
> But after I install I cannot boost it as before. when I insert it in
> windows computer I cannot open it and shows ?you need to format the disk in
> friveE:before you can use it? and
>
> ?E:\is not accessible.The volume does not contain a recognized file
> system?.
>
>
>
> Do I miss anything important? Hoping you give me some advice.
>
>
>
> Many thanks,
>
> Yan
>
>
>
> This message and any attachment are intended solely for the addressee
> and may contain confidential information. If you have received this
> message in error, please send it back to me, and immediately delete it.
>
> Please do not use, copy or disclose the information contained in this
> message or in any attachment.  Any views or opinions expressed by the
> author of this email do not necessarily reflect the views of the
> University of Nottingham.
>
> This message has been checked for viruses but the contents of an
> attachment may still contain software viruses which could damage your
> computer system, you are advised to perform your own checks. Email
> communications with the University of Nottingham may be monitored as
> permitted by UK legislation.
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160427/b20263df/attachment-0001.html>

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

Message: 4
Date: Wed, 27 Apr 2016 11:27:24 -0700
From: James Wagner <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: Patrick Berger <[email protected]>,
        "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Unable to create Vivado projekt or to build
        clean   repo
Message-ID:
        <ca+usookpdkqbnf4ghperlfdump8mqmf52_oxtdarqeg0enz...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Johnathon,
Thanks, 'make cleanall' seems to resolve the problem although 'make clean'
does not.

I noticed that both the original poster and I had 2015.4 so maybe this is
an issue with it trying to use 2015.4 IP unless you force the script to
clear all previous IP.

On Tue, Apr 26, 2016 at 9:14 AM, Jonathon Pendlum <
[email protected]> wrote:

> Hi James,
>
> Did you try running 'make cleanall' and building again?
>
>
>
> Jonathon
>
> On Mon, Apr 25, 2016 at 2:36 PM, James Wagner <[email protected]>
> wrote:
>
>> I am also getting the same error.
>>
>> this is an attempt to build the base RFNOC HGS image with no change in
>> the utilized blocks.
>>
>> I run
>>
>> source setupenv.sh --vivado-path=/home/sdr-dev/xilinx/Vivado
>>
>> which outputs the following
>>
>> Setting up X3x0 FPGA build environment (64-bit)...
>> bash:
>> /home/sdr-dev/xilinx/Vivado_HLS/2015.2/.settings64-Vivado_High_Level_Synthesis.sh:
>> No such file or directory
>> bash: /opt/Xilinx/DocNav/.settings64-DocNav.sh: No such file or directory
>> - Vivado: Found (/home/sdr-dev/xilinx/Vivado/2015.2/bin)
>>
>> Environment successfully initialized.
>>
>>
>>
>> I then run the command
>>
>> make X310_RFNOC_HGS
>>
>> yielding a message saying
>>
>>
>> INFO: [Common 17-206] Exiting Webtalk at Mon Apr 25 14:31:25 2016...
>> INFO: [Vivado 12-3441] generate_netlist_ip - operation complete
>> synth_ip: Time (s): cpu = 00:00:58 ; elapsed = 00:01:17 . Memory (MB):
>> peak = 1857.766 ; gain = 970.414 ; free physical = 4787 ; free virtual =
>> 14137
>> # if [string match $gen_example_proj "1"] {
>> #     puts "BUILDER: Generating Example Design..."
>> #     open_example_project -force -dir . [get_ips $ip_name]
>> # }
>> BUILDER: Generating Example Design...
>> ERROR: [Common 17-69] Command failed: * The IP Data in the repository is
>> incompatible with the current instance (despite having identical Version
>> and Revision). You will need to update the IP before viewing the
>> customization and generating outputs.
>> * IP file
>> '/home/sdr-dev/repo/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/ten_gig_eth_pcs_pma/ten_gig_eth_pcs_pma.xml'
>> for IP 'ten_gig_eth_pcs_pma' contains stale content.
>> Please select 'Report IP Status' from the 'Tools/Report' menu or run Tcl
>> command 'report_ip_status' for more information.
>> INFO: [Common 17-206] Exiting Vivado at Mon Apr 25 14:31:25 2016...
>> Releasing IP location:
>> /home/sdr-dev/repo/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/ten_gig_eth_pcs_pma
>> make[1]: ***
>> [/home/sdr-dev/repo/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/ten_gig_eth_pcs_pma/ten_gig_eth_pcs_pma.xci.out]
>> Error 1
>> make[1]: Leaving directory
>> `/home/sdr-dev/repo/uhd/fpga-src/usrp3/top/x300'
>> make: *** [X310_RFNOC_HGS] Error 2
>>
>>
>>
>>
>>
>> On Sun, Apr 10, 2016 at 12:52 PM, Jonathon Pendlum via USRP-users <
>> [email protected]> wrote:
>>
>>> Hi Patrick,
>>>
>>> What branch are you on? rfnoc-devel or rfnoc-ofdm? Did you run source
>>> setupenv.sh in the usrp3/top/x300/ directory? What is it output?
>>>
>>>
>>>
>>> Jonathon
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160427/bf366858/attachment-0001.html>

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

Message: 5
Date: Wed, 27 Apr 2016 18:33:24 +0000
From: "Swanson, Craig" <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: Martin Braun <[email protected]>,
        "[email protected]"    <[email protected]>
Subject: [USRP-users] Is there an easy way to create a timestamp in a
        read only register in rfnoc to verify the .bit file is what we just
        generated?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"

Jonathon,

We are starting hardware in the loop debug of our fpga code in an E310 and 
gnuradio companion.


Let's say I generated a new bit file on April 27 at 3:15 pm.

I would would like to embed that day and possible time into a read only 
register in the E310 that could verify either in uhd_usrp_probe or while 
running a flowgraph or python file.


I don't want to use  NOC ID because then I have to load a different XML file 
each time as well, which also means I would need to re-cross compile each time.


What do you suggest?


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>

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

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

Message: 6
Date: Wed, 27 Apr 2016 14:07:53 -0500
From: Jonathon Pendlum <[email protected]>
To: James Wagner <[email protected]>
Cc: Patrick Berger <[email protected]>,
        "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Unable to create Vivado projekt or to build
        clean   repo
Message-ID:
        <cagdo0urdvvfawocgr1jj-w5txj369z_we1xxek_wtxuek5k...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Correct, when the build uses a different Vivado version the old IP needs to
be cleaned with 'make cleanall'. I'll see if we can modify the makefiles to
make that unnecessary or at least less of a hassle.


On Wed, Apr 27, 2016 at 1:27 PM, James Wagner <[email protected]> wrote:

> Johnathon,
> Thanks, 'make cleanall' seems to resolve the problem although 'make clean'
> does not.
>
> I noticed that both the original poster and I had 2015.4 so maybe this is
> an issue with it trying to use 2015.4 IP unless you force the script to
> clear all previous IP.
>
> On Tue, Apr 26, 2016 at 9:14 AM, Jonathon Pendlum <
> [email protected]> wrote:
>
>> Hi James,
>>
>> Did you try running 'make cleanall' and building again?
>>
>>
>>
>> Jonathon
>>
>> On Mon, Apr 25, 2016 at 2:36 PM, James Wagner <[email protected]>
>> wrote:
>>
>>> I am also getting the same error.
>>>
>>> this is an attempt to build the base RFNOC HGS image with no change in
>>> the utilized blocks.
>>>
>>> I run
>>>
>>> source setupenv.sh --vivado-path=/home/sdr-dev/xilinx/Vivado
>>>
>>> which outputs the following
>>>
>>> Setting up X3x0 FPGA build environment (64-bit)...
>>> bash:
>>> /home/sdr-dev/xilinx/Vivado_HLS/2015.2/.settings64-Vivado_High_Level_Synthesis.sh:
>>> No such file or directory
>>> bash: /opt/Xilinx/DocNav/.settings64-DocNav.sh: No such file or directory
>>> - Vivado: Found (/home/sdr-dev/xilinx/Vivado/2015.2/bin)
>>>
>>> Environment successfully initialized.
>>>
>>>
>>>
>>> I then run the command
>>>
>>> make X310_RFNOC_HGS
>>>
>>> yielding a message saying
>>>
>>>
>>> INFO: [Common 17-206] Exiting Webtalk at Mon Apr 25 14:31:25 2016...
>>> INFO: [Vivado 12-3441] generate_netlist_ip - operation complete
>>> synth_ip: Time (s): cpu = 00:00:58 ; elapsed = 00:01:17 . Memory (MB):
>>> peak = 1857.766 ; gain = 970.414 ; free physical = 4787 ; free virtual =
>>> 14137
>>> # if [string match $gen_example_proj "1"] {
>>> #     puts "BUILDER: Generating Example Design..."
>>> #     open_example_project -force -dir . [get_ips $ip_name]
>>> # }
>>> BUILDER: Generating Example Design...
>>> ERROR: [Common 17-69] Command failed: * The IP Data in the repository is
>>> incompatible with the current instance (despite having identical Version
>>> and Revision). You will need to update the IP before viewing the
>>> customization and generating outputs.
>>> * IP file
>>> '/home/sdr-dev/repo/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/ten_gig_eth_pcs_pma/ten_gig_eth_pcs_pma.xml'
>>> for IP 'ten_gig_eth_pcs_pma' contains stale content.
>>> Please select 'Report IP Status' from the 'Tools/Report' menu or run Tcl
>>> command 'report_ip_status' for more information.
>>> INFO: [Common 17-206] Exiting Vivado at Mon Apr 25 14:31:25 2016...
>>> Releasing IP location:
>>> /home/sdr-dev/repo/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/ten_gig_eth_pcs_pma
>>> make[1]: ***
>>> [/home/sdr-dev/repo/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/ten_gig_eth_pcs_pma/ten_gig_eth_pcs_pma.xci.out]
>>> Error 1
>>> make[1]: Leaving directory
>>> `/home/sdr-dev/repo/uhd/fpga-src/usrp3/top/x300'
>>> make: *** [X310_RFNOC_HGS] Error 2
>>>
>>>
>>>
>>>
>>>
>>> On Sun, Apr 10, 2016 at 12:52 PM, Jonathon Pendlum via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> Hi Patrick,
>>>>
>>>> What branch are you on? rfnoc-devel or rfnoc-ofdm? Did you run source
>>>> setupenv.sh in the usrp3/top/x300/ directory? What is it output?
>>>>
>>>>
>>>>
>>>> Jonathon
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160427/60afe26b/attachment-0001.html>

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

Message: 7
Date: Wed, 27 Apr 2016 12:14:46 -0700
From: Ian Buckley <[email protected]>
To: "Swanson, Craig" <[email protected]>
Cc: Jonathon Pendlum <[email protected]>,
        "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Is there an easy way to create a timestamp
        in a read only register in rfnoc to verify the .bit file is what we
        just generated?
Message-ID:
        <cam_0ocfmwah2_dvizx9forfcbksj-bkrn0k9u6erfocjweu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Craig, FWIW and nothing to do with the current Ettus build environment.
As part of my make environment for an FPGA build I call a .tcl script that
sources current time and date from the host as well as a short git hash,
then use them as initialization parameters for predefined registers in the
RTL. For example:

set git_rev [exec git rev-parse --short=8 HEAD]
set year [exec date -u +%Y]
etc...

-Ian


On Wed, Apr 27, 2016 at 11:33 AM, Swanson, Craig via USRP-users <
[email protected]> wrote:

> Jonathon,
>
> We are starting hardware in the loop debug of our fpga code in an E310 and
> gnuradio companion.
>
>
> Let's say I generated a new bit file on April 27 at 3:15 pm.
>
> I would would like to embed that day and possible time into a read
> only register in the E310 that could verify either in uhd_usrp_probe or
> while running a flowgraph or python file.
>
>
> I don't want to use  NOC ID because then I have to load a different XML
> file each time as well, which also means I would need to re-cross compile
> each time.
>
>
> What do you suggest?
>
>
> 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 <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>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160427/f3058313/attachment-0001.html>

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

Message: 8
Date: Wed, 27 Apr 2016 12:18:43 -0700
From: Ian Buckley <[email protected]>
To: Kyle A Logue <[email protected]>
Cc: "[email protected]" <[email protected]>,  Ettus Mail List
        <[email protected]>
Subject: Re: [USRP-users] E310 Clock Synchronization with internal GPS
Message-ID:
        <CAM_0ocGs5-MKAY+rN5rK0gd9fkEVCWEAx7DCv=reo8bzhse...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Kyle,
You'll note that Paul said 3.8.5 *not* 3.9.5
-Ian


On Wed, Apr 27, 2016 at 8:51 AM, Kyle A Logue via USRP-users <
[email protected]> wrote:

> A quick correction:
>
>
> I said this problem was unresolved in 3.10.x but that is not strictly
> true. It is unresolved in the E310 Release 4 image which is using 3.9.2.
>
>
> Paul Garver posted to the mailing list today this tidbit:
>
>
> For others who may be searching this same topic, I?ll provide an update.
> We had an error in our metadata recording code which was causing the mean
> time delay estimation between multiple B200s to be on the order of
> microseconds (~25uS) at 25 MSPS. Now, we have all three B200s sync?d within
> a sample on UHD 3.8.5 using a timing reference and 10 MHz/1PPS. The sample
> mean is around 40nS and the sample variance is extremely low (reads zero).
> To do better than this, I presume we will need to compensate for the random
> phase by calibrating on every run / retune.
>
> We use our custom recording tool in gr-analysis to record the times, which
> looks like it time-tags accurately as long as the correct segment size is
> given (default is OK).
> https://github.com/garverp/gr-analysis
>
> Does this seem reasonable? Does anyone else have time alignment results
> for the B200 they would care to share?
>
> PWG
>
> Which may indicate that there is something in UHD 3.9.5+ that could
> address this problem, but i haven't seen any alpha images on
> files.ettus.com newer than release 4.
>
> Something to keep an eye on,
>
> Kyle
>
> ------------------------------
> *From:* USRP-users <[email protected]> on behalf of
> Thierry Guichon via USRP-users <[email protected]>
> *Sent:* Thursday, April 21, 2016 10:34
> *To:* 'USRP Mailing List'
>
> *Subject:* Re: [USRP-users] E310 Clock Synchronization with internal GPS
>
>
> Thank you Marcus and Kyle,
>
>
>
> It looks like anyhow I need to update my image :-)
>
> The offset of 2 microseconds that you are experiencing will not be a
> problem for my application. The offsets that I am currently seeing are more
> in the order of several hundreds milliseconds so there is something
> fundamentally wrong with either my setup or the UHD version that I am using.
>
> I will see what I get after the upgrade.
>
>
>
> Sincerely
>
>
>
> Thierry
>
>
> ------------------------------
>
> *From:* USRP-users [mailto:[email protected]] *On Behalf
> Of *Kyle A Logue via USRP-users
> *Sent:* Thursday, April 21, 2016 1:09 PM
> *To:* Ettus Mail List
> *Subject:* Re: [USRP-users] E310 Clock Synchronization with internal GPS
>
>
>
> Thierry:
>
>
>
> This question has come up so many times and there isn't a proper solution
> for it yet. To me it's the largest outstanding bug in the E310 and a
> deal-killer for several applications.
>
>
>
> You can use my dance for synchronizing the E310 GPS previously posted here:
>
>
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-January/017483.html
>
>
>
> But the best you can do is GPS time +- 2000ns. Even if you use an external
> signal source for time synchronization, the onboard pps trigger is never
> more than 20ns accurate to GPS time. As a quick summary, some of the other
> posts talking about this problem:
>
>
>
>
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-November/016928.html
>
>
> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-November/016928.html>
> http://permalink.gmane.org/gmane.comp.hardware.usrp.e100/18253
>
>
>
> The issue seems to arise from an FPGA pps trigger issue, but it's still
> unresolved in UHD 003.010.x.
>
>
>
> As a side note, you need to be using the Release 4 version of the SD
> image, previous releases used the GPSDO quite differently.
>
>
>
> Good Luck.
>
>
>
> Kyle Logue
>
>
> ------------------------------
>
> *From:* USRP-users <[email protected]> on behalf of
> Marcus D. Leech via USRP-users <[email protected]>
> *Sent:* Thursday, April 21, 2016 07:12
> *To:* [email protected]
> *Subject:* Re: [USRP-users] E310 Clock Synchronization with internal GPS
>
>
>
> On 04/21/2016 09:04 AM, Thierry Guichon via USRP-users wrote:
>
> Hello
>
>
>
>
>
> I am facing a problem with the E310  that I do not encounter when using
> the E100
>
>
>
> Here is the relevant configuration to the device:
>
>
>
> set_time_next_pps(time_spec_t{});  // Set the time at 0 at the next pps
> tick
>
>
>
> #if device == E31X
>
> set_time_source("gpsdo")
>
> #endif
>
>
>
> In both devices, the gps reports to be locked.
>
>
>
>
>
> We then receive a signal which is externally synchronized to the GPS PPS.
>
> When receiving this signal, the E100 correctly reports the reception time
> at a few us after the PPS while the E310 reports this time at a large
> offset after the  PPS. In addition, for the E310, this offset changes each
> time the program is run.
>
>
>
> It appears  as if on the E310 calling set_time_next_pps(time_spec_t{})
> does not set the time at the internal GPS 1 PPS tick? Did I miss a
> configuration step?
>
>
>
> I am using UHD 003.008.005
>
>
>
> If you can, I strongly recommend upgrading your E310 to the latest system
> image, which has a much-more-recent UHD.
>
> Use the image from here:
>
>
> http://files.ettus.com/e3xx_images/e3xx-release-4/ettus-e3xx-sg1/sdimage-gnuradio-dev.direct.xz
>
> Using the instructions here:
>
> http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_upgrade_sd_card
>
>
>
> Also, we're probably going to have to see more of your setup code to make
> a determination about what might be wrong.
>
>
>
>
>
> Thank you
>
>
>
> Thierry
>
>
>
>
>
>
>
> _______________________________________________
>
> USRP-users mailing list
>
> [email protected]
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160427/8114109b/attachment-0001.html>

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

Message: 9
Date: Wed, 27 Apr 2016 22:24:27 +0200
From: Marc Bauduin <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Frequency synchronization problem
Message-ID:
        <ca+ekp-axwcoyly+gx1qxnz41ehv5it0sjurhrt_8ulfl8bx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Thank you for your answer. It was effectively that.I used the
function set_rx_dc_offset(false) to remove the algorithm and I don't
observe this effect anymore when I send a signal constant in baseband.

2016-04-27 15:39 GMT+02:00 Marcus D. Leech via USRP-users <
[email protected]>:

> On 04/27/2016 08:40 AM, Herlook Search via USRP-users wrote:
>
>> Hi everyone,
>>
>> I use two USRP N210 with the RFX2450. I manipulate them in C++.
>>
>> I would like to characterize the USRPs. In that way, I send very simple
>> signals, as a constant signal in baseband. When I send this signal, I
>> observe a circle in baseband due to the CFO. This is what I expected.
>>
>> If I send the same signal when the USRPs are synchronized with the same
>> 10 MHz clock (I use an external square wave generator), I see that the
>> amplitude of this sequence quickly decreases through time. If I use an
>> alternate sequence of {-1;+1}, I also observe that its amplitude decreases.
>>
>> But it seems that the synchronisation works because, when I do an OFDM
>> communication or a single carrier communication with the 10 MHz clock, I
>> can recover my QAM constellation without CFO.
>>
>> Can you confirm that these results are expected from such a
>> configuration? If it is the case, can we avoid them?
>>
>> Thanks in advance.
>>
>> Marc
>>
>> Make sure that your baseband tone is far enough away from DC so as not to
> get swallowed by the DC-offset compensation algorithm, which takes a while
> to converge.
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160427/52979c4e/attachment-0001.html>

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

Message: 10
Date: Thu, 28 Apr 2016 02:05:26 +0200
From: Sanjoy Basak <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] switching between TX/RX and RX2 for SBX-120
Message-ID:
        <cajpq1a0+wscl+aavqosjayymmh6nv5_uw2ag5ptavyuty18...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi all,
I want to perform switching between TX/RX and RX2 port for a TDD kind of
operation with SBX-120 daughterboard. Here, the TX/RX and RX2 both will be
used as receiver.
The transmitted burst will first be received by the TX/RX port and then
switch to the RX2 port and the rest bursts will be received by the RX2
port.

How can I perform such switching operation?

My setup is X310/SBX-120/UHD 3.10

Best regards
Sanjoy Basak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160428/541b00f4/attachment-0001.html>

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

Message: 11
Date: Wed, 27 Apr 2016 18:38:29 -0700
From: Derek Kozel <[email protected]>
To: Sanjoy Basak <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] switching between TX/RX and RX2 for SBX-120
Message-ID:
        <CAA+K=tubb9aji4vuvuc2xiond5am+o+9t28zbxqr14qqpm1...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hello Sanjoy,

The command to change the RX antenna for a channel is set_rx_antenna.
http://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a72b7947cb0c434b98e9915f91b8f8fe0

Your application will have to detect the first burst and issue the command
to change antennas. How much time do you have between bursts? Also, you
must not transmit and receive simultaneously on the same antenna, you will
damage the receive RF chain. If your transmit antenna is too close to the
receive antenna that can also cause damage depending on your transmit power
and receive gain. Can you describe more of your application?

Regards,
Derek

On Wed, Apr 27, 2016 at 5:05 PM, Sanjoy Basak via USRP-users <
[email protected]> wrote:

> Hi all,
> I want to perform switching between TX/RX and RX2 port for a TDD kind of
> operation with SBX-120 daughterboard. Here, the TX/RX and RX2 both will be
> used as receiver.
> The transmitted burst will first be received by the TX/RX port and then
> switch to the RX2 port and the rest bursts will be received by the RX2
> port.
>
> How can I perform such switching operation?
>
> My setup is X310/SBX-120/UHD 3.10
>
> Best regards
> Sanjoy Basak
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160427/2a617a65/attachment-0001.html>

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

Message: 12
Date: Thu, 28 Apr 2016 11:10:31 -0400
From: Jason Matusiak <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Adding list of files to RFNoC build
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed

I am trying to incorporate a previously created VHDL module into RFNoC, 
but am a little confused.  My previous custom blocks have been two files 
only (the module, and the noc_block_module).  What I did in that case 
was to include the two new verilog files in the Makefile.srcs and 
rebuild; this new block has a lot of files that need to be included 
though.  Do I need to go through and figure out the file names and add 
them one-by-one?  Or is there a way to include a folder in the 
Makefile.srcs file so it will just suck everything in?



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

Subject: Digest Footer

_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


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

End of USRP-users Digest, Vol 68, Issue 29
******************************************

Reply via email to