Rob- Thank you for responding.
Yes I agree that if you look in legacy_compat.cpp it seems to suggest that if it did find the duc and ddc it would skip it and wire direct to the radio block. That is kind of why I thought it might be safe to do this. I am guessing there might be a bug with this “feature” and it would be low on the Ettus list of things to make sure work given they are really expecting people not to touch the FPGA design in the maint branches. It seems that if I avoid that whole multi-usrp and use the device3 approach it works but of course this is not completely fleshed out yet because the final solution is being built in master. To be honest I have really been avoiding master. It seems to be a work in progress (not stable) and I have to build a system that needs to be distributed beyond my organization. To that end I have gone back to the old reliable property tree to get at what I need. Luckily the property tree is exposed on device3. Most of what I need is in the radio-ctrl except the sensors. I needed gps_time and to check gps_lock and ref_lock and just pull them from the tree. I am guessing this is what you might have done too? Yeah RFNOC is totally dead and it’s probably really confusing for people who want to do this work and see totally out of date how-tos on the knowledge base. They have been talking about the RFNOC switchover for ever now but its like we are in perpetual limbo on this. Thanks again for responding. Jeff From: Rob Kossler <[email protected]> Sent: Wednesday, March 18, 2020 7:06 PM To: Long, Jeffrey P. <[email protected]> Cc: [email protected] Subject: [EXT] Re: [USRP-users] RFNOC uhd api vs traditional Hi Jeff, I have been using UHD with custom RFNoC and an N310. Here are a few remarks: * I am surprised that you can't run multi_usrp with an N310 once you remove DDCs and DUCs. I thought that multi_usrp had the smarts to essentially skip the DUC and DDC if either the blocks were missing or if the user explicitly specified skip_duc, skip_duc in the make args (see legacy_compat.cpp). But, even if this worked as expected, it still wouldn't solve your issue of handling custom flow graphs. * I believe you are correct in saying that certain functions are not provided outside of multi_usrp. Because of this, I had to create my own class, 'my_rfnoc_usrp', which inherited multi_usrp.hpp and I essentially copied the code from muti_usrp_impl for all functions that didn't have an equivalent rfnoc function. But this was not a trivial task. If you are only interested in a few select functions, you could just copy the code from multi_usrp_impl for those functions. * I believe you are correct in saying that 'master' changes this architecture. From what I understand, 'master' is the better approach in the long run, but I'm just not sure how stable this new branch is in comparison to 3.15.LTS. And, these changes go along with some pretty major changes on the FPGA side. So, moving to 'master' may be a pretty big undertaking. * You should not use rfnoc dev branch as this has been dormant for a long time (a couple of years) Rob On Tue, Mar 17, 2020 at 8:59 PM Long, Jeffrey P. via USRP-users <[email protected]<mailto:[email protected]>> wrote: I have been working on applications to control a N310 directly using the uhd api. As I work with the code I am noticing there is a difference in the way you bring up a usrp in what I will call the traditional (legacy) uhd::multi_usrp::make() approach vs the newer uhd::device3::make approach which seems to only appear in the examples that are specifically rfnoc. I realize you can use the legacy approach and examples to run on the N310 but as soon as I start modifying the FPGA image and manually take out the DDC and DUC for example it does not like that and seg faults. I am guessing it is looking for those blocks and doing a whole rfnoc block enumeration thing under hood and getting mad? I have been successful using the rfnoc (device3) examples on my tweaked FPGA image and I am currently using 3.15 LTS. So I would like to do the following and am asking how best to proceed? -I want to remove DDC and DUC blocks from the FPGA build to make room for my own stuff. -I would like to have full uhd api capability and it appears some things are missing like the sensor query that seems to be available only via multi_usrp using the traditional approach. If you look at the rfnoc examples they have TODOs in those sections. I did notice that in the latest master branch there is a mb_controller class that looks like it might make that stuff available. It makes sense to me that the radio_ctrl would not have that motherboard type stuff but in the lastest release branch it only seems to be available via the traditional multi-usrp approach. So do I need to use the master branch if I want full capability using the newer api or is there some other way to get to things like the sensor query? Or should I use the rfnoc dev branch? It seems master has more than even rfnoc at this point. Thanks Jeff Long _______________________________________________ USRP-users mailing list [email protected]<mailto:[email protected]> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________ USRP-users mailing list [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
