[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] updated packet format on USRP inband signaling
From: |
Eric Blossom |
Subject: |
Re: [Discuss-gnuradio] updated packet format on USRP inband signaling |
Date: |
Mon, 26 Feb 2007 13:15:59 -0800 |
User-agent: |
Mutt/1.5.9i |
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
Re: [Discuss-gnuradio] updated packet format on USRP inband signaling, David Scaperoth, 2007/02/26
Re: [Discuss-gnuradio] updated packet format on USRP inband signaling, Martin Dvh, 2007/02/26
- Re: [Discuss-gnuradio] updated packet format on USRP inband signaling,
Eric Blossom <=
- Re: [Discuss-gnuradio] updated packet format on USRP inband signaling, Brian Padalino, 2007/02/26
- Re: [Discuss-gnuradio] updated packet format on USRP inband signaling, Eric Blossom, 2007/02/26
- Message not available
- Re: [Discuss-gnuradio] updated packet format on USRP inband signaling, Eric Blossom, 2007/02/26
- Re: [Discuss-gnuradio] updated packet format on USRP inband signaling, Greg Troxel, 2007/02/27
- Re: [Discuss-gnuradio] updated packet format on USRP inband signaling, Eric Blossom, 2007/02/27
- Re: [Discuss-gnuradio] updated packet format on USRP inband signaling, Greg Troxel, 2007/02/27
- Re: [Discuss-gnuradio] updated packet format on USRP inband signaling, Eric Blossom, 2007/02/28
- Re: [Discuss-gnuradio] updated packet format on USRP inband signaling, Greg Troxel, 2007/02/28
- Re: [Discuss-gnuradio] updated packet format on USRP inband signaling, Timothy Brown, 2007/02/28
- Re: [Discuss-gnuradio] updated packet format on USRP inband signaling, Eric Blossom, 2007/02/28