[Top][All Lists]

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

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

From: George Nychis
Subject: Re: [Discuss-gnuradio] Re: reporting control/status responses for inband signaling?
Date: Thu, 28 Jun 2007 13:35:10 -0400
User-agent: Thunderbird (X11/20070604)

George Nychis wrote:

George Nychis wrote:

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 about that?

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 correctly ;)

Okay so actually coding this up, I'm still missing something. So here's what I'm doing... and you'll see the hole.

Application sends PING

USRP server gets the PING request and generates the RID, creates the USB block, and fires it off to the FPGA.

USRP server then needs to associate _something_ with the RID. The only thing the USRP server knows is information about the port the PING was sent on, this information is defined publically here:

... which is port_name, port_symbol, protocol_class, conjugated, and port_type.

This is information about a TX port, and I'm assuming that we want ping responses to come back on RX ports and none of this information will tell anything about what RX port to respond on.

My initial thought was to find the "owner" of the TX port, and respond on any RX port that "owner" also has. But, there is no way for me to find out information about the owner that I can find in the m-block implementation.

The typical thing for receiving data blocks from the USRP is that the application is required to allocate channels. When allocated, USRP server says "channel 0 belongs to this port_symbol" ... so then when I receive data blocks, I read the channel number, find the port_symbol, and send the response back to the application who owns the channel.

Again, I can't do this because our channel is 0x1f which is C/S.

I can certainly associate something with the RID, I just can't find what to associate it with to get the response back properly.

Any more ideas? :)


- George

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.

reply via email to

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