|
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 1.5.0.12 (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 Application.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 PINGUSRP 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:./mblock/src/lib/mb_port.h... 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? :) Thanks! - 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.
[Prev in Thread] | Current Thread | [Next in Thread] |