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 <[EMAIL PROTECTED]> 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 _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
