Brian- I think I am getting closer here. I actually just went back to using network mode so I could debug my issues without the extra challenge of the crossdev. That is a real nice thing about the E320.
So I think the usrp probe will always come back with that error because there is no controller for your custom block in that usrp probe code (Sorry my terminology is probably wrong here). As you mention the generic name is just a fact of life however I really think the getting started guide should point that out so people know what to expect. With the proper block controller called with the correct noc ID registered it seems to work now. Embedded mode should probably work now too however I think I am just going to continue in network till I get my custom design into the FPGA and then move it over. Thanks for your help on this. Jeff From: Brian Padalino <[email protected]> Sent: Monday, May 17, 2021 10:10 AM To: Jeffrey P Long <[email protected]> Cc: [email protected] Subject: Re: [USRP-users] Re: [EXT] Re: RFNOC block name? On Sat, May 15, 2021 at 7:17 PM Jeffrey P Long <[email protected]<mailto:[email protected]>> wrote: Brian- As a further test I moved the whole OOT module directory over to the device and cmake/make/install right on the device to see if it had some special sauce but no luck. OK maybe this is a real problem that Ettus is not going to resolve for custom C++ work? OOT RFNoC Block not propagating action in UHD4 · Issue #406 · EttusResearch/uhd · GitHub<https://github.com/EttusResearch/uhd/issues/406> The solution according to this issue is to use gr-ettus etc. I don’t use GNU radio and hoped to finally try RFNOC for real but it seems to still not be fully functional. I am guessing that since my controller is looking for the real name or something its getting confused? I have seen work arounds posted related to naming your OOT module “block” instead of something custom which seems limited. Also something about building the block controller in-tree. I suppose I could do that but I guess I would have to rebuild UHD and move it over. These are all possibilities, but I am not a huge fan of them. I have been successful using the UHD_MODULE_PATH way with my block controller defined in the library. What’s funny is that even in their OOT example on getting started with UHD 4.0 their gain block shows up generically as “block”. Somehow they did not notice that? The reason is because the C++ block really defines the block name, and the YAML is not scanned during every load of UHD unlike the old RFNoC way where the XML files were scanned every time UHD was loaded to build the registry of blocks and names. It was a known design choice from what I understand. Not sure why you can't get it to show up when the library is appropriately defined and UHD_MODULE_PATH is also appropriately defined. What does your txcore_block.cpp look like? Brian
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
