Reporting control/status responses for inband signaling?

GNU Radio
1

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 :slight_smile:

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?

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.

So for example, the way the ports are setup:
http://gnuradio.org/trac/browser/gnuradio/branches/developers/gnychis/inband/usrp/host/lib/inband/usrp_server.mbh

usrp-tx includes usrp-low-level-cs so that I can send a PING over a TX
channel that I own, and usrp-rx includes usrp-low-level-cs so that I can
receive the PING response over an RX channel I own. So, sending the
PING works just great, but again how will usrp_server know what RX
channel to place the response on? The packets don’t seem setup for
this.

It would make more sense if we had a single bit that specified it was a
CS packet, and then the channel specifies which RX channel to send the
response on.

Maybe I’m missing something?

  • George
2

On 6/25/07, George N. [email protected] 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 :slight_smile:

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.

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

3

Brian P. wrote:

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.

Definitely, I agree with this.

(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?

I think you’re right on this, all of the commands which have a response
have an RID. I’m going to go with the incremental counter mod X because
I can imagine instances where one app could have multiple outstanding
commands. It’s unlikely, but for safety sake.

Thanks for the response and insight, I was just going to ‘broadcast’ all
responses to all applications for now… but now I can actually code it
correctly :wink:

  • George
4

George N. wrote:

(probably just some incremental counter mod 64, or if you don’t expect
I think you’re right on this, all of the commands which have a response
have an RID. I’m going to go with the incremental counter mod X because
I can imagine instances where one app could have multiple outstanding
commands. It’s unlikely, but for safety sake.

Thanks for the response and insight, I was just going to ‘broadcast’ all
responses to all applications for now… but now I can actually code it
correctly :wink:

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.

Any more ideas? :slight_smile:

Thanks!

  • George
5

George N. wrote:

code it correctly :wink:
USRP server then needs to associate something with the RID. The only

I’m beginning to think that the response should be sent back on the TX
port the command was sent on… because what happens when an application
owns more than 1 RX channel? Even if we went by owner, the application
doesn’t exactly know which RX port it will come over unless it
explicitly states it.

6

Brian P. wrote:

On 6/28/07, George N. [email protected] wrote:

I’m beginning to think that the response should be sent back on the
TX
port the command was sent on… because what happens when an
application
owns more than 1 RX channel? Even if we went by owner, the
application
doesn’t exactly know which RX port it will come over unless it
explicitly states it.

Can the TX port actually explicitly tell the usrp_server to send a
response to a specific channel that is owned by the same application?

It could, but its not the way the interface is currently designed. So
for example:
http://gnuradio.org/trac/browser/gnuradio/branches/developers/gnychis/inband/usrp/host/lib/inband/usrp_server.mbh#L105

We would need to add something like ‘response-port’

Should it be expected that transmit blocks get responses back on
certain packets but not others?

As long as we specify it, I don’t see anything wrong with it.

I am not sure I know enough about the mblock implementation to really
be useful at this point - I am sorry. :frowning:

Its okay, we’re the first :wink:

Your suggestion sounds feasible - but, as I noted earlier, should we
be thinking of these blocks as flows in one direction? If so, then
the TX may want to be able to specify which RX responses should go
to,
right?

So they’re not quite flows in one direction. For example, when you
request a channel allocation on a TX or RX port, the response comes back
on that exact port. Therefore, you are getting a response up the TX,
and sending down the RX. This is what makes me think its ok to report
back the CS response to the TX port. It’s the only “proper” way I can
think of without changing the interface.

If we’re not sure I’m going to respond on the TX port for now. It’ll
allow me to move forward and it seems logical.

  • George
7

On 6/28/07, George N. [email protected] wrote:

I’m beginning to think that the response should be sent back on the TX
port the command was sent on… because what happens when an application
owns more than 1 RX channel? Even if we went by owner, the application
doesn’t exactly know which RX port it will come over unless it
explicitly states it.

Can the TX port actually explicitly tell the usrp_server to send a
response to a specific channel that is owned by the same application?

Should it be expected that transmit blocks get responses back on
certain packets but not others?

I am not sure I know enough about the mblock implementation to really
be useful at this point - I am sorry. :frowning:

Your suggestion sounds feasible - but, as I noted earlier, should we
be thinking of these blocks as flows in one direction? If so, then
the TX may want to be able to specify which RX responses should go to,
right?

Brian