It is up to you. You can keep the time stamp from the first packet assuming you consume on packet boundaries (e.g. you consume N whole packets to output one packet). If you don't consume on packet boundaries, it will be easier to throw away the vita time.
On Thu, Aug 10, 2017 at 12:23 PM, Jason Matusiak < [email protected]> wrote: > I assume that the timestamps from the radio need to be thrown out the > window when doing something like this (or fosphor), right? > > > On 08/08/2017 06:18 PM, Jonathon Pendlum wrote: > > I think you're overthinking it. :-) Consider RFNoC fosphor, it takes in > 200 MSPS but has a very low output rate. Everything works fine because UHD > has no expectations on the line rate of the incoming data stream. > > On Tue, Aug 8, 2017 at 12:02 PM, Jason Matusiak via USRP-users < > [email protected]> wrote: > >> I have an RFNoC block that is probably going to take in a vector of data >> (200msps off the RFNoC:Radio), sum it with some values and continue. Every >> X number of vectors (could be as high as 1024 times), it will output a >> vector of its own. >> >> This means that at 200msps, I could have a flow of data as slow as nearly >> 200ksps. I could use the DDC, but that would muck with my summed values. >> Is there any way for me to run my block yet have UHD know that I am >> outputting at a slower rate so it doesn't try to suck in 200msps across the >> connection to the host? >> >> _______________________________________________ >> USRP-users mailing list >> [email protected] >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> > > >
_______________________________________________ USRP-users mailing list [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
