Hi Maria, I'm glad that things are working well now. I don't really understand what the problem was (possibly related to MTU forwarding policy that defaults to DROP in your UHD version and thus must be explicitly set to one-to-one in your custom controller). Good luck. Rob
On Thu, Feb 24, 2022 at 5:35 AM Maria Muñoz <mamuk...@gmail.com> wrote: > Hi Rob, > > Good news! > I managed to get my block receiving samples through the RX radio. It > turned out to be a problem with the Radio and Streamer SPP configuration. > If I set them with 256, it works. I can increase the number of SPP if I add > a fosphor block instead of the QT sink (test it up to 1024). > I still haven't found a solution for GNURadio complaining about the > "previously registered RFNoC block" but seems another issue not related to > this one. > Thanks again for your help. > > Kind Regards, > Maria > > El lun, 21 feb 2022 a las 18:44, Maria Muñoz (<mamuk...@gmail.com>) > escribió: > >> 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
