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

[Mattias Kjellsson]

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"
> 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,

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 Kjellsson

> Eric
>