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
