sent on, this information is defined publically here:
on any RX port that “owner” also has. But, there is no way for me toI can certainly associate something with the RID, I just can’t find
what to associate it with to get the response back properly.
I hope I’m not completely wrong here; I’ve just started to look at the
code, and haven’t yet put my hands on a usrp.
Is it possible that when the usrp_server constructs the usb packet it
sets the control chan 0x1f, but the user gives the usrp_server more
information than is actually in the usb packet? For example, the user
could request the usrp_server to ping channel 2. The user could specify
a port for the reply, or perhaps the server knows by an association with
channel 2. The server then knows that this requires a control packet,
and so it sets the chan in the usb packet appropriately, along with the
corresponding opcode. It can use part of the RID to track the request
and will know where to send the response. In any case, the information
in the user’s request to the server has to have sufficient info in it to
allow the server to figure out where the response needs to go. This is
a different matter than what’s in the usb packet the server sends to the
usrp.
I noticed that Eric mentioned splitting the RID field to allow the user
and server to share it; the thread was: allocation of USB channel for
commands:
Note how I limit the user to 3-bit RID values in the interface. This
leaves 3-bits for the server’s use. You’ll be able to use the “server
portion” of the 6-bit RID allocation to figure out which port send the
reply on.
I imagine he was thinking that the server can figure out the port for
the reply from the info in the request from the user??
/Hugh