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 <
ja...@gardettoengineering.com> 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 <
> usrp-users@lists.ettus.com> 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
>> 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