Mark,
I had a similar problem earlier.� Jonathon Pendlum responded to me as
follows:
/The might be due to the PYTHONPATH env variable not including the />/directory where
your OOT module is installed. Try looking for a />/directory like
/usr/lib/python2/dist-packages or similar and adding />/that to PYTHONPATH. /
/What I had to do was add a search path to the location where my OOT
module was added to.� In my case the issue was solved by adding the
following:/
$LOCALPREFIX/lib/python2.7/dist-packages:$PYTHONPATH
to my python path that is configured when you source the environment
variables.� Also, this was done on my E310 but that was because that was
where I was trying to execute the program (on ARM).� You may need to add
the search path on your host machine so it knows where to find your new
OOT module there as well.
Mike
On 2/15/21 5:40 AM, Mark D wrote:
Mike,
Thanks for your input into this, it�s really useful being able to talk
over this issue.
My system will be placing all the signal conditioning within the FPGA.
The output from this is a relatively low data rate which I was hoping
to stream via the Ethernet connected to the ARM. There should be no
need for us to use the SFP+ interface. The ARM will not be doing any
processing of the data, just passing it back to the host PC. I have
just out of interest tried connecting via the SFP+ and get the same issue.
I am able to build the FPGA image with my block in, and upload this to
the E320. My initial understanding of how a system as described above
would work is the software on the Host PC would issue commands to the
USRP to read and write registers in blocks as required to configure
the device, for example the gain setting in the examples. The ARM
wouldn�t require any knowledge of how the blocks worked, it just
writes and reads to the address within the blocks as instructed. This
was what I thought Network Mode (as opposed to Embedded Mode) meant,
it was acting more or less like the USRPs without the ARM.
As we�re both seeing the same error then I�m not 100% sure that
cross-compiling the OOT code for the E320 will resolve the problem.
�My GNU radio code is running entirely on the host PC. I�ll probably
look more into the cross-compiling today as I�m running out of any
other ideas to try.
The error I�m currently hitting is that when running the GNU radio
flow graph with my new block I get the error
�Line 98, in __init__
��self.dilbert_dogbert_0=dilbert.dogbert(
AttributeErroe:module �dilbert� has no attribute�dogbert��
What I have found that is if I enter Python on the command line and
enter �import dilbert� followed by �dir(dilbert)� then it appears that
there�s nothing in this module other that the things like __builtins__
, __cached__,__doc__ �.. . There is no dogbert class within module,
and this I think is the source of the issue.
Like you say, we could really do with a response from Ettus to throw
some light on this. An update to Gain Block tutorials aimed at the
E3xx devices would be really useful.
Mark
*From:*USRP-users <usrp-users-boun...@lists.ettus.com> *On Behalf Of
*Mike via USRP-users
*Sent:* 12 February 2021 21:37
*To:* usrp-users@lists.ettus.com
*Subject:* Re: [USRP-users] RFNoC OTT Block on E320
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>
<mailto: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
<mailto: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 <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
