On Thu, Mar 15, 2018 at 2:20 PM, EJ Kreinar via USRP-users < usrp-users@lists.ettus.com> wrote:
> Hi Sebastian, > > > Does RFNoC assume that a block always has to output samples within a > certain time limit? Can someone explain to me, where the timeout is checked > and raised? > > You can find the "timeout on chan 0" message implemented in > gr-ettus/lib/rfnoc_block_impl.cc. As you suspected (correctly), it is a > harmless output that can be ignored if no data is actually coming from your > RFNoC block. It is driven by receiving a timeout from the streamer->recv() > function -- it looks like the timeout defaults to 0.1 seconds. > > Why is there a poke32 timeout when it's trying to receive something? That doesn't make any sense to me. What is being poked to the block and, even though there is no AXI data flowing, why would the block timeout? I've seen this happen as well, for some of my custom blocks, and I would like to know needs to happen from an RFNoC perspective to ensure things stay alive. The second message about a task loop exiting, from my experience, basically causes the X310 to become unresponsive until an FPGA reload which is absurd to me. Is there a resource which explains exactly what "background" communication is occurring that would cause this error? Thanks, Brian
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
