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

[George Nychis]

Brian Padalino wrote:
> On 6/28/07, George Nychis <address@hidden> 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. :(

Its okay, we're the first ;)

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