I prefer the packet pushing idea, but feel free to do what you feel is
the better idea.
I agree with Brian. The push functionality is a better way to go. In
particular, I think it would insure a more “correct” operation for the
receive timestamps. 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 M.
On Tue, Aug 26, 2008 at 07:38:47PM -0500, Ketan M. 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
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 B. [email protected] wrote:
delay, and thus can achieve the goal of precise time of transmission,
Tx timing Ref Pt
–
Ketan M.