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

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 <mamuki92@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-leave@lists.ettus.com >

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 <rkossler@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 <mamuki92@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-leave@lists.ettus.com >> >

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);
 }

 void issue_stream_cmd(const uhd::stream_cmd_t& stream_cmd, const

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 (<rkossler@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 <rkossler@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 <mamuki92@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-leave@lists.ettus.com >>> >>

 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);
 }

  void issue_stream_cmd(const uhd::stream_cmd_t& stream_cmd, const

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 <mamuki92@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 (<rkossler@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 <rkossler@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 <mamuki92@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-leave@lists.ettus.com >>>> >>>

- 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.

 auto 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);
 }

  void issue_stream_cmd(const uhd::stream_cmd_t& stream_cmd, const

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 (<rkossler@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 <mamuki92@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 (<rkossler@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 <rkossler@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 <mamuki92@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-leave@lists.ettus.com >>>>> >>>>

- 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.

 auto 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);
 }

  void issue_stream_cmd(const uhd::stream_cmd_t& stream_cmd, const

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 <mamuki92@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 (<rkossler@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 <mamuki92@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 (<rkossler@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 <rkossler@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 <mamuki92@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-leave@lists.ettus.com >>>>>> >>>>>

- 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.

 auto 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);
 }

  void issue_stream_cmd(const uhd::stream_cmd_t& stream_cmd, const

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 (<rkossler@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 <mamuki92@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 (<rkossler@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 <mamuki92@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 (<rkossler@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 <rkossler@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 <mamuki92@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-leave@lists.ettus.com >>>>>>> >>>>>>

- 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.

 auto 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);
 }

  void issue_stream_cmd(const uhd::stream_cmd_t& stream_cmd, const

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 <mamuki92@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 (<rkossler@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 <mamuki92@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 (<rkossler@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 <mamuki92@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 (<rkossler@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 <rkossler@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 <mamuki92@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-leave@lists.ettus.com >>>>>>>> >>>>>>>

- 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.

 auto 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);
 }

  void issue_stream_cmd(const uhd::stream_cmd_t& stream_cmd, const

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 <rkossler@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 <mamuki92@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 (<rkossler@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 <mamuki92@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 (<rkossler@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 <mamuki92@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 (<rkossler@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 <rkossler@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 <mamuki92@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-leave@lists.ettus.com >>>>>>>>> >>>>>>>>