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. Alternatives for uhd_fft in Ubuntu (Dario Fertonani)
      (oscar llerena)
   2. writing to user settings register (Oliver Wayne)
   3. Re: writing to user settings register (Long, Jeffrey P.)
   4. Re: writing to user settings register (Oliver Wayne)
   5. Re: writing to user settings register (Long, Jeffrey P.)
   6. SBX initial saturation (Amirhosein naseri)
   7.  B205i transient behavior (Ivan Kokic)


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

Message: 1
Date: Fri, 28 Apr 2017 09:28:00 -0700
From: oscar llerena <[email protected]>
To: [email protected]
Subject: [USRP-users] Alternatives for uhd_fft in Ubuntu (Dario
        Fertonani)
Message-ID:
        <cacxdq1qkmw2jozg1tqrbtsxsfpddwjbkmmttnqon-l3mgbh...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hello there Dario

Maybe you can find something that helps you here.
https://github.com/cn0xroot/RFSec-ToolKit

Best regards
Jarodcs

On Fri, Apr 28, 2017 at 9:00 AM, <[email protected]> wrote:

> 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: x310 rfnoc fpga code (Jason Matusiak)
>    2. Alternatives for uhd_fft in Ubuntu (Dario Fertonani)
>    3. Re: B210 GPS L1 receiver in Simulink (Mike McLernon)
>    4. [FPGA IMAGES] Image too large to E310 (Rub?n Vogel)
>    5. Re: [FPGA IMAGES] Image too large to E310 (Jonathon Pendlum)
>    6. Re: x310 rfnoc fpga code (Anon Lister)
>    7. Re: x310 rfnoc fpga code (Jason Matusiak)
>    8. Re: x310 rfnoc fpga code (Derek Kozel)
>    9. Issue running UHD via sshfs on E310 (Jessica Iwamoto)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 27 Apr 2017 12:05:33 -0400
> From: Jason Matusiak <[email protected]>
> To: Derek Kozel <[email protected]>, Lihua Ren
>         <[email protected]>
> Cc: "[email protected]" <[email protected]>
> Subject: Re: [USRP-users] x310 rfnoc fpga code
> Message-ID:
>         <[email protected]>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> To expand on what Derek said (because I have fallen into the same rabbit
> hole in the past; Jonathon has said he will remove the option for sample
> rate from the block for the X310 in the future to reduce confusion), the
> X310's RFNoC radio block runs at the system clock of the X310 (default
> of 200MHz; the other options are 100MHz, and 184.32MHz).  You will want
> to set your DDC to have an input rate of 200MHZ, and an output rate of
> 1.6284MHz.  That said, the DDC will only select integer divisors, so
> your resulting output won't be exact.
>
> Sadly, I don't think that there is a integer divisor that will get you
> the exact value based on your required end frequency (though I could be
> wrong).
>
>
> On 04/27/2017 10:38 AM, Derek Kozel via USRP-users wrote:
> > Hello Lihua,
> >
> > The X310 RFNoC Radio block will always have a sample rate of either
> > 200 MS/s or 100 MS/s if using the TwinRX. If you look in the log
> > messages you will see a warning saying that the 16.384 MHz rate could
> > not be set.
> >
> > Regards,
> > Derek
> >
> > On Thu, Apr 27, 2017 at 3:28 PM, Lihua Ren via USRP-users
> > <[email protected] <mailto:[email protected]>> wrote:
> >
> >     hi,
> >     My design is as follows :in GNUradio, RFnoc: radio-->RFnoc: DDC
> >     ---> RFnoc:my block,
> >     in radio block, sampling rate :16.384MHz,
> >     in DDC block ?input rate :16.384MHz,output rate :1.6384MHz,
> >     I think the data rate in the FPGA code should be :1.6384MHz ?but
> >      the use of ChipScope to see the data rate does not match.why?
> >     ,I would like to know the axis interface  the i_valid   cycle,
> >     and effective time?
> >     Thanks.
> >
> >
> >
> >     _______________________________________________
> >     USRP-users mailing list
> >     [email protected] <mailto:[email protected]>
> >     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
> > [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/20170427/554424b7/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 27 Apr 2017 09:22:17 -0700
> From: Dario Fertonani <[email protected]>
> To: "[email protected]" <[email protected]>
> Subject: [USRP-users] Alternatives for uhd_fft in Ubuntu
> Message-ID:
>         <CAJGEdAjODq=UK54JZ4KjZ4wL37-ygqnkT=61FkZMMpBiRVR2Bw@mail.
> gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Is anybody aware of Ubuntu alternatives for the uhd_fft app? I'm looking
> for a basic spectrum analyzer.
>
> The uhd_fft app is great, but impractical for me because the packaged
> version of Gnuradio is always behind the latest UHD version (from Ettus
> Research PPA), and source code compiling of UHD/Gnuradio is an overkill for
> most of my uses cases.
>
> As many Ubuntu users have experienced, the current version of Gnuradio apps
> dies out on Ubuntu 16.04 LTS with the following error.
>
> RuntimeError:
> GR-UHD detected ABI compatibility mismatch with UHD library.
> GR-UHD was build against ABI: 3.9.0-0,
> but UHD library reports ABI: 3.10.1
> Suggestion: install an ABI compatible version of UHD,
> or rebuild GR-UHD component against this ABI version.
>
>
> Thanks,
> Dario
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.
> ettus.com/attachments/20170427/83ad9c99/attachment-0001.html>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 27 Apr 2017 16:55:50 +0000
> From: Mike McLernon <[email protected]>
> To: Mihkel M <[email protected]>
> Cc: "[email protected]" <[email protected]>
> Subject: Re: [USRP-users] B210 GPS L1 receiver in Simulink
> Message-ID:
>         <BN1PR05MB437878D320AA0E2103B6A31E9100@BN1PR05MB437.
> namprd05.prod.outlook.com>
>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi Mihkel,
>
> A couple of points:
>
> 1.       The sample time is 1/1023000, not the sample rate.
>
> 2.       You shouldn't need any additional blocks before you save the
> signal to workspace.
>
> Hth,
> Mike
>
>
> From: USRP-users [mailto:[email protected]] On Behalf Of
> Mihkel M via USRP-users
> Sent: Thursday, April 27, 2017 4:55 AM
> To: [email protected]
> Subject: [USRP-users] B210 GPS L1 receviver in Simulink
>
>
> Hi.
>
> My friend has project, where he has also couple of questions:
>
>
>
> "I am trying to receive and play GPS L1 signal using Simulink and B210.
> For observation I am using Ucenter 5.0. An active GPS antenna is used for
> receiving. I am not sure what the receiver block parameters should be
> because based on my calculations (decimation=master clock rate*sample time)
> I used Fc=1.57542 Ghz, master clock rate 6.138Mhz, decimation is 6 and
> sample rate is 1/1023000. Should I use some additional blocks before saving
> the signal to workspace and playing it back from workspace to the
> transmitter block? In additon to that can someone please explain how IF is
> formulated using receiver block parameters?"
>
>
>
> Mihkel.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.
> ettus.com/attachments/20170427/4f069bce/attachment-0001.html>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 27 Apr 2017 15:05:05 -0300
> From: Rub?n Vogel <[email protected]>
> To: [email protected]
> Subject: [USRP-users] [FPGA IMAGES] Image too large to E310
> Message-ID:
>         <CAM7GM7BUnp7o2ahVVwWYnsuaOOVxGit6LCDv5h8wZdq5vzLO1w@mail.
> gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hey,I am analyzing the structure of the different images in Xilinx
> Vivado that are possible to generate using the Makefile:
> fpga/usrp3/top/e300/Makefile
> This Makefile allows to generate 3 types of images for the Ettus E310:
> - make E310- make E310_RFNOC- make E3XX_IDLE
> I generated the 3 types of images using the GUI = 1 option and I have
> the following questions:
> 1 ? After generating the image E310, the resource utilization
> information provided by Vivado indicates that the use of LUT's is
> greater than 100% (115% to be exact). How is this possible?
> 2 ? The E3XX_IDLE image always loads at the end when we use the
> uhd_usrp_probe command on the E310. What is the purpose of this image?
>
> Rub?n O. VogelAdvanced Computer Engineering StudentDigital
> Communications LabSchool of Exact, Physical and Natural
> SciencesNational University of Cordoba ? Argentina
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.
> ettus.com/attachments/20170427/b9a925a0/attachment-0001.html>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 27 Apr 2017 13:30:29 -0500
> From: Jonathon Pendlum <[email protected]>
> To: Rub?n Vogel <[email protected]>
> Cc: "[email protected]" <[email protected]>
> Subject: Re: [USRP-users] [FPGA IMAGES] Image too large to E310
> Message-ID:
>         <CAGdo0uQgtWRs0nr4TRxJjO_Cq1y6i6NjguXZndwTd6mg6XcZOQ@
> mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> >
> > 1 ? After generating the image E310, the resource utilization information
> > provided by Vivado indicates that the use of LUT's is greater than 100%
> > (115% to be exact). How is this possible?
> >
>
> Our makefile changes build parameters, but those changes are not applied
> when doing a GUI build. Try the "Area Optimization High" strategy for
> Synthesis.
>
>
> > 2 ? The E3XX_IDLE image always loads at the end when we use the
> > uhd_usrp_probe commandn  on the E310. What is the purpose of this image?
>
>
> When you are not actively using the FPGA / RF frontend (e.g. when running a
> UHD app or GNU Radio flowgraph), the idle image is loaded to reduce power
> consumption.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.
> ettus.com/attachments/20170427/56f85e4e/attachment-0001.html>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 27 Apr 2017 14:37:05 -0400
> From: Anon Lister <[email protected]>
> To: Jason Matusiak <[email protected]>
> Cc: Lihua Ren <[email protected]>,    "[email protected]"
>         <[email protected]>,   Derek Kozel <[email protected]
> >
> Subject: Re: [USRP-users] x310 rfnoc fpga code
> Message-ID:
>         <CAMp204S6hKBUZ9QX71qxzYCFQpn_QwFQSEaYFfGUymzcZikb5g@mail.
> gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Oh, is this integer behavior the same on the DUCs? This would explain why I
> was having issues when I was messing around with using rfnoc for playing
> back arbitrary rate data on the x300 in the same manner I am able to with a
> b205 (utilizing the configurable master clock.)
>
>
> On Apr 27, 2017 12:07 PM, "Jason Matusiak via USRP-users" <
> [email protected]> wrote:
>
> > To expand on what Derek said (because I have fallen into the same rabbit
> > hole in the past; Jonathon has said he will remove the option for sample
> > rate from the block for the X310 in the future to reduce confusion), the
> > X310's RFNoC radio block runs at the system clock of the X310 (default of
> > 200MHz; the other options are 100MHz, and 184.32MHz).  You will want to
> set
> > your DDC to have an input rate of 200MHZ, and an output rate of
> 1.6284MHz.
> > That said, the DDC will only select integer divisors, so your resulting
> > output won't be exact.
> >
> > Sadly, I don't think that there is a integer divisor that will get you
> the
> > exact value based on your required end frequency (though I could be
> wrong).
> >
> >
> > On 04/27/2017 10:38 AM, Derek Kozel via USRP-users wrote:
> >
> > Hello Lihua,
> >
> > The X310 RFNoC Radio block will always have a sample rate of either 200
> > MS/s or 100 MS/s if using the TwinRX. If you look in the log messages you
> > will see a warning saying that the 16.384 MHz rate could not be set.
> >
> > Regards,
> > Derek
> >
> > On Thu, Apr 27, 2017 at 3:28 PM, Lihua Ren via USRP-users <
> > [email protected]> wrote:
> >
> >> hi,
> >>
> >> My design is as follows :in GNUradio, RFnoc: radio-->RFnoc: DDC --->
> >> RFnoc:my block,
> >> in radio block, sampling rate :16.384MHz,
> >> in DDC block ?input rate :16.384MHz,output rate :1.6384MHz,
> >> I think the data rate in the FPGA code should be :1.6384MHz ?but  the
> >> use of ChipScope to see the data rate does not match.why?
> >> ,I would like to know the axis interface  the i_valid   cycle,
> >> and effective time?
> >> Thanks.
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> USRP-users mailing list
> >> [email protected]
> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >>
> >>
> >
> >
> > _______________________________________________
> > USRP-users mailing [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/20170427/3d575801/attachment-0001.html>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 27 Apr 2017 14:40:04 -0400
> From: Jason Matusiak <[email protected]>
> To: Anon Lister <[email protected]>
> Cc: Lihua Ren <[email protected]>,    "[email protected]"
>         <[email protected]>,   Derek Kozel <[email protected]
> >
> Subject: Re: [USRP-users] x310 rfnoc fpga code
> Message-ID:
>         <[email protected]>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> Yes, I believe that the DUC works the same way as the DDC.  And one more
> piece information, one of the Ettus folks clarified on the list in the
> last couple of weeks that due to the way the DDC/DUC work, a integer
> multiple of 4 will give even better results than other integers.  So if
> you have the ability to choose your output freq in other applications,
> you might want to keep that in mind.
>
>
> On 04/27/2017 02:37 PM, Anon Lister wrote:
> > Oh, is this integer behavior the same on the DUCs? This would explain
> > why I was having issues when I was messing around with using rfnoc for
> > playing back arbitrary rate data on the x300 in the same manner I am
> > able to with a b205 (utilizing the configurable master clock.)
> >
> >
> > On Apr 27, 2017 12:07 PM, "Jason Matusiak via USRP-users"
> > <[email protected] <mailto:[email protected]>> wrote:
> >
> >     To expand on what Derek said (because I have fallen into the same
> >     rabbit hole in the past; Jonathon has said he will remove the
> >     option for sample rate from the block for the X310 in the future
> >     to reduce confusion), the X310's RFNoC radio block runs at the
> >     system clock of the X310 (default of 200MHz; the other options are
> >     100MHz, and 184.32MHz).  You will want to set your DDC to have an
> >     input rate of 200MHZ, and an output rate of 1.6284MHz.  That said,
> >     the DDC will only select integer divisors, so your resulting
> >     output won't be exact.
> >
> >     Sadly, I don't think that there is a integer divisor that will get
> >     you the exact value based on your required end frequency (though I
> >     could be wrong).
> >
> >
> >     On 04/27/2017 10:38 AM, Derek Kozel via USRP-users wrote:
> >>     Hello Lihua,
> >>
> >>     The X310 RFNoC Radio block will always have a sample rate of
> >>     either 200 MS/s or 100 MS/s if using the TwinRX. If you look in
> >>     the log messages you will see a warning saying that the 16.384
> >>     MHz rate could not be set.
> >>
> >>     Regards,
> >>     Derek
> >>
> >>     On Thu, Apr 27, 2017 at 3:28 PM, Lihua Ren via USRP-users
> >>     <[email protected] <mailto:[email protected]>>
> >>     wrote:
> >>
> >>         hi,
> >>         My design is as follows :in GNUradio, RFnoc: radio-->RFnoc:
> >>         DDC ---> RFnoc:my block,
> >>         in radio block, sampling rate :16.384MHz,
> >>         in DDC block ?input rate :16.384MHz,output rate :1.6384MHz,
> >>         I think the data rate in the FPGA code should be
> >>         :1.6384MHz ?but  the use of ChipScope to see the data rate
> >>         does not match.why?
> >>         ,I would like to know the axis interface  the i_valid
> >>         cycle, and effective time?
> >>         Thanks.
> >>
> >>
> >>
> >>         _______________________________________________
> >>         USRP-users mailing list
> >>         [email protected] <mailto:[email protected]>
> >>         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
> >>     [email protected] <mailto:[email protected]>
> >>     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 [email protected]
> >     <mailto:[email protected]>
> >     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/20170427/6d7a79f8/attachment-0001.html>
>
> ------------------------------
>
> Message: 8
> Date: Thu, 27 Apr 2017 20:05:36 +0100
> From: Derek Kozel <[email protected]>
> To: Jason Matusiak <[email protected]>
> Cc: Anon Lister <[email protected]>, Lihua Ren
>         <[email protected]>,  "[email protected]"
>         <[email protected]>
> Subject: Re: [USRP-users] x310 rfnoc fpga code
> Message-ID:
>         <CAA+K=tt9z7jb0q5KKe2KND=SOYbmVA1+LwTM=JuFauWsmiJcEQ@
> mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Jason,
>
> Thanks for including the 184.32 MHz sample rate. That is an important one
> to note for the LTE and cellular applications.
>
> The Transmit side of the radio is also fixed at one of the three above
> rates.
>
> The DDC filters include a set of halfband filters which are used
> preferentially to the CIC filter. Decimation rates which use these halfband
> filters have lower passband loss and sharper roll off in the transition
> region. Each halfband decimates by two so divisible by two, four, or eight
> will provide better performance than other rates. UHD will warn about odd
> decimation rates as these have some roll off in the passband.
>
> On Thu, Apr 27, 2017 at 7:40 PM, Jason Matusiak <
> [email protected]> wrote:
>
> > Yes, I believe that the DUC works the same way as the DDC.  And one more
> > piece information, one of the Ettus folks clarified on the list in the
> last
> > couple of weeks that due to the way the DDC/DUC work, a integer multiple
> of
> > 4 will give even better results than other integers.  So if you have the
> > ability to choose your output freq in other applications, you might want
> to
> > keep that in mind.
> >
> >
> >
> > On 04/27/2017 02:37 PM, Anon Lister wrote:
> >
> > Oh, is this integer behavior the same on the DUCs? This would explain why
> > I was having issues when I was messing around with using rfnoc for
> playing
> > back arbitrary rate data on the x300 in the same manner I am able to
> with a
> > b205 (utilizing the configurable master clock.)
> >
> >
> > On Apr 27, 2017 12:07 PM, "Jason Matusiak via USRP-users" <
> > [email protected]> wrote:
> >
> >> To expand on what Derek said (because I have fallen into the same rabbit
> >> hole in the past; Jonathon has said he will remove the option for sample
> >> rate from the block for the X310 in the future to reduce confusion), the
> >> X310's RFNoC radio block runs at the system clock of the X310 (default
> of
> >> 200MHz; the other options are 100MHz, and 184.32MHz).  You will want to
> set
> >> your DDC to have an input rate of 200MHZ, and an output rate of
> 1.6284MHz.
> >> That said, the DDC will only select integer divisors, so your resulting
> >> output won't be exact.
> >>
> >> Sadly, I don't think that there is a integer divisor that will get you
> >> the exact value based on your required end frequency (though I could be
> >> wrong).
> >>
> >>
> >> On 04/27/2017 10:38 AM, Derek Kozel via USRP-users wrote:
> >>
> >> Hello Lihua,
> >>
> >> The X310 RFNoC Radio block will always have a sample rate of either 200
> >> MS/s or 100 MS/s if using the TwinRX. If you look in the log messages
> you
> >> will see a warning saying that the 16.384 MHz rate could not be set.
> >>
> >> Regards,
> >> Derek
> >>
> >> On Thu, Apr 27, 2017 at 3:28 PM, Lihua Ren via USRP-users <
> >> [email protected]> wrote:
> >>
> >>> hi,
> >>>
> >>> My design is as follows :in GNUradio, RFnoc: radio-->RFnoc: DDC --->
> >>> RFnoc:my block,
> >>> in radio block, sampling rate :16.384MHz,
> >>> in DDC block ?input rate :16.384MHz,output rate :1.6384MHz,
> >>> I think the data rate in the FPGA code should be :1.6384MHz ?but  the
> >>> use of ChipScope to see the data rate does not match.why?
> >>> ,I would like to know the axis interface  the i_valid   cycle,
> >>> and effective time?
> >>> Thanks.
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> USRP-users mailing list
> >>> [email protected]
> >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >>>
> >>>
> >>
> >>
> >> _______________________________________________
> >> USRP-users mailing [email protected]://
> 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/20170427/4d0a2a5b/attachment-0001.html>
>
> ------------------------------
>
> Message: 9
> Date: Thu, 27 Apr 2017 22:37:54 +0000
> From: Jessica Iwamoto <[email protected]>
> To: usrp-users <[email protected]>
> Subject: [USRP-users] Issue running UHD via sshfs on E310
> Message-ID:
>         <SN1PR09MB10085D91B0E257DE971DCBCA9B100@SN1PR09MB1008.
> namprd09.prod.outlook.com>
>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi all,
>
> I am following the instructions here (https://kb.ettus.com/
> Software_Development_on_the_E310_and_E312) to build the SDK and cross
> compiling setup for the E310, however, I am running into some issues with
> UHD. After following all the steps in the link above, up to installing UHD,
> I tried to run one of the UHD examples but it seems to get stuck. I got the
> following output when running the benchmark_rate example:
>
> ./benchmark_rate --tx_rate 1e6
> [INFO] [UHD] linux; GNU C++ version 4.9.2; Boost_105700;
> UHD_3.11.0.git-162-g2790b51f
>
> Creating the usrp device with: ...
> [INFO] [E300] Loading FPGA image: /usr/share/uhd/images/usrp_
> e310_fpga.bit...
> [INFO] [E300] FPGA image loaded
> [INFO] [E300] Initializing core control...
> [INFO] [E300] Performing register loopback test...
> [INFO] [E300] Register loopback test passed
>
> After this the program gets stuck and just hangs at this point. Any help
> would be appreciated!
>
> Thanks,
> Jessica
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.
> ettus.com/attachments/20170427/f03360f2/attachment-0001.html>
>
> ------------------------------
>
> 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 80, Issue 28
> ******************************************
>



-- 
Oscar Llerena
Tlf: 997575596
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170428/cdc5a8ec/attachment-0001.html>

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

Message: 2
Date: Fri, 28 Apr 2017 13:29:13 -0400
From: Oliver Wayne <[email protected]>
To: [email protected]
Subject: [USRP-users] writing to user settings register
Message-ID:
        <CADueRbmbHfepKE9qg==mFrCun=lmdocv6hpif2nq_yx-sna...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

hi,

i am trying to write to the user settings register on the fpga on the b200
device, but am havings ome problems. i followed instructions at
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2013-April/006558.html
and
added in the verilog modules

    reg [31:0] prtCycles;
    wire [31:0] prtCycles_sr;
    wire prtCycles_ch;
    setting_reg #(.my_addr(0)) sr_0
        
(.clk(radio_clk),.rst(radio_rst),.strobe(set_stb),.addr(set_addr),.in(set_data),
.out(prtCycles_sr),.changed(prtCycles_ch));

i also went to b200_core.v and changed ".USER_SETTINGS(0)" ->
".USER_SETTINGS(1)."

Then in my cpp file I added

usrp -> set_user_register(0, 131, uhd::usrp::multi_usrp::ALL_MBOARDS);


131 is the value that I want to set my register prtCycles to. but this
doesnt seem to happen, can anyone tell me what i am doing wrong?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170428/bbcb7ef2/attachment-0001.html>

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

Message: 3
Date: Fri, 28 Apr 2017 21:04:58 +0000
From: "Long, Jeffrey P." <[email protected]>
To: Oliver Wayne <[email protected]>,
        "[email protected]"    <[email protected]>
Subject: Re: [USRP-users] writing to user settings register
Message-ID:
        
<dm5pr09mb1372ac3e144b84b872123369d9...@dm5pr09mb1372.namprd09.prod.outlook.com>
        
Content-Type: text/plain; charset="utf-8"

Oliver-

I just went through all this myself. Unlike the N210 and older etti the user 
registers are no longer exposed in the API so while you can ?turn? stuff on in 
the FPGA image there are no implementations exposed in the B200 api.

It?s not actually too hard and what I did was just forget the user register 
space entirely and I just put my stuff in the regular radio mapped area in an 
unused range. The caveat here being that you are manually tweaking the fpga 
image and the API and that won?t move forward as Ettus releases.

If you are interested I can give you an example. I would just have to write 
something up.

Jeff

From: USRP-users [mailto:[email protected]] On Behalf Of 
Oliver Wayne via USRP-users
Sent: Friday, April 28, 2017 1:29 PM
To: [email protected]
Subject: [USRP-users] writing to user settings register

hi,

i am trying to write to the user settings register on the fpga on the b200 
device, but am havings ome problems. i followed instructions at 
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2013-April/006558.html
 and added in the verilog modules


    reg [31:0] prtCycles;

    wire [31:0] prtCycles_sr;

    wire prtCycles_ch;

    setting_reg #(.my_addr(0)) sr_0

        
(.clk(radio_clk),.rst(radio_rst),.strobe(set_stb),.addr(set_addr),.in(set_data),
 .out(prtCycles_sr),.changed(prtCycles_ch));

i also went to b200_core.v and changed ".USER_SETTINGS(0)" -> 
".USER_SETTINGS(1)."

Then in my cpp file I added

usrp -> set_user_register(0, 131, uhd::usrp::multi_usrp::ALL_MBOARDS);



131 is the value that I want to set my register prtCycles to. but this doesnt 
seem to happen, can anyone tell me what i am doing wrong?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170428/a3c68b55/attachment-0001.html>

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

Message: 4
Date: Fri, 28 Apr 2017 17:09:22 -0400
From: Oliver Wayne <[email protected]>
To: "Long, Jeffrey P." <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] writing to user settings register
Message-ID:
        <caduerbnsyed__6augvs_dr8cbexukaa_frjchb4tcjo2+hf...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

i'd appreciate it if you could give me an example. i've been playing around
with the b200 cpp files in the uhd repo but think im looking in the wrong
place.

On Fri, Apr 28, 2017 at 5:04 PM, Long, Jeffrey P. <[email protected]> wrote:

> Oliver-
>
>
>
> I just went through all this myself. Unlike the N210 and older etti the
> user registers are no longer exposed in the API so while you can ?turn?
> stuff on in the FPGA image there are no implementations exposed in the B200
> api.
>
>
>
> It?s not actually too hard and what I did was just forget the user
> register space entirely and I just put my stuff in the regular radio mapped
> area in an unused range. The caveat here being that you are manually
> tweaking the fpga image and the API and that won?t move forward as Ettus
> releases.
>
>
>
> If you are interested I can give you an example. I would just have to
> write something up.
>
>
>
> Jeff
>
>
>
> *From:* USRP-users [mailto:[email protected]] *On Behalf
> Of *Oliver Wayne via USRP-users
> *Sent:* Friday, April 28, 2017 1:29 PM
> *To:* [email protected]
> *Subject:* [USRP-users] writing to user settings register
>
>
>
> hi,
>
>
>
> i am trying to write to the user settings register on the fpga on the b200
> device, but am havings ome problems. i followed instructions at
> http://lists.ettus.com/pipermail/usrp-users_lists.
> ettus.com/2013-April/006558.html and added in the verilog modules
>
>
>
>     reg [31:0] prtCycles;
>
>     wire [31:0] prtCycles_sr;
>
>     wire prtCycles_ch;
>
>     setting_reg #(.my_addr(0)) sr_0
>
>         
> (.clk(radio_clk),.rst(radio_rst),.strobe(set_stb),.addr(set_addr),.in(set_data),
>  .out(prtCycles_sr),.changed(prtCycles_ch));
>
> i also went to b200_core.v and changed ".USER_SETTINGS(0)" -> 
> ".USER_SETTINGS(1)."
>
> Then in my cpp file I added
>
> usrp -> set_user_register(0, 131, uhd::usrp::multi_usrp::ALL_MBOARDS);
>
>
>
> 131 is the value that I want to set my register prtCycles to. but this doesnt 
> seem to happen, can anyone tell me what i am doing wrong?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170428/0650dc44/attachment-0001.html>

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

Message: 5
Date: Fri, 28 Apr 2017 21:22:32 +0000
From: "Long, Jeffrey P." <[email protected]>
To: Oliver Wayne <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] writing to user settings register
Message-ID:
        
<dm5pr09mb13727d2f487b6c83d6a0f2a1d9...@dm5pr09mb1372.namprd09.prod.outlook.com>
        
Content-Type: text/plain; charset="utf-8"

OK sure. I will put together an example and send you it off list.

Jeff

From: Oliver Wayne [mailto:[email protected]]
Sent: Friday, April 28, 2017 5:09 PM
To: Long, Jeffrey P.
Cc: [email protected]
Subject: Re: [USRP-users] writing to user settings register

i'd appreciate it if you could give me an example. i've been playing around 
with the b200 cpp files in the uhd repo but think im looking in the wrong place.

On Fri, Apr 28, 2017 at 5:04 PM, Long, Jeffrey P. 
<[email protected]<mailto:[email protected]>> wrote:
Oliver-

I just went through all this myself. Unlike the N210 and older etti the user 
registers are no longer exposed in the API so while you can ?turn? stuff on in 
the FPGA image there are no implementations exposed in the B200 api.

It?s not actually too hard and what I did was just forget the user register 
space entirely and I just put my stuff in the regular radio mapped area in an 
unused range. The caveat here being that you are manually tweaking the fpga 
image and the API and that won?t move forward as Ettus releases.

If you are interested I can give you an example. I would just have to write 
something up.

Jeff

From: USRP-users 
[mailto:[email protected]<mailto:[email protected]>]
 On Behalf Of Oliver Wayne via USRP-users
Sent: Friday, April 28, 2017 1:29 PM
To: [email protected]<mailto:[email protected]>
Subject: [USRP-users] writing to user settings register

hi,

i am trying to write to the user settings register on the fpga on the b200 
device, but am havings ome problems. i followed instructions at 
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2013-April/006558.html
 and added in the verilog modules


    reg [31:0] prtCycles;

    wire [31:0] prtCycles_sr;

    wire prtCycles_ch;

    setting_reg #(.my_addr(0)) sr_0

        
(.clk(radio_clk),.rst(radio_rst),.strobe(set_stb),.addr(set_addr),.in(set_data),
 .out(prtCycles_sr),.changed(prtCycles_ch));

i also went to b200_core.v and changed ".USER_SETTINGS(0)" -> 
".USER_SETTINGS(1)."

Then in my cpp file I added

usrp -> set_user_register(0, 131, uhd::usrp::multi_usrp::ALL_MBOARDS);



131 is the value that I want to set my register prtCycles to. but this doesnt 
seem to happen, can anyone tell me what i am doing wrong?

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

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

Message: 6
Date: Sat, 29 Apr 2017 07:53:07 +0000 (UTC)
From: Amirhosein naseri <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] SBX initial saturation
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"

Hi
I have n210 with SBX daughterboard . when I start capturing sample after a 
while that usurp was off, after starting SBX is in saturation and keep in this 
state .... after 5 to 10 minutes, SBX start to work correctly, why?

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

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

Message: 7
Date: Sat, 29 Apr 2017 11:26:26 +0000
From: Ivan Kokic <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users]  B205i transient behavior
Message-ID:
        
<vi1pr0501mb279737b41d87dd0379a9529eba...@vi1pr0501mb2797.eurprd05.prod.outlook.com>
        
Content-Type: text/plain; charset="iso-8859-1"

Hi,


I want to disscuse a message that Michael West sent on 11 Apr 2017 14:40:30 EDT.

Below is the list of message parts that attracted my attention:


1) Looking at the images you posted, the gap and first spur correlate to the

   creation of the TX streamer, so that should be eliminated if the streamers

   are created first.

2) The next significant spur seems to align with the start of the TX streaming.
   My suspicion is that it is from garbage samples left

   in the DUC from initialization, but some testing is needed to prove that.

3) Pad the end of the TX burst with zeros. The first few samples

   transmitted are always the residual samples in the DUC. This means the

   last few samples of the burst will not actually make it to the AD9364

   unless you pad with zeros to flush them. Zero padding the end of every

   burst will make sure all desired samples are transmitted and that the next

   burst will start by transmitting the residual zeros.


Questions:


0) First of all, are those behaviors inherent to all USRP device?


1) Why creation of TX streamer causes generation of a "spur" and can it be 
avoided?


2) What do You mean by


      garbage samples left in the DUC?


   Why are those garbage samples even left in DUC?


3) The most interesting information is



      The first few samples transmitted are always the residual samples in the 
DUC

      ... last few samples of the burst will not actually make it to the AD9364

      unless you pad with zeros to flush them.


   First of all, where can I find this information? This is something that 
should be noted down

   with big, bold, red letters.

   Second, is this something driver should carry about or application code?! I 
think that driver

   should carry about those things, not application code.


Regards,
Ivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170429/7bd0f027/attachment-0001.html>

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

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 80, Issue 29
******************************************

Reply via email to