EJ Kreinar wrote:
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
Thank you EJ for pointing me in the right direction. Good to know that I
can ignore these messages.
Brian Padalino wrote:
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?
It would indeed be very interesting to know how this background
communication operates in order to be able to debug those error messages.
Best regards,
Sebastian
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
