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