discuss-gnuradio
[Top][All Lists]
Advanced

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

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


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] two byte bool, and 30 channels?
Date: Sat, 16 Aug 2008 07:53:13 -0700
User-agent: Mutt/1.5.17 (2007-11-01)

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




reply via email to

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