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

Reply via email to