Mark,
I looked at the capabilities of the E320 compared to the E310 and I
understand your comment about "embedded mode" now.� My experience is
strictly with the E310.� I didn't realize the E320 had an SFP+ interface
that allows you to stream sample data back to the host at a much higher
rate than the embedded ARM core can process.� So, it seems like you
should be able to update the FPGA on the E320 and stream the data into
your host machine bypassing the internal ARM processor.� Still, it seems
that you need to install the the new RFNoC module onto the E320 so that
it knows what each block in the FPGA is when you run uhd_usrp_probe (you
were seeing the block named simply Block #0).
And if you can stream data directly to the host then you shouldn't be
seeing the same error I'm having (running on the embedded ARM).� You
should be able to run directly on the host. If you are trying to run on
the embedded ARM then you will have to follow the steps I outlined below
for cross-compiling.
Meanwhile, I'd like to hear a response from one of the Ettus guys
because I'm sure I'm off base in a couple areas.� Like, my RFNoC stuff
is not working so clearly I'm doing something wrong.� But, I'm hoping
just talking it out will reveal where the errors are.
Mike
On 2/12/21 11:46 AM, Mike via USRP-users wrote:
Mark,
I'm not sure I understand what you mean by "embedded mode".� That
may be a term used for other Ettus devices like X310 or N310.� Let
me describe what I think the E3xx GNU Radio universe looks like.
In addition to the Ettus E310, I have a Lime Mini device that connects
directly to the host computer via USB3.0.� Any GNU Radio program
that I make (usually gnuradio-companion) runs directly on the host
computer (my laptop with Ubuntu 18.04LTS) and directly processes the
raw samples from the radio. Ettus X310 and N310 type devices would
transfer raw samples from the radio via 10GigE type interfaces for
similar processing on the host computer.� Note, no local software
processing on the USRP device.� FPGA processing, yes; but software
processing, no.
In contrast to that, the E310 has an embedded ARM processor that
executes a python script (usually output from GRC).� Obviously, this
needs to run in non-gui mode which is controlled by the "Options"
block in your GRC flow graph (set to No GUI).� Similar to the host
computer running with the Lime Mini (for example), the ARM processor
can process the raw samples from the radio.� However, since the ARM
processor is relatively low powered it cannot process "raw" samples at
a very high rate.� Therefore it requires the FPGA (RFNoC) to handle
as much of the raw data processing as possible.� So, the host
computer is used to generate the FPGA bit file (using Xilinx, Vivado)
as well as any software modules (OOT) that need to be run on the
ARM.� This is where the cross-compiling comes in.� The host
computer has to compile the code that is going to eventually execute
on the ARM.� After the cross-compilation is complete you need to
move your newly compiled module over to the E3xx.� This is where I
use sshfs so that I can "make install DESTDIR=..." into a location
that is temporarily visible within the E3xx device.� Eventually you
will copy this data to the flash card on your E3xx device so that your
application can be available at any time (running totally disconnected
from any host computer).
So, using the E3xx devices are a little more complex because you have
to navigate the cross-compiling aspect and rely on the FPGA to handle
the higher bandwidth data processing.� Thus the reason why I'm
anxious to fix an issue with the ARM executing a GRC flow-graph that
contains an OOT RFNoC module.� It's hard to make the E3xx do
anything reasonable without the FPGA performing as much work as possible.
Anyway, hope that helped clear things up a little,
Mike
On 2/12/21 10:32 AM, Mark D wrote:
Thanks Mike,
�
I don�t have a much experience of Linux, I�ve just had to look up
what sshfs is, so as you can imagine this is becoming a very steep
learning curve for me.
�
After reading your reply and doing a bit of research I�ve found
AN-315 �Software Development on the E3xx USRP� which goes through
the cross-compiling process. Unfortunately it looks like this was
written for UHD 3.14.1. so there may be some differences for 4.0.
�
I did initially think that as I wasn�t using the USRP in
�embedded mode� then the firmware on the unit wouldn�t need to
be updated, and the RFNoC would be more or less configured via the
host computer. Seems that this isn�t the case.
�
Mark
�
*From:*USRP-users <usrp-users-boun...@lists.ettus.com> *On Behalf Of
*Mike via USRP-users
*Sent:* 12 February 2021 13:40
*To:* usrp-users@lists.ettus.com
*Subject:* Re: [USRP-users] RFNoC OTT Block on E320
�
Mark,
For uhd_usrp_probe to correctly read your fpga block module you need
to update the XML file in your RFNOC-module/rfnoc/blocks
directory.� Then you need to cross-compile your module like you
would with gr-ettus and install it on the E320.� I use sshfs to
cross-compile on the host and make it immediately available on my E310.
It may be that the process on UHD4 is slightly different but that is
what I do to make the correct name of my new block show up in
uhd_usrp_probe.
I still have the python "attribute error" so hopefully now that two
people are seeing this on both UHD3.15 and UHD4.0 we can get to the
bottom of it.
Mike
On 2/12/21 6:52 AM, Mark D via USRP-users wrote:
Hi,
�
I�m trying to add an OTT block into the FPGA for an E320. I�m
using version 4.0.0 of the UHD.
�
So far I�ve used rfnocmodtool to create the OOT folder
structure and add my new block. My initial plan was to add this
block as per the default code generated that just passes data
through. I wanted see that this was instantiated into the FPGA
and the system still worked before starting to add my own code.
�
I�ve been following the �Getting Started with RFNoC in UHD
4.0� page on the Ettus website and also the Youtube video
�RFNoC 4 Workshop - GRCon 2020�. The .yml file I�ve created
connects the OTT block between the radio Rx and stream endpoint
(I�ve removed the DDC / DUC and already had the FPGA working
without these).
�
So far I�ve got the FPGA built and uploaded to the FPGA.
Uhd_usrp_probe shows that the RFNoC routing as expected, but the
name of OTT block has been replaced with Block#0. The OOT project
appears as a folder in GNU radio with the new block available to
be dragged into the project.
�
I think the issues I�m now having are similar to those reported
recently by Mike with the E310. Trying to run a GNU radio project
results in the error � AttributeError: module �Dilbert�
object has no attribute 'dogbert'�
�
The examples I�m following are all based around the X310, is
there an extra step required for the E3xx USRPs to update the
firmware running on the device so that it�s aware of the new
block type? If so I�ve no idea how I would go about this.
�
Any help on this would be much appreciated,
�
Mark
------------------------------------------------------------------------
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom
they are addressed. If you have received this email in error
please notify the system manager.
_______________________________________________
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
_______________________________________________
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
