Re: [Discuss-gnuradio] Regarding 371 samples/frame in usrp2

[Eric Blossom]

On Wed, Nov 05, 2008 at 07:30:01PM +0100, Mattias Kjellsson wrote:
> Eric Blossom wrote:
>>
>> There are a couple of headers.  See usrp2_eth_packet.h 
>
> So I have. Regarding the channel and timestamp fields in "struct  
> u2_fixed_hdr_t", channel is going to (when implemented) reflect which  
> usrp2 you want to "speak" with, when mimo- configured? For instance say  
> I have two usrp2 connected with a mimo- cable. Then I send data to  
> usrp2#1 on channel #1 and to usrp2#2 on channel #2, while I still use  
> channel #0 to configure them? Or is this functionality still to much on  
> the drawing- board to be able to say "this is how it's (going to(?)) 
> work.

Probably too early on this.  We'll probably be moving to something
that looks like VRT ("Virtual Radio Transport" a.k.a VITA 49 -- a
format for digitized IF data), and possibly over UDP instead of raw
ethernet.  In any event there will be some way to distinguish control
packets from data packets, and for each of those types, some way to
distinguish which logical pipeline (stream) the data is from or for.
The mimo stuff is really just a generalization of support for multiple
streams within a single USRP.

> The timestamp in the same header, supposed to reflect when it's going to  
> be sent out on the antenna, when it was received to the usrp2, when it  
> left the host- computer, or any of the above, depending on what the  
> current time is, and what the timestamp is? Or is this function as well  
> in to early stages to say?

On Tx, the timestamp is the time when the samples will be clocked into
the DSP pipeline.  On Rx, the timestamp is the time that the first
sample was clocked out of the DSP pipeline.  There was a discussion
about this on the list about a month ago with regard to the USRP1
inband code.

If the host cares, it'll have to compute the delay from the head of
the DSP pipeline to the antenna.  This is composed of at least the
pipeline delay, the group delay through the DSP filters, any internal
pipeline and group delays in the A/D, etc.

>> (This format is all subject to change.)  
> So I have noticed ;)

>> We'll be modifying the code so that it checks
>> for the actual MTU and does the right thing.  It's ticket:310.
>>   
> I might have some code to do precisely this, but I don't know if it is  
> as portable and neat as the rest of the code in here, and as I mentioned  
> earlier I'm not sure exactly where U2_MAX_SAMPLES is used, but I guess  
> "it's just trail and error, compile and re- write", that does the trick?

The header in question is used by the firmware and the host.  We need
to represent (somewhere) the maximum physical buffer size that's
available in the USRP and then derive a maximum number of samples that
the USRP can possibly handle based on that number and the sizes of the
various headers.  That will set one upper bound.  The MTU of the link,
if configured, is another upper bound.  For interfaces that have no
MTU configured, we need some way to figure out if the interface can
handle jumbo frames or not.

If you've got code that figures this out on a variety of OS's, I'd
love to take a look at it.

Eric