discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] inband timestamp issues


From: Ketan Mandke
Subject: Re: [Discuss-gnuradio] inband timestamp issues
Date: Tue, 26 Aug 2008 20:58:03 -0500

Eric,

>              Tx timing Ref Pt
>                    |
>                    v
> USB --> buffers ---> DSP pipeline --> DAC
>
> USB <-- buffers <--- DSP pipeline <-- ADC
>                    ^
>                    |
>              Rx timing Ref Pt

I definitely see why the reference point for the timestamp should come
after the DSP pipeline. I guess my point was that if the ADC+DSP
pipeline for each channel is configured to the same setting (i.e.
interpolation rate, filter, etc.), then the timestamps for
corrseponding packets must be consistent (i.e. identical). If the
channels are configured differently, it would make sense that the
timestamps would not correspond. The current configuration of the
packet builder assembles packets from each channel fifo one-at-a-time,
and thus the timestamp corresponds to the time at which the packet was
built not when the packet was received or passed through the pipeline.

For my own part, I am more concerned with consistent timing between
the antenna chains, more so than precise timing. That way, I can be
sure of what samples match up from the different RX chains; and be
sure that if I send packets to each TX chain with the same timestamp,
both TX chains will fire at the same time. I might be rambling a bit,
so I should conclude by saying that I think that the push strategy
which Brian has suggested (i.e. with parallel packet FIFO's) is
probably a good way to maintain a consistent timestamp between the RX
chains. Hope that wasn't too confusing.

On Tue, Aug 26, 2008 at 8:29 PM, Eric Blossom <address@hidden> wrote:
> On Tue, Aug 26, 2008 at 07:38:47PM -0500, Ketan Mandke wrote:
>
>> The timestamp for packets should corrsepond to the
>> time when the first sample in the packet is actually "strobed" off the
>> ADC. This would also insure that the two channels on the board would
>> have synchronous timestamps (i.e. if a sample is strobed in from each
>> channel at the same time, the packets formed from the proceeding
>> samples should have the same timestamp).
>
> Ketan,
>
> We definitely want the two channels to have synchronous timestamps,
> and we want the Tx and Rx to share a common idea of time.  However
> I think that the reference point for timing is at the edge the DSP
> pipeline, not the ADC or DAC.  (I thought it was at the ADC/DAC
> originally too, but after a fair amount of reflection (and strong
> prodding from Matt, I've come around to this point of view.))
> The challenge is easy to see if you look at the Tx direction.  The
> pipeline and group delay through the Tx DSP pipeline varies depending
> on many configuration options, including the interpolation rate, any
> filters, etc.  The host is capable of knowing and computing this
> delay, and thus can achieve the goal of precise time of transmission,
> even though the reference point is at the near edge of the DSP
> pipeline, not the DAC.  Same story on Rx.
>
> This also implies that the host should preload enough zeros into the
> head of the burst such that the signal of interest gets out of the DAC
> at the desired time.
>
> Does this make sense?
>
>
>              Tx timing Ref Pt
>                    |
>                    v
> USB --> buffers ---> DSP pipeline --> DAC
>
> USB <-- buffers <--- DSP pipeline <-- ADC
>                    ^
>                    |
>              Rx timing Ref Pt
>
> Eric
>



-- 
Ketan Mandke




reply via email to

[Prev in Thread] Current Thread [Next in Thread]