Hi Kevin,\ \ As per the [RFNoC specification](https://files.ettus.com/app_notes/RFNoC_Specification.pdf) Section 2.2.2.1, if you are using bursts, only the first packet of each burst is required to have a timestamp. All subsequent packets of the same burst do not need to have a timestamp included.
The downside of a burst is, that there is the assumption that the data is concurrent, meaning that you have to make sure that you send each packet of the burst to the radio in time, such that the radio always has enough data buffered, and no underflows occur because there are no samples to send in a specific radio clock cycle.\ \ The timestamp itself specifies the time of the first sample within the packet payload. This timestamp signifies, when this first sample was received or when it is supposed to be transmitted, depending on what type of packet you have and the data flow direction, e.g. RX or TX.\ \ Blocks like the radio block (usually) process only one sample per clock cycle per channel internally.\ Since the timestamps are derived from the radio clock this means that the timestamp delta between two subsequent samples is 1. \ This means that for a TX packet with timestamp ts_0, the first sample of the packet will be transmitted at radio clock time ts_0, the second sample will be transmitted at time ts_0 +1, the third at time ts_0 + 2, and so on.\ \ What this means in practice, is that if you take an existing packet with a timestamp and want to split it into two separate packet, both with a timestamp, what you can usually do is this: * The first packet can just reuse the timestamp of the original packet. * For the second packet, you have to check how many samples are included in the payload of the first packet, and then add add that number on top of the timestamp of the original packet. I had a look at the new version of the FFT rfnoc block recently and where it also calculated timestamps for each of the individual samples based on the timestamp of the overarching packet/burst, so maybe you can take a look at that if you need an example of how this can be done in practice [there](https://github.com/EttusResearch/uhd/blob/master/fpga/usrp3/lib/rfnoc/blocks/rfnoc_block_fft/fft_depacketize.sv). For your case, what might make this tricky, is that you might be breaking the continuous sample assumption with your decimator, since the OTA timestamp delta between subsequent samples within the payload of the packet is no longer 1. This is probably fine, as long as you do not forward this decimated packet to another rfnoc block that is timestamp sensitive, e.g. a DUC/DDC, radio, etc…. .\ If you are transmitting the samples to the host, then you as long as you are aware in your application that the packet contains samples that correspond to a sample rate that differs from the radio sample rate, you should also most likely be fine. Disclaimer: I am not 100% sure that all of the assumptions I made are correct, but I have recently done some work on a custom rfnoc_block, where I had to deal with manual timestamping, so hopefully these insights are helpful for you. Regards,\ Niels --- \ Kevin Williams wrote: > Hi, > > Must the timestamp of every packet in an rfnoc network must remain locked to > the time source the radio used when it timestamped the first adc sample of > that packet? > > In other words, if I have a decimator must I figure out the time offset of > the first sample of my decimated packets to within 1 sample of the original > data? > > This seems complex because the radio is delivering packets of some size > related to an rfnoc mtu and most likely not related to my decimator ratio - > so the timestamp of the first sample of my packets changes as it "beats" > with the input packets? > > Thanks, Kevin
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
