Ok Rob, I will check everything you've said and give you an answer if I find the solution. Many thanks for the help!
Maria El lun., 21 feb. 2022 18:25, Rob Kossler <rkoss...@nd.edu> escribió: > I'm not sure. Yes, it seems the first line could be a problem. Maybe your > OOT rfnoc_mod_tool is correctly registering your block AND the in-tree > block is being registered. I don't see why that would be a problem (given > that they should both be the same anyway), but you should probably try to > fix it. > > Another idea is to enable UHD "debug" logging by setting environment > variables as shown here > <https://files.ettus.com/manual/log_8hpp.html#loghpp_levels>. This may > show useful information. > > Another idea is to specifically set the policy to ONE_TO_ONE in your > custom block controller constructor as is done with several Ettus RFNoC > blocks like this > <https://github.com/EttusResearch/uhd/blob/master/host/lib/rfnoc/fft_block_control.cpp>FFT > controller. But, really, this shouldn't be needed since it should be the > default. > > And, again, maybe see about calling issue_stream_cmd() from the DDC > controller instead of the rx_streamer. > > Rob > > > > On Mon, Feb 21, 2022 at 11:52 AM Maria Muñoz <mamuk...@gmail.com> wrote: > >> This is my output for gnuradio: >> >> *REGISTRY] WARNING: Attempting to overwrite previously registered RFNoC >> block with noc_id,device_id: 0x29106060, 0xffff* >> [INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100; >> UHD_4.0.0.HEAD-0-g90ce6062 >> [INFO] [MPMD] Initializing 1 device(s) in parallel with args: >> mgmt_addr=192.168.1.23,type=e3xx,product=e320,serial=31DFBB7,claimed=False,addr=192.168.1.23 >> [INFO] [MPM.main] Launching USRP/MPM, version: 4.0.0.0-g57ca4235 >> [INFO] [MPM.main] Spawning RPC process... >> [INFO] [MPM.PeriphManager] Device serial number: 31DFBB7 >> [INFO] [MPM.PeriphManager] Found 1 daughterboard(s). >> [INFO] [MPM.RPCServer] RPC server ready! >> [INFO] [MPM.RPCServer] Spawning watchdog task... >> [INFO] [MPM.PeriphManager] iniciando mpm >> [INFO] [MPM.PeriphManager] init() called with device args >> `mgmt_addr=192.168.1.23,product=e320'. >> [INFO] [0/DmaFIFO#0] BIST passed (Estimated Minimum Throughput: 1361 MB/s) >> [INFO] [0/DmaFIFO#0] BIST passed (Estimated Minimum Throughput: 1361 MB/s) >> [INFO] [0/Radio#0] Performing CODEC loopback test on channel 0 ... >> [INFO] [0/Radio#0] CODEC loopback test passed >> [INFO] [0/Radio#0] Performing CODEC loopback test on channel 1 ... >> [INFO] [0/Radio#0] CODEC loopback test passed >> gr::log :DEBUG: rfnoc_rx_streamer0 - Committing graph... >> [WARNING] [0/Radio#0] Attempting to set tick rate to 0. Skipping. >> gr::log :DEBUG: rfnoc_rx_streamer0 - Sending start stream command... >> Ogr::log :DEBUG: rfnoc_rx_streamer0 - UHD recv() call timed out. >> >> Seems that the first line is the problem. The 0x29106060 is my rfnoc >> block. Should I recompile also gnuradio to catch the controller I install >> in UHD? >> >> El lun, 21 feb 2022 a las 17:38, Rob Kossler (<rkoss...@nd.edu>) >> escribió: >> >>> This looks all correct when using uhd_usrp_probe. How about when you >>> run from gnuradio - does the UHD console log show "anc2#0" or "Block#0" (or >>> neither)? >>> >>> Regarding your question about issue_stream_cmd() from the DDC controller >>> in gnuradio, I've forgotten how things are done in gnuradio - could you >>> send your python file and maybe I can suggest a modification? >>> >>> By the way, each FPGA block (such as DDC) has a corresponding UHD block >>> controller (running on the host side). So, it is possible to run >>> issue_stream_cmd from the DDC controller rather than the rx_streamer. I >>> just don't remember how exactly to do that from gnuradio. >>> Rob >>> >>> On Mon, Feb 21, 2022 at 11:27 AM Maria Muñoz <mamuk...@gmail.com> wrote: >>> >>>> Hi Rob, >>>> >>>> I have compiled the default cpp and hpp files in-tree, as I read that >>>> this could be the issue. And uhd_usrp_probe identifies my block controller >>>> name (anc2): >>>> >>>> uhd_usrp_probe >>>> [INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100; >>>> UHD_4.0.0.HEAD-0-g90ce6062 >>>> [INFO] [MPMD] Initializing 1 device(s) in parallel with args: >>>> mgmt_addr=,type=e3xx,product=e320,serial=31DFBB7,claimed=False,addr= >>>> [INFO] [MPM.PeriphManager] iniciando mpm >>>> [INFO] [MPM.PeriphManager] init() called with device args >>>> `mgmt_addr=,product=e320'. >>>> [INFO] [0/DmaFIFO#0] BIST passed (Estimated Minimum Throughput: 1361 >>>> MB/s) >>>> [INFO] [0/DmaFIFO#0] BIST passed (Estimated Minimum Throughput: 1361 >>>> MB/s) >>>> [INFO] [0/Radio#0] Performing CODEC loopback test on channel 0 ... >>>> [INFO] [0/Radio#0] CODEC loopback test passed >>>> [INFO] [0/Radio#0] Performing CODEC loopback test on channel 1 ... >>>> [INFO] [0/Radio#0] CODEC loopback test passed >>>> _____________________________________________________ >>>> / >>>> | Device: E300-Series Device >>>> | _____________________________________________________ >>>> | / >>>> | | Mboard: ni-e320-31DFBB7 >>>> | | eeprom_version: 3 >>>> | | fs_version: 20200914014807 >>>> | | mender_artifact: v4.0.0.0_e320 >>>> | | mpm_sw_version: 4.0.0.0-g57ca4235 >>>> | | pid: 58144 >>>> | | product: e320 >>>> | | rev: 5 >>>> | | rpc_connection: remote >>>> | | serial: 31DFBB7 >>>> | | type: e3xx >>>> | | MPM Version: 3.0 >>>> | | FPGA Version: 6.0 >>>> | | FPGA git hash: 90ce606.dirty >>>> | | >>>> | | Time sources: internal, external, gpsdo >>>> | | Clock sources: external, internal, gpsdo >>>> | | Sensors: ref_locked, gps_locked, fan, temp_fpga, temp_internal, >>>> temp_rf_channelA, temp_rf_channelB, temp_main_power, gps_gpgga, gps_sky, >>>> gps_time, gps_tpv >>>> | _____________________________________________________ >>>> | / >>>> | | RFNoC blocks on this device: >>>> | | >>>> | | * 0/DDC#0 >>>> | | * 0/DUC#0 >>>> | | * 0/DmaFIFO#0 >>>> | | * 0/Radio#0 >>>> | | ** 0/anc2#0* >>>> | _____________________________________________________ >>>> | / >>>> | | Static connections on this device: >>>> | | >>>> | | * 0/SEP#0:0==>0/DUC#0:0 >>>> | | * 0/DUC#0:0==>0/Radio#0:0 >>>> | | * 0/Radio#0:0==>0/DDC#0:0 >>>> | | * 0/DDC#0:0==>0/SEP#0:0 >>>> | | * 0/SEP#1:0==>0/DUC#0:1 >>>> | | * 0/DUC#0:1==>0/Radio#0:1 >>>> | | * 0/Radio#0:1==>0/DDC#0:1 >>>> | | * 0/DDC#0:1==>0/SEP#1:0 >>>> | | * 0/SEP#2:0==>0/DmaFIFO#0:0 >>>> | | * 0/DmaFIFO#0:0==>0/SEP#2:0 >>>> | | * 0/SEP#3:0==>0/DmaFIFO#0:1 >>>> | | * 0/DmaFIFO#0:1==>0/SEP#3:0 >>>> | | * 0/SEP#4:0==>0/anc2#0:0 >>>> | | * 0/anc2#0:0==>0/SEP#4:0 >>>> | _____________________________________________________ >>>> | / >>>> | | TX Dboard: dboard >>>> | | _____________________________________________________ >>>> | | / >>>> | | | TX Frontend: 0 >>>> | | | Name: E3xx >>>> | | | Antennas: TX/RX >>>> | | | Freq range: 47.000 to 6000.000 MHz >>>> | | | Gain range PGA: 0.0 to 89.8 step 0.2 dB >>>> | | | Bandwidth range: 20000000.0 to 40000000.0 step 0.0 Hz >>>> | | | Connection Type: IQ >>>> | | | Uses LO offset: No >>>> | | _____________________________________________________ >>>> | | / >>>> | | | TX Frontend: 1 >>>> | | | Name: E3xx >>>> | | | Antennas: TX/RX >>>> | | | Freq range: 47.000 to 6000.000 MHz >>>> | | | Gain range PGA: 0.0 to 89.8 step 0.2 dB >>>> | | | Bandwidth range: 20000000.0 to 40000000.0 step 0.0 Hz >>>> | | | Connection Type: IQ >>>> | | | Uses LO offset: No >>>> | _____________________________________________________ >>>> | / >>>> | | RX Dboard: dboard >>>> | | _____________________________________________________ >>>> | | / >>>> | | | RX Frontend: 0 >>>> | | | Name: E3xx >>>> | | | Antennas: RX2, TX/RX >>>> | | | Freq range: 70.000 to 6000.000 MHz >>>> | | | Gain range PGA: 0.0 to 76.0 step 1.0 dB >>>> | | | Bandwidth range: 20000000.0 to 40000000.0 step 0.0 Hz >>>> | | | Connection Type: IQ >>>> | | | Uses LO offset: No >>>> | | _____________________________________________________ >>>> | | / >>>> | | | RX Frontend: 1 >>>> | | | Name: E3xx >>>> | | | Antennas: RX2, TX/RX >>>> | | | Freq range: 70.000 to 6000.000 MHz >>>> | | | Gain range PGA: 0.0 to 76.0 step 1.0 dB >>>> | | | Bandwidth range: 20000000.0 to 40000000.0 step 0.0 Hz >>>> | | | Connection Type: IQ >>>> | | | Uses LO offset: No >>>> >>>> >>>> >>>> But besides that, Radio does not stream anything. I attach my block >>>> controller (which I haven't modified and has been generated with >>>> rfnocmodtool). >>>> I guess the problem could be what you said about the forwarding policy >>>> set as drop by default, but I do not see any parameter like "one-to-one" or >>>> "drop" anywhere. I use UHD 4.0 but not sure if this issue was fixed when I >>>> installed it. >>>> Do you see any problem with the controller I am using? >>>> >>>> Thanks again for the help, >>>> >>>> Maria. >>>> >>>> El lun, 21 feb 2022 a las 16:49, Rob Kossler (<rkoss...@nd.edu>) >>>> escribió: >>>> >>>>> Hi Maria, >>>>> A few remarks: >>>>> >>>>> - If you wrote a custom block controller for your custom block, >>>>> then the forwarding policy should already be correct (one-to-one) by >>>>> default (unless your custom block controller specifically set the >>>>> policy to >>>>> DROP). On the other hand, if you did not write a custom block >>>>> controller >>>>> (thus relying on the UHD default block controller), then this explains >>>>> the >>>>> issue because in that case the default policy is "drop" (which will >>>>> cause >>>>> the issue you are seeing). Note that the default behavior of DROP for >>>>> the >>>>> default block controller has been changed to ONE_TO_ONE on the 'master' >>>>> branch of UHD but has not yet been changed on branch UHD-4.1. >>>>> - So, you don't need to implement "issue_stream_cmd". You just >>>>> need to verify that your block's action & properties forwarding >>>>> policies >>>>> are ONE_TO_ONE (which as I mentioned should be automatic if you create >>>>> your >>>>> own custom controller). >>>>> - You mentioned that you used rfnocmodtool to create your block >>>>> controller. But, my concern is that this block controller is not really >>>>> being used. If you run uhd_usrp_probe, does your block show up with a >>>>> custom name (that you specified) or does it show up as "Block#0". If it >>>>> shows with the generic name "Block#0" it means that UHD is not using >>>>> your >>>>> block controller and instead using the default block controller (which >>>>> DROPs forwarding on UHD 4.1). So, if this is the case for you, that >>>>> is the >>>>> issue that needs to be solved. Unfortunately, I don't know the best >>>>> way to >>>>> solve this because I don't use rfnoc_mod_tool. Take a look at the gain >>>>> block controller >>>>> >>>>> <https://github.com/EttusResearch/uhd/blob/UHD-4.1/host/examples/rfnoc-example/lib/gain_block_control.cpp> >>>>> in the uhd/host/examples/rfnoc-example/ folder. Note that this example >>>>> does very little (empty constructor). At the bottom is a string >>>>> identifying the block which is the string that will be shown with >>>>> uhd_usrp_probe if UHD is using your block controller. >>>>> >>>>> Let me know if this is the issue. Once you get uhd_usrp_probe to "see" >>>>> your block controller, your problem should be solved. If you can't get >>>>> this >>>>> to work, let me know. >>>>> Rob >>>>> >>>>> On Mon, Feb 21, 2022 at 4:41 AM Maria Muñoz <mamuk...@gmail.com> >>>>> wrote: >>>>> >>>>>> Hi Rob, >>>>>> >>>>>> Thanks for the answer. >>>>>> >>>>>> I have checked rfnoc_rx_streamer.cpp, ddc_block_control.cpp and my >>>>>> custom block controller in uhd/host/lib folder, and I search for >>>>>> "issue_stream_cmd" in them. >>>>>> >>>>>> In the rx_streamer one I see this function: >>>>>> >>>>>> void rfnoc_rx_streamer::issue_stream_cmd(const stream_cmd_t& >>>>>>> stream_cmd) >>>>>>> { >>>>>>> if (get_num_channels() > 1 and stream_cmd.stream_now >>>>>>> and stream_cmd.stream_mode != >>>>>>> stream_cmd_t::STREAM_MODE_STOP_CONTINUOUS) { >>>>>>> throw uhd::runtime_error( >>>>>>> "Invalid recv stream command - stream now on multiple >>>>>>> channels in a " >>>>>>> "single streamer will fail to time align."); >>>>>>> } >>>>>> >>>>>> >>>>>> auto cmd = >>>>>>> stream_cmd_action_info::make(stream_cmd.stream_mode); >>>>>>> cmd->stream_cmd = stream_cmd; >>>>>> >>>>>> >>>>>> for (size_t i = 0; i < get_num_channels(); i++) { >>>>>>> const res_source_info info(res_source_info::INPUT_EDGE, i); >>>>>>> post_action(info, cmd); >>>>>>> } >>>>>>> } >>>>>> >>>>>> >>>>>> While in the ddc I see this: >>>>>> >>>>>> void issue_stream_cmd(const uhd::stream_cmd_t& stream_cmd, const >>>>>>> size_t port) >>>>>>> { >>>>>>> RFNOC_LOG_TRACE("issue_stream_cmd(stream_mode=" << >>>>>>> char(stream_cmd.stream_mode) >>>>>>> << ", port=" >>>>>>> << port); >>>>>>> res_source_info dst_edge{res_source_info::OUTPUT_EDGE, port}; >>>>>>> auto new_action = >>>>>>> stream_cmd_action_info::make(stream_cmd.stream_mode); >>>>>>> new_action->stream_cmd = stream_cmd; >>>>>>> issue_stream_cmd_action_handler(dst_edge, new_action); >>>>>>> } >>>>>> >>>>>> >>>>>> There's no "issue_stream_cmd" on my block controller, so maybe as you >>>>>> said the block is not forwarding actions. I'm not very familiar with >>>>>> controller files, so could you please tell me which changes I must do to >>>>>> have my block forwarding actions or point me out to any example to take >>>>>> as >>>>>> a reference? I created my block using rfnocmodtool and follow the gain >>>>>> example, so I guess this example is not forwarding actions either. >>>>>> >>>>>> By the way, how can I stream from DDC in a GNURadiograph? If DDC is >>>>>> on the FPGA side, I have to cross to the host domain through a streamer, >>>>>> don't I? >>>>>> >>>>>> Kind Regards, >>>>>> >>>>>> Maria >>>>>> >>>>>> >>>>>> >>>>>> El vie, 18 feb 2022 a las 15:14, Rob Kossler (<rkoss...@nd.edu>) >>>>>> escribió: >>>>>> >>>>>>> By the way, if your custom FPGA block was truly the problem >>>>>>> (blocking streaming), the Rx LED should be on and you should be getting >>>>>>> lots of Overflow. Since this is not happening, it is a good indication >>>>>>> that >>>>>>> the Rx Radio is never starting. >>>>>>> >>>>>>> On Fri, Feb 18, 2022 at 9:10 AM Rob Kossler <rkoss...@nd.edu> wrote: >>>>>>> >>>>>>>> Hi Maria, >>>>>>>> The issue is likely related to "action forwarding" of the streaming >>>>>>>> command. When your application asks to start streaming, it typically >>>>>>>> does >>>>>>>> so by calling rx_streamer->issue_stream_cmd(). This "action" will >>>>>>>> then be >>>>>>>> forwarded to the next upstream block controller (typically DDC block >>>>>>>> controller) which will see the command and forward it to the next >>>>>>>> upstream >>>>>>>> block controller (typically the Rx radio controller). The Rx radio >>>>>>>> block >>>>>>>> controller will then start the streaming. As an example, let's say >>>>>>>> your >>>>>>>> rx_streamer requested a fixed number of samples (say 1000) and assume >>>>>>>> that >>>>>>>> your DDC decimation is 4. With this architecture, the DDC block >>>>>>>> controller >>>>>>>> can intercept the action and change the requested number of samples >>>>>>>> from >>>>>>>> 1000 to 4000 so that when the radio block controller receives the >>>>>>>> command, >>>>>>>> it will stream for exactly 4000 samples (which will provide 1000 >>>>>>>> samples >>>>>>>> out of the DDC). Note that all of this "action" propagation occurs in >>>>>>>> UHD >>>>>>>> land (not on the FPGA). So, if your custom block controller is not >>>>>>>> forwarding actions, the Radio controller never gets the action and thus >>>>>>>> never starts the streaming. One way you can verify this is if you are >>>>>>>> able >>>>>>>> to call issue_stream_cmd() from the DDC controller rather than the >>>>>>>> rx_streamer. This should cause your streaming to start. >>>>>>>> Rob >>>>>>>> >>>>>>>> On Fri, Feb 18, 2022 at 8:13 AM Maria Muñoz <mamuk...@gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I'm using a USRP E320 with UHD 4.0 and GNURadio 3.8 for receiving >>>>>>>>> samples through an RX RFNoC Radio block and performing some >>>>>>>>> processing in a >>>>>>>>> custom RFNoC block. >>>>>>>>> I have created my block using rfnocmodtool, modifying the Verilog >>>>>>>>> and yml files for my custom block. I left the cpp and hpp files as >>>>>>>>> default, >>>>>>>>> but I copied them to the UHD install path to see the name of my block >>>>>>>>> with >>>>>>>>> uhd_usrp_probe. >>>>>>>>> I have tested satisfactorily my custom block with a gnuradio graph >>>>>>>>> like this: >>>>>>>>> >>>>>>>>> Host block => rfnoc tx streamer => custom RFNoC block => rfnoc rx >>>>>>>>> streamer => Host block >>>>>>>>> >>>>>>>>> I have also tested it for transmission through the rfnoc tx radio, >>>>>>>>> and works fine: >>>>>>>>> >>>>>>>>> Host block => rfnoc tx streamer => custom RFNoC block => RFNoC >>>>>>>>> DUC=> RFNoC TX Radio >>>>>>>>> >>>>>>>>> But when I try to receive from the radio with the following graph, >>>>>>>>> rx led does not light up and gnuradio give time out: >>>>>>>>> RFNoC RX Radio => RFNoC DDC => custom RFNoC block => rfnoc rx >>>>>>>>> streamer =>Host block >>>>>>>>> >>>>>>>>> If I remove my custom block from the last graph, I can receive >>>>>>>>> samples and the led is on. >>>>>>>>> >>>>>>>>> It seems like the custom block is blocking somehow the samples. I >>>>>>>>> tried with different sampling rates and spp values for the radio but >>>>>>>>> nothing works. >>>>>>>>> >>>>>>>>> Any help on this will be appreciated. >>>>>>>>> >>>>>>>>> Kind Regards, >>>>>>>>> >>>>>>>>> Maria >>>>>>>>> _______________________________________________ >>>>>>>>> USRP-users mailing list -- usrp-users@lists.ettus.com >>>>>>>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com >>>>>>>>> >>>>>>>>
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
