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
