Re: [Discuss-gnuradio] Re: reporting control/status responses for inband signaling?

[Hugh Brunk]

> Okay so actually coding this up, I'm still missing something. So 
> here's what I'm doing... and you'll see the hole.
>
> Application sends PING
>
> USRP server gets the PING request and generates the RID, creates the 
> USB block, and fires it off to the FPGA.
>
> USRP server then needs to associate _something_ with the RID. The only 
> thing the USRP server knows is information about the port the PING was 
> sent on, this information is defined publically here:
> ./mblock/src/lib/mb_port.h
>
> ... which is port_name, port_symbol, protocol_class, conjugated, and 
> port_type.
>
> This is information about a TX port, and I'm assuming that we want 
> ping responses to come back on RX ports and none of this information 
> will tell anything about what RX port to respond on.
>
> My initial thought was to find the "owner" of the TX port, and respond 
> on any RX port that "owner" also has. But, there is no way for me to 
> find out information about the owner that I can find in the m-block 
> implementation.
>
> The typical thing for receiving data blocks from the USRP is that the 
> application is required to allocate channels. When allocated, USRP 
> server says "channel 0 belongs to this port_symbol" ... so then when I 
> receive data blocks, I read the channel number, find the port_symbol, 
> and send the response back to the application who owns the channel.
>
> Again, I can't do this because our channel is 0x1f which is C/S.
>
> I 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