Re: [USRP-users] [UHD] Coarse roadmap for USRP E310 Software

[Philip Balister via USRP-users]

A couple of notes based on updating the E300 to rocko 

1) The N310 branch added a bbappend on something called salt which added
the need for the meta-openstack and meta-virtualization layers. For
basic E300 support, this is crazy layer bloat. I removed the bbappend.
If you really need it, I'd create a layer for specific applications,
salt seems to be some form of enterprise software config management
system ( https://en.wikipedia.org/wiki/Salt_(software) ) Certainly not
every E300 project needs this.

2) The uhd recipe in meta-sdr needs updating. I'd suggest moving it to
meta-ettus, but it also supports users using other Ettus products with
other embedded hardware, so the recipe doesn't belong there. It would be
silly having to add the meta-ettus bsp to use a b200 with a pi-s.

3) While messing with uhd, it is time to have the firmware recipe
package the fpga files on a per device basis, instead of all images on
one package.

4) There are some other smaller fixes in
https://github.com/balister/meta-ettus-1

Philip

On 07/10/2018 01:54 PM, Martin Braun via USRP-users wrote:
> 
> Hi all E310/E312/E313 users,
> 
> I would like to focus people's attention to some changes we have just
> started rolling out, and will continue to roll out over the next months.
> 
> Executive Summary
> =
> - For those requiring *no* RFNoC support whatsoever, just plain RX/TX
> and UHD support, we recommend sticking with the 3.9 LTS version of UHD
> for now (this advice is for the E310/E312/E313 only!).
> - Going forward, we will be moving the E310 to a more modern RFNoC
> architecture, and start incorporating things we've learned from other
> embedded USRPs.
> - However, this means that certain features (most importantly, network
> mode) will be unavailable for the time being on newer UHD versions until
> the transition is complete.
> 
> 
> Full Story
> ==
> As we've rolled out the USRP N310 and other devices using embedded
> Linux, we have gotten a little smarter with respect to OpenEmbedded and
> other embedded-Linux related topics. For example, the USRP N310 features
> the MPM architecture, which moves a lot of the hardware controls onto
> the device itself, as opposed to toggling every bit in every register
> from within UHD, and we have a better way of creating file systems which
> makes it easier for us to upgrade to newer OE and kernel versions.
> 
> The USRP E310, even though it was released years ago, is still a great
> product, with an amazing form factor. Unfortunately, its software design
> hasn't kept up with the times, and the currently shipping filesystems
> have fairly old kernels, among other things. Over the course of the next
> few months, we intend to remedy that. We will be taking the following steps:
> 
> 1. Port all RFNoC code from E310 onto master branch. This means we no
> longer support different architectures between the master and
> rfnoc-devel branches (note: On X310, we did this for the 3.10 release).
> The main downside of this is that it will disable network mode (i.e.,
> the ability to run the E310 like an N210, with UHD running on a host
> computer, over Ethernet).
> 
> 2. Forward-port the E310 code to the same OE release as we use for N310.
> Since this entails a major kernel upgrade, it will take some time to
> have all the power management up to date. There may be periods of time
> where the E312 (the battery-powered version) will have reduced
> capabilities. We will send out more updates when we know more.
> 
> 3. Forward-port the E310 code the same UHD software architecture as the
> N310. Once this is complete, network mode will be back in place, albeit
> with more capabilities. For RFNoC development in particular, this will
> be useful, because full RFNoC support will be made available over
> network mode (the bandwidth limitations for E310 network will remain the
> same, we expect a nominal sampling rate of 1 Msps over network mode).
> 
> Timeline
> 
> We plan to complete these steps by the end of 2018. The first step,
> however, has already been completed on master branch: Here, the E310 has
> already been synchronized with the code from rfnoc-devel.
> 
> Once this transition is complete, we will be able to keep providing
> updates for the E310 more easily than before, and they will stay in
> lockstep with the N310 filesystem releases.
> 
> Note that since we're merging all of this into master branch, there will
> be intermediate releases of UHD with different feature sets for the E310.
> 
> 
> Which branch/release should I run?
> ==
> If you are using none of the RFNoC features, i.e., you are simply doing
> send() and recv() calls, then we recommend sticking with the UHD-3.9.LTS
> branch.
> If you are doing RFNoC development, then simply move from rfnoc-devel to
> master branch, and everything else stays the same.
> 
> 
> Why do all of this on master branch?
> 
> We could have consider

Re: [USRP-users] [RFNoC] Transition of branch from rfnoc-devel to master

[Martin Braun via USRP-users]

On 07/12/2018 02:45 PM, Rob Kossler wrote:
> Hi Martin,
> Regarding the API version "guarantee", I am wondering if there is any
> way to distinguish between versions.  Presently, it seems that branches
> 3.12 and master both have UHD_VERSION set to 3120099.   I had previously
> been using UHD_VERSION to select (via #if) code appropriate to a given
> UHD version.  However, my function call to "get_device3()" compiles
> successfully on master, but not on 3.12 (because this function is not
> part of the 3.12 API). So, I keep having to change my source code
> whenever compiling for one or the other.  Is there a way for me to avoid
> this?

Hey Rob,

good question. First of all, we missed the time when we should have
changed the version on master branch to 3.13 and flag it as development
(which is now remedied). That would normally be your first indicator.

The other thing you can use is, when using master branch to do RFNoC
work, you have to specify -DENABLE_RFNOC=ON during CMake. When you do
that, you will have additional info available in your software project.
See how gr-ettus checks for the existence of RFNoC:

https://github.com/EttusResearch/gr-ettus/blob/cd6db6b2f6d181e117c0b100f112669e2774ce11/CMakeLists.txt#L138-L141

...you can do something similar, and use CMake to set defines in your
source code (assuming you're using CMake).

The other thing I was curious about this is the value of UHD_VERSION.
On master branch, it was (until today) 3120099 as you say (it will
change to  when you compile the lastest master branch now).

On UHD-3.12, you're right that UHD_VERSION is 3120099, but it should
read 312 on the current version (and will become 3120001 on the next
one). We'll need to remedy that, too.

Thanks for bringing all of this up!

Cheers,
Martin


> 
> Rob
> 
> 
> On Mon, Jul 9, 2018 at 1:48 PM Martin Braun via USRP-users
> mailto:usrp-users@lists.ettus.com>> wrote:
> 
> Hi all,
> 
> we have recently been working more on the RFNoC side of things, and
> there's some updates I want to bring to you.
> 
> The first step we did to a more stable version of RFNoC is merging all
> of the work on rfnoc-devel back into master. This will make it a lot
> easier to keep features in sync between RFNoC and regular/vanilla UHD.
> Going forward, we will no longer push updates to the rfnoc-devel
> branches, and at some point we will delete those branches in favour of
> master (for now, we'll leave them up so people following the existing
> instructions won't get an error, but they will be frozen as of now).
> 
> For those of you who aren't actively developing on RFNoC, there is no
> difference (with the exception of E310 users, but I'll send out another
> email on that in a bit).
> For people playing with RFNoC, keep the following things in mind:
> 
> - Anytime you read something referencing the rfnoc-devel branch, simply
> change that to master branch.
> - The RFNoC APIs are still disabled by default, and require using the
> -DENABLE_RFNOC=ON CMake switch to use them
> - If you have patches on top of rfnoc-devel, you may want to rebase them
> on top of master. They should cleanly apply, as of now, the diff between
> the two branches is minimal.
> 
> Why do we require the `-DENABLE_RFNOC=ON`? The reason is, the APIs are
> not covered by our guarantee that we won't change them (in case you were
> unaware, we have a strong guarantee that we won't change APIs unless we
> also change the API version number, i.e., all 3.11.* releases have the
> same API). Think of setting that switch as a waiver that says "I have
> understood that I am using APIs that do not have a strong guarantee of
> being unchanged".
> 
> On the FPGA branch, there is no such CMake switch, and the same branch
> will server RFNoC and non-RFNoC users alike.
> 
> Thanks all!
> 
> Martin
> 
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com 
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] branch 3.12 with ENABLE_RFNOC=ON

[Rob Kossler via USRP-users]

Hi,
With the recent changes to the branches, I understand that users doing
RFNoC development should be using master branch and users that previously
used 'maint' should be using 3.10, 3.11, or 3.12 as appropriate.  I am
wondering about the possibility of using the RFNoC API with the 3.12
branch.  Is this a possibility?

I tried to use 3.12 and supplied the -DENABLE_RFNOC=ON parameter to cmake.
I can compile UHD successfully, but the subsequent "make test" produces an
error on the "blockdef_test".  So, I am wondering if this is not an
intended use case.

Rob
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Random Phase Offset Between Two Rx Channels of B210 ???

[Jack Yang via USRP-users]

Hi I would like to follow up this conversation. Is it possible to have a
constant initial phase offset for every run when power is up?
I knew the B210 can remains constant phase offset across two receivers
during the operation. However, the challenge for me is that whenever power
is up, the initial phase across devices is not constant. Namely, the first
run  v.s. the second run will have different phase offset across two
receiver even though I feed into the same single frequency tone through the
power-splitter. Is there anyway we can fix this thing?

Thanks!

All Best,
Jack

On Fri, Jul 13, 2018 at 8:05 PM, Jack Yang  wrote:

> Hi I would like to follow up this conversation. Is it possible to have a
> constant initial phase offset for every run when power is up?
> I knew the B210 can remains constant phase offset across two receivers
> during the operation. However, the challenge for me is that whenever power
> is up, the initial phase across devices is not constant. Namely, the first
> run  v.s. the second run will have different phase offset across two
> receiver even though I feed into the same single frequency tone through the
> power-splitter. Is there anyway we can fix this thing?
>
> Thanks!
>
> All Best,
> Jack
>
>
> On Tue, Mar 24, 2015 at 2:38 PM, Ufuk Tamer via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> I am using the block in default settings so time sync part is in default.
>>
>> On 24.3.2015 23:20, Marcus D. Leech wrote:
>>
>> On 03/24/2015 05:18 PM, Ufuk Tamer wrote:
>>
>> I am using the latest version. I have a simple GRC flow graph that takes
>> two channel I&Q data and then processing this data in Octave. And every
>> time I turn on the receiver (tx & rx  locations are fixed), I get different
>> phase offset between two rx channels.
>>
>> In order to apply direction of arrival (DOA) technique, I have to first
>> use a reference signal to detect this random phase offset, remove it and
>> then estimate the angle of transmitter.
>>
>> What are you using for time-synch in the UHD source block?
>>
>>
>> On 24.3.2015 22:12, Marcus D. Leech via USRP-users wrote:
>>
>> On 03/24/2015 03:12 PM, Ufuk Tamer via USRP-users wrote:
>>
>> Dear all,
>>
>> I am testing the phase offset between two Rx channels of B210. For this
>> case, I transmit a sine signal with another USRP device and receive it with
>> two RX channels of B210. Then I calculate the phase offset between
>> channels. The problem is the phase offset changes whenever I reset the
>> receiver. So it gives a random phase offset on each device turn on.
>>
>> Is this normal? If yes, what is the reason for this random phase offset.
>> Since both channels share the same LO, where this "random" phase offset
>> come from?
>>
>> Thank you...
>>
>> --
>>
>> *Ufuk Tamer *
>>
>> What version of UHD are you using?
>>
>> How are you doing the two-channel receive?
>>
>>
>>
>>
>>
>> ___
>> USRP-users mailing 
>> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>> --
>> *Ufuk*
>>
>>
>>
>> --
>> *Ufuk *
>>
>> ___
>> 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