On Wed, Feb 23, 2005 at 05:58:08PM -0500, James Cooley wrote: > Hi Chuck/All > > I have a rough version of exactly what you seek that I did today! See > attached. Not cleaned, no guarantees, but suggestions/improvements > welcome. I have a wrapper class, gr_powermate which wraps the standard > python powermate lib posted recently. > > Also, I got tired of setting and calculating a separate front-end freq. > So with this, there is ONE notion of freq. THere's a func that sets the > front end and usrp accordingly. > > This amounts to a nearly full featured scanner.
Great job! > The gist of your problem was solved by using a wx EVT_IDLE, like so: > > # add an idle handler > self.frame.Bind(wx.EVT_IDLE, self.onIdle) > > Be careful. So the onIdle handler is called when ever wx isn't busy. wx > is busy a lot, so make sure you don't block for too long. There's > probably a more elegant way to not block. For me, I just made sure the > powermate stuff was quick! It scans for 50ms at a time then gives up. I strongly recommend AGAINST using EVT_IDLE. You really don't want to poll when there's a better way to do it. And there's almost always a better way to do it. Start a separate thread that loops doing a blocking wait for an event from the powermate. When you get an event that's interesting, send an event to your main gui thread using wx.PostEvent. You set up the handler for your new event and let the callback handle it. This is all thread safe, works great, and doesn't waste any CPU cycles. If you take a look at the guts of fftsink.py it implements this strategy. There's a class input_watcher that does blocking reads on a pipe. When it gets something it creates a DataEvent and posts it with wx.PostEvent. A minor variation on this theme will handle the the powermate cleanly and efficiently. Eric _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio