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

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

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio