Two byte bool, and 30 channels?

mattias_k · August 14, 2008, 4:53pm

Hi list,

I have been poking around the usrp2- api for a while, and I finaly got
my usrp2- emulating software to work in a almost satisfactory way.
Anyhow, I have at least one questions regarding the configuration of a
usrp2.

In op_config_rx_reply_v2_t structure (and op_config_tx_reply_v2_t),
defined in usrp2_eth_packet.h, the member “ok” is a uint16_t… Why is
that? Does it have something to do with _AL4 maybe, or does it have
something to do with future features?
The maximum number of channels is defined as 30 in usrp2.h… What
does channel refer to in this case?

BR
Mattias K.

mattias_k · August 14, 2008, 9:50pm

On Thu, Aug 14, 2008 at 7:52 AM, Mattias K. [email protected] wrote:

In op_config_rx_reply_v2_t structure (and op_config_tx_reply_v2_t),
defined in usrp2_eth_packet.h, the member “ok” is a uint16_t… Why is that?
Does it have something to do with _AL4 maybe, or does it have something to
do with future features?

_AL4

The maximum number of channels is defined as 30 in usrp2.h… What does
channel refer to in this case?

The USRP2 GbE transport can support 32 (0-31) independent streams of
data. Channel 31 is reserved for the control channel, making 30 the
largest valid data channel number.

These independent channels will be used to send streams from multiple
USRP2s ganged together over their high-speed interconnect bus and
connected to the host via a single GbE.

–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com/

mattias_k · August 14, 2008, 11:58pm

Johnathan C. wrote:

Nice to know, I almost went insane over a couple of htons() earlier
today.

USRP2s ganged together over their high-speed interconnect bus and
connected to the host via a single GbE.

As well good to know, I had some rather strange ideas what the
“op_mimo_config_t”- structure could be used for, together with
different channels, but this makes things make a bit more sense.

–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com/

On a related matter, might you (or anybody else) know, how close to
“release” the usrp2- libraries code is? If I re- phrase the question,
will the things in the usrp2- trunk change fundamentally; change but not
to much; or will things just be added? For instance adding the channels
and so on. .

BR
Mattias

mattias_k · August 16, 2008, 4:54pm

On Thu, Aug 14, 2008 at 11:57:27PM -0100, Mattias K. wrote:

Johnathan C. wrote:

On Thu, Aug 14, 2008 at 7:52 AM, Mattias K. [email protected] wrote:

Nice to know, I almost went insane over a couple of htons() earlier today.

That’s why we built htonx

The maximum number of channels is defined as 30 in usrp2.h… What does
channel refer to in this case?

What’s currently being called channel will probably be renamed
stream_index in the not too distant future. As is, the USRP1 and
USRP2 definitions of channel are somewhat different.

The USRP2 GbE transport can support 32 (0-31) independent streams of
data. Channel 31 is reserved for the control channel, making 30 the
largest valid data channel number.

These independent channels will be used to send streams from multiple
USRP2s ganged together over their high-speed interconnect bus and
connected to the host via a single GbE.

The whole channel mechanism could be refactored and/or changed. In
addition to Johnatahn’s example, you could have custom fpga builds
that are streaming data at different rates. See the VITA 49 “stream”
concept.

On a related matter, might you (or anybody else) know, how close to
“release” the usrp2- libraries code is? If I re- phrase the question, will
the things in the usrp2- trunk change fundamentally; change but not to
much; or will things just be added? For instance adding the channels and so
on. .

BR
Mattias

Mattias,

Though it’s unlikely that we’ll dump everything and start again, I
wouldn’t count on anything staying the same for a while. For example,
the way that tuning is handled only works for the single front end /
single DDC/DUC case. This is clearly not a general solution.

What is it that you’re trying to figure out or do with the current
(prototype) interface?

Eric

mattias_k · August 18, 2008, 12:44pm

Eric B. wrote:

That’s why we built htonx

addition to Johnatahn’s example, you could have custom fpga builds

BR
What is it that you’re trying to figure out or do with the current
(prototype) interface?

Eric,

Our intention was to start developing code for the USRP2. In the absence
of
the USRP2 we are trying to familiar ourselves with the code.

This was also suggested by in the following mail from Matt:
http://lists.gnu.org/archive/html/discuss-gnuradio/2008-01/msg00136.html

This brings up my next question on a related matter. I noticed that I
got a lot of “S” printed out
while running the supplied test program “rx_streaming_samples”, from the
host-ng/apps directory.
I traced them back to
usrp2_impl.cc::handle_data_packet(const void *base, size_t len), lines
~367->~416.

There is a “rid” (reply id?) in the command structures. What is the
difference between
this and the “seqno/ack” from the transport header? As I have come to
understand it, the
rid is used for control- messages, and seq/ack is for data?

As I have come to understand it the rid works like follow: If the
incoming (from host to usrp2)
“op_config_rx_v2_t->rid=6” then the host expects an answer like
“op_config_rx_reply_v2_t->rid=6”
(as well as the correct opcode,len and mbz), or does it expect rid==7?

But with data packages, the usrp2 set seqno=0 and ack=1 for the first
package,
seqno=1/ack=1 for the second and seqno=2/ack=1 for the third an so
forth.
Or should the control- messages count seqno/ack up as well?

BR
Mattias K.

mattias_k · August 15, 2008, 12:49am

Mattias K. wrote:

On a related matter, might you (or anybody else) know, how close to
“release” the usrp2- libraries code is? If I re- phrase the question,
will the things in the usrp2- trunk change fundamentally; change but not
to much; or will things just be added? For instance adding the channels
and so on. .

The majority of the low-level C++ interface to the USRP2 is finished,
but is Linux specific. That’s not to say there won’t be changes and
additions, but the architecture won’t change any time soon. As I’m sure
you’ve noticed it’s quite different from the USRP1 interface.

The gr-usrp2 wrappers are being written (I’m a bit behind on this,
working through a backlog of commercial contracts right now), and will
allow use in GNU Radio from C++ or Python.

mattias_k · August 18, 2008, 3:13pm

On Sat, Aug 16, 2008 at 10:53 AM, Eric B. [email protected] wrote:

The whole channel mechanism could be refactored and/or changed. In
addition to Johnatahn’s example, you could have custom fpga builds
that are streaming data at different rates. See the VITA 49 “stream”
concept.

Is the VITA 49 spec public? Where can we find information about the
stream concept?

Philip

mattias_k · August 18, 2008, 6:09pm

On Mon, Aug 18, 2008 at 12:43:40PM +0200, Mattias K. wrote:

Eric,

Our intention was to start developing code for the USRP2. In the absence of
the USRP2 we are trying to familiar ourselves with the code.

This was also suggested by in the following mail from Matt:
[Discuss-gnuradio] How to get ready for the USRP2

Good.

This brings up my next question on a related matter. I noticed that
I got a lot of “S” printed out while running the supplied test
program “rx_streaming_samples”, from the host-ng/apps directory. I
traced them back to usrp2_impl.cc::handle_data_packet(const void
*base, size_t len), lines ~367->~416.

S == bad sequence number.
Try using a higher decimation rate and see if that helps.
If you’re writing to disk, try writing to /dev/null

On most of my machines, I can transmit and receive at 25 MS/s (100
MB/s).

There is a “rid” (reply id?) in the command structures.

Yes, it’s a reply ID. It’s used to match requests to replies.

What is the difference between this and the “seqno/ack” from the
transport header? As I have come to understand it, the rid is used
for control- messages, and seq/ack is for data?

At this point, you should assume nothing about the transport header.
It’s likely to be completely changed/deleted/moved to the kernel, etc.
It is not visible through the top-level API and never will be.

At a minimum we want to know if we’re dropping data packets in either
direction. In the transmit direction (host->USRP2) we also need a way
to flow control the host. At present we’re using ethernet PAUSE
frames, but this is not ideal unless you’ve got a dedicated interface
(and switch if you’re using one) between the USRP2 and the host. At
some point, this function will be handled by some kind of “real”
transport header that includes some kind of a window. What’s in there
now is just a stopgap measure to see if we’ve got a problem.

As I have come to understand it the rid works like follow: If the incoming
(from host to usrp2) “op_config_rx_v2_t->rid=6” then the host expects an
answer like “op_config_rx_reply_v2_t->rid=6” (as well as the correct
opcode,len and mbz), or does it expect rid==7?

You understand correctly. The code should also be checking that the
opcode is what it expects.

But with data packages, the usrp2 set seqno=0 and ack=1 for the first
package, seqno=1/ack=1 for the second and seqno=2/ack=1 for the third an so
forth. Or should the control- messages count seqno/ack up as well?

There are currently no sequence numbers on control messages since they
all have explicit replies.

Eric