[USRP-users] Fwd: GPSDO not found

Dan Sego bubbadoradar at gmail.com
Sat Dec 6 22:18:33 EST 2014


Some progress Marcus.

I removed power to the GPSDO and input_pps_test failed. This confirmed the
board was working, at least in part.

Removed the surrogate GPS antenna and left the SMA connection open
(unterminated).

Modified the compatibility of rx_multi_sample to Windows 7/administrator
(as I'm on Windows 8.1) and was able to get it to run on dual channels AND
the GPSDO was detected.

The runtime error (fifo timed out looking for acks) still occurred
launching the .exe (either from uhd/examples or my c++). I was hoping that
the compatibility change would solve that. Apparently not. The NIC, after
adding the registry change to 1500 for FastSendDatagramThreshold, still has
the transmit buffer at 128 and the receive buffer at 512 (which I am
inhibited from increasing in the control panel). I'm not sending any timed
commands at the point where the error occurs (having found this error
referenced thus in the list archives), and since the error appears to occur
in the usrp:make() instruction.

cheers
Dan


On Sat, Dec 6, 2014 at 3:20 PM, Marcus D. Leech <mleech at ripnet.com> wrote:

>  On 12/06/2014 05:56 PM, Dan Sego wrote:
>
> Ii also occurs to me, given your PPS response, that I was using a
> surrogate antenna for the GPS, waiting for a female MCX to male SMA adapter
> to connect a purpose built 3V antenna to the unit. The antenna is one of
> the WA5VJB log periodics?????
>
> Those antenna are very directional, also, I don't remember whether they're
> a DC short or not, which could be a problem, since there's 3.3VDC on the
>   GPS input (to power an active antenna).
>
>
>
>
> On Sat, Dec 6, 2014 at 2:53 PM, Dan Sego <bubbadoradar at gmail.com> wrote:
>
>> Good suggestion. I do have a second N200 to try. see ya
>>
>> On Sat, Dec 6, 2014 at 2:48 PM, Marcus D. Leech <mleech at ripnet.com>
>> wrote:
>>
>>>  On 12/06/2014 05:39 PM, Dan Sego wrote:
>>>
>>>  Again thanks. How is the test_pps_input successful without a PPS
>>> source? does it default to whatever clock is detected?
>>>
>>>  It's entirely possible that the PPS output on the GPSDO is working just
>>> fine, but the NMEA output (which is how the FPGA confirms the
>>>   presence of the GPSDO) failing can cause it to conclude that its not
>>> there.
>>>
>>>
>>>
>>>  Since the installation was done with anti-static safeguards, and since
>>> installation is so straight forward (all connectors keyed for example) I
>>> have to presume that I received a bad unit.
>>>
>>>  Do you have other N2xx to test it on, or conversely, another GPSDO to
>>> test?  Otherwise, there's an ambiguity about which piece is in trouble.
>>>
>>>
>>>
>>>
>>>  Dan
>>>
>>> On Sat, Dec 6, 2014 at 2:23 PM, Marcus D. Leech <mleech at ripnet.com>
>>> wrote:
>>>
>>>>  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>
>>>> 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> wrote:
>>>>>
>>>>>>   On 12/03/2014 10:01 PM, Dan Sego via USRP-users wrote:
>>>>>>
>>>>>>
>>>>>> ---------- Forwarded message ----------
>>>>>> From: Dan Sego <bubbadoradar at gmail.com>
>>>>>> Date: Wed, Dec 3, 2014 at 6:37 PM
>>>>>> Subject: GPSDO not found
>>>>>> To: 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 Consortiumhttp://www.sbrac.org
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> USRP-users mailing list
>>>>>> 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 Consortiumhttp://www.sbrac.org
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Marcus Leech
>>>> Principal Investigator
>>>> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>>>>
>>>>
>>>
>>>
>>> --
>>> Marcus Leech
>>> Principal Investigator
>>> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>>>
>>>
>>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141206/f6c418b7/attachment-0002.html>


More information about the USRP-users mailing list