I have a very simple GRC project with a UHD:USRP Source Block, a QT GUI Frequency Sink Block and two function probes into the UHD's function "get_mboard_sensor". When it works, two QT GUI Labels are filled with the output from calls to get the "gps_time" and "gps_lock".
I'm connected to an N210 with GPSDO.
GNURadio 3.7.9.1, UHD 3.09.02, Ubuntu 14.04.4 trusty
Even with very slow (once every 4 seconds) access to the "gps_time" and "gps_lock" sensor values this example eventually loses lock and stops reporting time. The rest of the flowgraph keeps running. It almost always starts out locked. If I don't use a function probe but have an OOT block that creates an instance of a uhd::usrp::multi_usrp::sptr to access the call to "get_mboard_sensor" I see the same behavior.
At first there are UHD Warnings: "get_time: ValueError: get_nmea(): no GPRMC message found". Then it throws a "RuntimeError: ValueError: Timeout after no valid message found" from the "get_mboard_sensor('gps_time')" which halts writing to the QT GUI Labels. The spectrum keeps updating.
If I add a try/except for the RuntimeError in the Python code for the get_time function probe I eventually still get continuous UHD Warnings about "no GPRMC message found" but, of course, the exception is caught. Just adding a pass doesn't fix it though. Right now this is an unrecoverable error - the system never gets lock back and the time is never updated again.
Is there anything I can do in the "except" that will allow the GPS to lock again? Or better, why is this happening!!
I do have a good GPS antenna and signal with a re-radiator by the puck as well as other equipment on the same antenna that is not having a problem staying locked.
UHD Setup:
Device Address: addr0=192.168.10.2
Sync: unknown PPS
Mb0 Clock Source: O/B GPSDO
Mb0 Time Source: O/B GPSDO
Mb0 Subdev Spec: A:A A:B
Num Channels: 2
Thanks for any suggestions.
Kathy Hertzog