[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 
> appeared.
>
> 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: 
> LookupError.
>
> 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 
the GPSDO.


>
>
> 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 <<
>>     std::endl;
>>
>>     usrp->get_mboard_sensor("gps_time");
>>
>>     The last instruction (from
>>     http://files.ettus.com/manual/page_gpsdo.html) returns
>>     Error: LookupError: Path not found in tree:
>>     /mboards/0/sensors/gps_time
>     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
>     internal-to-N210
>       GPSDO?
>
>
>>
>>     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
>     suspicion
>       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>>
>>     wrote:
>>
>>         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?
>>>
>>>         cheers,
>>>         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
>>         http://www.sbrac.org
>>
>>
>>         _______________________________________________
>>         USRP-users mailing list
>>         USRP-users at lists.ettus.com <mailto:USRP-users at lists.ettus.com>
>>         http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
>
>     -- 
>     Marcus Leech
>     Principal Investigator
>     Shirleys Bay Radio Astronomy Consortium
>     http://www.sbrac.org
>
>


-- 
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141206/fa06d342/attachment-0002.html>


More information about the USRP-users mailing list