Hi Mark, Tuan, The problem seems to be that the default block controller does not propagate the issue_stream_cmd (I'm guessing that this is a "bug" but perhaps it is intended behavior). In any case, it seems that you have to build & link your own block controller if you need this to happen. There are a few work arounds that I know about, but they might not be possible in all cases:
- you could build your block controller in-tree. This assumes that you have the ability to build UHD from source code. If so, you can place your controller HPP & CPP files in the same folder that Ettus uses for the RFNOC block HPP & CPP files, edit the CMakeLists.txt file in those folders to add your new files, and then re-build UHD (and re-install using "make install" or "sudo make install"). This has the nice advantage that uhd_usrp_probe will now be aware of your blocks when it runs. - you could build your block controller out-of-tree and link it using the --no-as-needed link option. As you pointed out, you will need to link to rfnoc-tutorial or whatever the name of your OOT library is. This library will need to be installed in a location where the linker can find it. Perhaps by running "sudo make install" on your OOT library, this will take care of it, but not really sure. - you could modify the gnuradio code to call issue_stream_cmd() from the DDC block rather than from the rx_streamer. I'm a little fuzzy here because I don't use gnuradio, but I have done something similar from an Ettus c++ example and it seemed to work fine. Note that this case is assuming you don't really need a block controller and can live with the block id "Block#0". If you actually need your custom block controller (because it has functions you want to call), you will need to get one of the above items working. Rob On Mon, Feb 22, 2021 at 9:50 AM Mark D via USRP-users < [email protected]> wrote: > Hi Tuan, > > > > Good to know that I’m not the only one struggling to get past this issue. > > > > I must admit that the solutions proposed have left me rather confused and > needing to start look into a whole load of stuff that I was hoping to > avoid. I don’t know how to build controller code in the UHD tree. I was > also thinking of adapting the rfnox_rx_to_file.cpp code, but again > modifying this to set the routing in the FPGA and then building it is > something that I just don’t where to start with. > > > > I’ve been trying to just build a renamed copy of rfnoc_rx_to_file.cpp > under my OTT folder but so far have had no luck yet even getting it to > compile. > > > > I’m assuming the line after “"-Wl,--no-as-needed” should have the name of > OTT module, such as rfnoc-tutorial, but I get an error to “/usr/bin/ld: > cannot find -rfnoc-tutorial” > > > > The tutorial video on UHD with the gain block all looks quite straight > forward, but not being able to include an OTT block into a real-world GNU > Radio application is a huge stumbling block for those without prior > experience building CPP applications and make files. > > > > Do we have any idea when Ettus plan to release the next revision of UHD > that would have a fix for this? > > > > Mark > > > > *From:* USRP-users <[email protected]> *On Behalf Of *Tuan > Hoang Dinh via USRP-users > *Sent:* 21 February 2021 12:29 > *To:* usrp-users <[email protected]> > *Subject:* [USRP-users] How to issue start stream command directly to > DDC/Radio block using GNU Radio > > > > Hi, > > I'm testing my first RFNoC block using GNU radio, when executing the > graph, the UHD return recv() time out like the picture below. > > > > > > I searched on the mailing list and know this is a problem when start > stream command did not send directly to DDC/Radio block, the new RFNoC > block (Block0) did not forward start stream command to DDC block. You can > find the error here: https://github.com/EttusResearch/uhd/issues/406 > > > > Some solutions have been issued to fix rfnoc_rx_to_file.cpp but I'm still > looking for how to fix this error in GNU Radio. > > Does anyone know how to solve this? > > Thank you! > > > > Best regards, > > Tuan > > > ------------------------------ > 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 > [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
