On Wed, Nov 05, 2008 at 07:30:01PM +0100, Mattias K. wrote:
the drawing- board to be able to say "this is how it’s (going to(?))
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.
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
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.
(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.