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