[USRP-users] Fwd: GPSDO not found

Marcus D. Leech mleech at ripnet.com
Sun Dec 7 10:59:32 EST 2014


On 12/06/2014 10:18 PM, Dan Sego wrote:
> 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
That is good news about the GPSDO.

Could you try a simple benchmark_rate test:

UHD Benchmark Rate Allowed options:
   --help                help message
   --args arg            single uhd device address args
   --duration arg (=10)  duration for the test in seconds
   --rx_rate arg         specify to perform a RX rate test (sps)
   --tx_rate arg         specify to perform a TX rate test (sps)
   --rx_otw arg (=sc16)  specify the over-the-wire sample mode for RX
   --tx_otw arg (=sc16)  specify the over-the-wire sample mode for TX
   --rx_cpu arg (=fc32)  specify the host/cpu sample mode for RX
   --tx_cpu arg (=fc32)  specify the host/cpu sample mode for TX
   --mode arg (=none)    multi-channel sync mode option: none, mimo
   --channels arg (=0)   which channel(s) to use (specify "0", "1", 
"0,1", etc)

     Specify --rx_rate for a receive-only test.
     Specify --tx_rate for a transmit-only test.
     Specify both options for a full-duplex test.


>
> On Sat, Dec 6, 2014 at 3:20 PM, Marcus D. Leech <mleech at ripnet.com 
> <mailto: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
>>     <mailto: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 <mailto: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 <mailto: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 <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
>>>
>>>
>>
>>
>>             -- 
>>             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
>
>


-- 
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/20141207/cf3cd39b/attachment-0002.html>


More information about the USRP-users mailing list