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
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
