[Discuss-gnuradio] Re: Preliminary In-band signaling

[Eric Blossom]

On Wed, Feb 21, 2007 at 11:11:43PM -0500, Brian Padalino wrote:
> Eric,
> 
> I realize what you have checked in is strictly very preliminary (hence
> keeping this off-list), but I was curious if you had plans to add
> basically every one of the FPGA register settings that might get set
> for each burst transmission.

I'm planning on adding a section talking about the control channel.
I expect the control channel payload to be composed of a sequence of 
ops + args that is reasonably easy to parse in the FPGA.  Control
channel ops will honor the timestamp too.

One of the ops will be WRITE_REGISTER.
Others will include the rest of the stuff that can't be squeezed into
WRITE_REGISTER such as I2C_READ/WRITE, SPI_READ/WRITE

> I was also curious in regards to the timestamp field and
> synchronization.  Since the FPGA has no sense of time other than clock
> ticks, what kind of reference does that timestamp really give?

One of the use cases we want to be able to satisfy is TDMA waveforms.
In those cases you need to be able to hit a transmit slot that is
defined in relationship to some other receive slot.  Think about how
cellular mobiles work.

The timestamp will be a free running counter that is logically
adjacent to the A/D and D/A i/o pins.  On receive, the value stuck into the
packet is the value of the counter that corresponds to the first
sample in the payload.  On Tx, the timestamp corresponds to the tick
that the first sample of the payload will be sent to the DACS.

We'll provide some way for the host to set or reset the counter, but
this really only matters in multi-board setups.  In that case (on the
upcoming USRP2), we'll provide h/w that supports coherent timing
across multiple boards.

We'll also have to work out some way for the host to estimate
round-trip latency looped-back through the Tx/Rx path.

> Sorry if this is just too soon.

No problem.  I'm planning on doing more work on the description this
evening or tomorrow morning.  Let me know if you think I'm missing
something, or if I'm designing something that's hard to implement, or
if you think you've got a better way to approach the problem.

Thanks for all your efforts on the Wiki!

Eric