[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Brian Padalino
Subject: [Discuss-gnuradio] Re: reporting control/status responses for inband signaling?
Date: Mon, 25 Jun 2007 15:11:52 -0400

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:

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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]