[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] two byte bool, and 30 channels?

From: Mattias Kjellsson
Subject: Re: [Discuss-gnuradio] two byte bool, and 30 channels?
Date: Mon, 18 Aug 2008 12:43:40 +0200
User-agent: Thunderbird (X11/20080724)

Eric Blossom wrote:
On Thu, Aug 14, 2008 at 11:57:27PM -0100, Mattias Kjellsson wrote:
Johnathan Corgan wrote:
On Thu, Aug 14, 2008 at 7:52 AM, Mattias Kjellsson <address@hidden> wrote:

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

That's why we built htonx

2. 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"

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. .



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?

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:

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?

Mattias Kjellsson


reply via email to

[Prev in Thread] Current Thread [Next in Thread]