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

[Mattias Kjellsson]

Eric Blossom wrote:
> 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.
>   
Then I probably have to read up on what VRT is...
> > 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.
>   
Well, at least now I know when the times are set, which means I have to 
think about what it means :) But another way would be to have a look at 
the inband- code to usrp1 and try to understand what it actually does, 
since the time- stamps are set at the "same places", just to get a 
crash- course in time- stamps, and maybe, just maybe be able to actually 
use that to something useful.
>   
> > > (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.
>   
Well, I must say, you got me there, the code I have is only tested on 
linux (Slackware and Ubuntu), and it doesn't really deal with any 
hardware. So there isn't really any piece of code I have laying around 
that would fit nicely into the gnuradio- trunk, what I do have is code 
for reading/writing mtu (which isn't anything to brag with or put on 
ones resume...)

Jumbo- frames, as I have come to understand it, is just a large frame, 
but as far as I have seen there isn't any easy method to test for 
support of it.

Basically, I would as well love to see the code that does all the things 
above.

Regarding the available memory on the usrp2. There is another field 
amongst the headers I'm a bit curious about.
uint16_t fifo_status in the transport header. How should this be 
interpreted? As 16 bits which represent full/empty line of 32 bit. That 
would give 16bit*32bit = 128 byte of Rx- fifo?

Best regards
Mattias Kjellsson
> Eric
>