On Mon, Aug 18, 2008 at 12:43:40PM +0200, Mattias K. wrote:
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:
[Discuss-gnuradio] How to get ready for the USRP2
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
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.