UHD recv timestamp differs from stream command time spec

GNU Radio
1

I’m using a USRP2 with UHD and starting a receive a short time in the
future. I have an external reference and PPS. Below is the pertinent
code, slightly simplified.

The timestamp returned in the metadata by recv is always off a little
from the time I requested in the stream command. The amount it is off
seems to be consistent and related to the sampling rate. For 25 Msps,
it’s always off by 230 nanoseconds, for 12.5 Msps, it’s off by 270
nanoseconds, for 6.25 Msps, it’s off by 350 nanoseconds. If I receive
one packet at a time using RECV_MODE_ONE_PACKET, the first packet’s
metadata is off by the same amount.

I’m using the latest gnuradio and uhd (the one with USRP1 support).

Should I expect the timestamp in the received metadata to match the
requested time in the stream command?

-Marc

// set_clock_config elided.

uhd::stream_cmd_t
streamCommand(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);
streamCommand.num_samps = _buffer.size();
streamCommand.stream_now = false;
streamCommand.time_spec = startingTime;
_usrp->issue_stream_cmd(streamCommand);

size_t numReceived = _device->recv(&_buffer[0], _buffer.size(),
metadata,
uhd::io_type_t::COMPLEX_INT16,
uhd::device::RECV_MODE_FULL_BUFF);
// Error checking elided.

fprintf (stdout, “Off by %g nanoseconds.\n”, (metadata.time_spec -
startingTime).get_real_secs()*1e9);

2

On 09/02/2010 10:39 AM, Marc E. wrote:

metadata is off by the same amount.

I’m using the latest gnuradio and uhd (the one with USRP1 support).

Should I expect the timestamp in the received metadata to match the
requested time in the stream command?

The timestamp that you request is used as the time to turn on the
receiver. The timestamp returned with the data is the time of those
samples at the output of the receive DSP chain. Since there is
decimation in the receive chain, there will be some delay between when
you enable the receiver and when the DSP spits out its first sample.
When using our standard DSP units that we provide in the code, this
delay is a function of the decimation rate.

If you really need your first sample to be at time X, you will need to
send a command which starts the receive chain a little early.

There are two related issues. First, if you are using the standard ATR
settings, the receiver is turned off when you are not receiving.
Nothing powers up instantly, so if you want to have useful reception at
a particular time, you will also need to turn it on early.

The second issue is group delay through the RF, ADC, and DSP. We
demarcate time at the output (decimated) side of the DSP. That data
came in over the air some time earlier, but that time delta is a
function of the daughterboard design and settings (particularly the
filters), the ADC design, and the DSP design and settings. The DSP
delays can be calculated. In any application where you need to know to
the nanosecond the time a particular sample represents at the antenna
port you will need to calibrate the delays.

All of this applies to the TX side as well, in reverse.

Matt

3

On Sep 2, 2010, at 1:02 PM, Matt E. wrote:

[An excellent answer.]

Thanks!

-Marc