Nick, I had worked on something similar (a keep m-in-n block actually),
and may have oversimplified things. I kept track of how many samples I
outputted and set the tlast accordingly, wouldn't that solve the
"reconstituting packet boundaries" issue you mentioned?
Also, I am not sure I investigated the blocking. I just suck in samples
one at a time. If I don't need the sample, I dump it. If I want to
pass the sample I wait until the downstream block is ready and pass it
along. It seems to work for me, but maybe I just haven't pushed it hard
enough to see the gotchyas. Did I oversimplify this?
On 08/02/2017 05:57 PM, Nick Foster via USRP-users wrote:
I made one for a project, but can't share it as it's customer work.
It's a little bit tricky and I never got it 100% right, but it works
well enough for what it needs to do. The tricky parts are preserving
or reconstituting packet boundaries, and being able to advance and
delay the stream without blocking downstream (or upstream) blocks.
--n
On Wed, Aug 2, 2017 at 2:06 PM Dixon, James L via USRP-users
<usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote:
Hi,
I am wondering if there is some type of variable delay block
available in RFNoC. I see that there is a Delay block available
in gnu-radio, but I need it to be in the FPGA.
Thanks,
Jim
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
