Re: [Discuss-gnuradio] UHD Error handling from GNU Radio/Python

[Nowlan, Sean]

>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 address@hidden 
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> 
>
>
>_______________________________________________
>Discuss-gnuradio mailing list
>address@hidden
>https://lists.gnu.org/mailman/listinfo/discuss-gnuradio