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

[Eric Blossom]

On Mon, Feb 26, 2007 at 01:22:22AM -0500, David Scaperoth wrote:
> I am definitely interested in the capabilities of the in-band  
> signaling, but my lack of experience is going to show through in this  
> e-mail. =)

No problem.

> I am not sure I understand the meaning behind the 5-bit channel entry:
> I thought that this might refer to channels within the total  
> bandwidth of the incoming / outgoing signals...you said that these  
> are "logically independent of the others" samples, and  I was  
> thinking this was referring perhaps to frequency division of some  
> sort (like bin values in an FFT). Could you help me understand what  
> you mean by channels here?

It's just away to think about how to route samples to/from the A/D's
and D/A's.  (5-bits is probably overkill, but I'm dreaming of a day
when Matt provides us h/w that can do 16x16 MIMO.)  If you're running
two daughterboards, you may want to send an independent stream of
samples to each.  Now, it may be that you want the samples interleaved
(minimizing latency) on a single logical channel, but it also may be
that you are running the two daughterboards fully independently of
each other -- you could imagine them running with different interp or
decim rates (not implemented currently.)  In that case, one stream of
samples would be assigned to Chan 0, the other to Chan 1.


> Is the control channel (0x1f), configuring the hardware(setting  
> center frequency, registers for PGA gain...possibly an AGC in the  
> future, etc....using the I2C & SPI...I'm actually not very familiar  
> with SPI & I2C...)?

Yes.  SPI and I2C are relatively low speed buses commonly used to read
and write values into pieces of h/w (chips).  The differ in the number
of wires, addressing, and the way the bits are transmitted, but
basically they're two common ways of solving a similar problem.

> Just from looking through some of the usrp host files (prims,  
> standard, etc.) it looks like the SPI is for the devices on the  
> motherboard, and the I2C is for the daughterboards...is this correct?

Everything goes to both the motherboard and the daughterboards.
SPI is used to configure the AD9862s, the EEPROMs are controlled over
I2C.  The daughteboard-specific code uses the appropriate interface to
control the chips on the daughterboard.

> Also, I was wondering about Timestamping...In the document you wrote
> 
> "If a packet reaches the head of the transmit queue, and the current
> time is later than the timestamp, an error is assumed to have occurred
> and the       packet is discarded."
> 
> so, if the packet that is ready to be transmitted is early, then it  
> should be discarded?  Maybe I am misunderstanding how the time stamp  
> is going to be done.

If a packet is ready to be transmitted and it's early, it's held
until time to transmit.  If it's late, it's discarded.

> If the timestamp (for the OUT packet) is when the data "should" go
> out of the D/A, then why wouldn't it just wait for the time and
> send.

It does.  Using wall clock time for illustrative purposes, if the
current time is 8:30 and the packet timestamp says 8:25, the packet
got here late, and we drop it ;)

> Would that be too risky...meaning things  
> might get backed up waiting for an incorrect time stamp that is  
> marked two hours into the future?  Wouldn't the packets following  
> also be "early" as well, or could that be corrected?

FWIW, a 32-bit counter, clocked at 64MHz, rolls over every 67 seconds.

There's really very little RAM to store the packets on the FPGA.  The
host needs to send them in proper order.  The timestamp is used to ensure
that they don't go to the D/A's until the right instant.  This is
useful for hitting a TDMA time slot.

> Thanks for any clarification that you can give,

I hope this helped!

> David Scaperoth

Eric