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 (<[email protected]>) 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 <[email protected]> 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 (<[email protected]>) >> 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 <[email protected]> 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 (<[email protected]>) >>>> 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 <[email protected]> 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 <[email protected]> >>>>>> 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 -- [email protected] >>>>>>> To unsubscribe send an email to [email protected] >>>>>>> >>>>>>
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
