>On 07/19/2012 09:42 PM, Nowlan, Sean wrote: >> Hi all, >> >> I am interested in being able to recover from UHD Error conditions >> such as not finding a USRP on startup or an Ethernet cable getting >> knocked loose (USRP N200). I implemented an uhd_async_message source >> but all I can do with that is read error codes corresponding to >> sequence errors, late packets, underruns, etc. It's nice to have the >> ability to take action based on these messages, but if an Ethernet >> cable gets knocked loose, nothing gets sent to the message queue (at >> least, not that I could find). Instead, UHD prints to stdout using >> some other thread and then my script hangs. >> >> I hacked UHD's error printing code to do an exit after it prints >> whatever error occurred, and then a bash script handles restarting the >> Python program that's controlling GNU Radio behavior. I'm aware that >> there is a way to register a message handler function with UHD so that >> it won't just print to the screen and hang. Is there any way to >> implement this handler in Python and register the function with UHD? I >> don't normally post to both lists to avoid redundant spamming, but >> I'll take a leap of faith here. :) >> > >I think I see your point. There really isnt a good way to know that some >internal thread died. Whether it be in UHD or a gnuradio worker thread.
In this case, I'm not sure if a thread actually dies. It just goes into a loop or some kind of blocking state waiting for UHD control message responses. >It might be a decent idea to queue up an async message into the queue when an >internal thread dies. Not sure how you might get the info from a gnuradio >scheduler >thread though. I haven't needed this, but I could see how it could be useful. >In the short term, if you do try to communicate with the device object in >someway that involves an over-the-bus communication, and the transport is >down, you will >get a nice exception thrown all the way into python which you >can catch and react to. I've seen it throw an exception if the USRP is not connected when the UHD GNU Radio block is first instantiated. I'll try running a heartbeat "while True" loop in the main thread and see if I can get it to throw an error if I yank the Ethernet cable after the top block has already been started. I'm still curious though, do you know of a way to register a message handler function with UHD from Python? If I add %include <uhd/utils/msg.hpp> to gnuradio/gr-uhd-swig/uhd_swig.i, will SWIG know how to translate a function pointer to Python, or would this require UHD to implement a shared pointer interface? http://files.ettus.com/uhd_docs/manual/html/general.html#disabling-or-redirecting-prints-to-stdout >Example, periodically set_time_source(..) which is harmless to do, but causes >bus traffic. > >-josh > >> Thanks, Sean Nowlan >> >> P.S. - I'll sneak this question in with the technical one above: is >> the GNU Radio conference free to attend? Is there any registration >> required? Didn't see any such thing on the site, so I'm assuming it's >> free and the public can just show up and enjoy some awesomeness. >> >> >> >> _______________________________________________ USRP-users mailing >> list [email protected] >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> > > >_______________________________________________ >Discuss-gnuradio mailing list >[email protected] >https://lists.gnu.org/mailman/listinfo/discuss-gnuradio _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
