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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
