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

[Eric Blossom]

On Mon, Aug 18, 2008 at 12:43:40PM +0200, Mattias Kjellsson wrote:
> Eric Blossom wrote:
>> On Thu, Aug 14, 2008 at 11:57:27PM -0100, Mattias Kjellsson 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. .
>>>
>>> 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

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