[Top][All Lists]

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

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

From: Hugh Brunk
Subject: Re: [Discuss-gnuradio] Re: reporting control/status responses for inband signaling?
Date: Fri, 06 Jul 2007 15:07:35 -0700
User-agent: Thunderbird (Windows/20070604)

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:

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


reply via email to

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