[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss-gnuradio] reporting control/status responses for inband signali
[Discuss-gnuradio] reporting control/status responses for inband signaling?
Mon, 25 Jun 2007 14:26:51 -0400
Thunderbird 18.104.22.168 (X11/20070604)
This is a perfect question for Eric, but unfortunately he is on
vacation. So I'm hoping that maybe Brian or someone can answer who was
involved in the initial design of the inband USB packets :)
The way we have the low-level control/status packets designed, I'm not
sure how the application can ever get a response back correctly.
Heres how we have them defined:
They use the same packet header as data packets, except the channel is
fixed to 0x1f so they can be deciphered as CS packets easily in the
FPGA. If we do this, how are we ever supposed to properly determine
what application to send the response back to?
The current chain to get a CS packet to the USRP is like this:
Application -> usrp_server -> USRP
It's very straight forward, but sending responses back is a problem:
USRP -> usrp_server -> ?
How does usrp_server, which parses the USB packets, know which
application to send the CS response to? The packets used to be demuxed
by channel since channels are owned by specific applications, and
therefore the channel is read to determine the application. In this
case, the channel says absolutely nothing about the application that
So for example, the way the ports are setup:
usrp-tx includes usrp-low-level-cs so that I can send a PING over a TX
channel that I own, and usrp-rx includes usrp-low-level-cs so that I can
receive the PING response over an RX channel I own. So, sending the
PING works just great, but again how will usrp_server know what RX
channel to place the response on? The packets don't seem setup for this.
It would make more sense if we had a single bit that specified it was a
CS packet, and then the channel specifies which RX channel to send the
Maybe I'm missing something?
- [Discuss-gnuradio] reporting control/status responses for inband signaling?,
George Nychis <=