[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?
Thu, 28 Jun 2007 12:19:05 -0400
Thunderbird 184.108.40.206 (X11/20070604)
George Nychis wrote:
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
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
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
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.
Any more ideas? :)