[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] reporting control/status responses for inband signali

From: George Nychis
Subject: [Discuss-gnuradio] reporting control/status responses for inband signaling?
Date: Mon, 25 Jun 2007 14:26:51 -0400
User-agent: Thunderbird (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 sent it.

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 response on.

Maybe I'm missing something?

- George

reply via email to

[Prev in Thread] Current Thread [Next in Thread]