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

[Martin Dvh]

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, 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.


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.


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

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".

On READ_REPLY operations it would mean:
These value were read  (all reads were finished) at given timestamp.
If the timestamp is 0xffffffff it is interpreted as , "An error has occured, or 
timeout".

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

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)

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

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.


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


I hope these suggestions are of use.

Martin
> 
> http://gnuradio.org/trac/browser/gnuradio/trunk/usrp/doc/inband-signaling-usb
> 
> Thanks,
> Eric
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>