[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Regarding 371 samples/frame in usrp2
From: |
Eric Blossom |
Subject: |
Re: [Discuss-gnuradio] Regarding 371 samples/frame in usrp2 |
Date: |
Thu, 6 Nov 2008 08:31:38 -0800 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
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