[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss-gnuradio] Re: reporting control/status responses for inband sig
[Discuss-gnuradio] Re: reporting control/status responses for inband signaling?
Mon, 25 Jun 2007 15:21:39 -0400
Thunderbird 184.108.40.206 (X11/20070604)
Brian Padalino 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.
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