Re: [USRP-users] One or more blocks timed out during flush

My new logic appears to have solved the issue of cleaning up the unequal length streams coming from the radios. So, my block is not getting into this bad state anymore. However, just to finish up this discussion, I don't think that the warning is solely related to the output ports (which is how I

[USRP-users] Burst transmissions consistently lead to hard lock up on X310

I’m encountering a consistently reproducible problem on the X310 platform that causes the radio to lock up to the point where I have to power cycle it or flash it over JTAG to return it to a working state. My application is DragonRadio , Drexel’s DARP

Re: [USRP-users] One or more blocks timed out during flush

I like your first idea. To get rid of the warning, I think your block just needs to finish the last packet cleanly on each output port (i.e., TLAST needs to be asserted on the last word written to the NoC shell). The second idea will probably work too, but it won't necessarily get rid of the warnin

Re: [USRP-users] One or more blocks timed out during flush

Thanks Wade, So, I get what you are saying in general but I'm still not clear on specifics. My custom block is a multi-port pulse detector with an equal number of input and output ports. The idea is that the radios stream Rx samples on multiple ports to my block in a single continuous burst. My b

Re: [USRP-users] One or more blocks timed out during flush

I believe RFNoC tries to flush any partially transmitted packets out of blocks during initialization before resetting them. The idea is to get rid of any leftover data that might still be in the data pipes. I think a timeout means the noc_shell never saw the end of the last packet before the timeou

Re: [USRP-users] No streaming using OOT RFNoC Block in UHD4

On 25/01/21 12:37, Aaron Rossetto via USRP-users wrote: > On Mon, Jan 25, 2021 at 11:33 AM Cédric Hannotier via USRP-users > wrote: > > > So the action is propagated by the gain block iif the controller is > > built with UHD and hence recognized by uhd_usrp_probe. > > Building the controller as O