I've finally found the solution to this. Searching the internet for libgnuradio-tutorial.so issues showed that several people have hit the same error.
The solution was "sudo ldconfig" From: USRP-users <usrp-users-boun...@lists.ettus.com> On Behalf Of Mark D via USRP-users Sent: 15 February 2021 15:02 To: 'Mike' <mike...@verizon.net> Cc: 'usrp-users@lists.ettus.com' <usrp-users@lists.ettus.com> Subject: Re: [USRP-users] RFNoC OTT Block on E320 Thanks Mike, Good idea, but I'd already got the Python path pointing correctly to the /usr/lib/python3/dist-packages. I've been doing a bit more digging and trying to see what actually happens as the code loads up. The "import dilbert" that's near the top of the python code generated from GNU Radio goes off and pulls in __init__.py from the dilbert directory under the folder in the Python path above. This __init__.py file tries to import from dilbert_swig, and this failing. There's a comment that's been added stating "This might fail in the module is Python-only". I've added a bit of code into __init__.py to debug this, and the root cause seems to be that importing dilbert_swig fails due to not being able to access the libgnuradio-dilbert.so . The error message goes on to say that cannot open the shared object file, No such file or directory exists. So it looks like this shared object file is missing. I'm assuming that it should be built from C++ code for the module. I've sent an email off to Ettus support to see if they have any ideas what the issue may be. Mark From: Mike <mike...@verizon.net<mailto:mike...@verizon.net>> Sent: 15 February 2021 13:00 To: Mark D <md...@hmgcc.gov.uk<mailto:md...@hmgcc.gov.uk>> Cc: 'usrp-users@lists.ettus.com' <usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> Subject: Re: [USRP-users] RFNoC OTT Block on E320 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><mailto: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<mailto: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
