[USRP-users] Fwd: GPSDO not found
Marcus D. Leech
mleech at ripnet.com
Sat Dec 6 17:23:59 EST 2014
On 12/06/2014 05:22 PM, Dan Sego wrote:
> GPSDO shows "internal" under 'uhd_usrp_probe'. Also I ran, from
> examples, 'test_pps_input' which returned a success message (is this
> possible w/o GPSDO present and no other external time source?).
> Subsequent runs (using the admin command prompt) did not (appear) to
> step through the 'Detecting GPSDO..." step so no "not found' message
> The UHD version is 003.008.000-release. I purchased the GPSDO from NI
> and only installed it in N200 this week (but have had it for some time
> in original shipping wrapping).
> I have sensors.hpp as an #include. I don't understand the Error:
> vr Dan
That error means that when it tried to lookup that sensor in the virtual
attribute tree, it couldn't find it--because at init, it couldn't find
> On Sat, Dec 6, 2014 at 2:02 PM, Marcus D. Leech <mleech at ripnet.com
> <mailto:mleech at ripnet.com>> wrote:
> On 12/06/2014 04:37 PM, Dan Sego wrote:
>> Hello Marcus
>> Allowed the unit to run for > 1 hour. Still received -- Detecting
>> internal GPSDO....No GPSDO found. The code attempts to execute
>> usrp->set_clock_source("external", 0);
>> usrp->set_time_source("external", 0);
>> std::cout << std::endl << "Clock Source Set"<< std::endl <<
>> The last instruction (from
>> http://files.ettus.com/manual/page_gpsdo.html) returns
>> Error: LookupError: Path not found in tree:
> That error is because it never detected a GPSDO in the first
> place, so those sensors don't exist if it doesn't think there's a
> GPSDO there.
> So, either you have a defective GPSDO, or it's connected
> incorrectly. You purchased this GPSDO through Ettus, and it's the
>> Also, having implemented the SendFastDatagramThreshold registry
>> change, I still receive (though less regularly)
>> Error: RuntimeError: fifo cntl timed out looking for acks
>> Any suggestions?
> That's a distinct problem. Not sure where to go from here, your
> UHD software is up-to-date. How about your Windows updates? My
> is that this is a network driver issue, not specifically related
> to USRP, per se, but rather anything that drives the network stack
> through that interface
> "hard" will experience problems.
>> regards, Dan
>> On Thu, Dec 4, 2014 at 6:33 AM, Marcus D. Leech via USRP-users
>> <usrp-users at lists.ettus.com <mailto:usrp-users at lists.ettus.com>>
>> On 12/03/2014 10:01 PM, Dan Sego via USRP-users wrote:
>>> ---------- Forwarded message ----------
>>> From: *Dan Sego* <bubbadoradar at gmail.com
>>> <mailto:bubbadoradar at gmail.com>>
>>> Date: Wed, Dec 3, 2014 at 6:37 PM
>>> Subject: GPSDO not found
>>> To: usrp-users at lists.ettus.com
>>> <mailto:usrp-users at lists.ettus.com>
>>> Please disregard last note. When in doubt read (all) the
>>> documentation. Ran the eeprom burner (usrp_burn_mb_eeprom)
>>> and received a successful result.
>>> After cycling power I ran uhd_usrp_probe again. Detecting
>>> internal GPSDO again returned - No GPSDO found.
>>> However under Mboard N200r4 the gpdso field indicates "internal"
>>> So some consternation remains. Suggestions, please?
>>> Dan Sego
>> My recollection is that the GPSDO doesn't start putting out
>> NMEA sentences until it has warmed-up from cold start, and it
>> is the NMEA sentences that
>> the USRP is looking for to confirm the presence of the
>> GPSDO. So, power it up, leave it for 30 minutes, then try to
>> bring up a session with it.
>> Marcus Leech
>> Principal Investigator
>> Shirleys Bay Radio Astronomy Consortium
>> USRP-users mailing list
>> USRP-users at lists.ettus.com <mailto:USRP-users at lists.ettus.com>
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
Shirleys Bay Radio Astronomy Consortium
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the USRP-users