The in-band timestamp

GNU Radio
1

Okay, Brian brought this up to me in an off-list discussion that we
think needs to be discussed about the current timestamp generation.

Referring to:
http://gnuradio.org/trac/browser/gnuradio/branches/features/inband-usb/usrp/fpga/inband_lib/rx_buffer_inband.v#L37

The current timestamp runs at the decimated rate, when we’re tossing it
up for discussion if it should be driven from the free running 64MHz
clock.

Leo and I are in the middle of implementing/debugging some other
functionality that I want to finish before touching this, but it’s worth
discussion ahead of time.

  • George
2

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

My 2c:
I imagine that futuristic uses of the USRP (such as the ones for which
you’re explicitly redo-ing the stack) involve dynamically changing the
decimation on the fly. Drive it off the absolute clock to keep some
sense of meaning.

  • -Dan

George N. wrote:

Leo and I are in the middle of implementing/debugging some other
functionality that I want to finish before touching this, but it’s worth
discussion ahead of time.

  • George

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHHTX1y9GYuuMoUJ4RAs9UAJ0Vfz9vvGy5AdaiL0XphP721hodIgCeINaV
480gAWFq0nHaDTp5v8gRcEw=
=ioAZ
-----END PGP SIGNATURE-----

3

On Mon, Oct 22, 2007 at 07:40:40PM -0400, George N. wrote:

functionality that I want to finish before touching this, but it’s worth
discussion ahead of time.

The Rx timestamp should be based on the 64MHz clock, and should be
logically inserted at the tail end of the Rx DSP pipeline (the end
nearest the host).

With regard to the Tx path, Matt & I came to the conclusion that the
time clock should be the 64MHz clock, and that the time check should
be at the head of the DSP pipeline. That is, after the FIFO, but
before the signal processing.

This does imply that the host needs to know the pipeline delay, group
delay, and needs to provide padding for the head and tail of a burst.
After quite a bit of face-to-face discussion, this seemed to be the
only strategy that made sense.

Matt, if I got any of this wrong, please chime in.

Eric