Re: [Discuss-gnuradio] Passing the payload to the application level

[Michael Ford]

Packet reception is great, no problems there at all.

The prblem is that since the rx_callback function is called within the
_queue_watcher_thread class, I figured I could return the payload to
benchmark_gmsk2_tx.py from there (as opposed to simply printing the
payload). However, when I create a member variable in the
_queue_watcher_thread class called self.thepayload, and return the
payload from the rx_callback function into said member variable, and
then try to pass it back to the app layer, I get errors saying that the
_queue_watcher_thread class has no such member. Also, when I try to
directly print the payload obtained from the calls

def run(self):
        while self.keep_running:
            msg = self.rcvd_pktq.delete_head()
            ok, payload = packet_utils.unmake_packet(msg.to_string())
           
print
payload                
#added by me
            if self.callback:
               self.callback(ok, payload)

nothing happens.


But perhaps the most baffling thing is that no matter what I do to the
_queue_watcher_thread class, even totally comment it out, rx_callback
still runs. Also, printing the payload from within the rx_callback
function works, and that is the only place it works. I am under the
impression that rx_callback is passed down to the _queue_watcher_thread
class and is called from there. Why would it still output to the screen
if I comment out the class?


I am basically trying to use the contents of the payload as a
conditional, but I can't pass the payload back up to
benchmark_gmsk_rx.py to save my life.


Sorry if I'm not clear.

On 9/21/06, Eric Blossom <address@hidden> wrote:

On Wed, Sep 20, 2006 at 11:49:27PM -0500, Michael Ford wrote:
> I am trying to pass the payload from the layer where it is obtained back to
> the application level. However, I'm having some problems. When examining
> benchmark_gmsk_rx.py, I see that the rx_callback funstion is passed into the
> receive_path class. Going further, I see that the function is passed from
> benchmark_gmsk_rx.py to the receive_path class to the gmsk_demod_pkts class,
> which I understand to be in
> /usr/local/lib/python2.4/site-packages/gnuradio/blksimpl/gmsk2_pkt.py. Here,
> the function is finally called in a class called _queue_watcher_thread.
> However, no matter what I do, I can't get the payload data back to the app
> layer. Just to test things, I commented out the instance of
> _queue_watcher_thread that is instantiated by the gmsk2_demod_pkts() class,
> and the rx_callback function is still running, which leads me to believe
> that I'm not looking in the right place. Also, when I try to make a member
> variable of the _queue_watcher_thread class called self.thepayload and make
> a a return of the payload in the rx_callback function, and then try to print
> self.thepayload from the watcher class, nothing happens. If I make a print
> statement in the rx_callback function, the payload prints.
>
> -Michael Ford-

First off, I'm assuming that you are running the svn trunk code.
If not, please start there.

When you run the unmolested benchmark_gmsk_tx.py and
benchmark_gmsk_tx.rx on two machines do they work?  That is, does the
rx code report that it's receiving packets correctly?  I typically get
100% correct packet reception.


If not, what daughterboards are you using?
They need to be RFX-<something>'s.  Basic Tx and Rx won't work.
Long story, it's in the archives somewhere.  Also, keep the boards at
least 3m apart.


Now, assuming that that's working, what's the question?
Basically, packets are getting from the C++ to the python code by
virtue of a message queues and messages.

You are correct, this is set up in gmsk2_pkt.py.
framer_sink_1 is handed the message queue in its constructor and then at
runtime inserts messages into it.  The _queue_watcher_thread
hangs a blocking read on the queue by doing:

  msg = self.rcvd_pktq.delete_head ()

Eric