[USRP-users] RFNoC timing clarification
jason at gardettoengineering.com
Wed Jul 12 13:03:50 EDT 2017
Is a "packet" determined before or after the RFNoC stage of the chain (I
assume before since it is in the radio core)?
Is there anyway to modify things if I decide to resample in an RFNoC
block? It seems like it would throw off the timing since the sample
rate into the block != the sample rate leaving the block in this case.
On 07/12/2017 12:58 PM, Jonathon Pendlum wrote:
> Hey Jason,
> The timestamp of each packet describes the time the first sample in
> the packet was received. The timestamp is based on a counter in
> noc_block_radio_core (timekeeper.v.) that increments at the sample
> rate (i.e. radio_clk). The time is relative to that counter's
> placement in the processing chain. We do not do anything to back out
> the delays from elements in front of the counter, such as the delay
> through the front end filters, ADC, digital I/Q correction, etc.
> On Wed, Jul 12, 2017 at 9:20 AM, Jason Matusiak via USRP-users
> <usrp-users at lists.ettus.com <mailto:usrp-users at lists.ettus.com>> wrote:
> I have a timing question that has me going in circles, I don't
> understand how the USRP timestamps work when using RFNoC.
> In a normal system, packets have timestamps with them (or at least
> the first one does) and you can compute the time of any samples
> based on the timestamp, sample rate, and number of samples since
> the timestamp, right?
> Now, if I am using RFNoC, the timestamps aren't attached to the
> samples, right? Where does that timestamp get associated:
> Further down the stream?
> USRP-users mailing list
> USRP-users at lists.ettus.com <mailto:USRP-users at lists.ettus.com>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the USRP-users