[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 13:57:20 -0400
Thunderbird 22.214.171.124 (X11/20070604)
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
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,
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.