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

[Brian Padalino]

On 6/25/07, George Nychis <address@hidden> wrote:
> This is a perfect question for Eric, but unfortunately he is on
> vacation.  So I'm hoping that maybe Brian or someone can answer who was
> involved in the initial design of the inband USB packets :)

I'll do my best to figure it out.

> The way we have the low-level control/status packets designed, I'm not
> sure how the application can ever get a response back correctly.
>
> Heres how we have them defined:
> http://gnuradio.org/trac/browser/gnuradio/trunk/usrp/doc/inband-signaling-usb#L116
>
> They use the same packet header as data packets, except the channel is
> fixed to 0x1f so they can be deciphered as CS packets easily in the
> FPGA.  If we do this, how are we ever supposed to properly determine
> what application to send the response back to?

I should note here that the USRP doesn't care which application on the
host requests the different actions, which is probably why we have the
fixed channel of 0x1f.  The USRP is simply the endpoint.

> The current chain to get a CS packet to the USRP is like this:
> Application -> usrp_server -> USRP
>
> It's very straight forward, but sending responses back is a problem:
>
> USRP -> usrp_server -> ?
>
> How does usrp_server, which parses the USB packets, know which
> application to send the CS response to?  The packets used to be demuxed
> by channel since channels are owned by specific applications, and
> therefore the channel is read to determine the application.  In this
> case, the channel says absolutely nothing about the application that
> sent it.

Looking at the payload of the control channel, any of the op codes
that write something and then have the USRP reply back seem to have an
RID within them to determine where to send things back.

This is probably what should be inserted/stripped by the usrp_server
to figure out which application receives the reply.

I can see this working where the Application requests something (ping
perhaps?) and sends the ping request to the usrp_server.  The
usrp_server constructs the packet with the next available RID
(probably just some incremental counter mod 64, or if you don't expect
one application to have multiple outstanding commands, just a unique
number for each application which is reused - just ideas and you know
this more than I would).  After the USRP then processes the command
and sends the reply back, the usrp_server will read the RID field of
the received packet and forward the packet (minus the RID) back to the
Application.

I could be missing it just as much as you did, but what do you think about that?

Brian