[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Re: reporting control/status responses for inband
Re: [Discuss-gnuradio] Re: reporting control/status responses for inband signaling?
Fri, 06 Jul 2007 15:07:35 -0700
Thunderbird 18.104.22.168 (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.
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.
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
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
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.
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
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
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??
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
|[Prev in Thread]
||[Next in Thread]|
- Re: [Discuss-gnuradio] Re: reporting control/status responses for inband signaling?,
Hugh Brunk <=