Re: [Discuss-gnuradio] updated packet format on USRP inband signaling

[Eric Blossom]

On Mon, Feb 26, 2007 at 09:44:37PM +0100, Martin Dvh wrote:
> Eric Blossom wrote:
> > Would those of you with an interest in USRP inband signaling, please
> > take a look at the latest proposed packet format.  Now's a good time
> > to change things ;)
> > 
> > It's in trunk/usrp/doc/inband-signaling-usb
> 
> TIMESTAMP FORMAT:
> What timestamp format do you have in mind.
> 32 bit samplenumbers, or something else.
> And are samplenumbers, input-samples, output-samples or 64 Mhz clocks.
> 64 Mhz clocks would be the most accurate,

The master clock on the USRP.  For the current models, 64MHz.

> but could be awkward to work with when using fractional
> interpolation or decimation rates.  (I am working on these) When
> using samplenumbers of input-samples or output-samples, you have the
> problem that different channels could work at different rates.  When
> using seconds or milliseconds as timestanmps you have the problem of
> reduced accuracy.

Agreed, that's why I think the master clock is the time base.
It also gives an idea of time that is independent of how any of the
signal processing paths may be configured.

> In the multi_usrp fpga code which I use to synchronise multiple
> usrps I use a 32 bit samplenumember to align different channels from
> different usrps.  (The samplenumber counters are synchronised in
> hardware using GPIO 15 on daughterboard RA)

> In my pre-inbandsignaling code I am now using a whole channel which just 
> sends out samplenumbers.
> This way I can align channels from different usrps, sample-accurate.
> 
> Using in-band signaling I could get away with just a timestamp per
> packet, but then it must have at least 1 sample granularity.

Yes.  This shouldn't be a problem if we use the master clock as the time base.

> TIMESTAMP IN CONTROL CHANNEL:
> What I am missing is a desciption on how the timestamp in the control channel 
> operations is used.

I was thinking that it specifies the time at which the command packet
sequencer starts working through the sub-packets.

> I suggest it would have the following meaning:
> On (a bundle of) write and I2C READ and WRITE and SPI READ and WRITE 
> operations it would mean:
> 
> Start these operation at specified timestamp.
> If the timestamp is 0xffffffff it is interpreted as "Now".

Yes.

> On READ_REPLY operations it would mean:
> These value were read  (all reads were finished) at given timestamp.

Agreed.  On any reply packet, the timestamp is the time at which the command
(or group of commands) finished.

> If the timestamp is 0xffffffff it is interpreted as , "An error has occured, 
> or timeout".

I think I'd rather not overload timestamp for error signaling.

> This would give the following use:
> In a lot of applications you really want to know the exact sample at which 
> some setting was changed.
> 
> For example frequency hopping:
> Change DDC frequency to 16.0 Mhz at timestamp  1000
> Change DDC frequency to 17.0 Mhz at timestamp  1100

Yes.


> RX:

> Then when receiving and the samples come in, I know sample 1000 to
> 1100 have RX DDC freq 16.0 MHz and sample 1100 and beyond have RX
> DDC freq 17.0 Mhz

> TX: send samples 0000 to 1000 knowing it will be transmitted with 16.0 MHz,
>     send samples 1100 and beyond knowing it will be transmitted at 17 MHz.

> Another usefull application is sample-accurate control of the GPIO
> lines.  (set bit GPIO15 high at samplenumber 10000, set it low again
> at samplenumber 10001) This again could be used for the multi_usrp
> code to start synchronising the samplenumber counters (timestamps)

Yes.


> ERROR OR STATUS CONTROL:
> Maybe we also want some more status info (error-control) for operations.
> A single bit in all replies could indicate if an error had occured.
> 
> Or maybe even more advanced:
> ERROR: an error has occured
> INVALID: an invalid value was send to this register. (Better do this in 
> software)
> TIMEOUT: a timeout has occured
> IO_ERROR: I2C or SPI communication failed

OK.  We could grab another bit from the header, or reuse one that only
applies to data packets.  Perhaps we ought to define 4 cases for the
header flags:
  
  DATA    IN
  DATA    OUT
  CONTROL IN
  CONTROL OUT


> MASKED_WRITE:
> What I also miss is a masked write to registers:
> Write Register:
>       
>           Opcode:     OP_WRITE_REG_MASKED
>       
>          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>          |     Opcode    |       6       |    mbz    |     Reg Number    |
>          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>          |                        MASK                                   |
>          |                        Register Value                         |
>          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> A Masked write would save you from needing to do a read, modify,
> write over the BUS when you only want to change a single bit.

Good idea.  I'll add it.


> TYPO:
> I also found a little typo:
> 
> typo:
> 226   SPI Write:
> 227   
> 228       Opcode:           OP_SPI_WRITE
> 229       Enables:          Which SPI enables to assert (mask)
> 230       Format:           Specifies format of SPI data and Opt Header Bytes
> 231       Opt Header Bytes: 2-byte field containing optional Tx bytes; see 
> Format
> 232       Data:             The bytes to write to the I2C bus
> 
> must probably be:
> 232       Data:             The bytes to write to the SPI bus

Thanks!

> 
> I hope these suggestions are of use.

Definitely!  Thanks for taking the time to read through it.

> Martin

Eric