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

[Eric Blossom]

On Thu, Nov 06, 2008 at 05:02:46PM +0100, Mattias Kjellsson wrote:
> Eric Blossom wrote:
>>   
> 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.

FYI, I'm not up-to-date on the status of the USRP1 inband code.  Eric
Schneider was working on bugfixing/rewriting part of it, but we
haven't heard from him in a while.  Eric, anything to report?

>> 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...)

In any event, I'd like to see what you've got.

> 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? 

The 32-bit reference means that it's counting in units of 32-bit
integers (4 bytes).  The field is currently a place holder.  They idea
is to use some kind of a window to flow control the host -> usrp
direction.  The usrp -> host direction doesn't require flow control
since the usrp sends at a constant rate determined by the host.  
If the host can't keep up, the host is by definition misconfigured or broken.

Eric