We have someone looking into this now. In the meantime, try adding the device arguments "clock_source=external,time_source=external".
Regards, Michael On Tue, Jul 23, 2019 at 12:23 PM Nate Temple via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi Jason, > > I'm fairly confident that this is just a software issue. > > Regards, > Nate Temple > > On Tue, Jul 23, 2019 at 11:06 AM Jason Matusiak < > ja...@gardettoengineering.com> wrote: > >> Thank you Nate. Good to hear that it wasn't a screw up on our part. Do >> you have a gut as to whether or not it is a hardware or software issue? >> >> >> ------------------------------ >> *From:* Nate Temple <nate.tem...@ettus.com> >> *Sent:* Tuesday, July 23, 2019 2:01 PM >> *To:* Jason Matusiak <ja...@gardettoengineering.com> >> *Cc:* Ettus Mail List <usrp-users@lists.ettus.com> >> *Subject:* Re: [USRP-users] E320 unable to lock to external reference >> >> Hi Jason, >> >> I've been able to recreate this and have filed an issue on our internal >> bug tracker and escalated as a high priority issue. I'm not able to provide >> any ETA on when we will have a fix for it, but hope it will be soon. >> >> I will follow up as soon as I have more information. >> >> Regards, >> Nate Temple >> >> On Tue, Jul 23, 2019 at 10:12 AM Jason Matusiak < >> ja...@gardettoengineering.com> wrote: >> >> Do you need anything from my side of things? >> >> ------------------------------ >> *From:* Nate Temple <nate.tem...@ettus.com> >> *Sent:* Thursday, July 18, 2019 3:49 PM >> *To:* Jason Matusiak <ja...@gardettoengineering.com> >> *Cc:* Ettus Mail List <usrp-users@lists.ettus.com> >> *Subject:* Re: [USRP-users] E320 unable to lock to external reference >> >> Hi Jason, >> >> This might be a bug with the E320. I will need to try to recreate this >> issue. I'll follow up as soon as I have more info. >> >> Regards, >> Nate Temple >> >> On Thu, Jul 18, 2019 at 12:32 PM Jason Matusiak via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >> OK, we've been fighting this for a while and we think we narrowed it down >> to being a problem with the E320 (NOTE: we are running the E320 in network >> mode, not embedded) >> >> Some background: >> 1) external reference input is from an octo clock (so it the 1pps input) >> on many different ports >> a) also tried to use a Symmetricom box for external reference >> and had the same problems >> >> 3) the same code we are testing with works when using an x310 instead of >> an e320, with inputs from the same octoclock >> >> 4) the code basically does this: >> a) sets the reference source to external >> b) checks to see if the reference is locked (and it keeps doing >> this until we get a "locked" response, using the uhd commands to do this) >> >> 5) for the e320, the locked status never returns (when running the x310 >> with this code, it sometimes responds with unlocked, but after a few checks >> it comes back ok) >> >> 6) I tried some of the Ettus (UHD) test code >> a) running the "sync_to_gps" program did work - the reference was >> able to lock to the internal (gps) reference >> b) "test_clock_synch" returns similiar errors to what we get >> with our program (see below): >> Checking USRP devices for lock. >> * 318B08B: false >> WARNING: One or more devices not locked. >> Querying Clock for time and setting USRP times... >> [WARNING] [MPM.PeriphManager] Reference Clock reporting unlocked. >> MB_CLOCK_CTRL reg: 0x00000002 >> Running 10 comparisons at random intervals. >> Comparison #1 >> * Clock time: 1563463644 >> * 318B08B time: 1563463644 >> Comparison #2 >> * Clock time: 1563463652 >> * 318B08B time: 1563463652 >> Comparison #3 >> * Clock time: 1563463657 >> * 318B08B time: 1563463657 >> Comparison #4 >> * Clock time: 1563463664 >> * 318B08B time: 1563463664 >> Comparison #5 >> * Clock time: 1563463666 >> * 318B08B time: 1563463666 >> Comparison #6 >> * Clock time: 1563463671 >> * 318B08B time: 1563463671 >> Comparison #7 >> * Clock time: 1563463676 >> * 318B08B time: 1563463676 >> Comparison #8 >> * Clock time: 1563463686 >> * 318B08B time: 1563463686 >> Comparison #9 >> * Clock time: 1563463689 >> * 318B08B time: 1563463689 >> Comparison #10 >> * Clock time: 1563463691 >> * 318B08B time: 1563463691 >> >> Number of matches: 10/10 >> >> >> 7) we ran the same tests at a sister site that has four E320s, and they >> all exhibited the same issues >> >> 8)Finally, a uhd_usrp_probe command returns this: >> >> [INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-36); >> Boost_105300; UHD_3.14.1.0-9-g2aa5289d >> [INFO] [MPMD] Initializing 1 device(s) in parallel with args: >> mgmt_addr=192.168.10.3,type=e3xx,product=e320,serial=318B08B,claimed=False,addr=192.168.10.3 >> [WARNING] [MPM.PeriphManager] Reference Clock reporting unlocked. >> MB_CLOCK_CTRL reg: 0x00000002 >> ... many of these warnings repeating ... >> [WARNING] [MPM.PeriphManager] Reference Clock reporting unlocked. >> MB_CLOCK_CTRL reg: 0x00000002 >> [WARNING] [MPM.RPCServer] A timeout event occured! >> [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: >> 0xF1F0D00000000000) >> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1324 MB/s) >> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1322 MB/s) >> [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD100000003320) >> [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000000) >> [INFO] [MPM.PeriphManager] init() called with device args >> `product=e320,mgmt_addr=192.168.10.3'. >> [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0000000000002) >> [INFO] [0/Radio_0] Performing CODEC loopback test... >> [INFO] [0/Radio_0] CODEC loopback test passed >> [INFO] [0/Radio_0] Performing CODEC loopback test... >> [INFO] [0/Radio_0] CODEC loopback test passed >> _____________________________________________________ >> / >> | Device: E300-Series Device >> | _____________________________________________________ >> | / >> | | Mboard: ni-e320-318B08B >> | | eeprom_version: 2 >> | | mpm_version: 3.14.0.0-g6875d061 >> | | pid: 58144 >> | | product: e320 >> | | rev: 2 >> | | rpc_connection: remote >> | | serial: 318B08B >> | | type: e3xx >> | | MPM Version: 1.2 >> | | FPGA Version: 3.1 >> | | FPGA git hash: e39334f.clean >> | | RFNoC capable: Yes >> | | >> | | Time sources: internal, external, gpsdo >> | | Clock sources: external, internal, gpsdo >> | | Sensors: gps_sky, gps_locked, temp_rf_channelA, temp_rf_channelB, >> temp_internal, fan, temp_main_power, ref_locked, gps_gpgga, temp_fpga, >> gps_tpv, gps_time >> | | _____________________________________________________ >> | | / >> | | | RX Dboard: A >> | | | _____________________________________________________ >> | | | / >> | | | | RX Frontend: 0 >> | | | | Name: Neon >> | | | | Antennas: RX2, TX/RX >> | | | | Sensors: lo_locked, ad9361_temperature, rssi, lo_lock >> | | | | Freq range: 70.000 to 6000.000 MHz >> | | | | Gain range PGA: 0.0 to 76.0 step 1.0 dB >> | | | | Bandwidth range: 20000000.0 to 40000000.0 step 0.0 Hz >> | | | | Connection Type: IQ >> | | | | Uses LO offset: No >> | | | _____________________________________________________ >> | | | / >> | | | | RX Frontend: 1 >> | | | | Name: Neon >> | | | | Antennas: RX2, TX/RX >> | | | | Sensors: lo_locked, ad9361_temperature, rssi, lo_lock >> | | | | Freq range: 70.000 to 6000.000 MHz >> | | | | Gain range PGA: 0.0 to 76.0 step 1.0 dB >> | | | | Bandwidth range: 20000000.0 to 40000000.0 step 0.0 Hz >> | | | | Connection Type: IQ >> | | | | Uses LO offset: No >> | | | _____________________________________________________ >> | | | / >> | | | | RX Codec: A >> | | | | Name: AD9361 Dual ADC >> | | | | Gain Elements: None >> | | _____________________________________________________ >> | | / >> | | | TX Dboard: A >> | | | _____________________________________________________ >> | | | / >> | | | | TX Frontend: 0 >> | | | | Name: Neon >> | | | | Antennas: TX/RX >> | | | | Sensors: lo_locked, ad9361_temperature >> | | | | Freq range: 47.000 to 6000.000 MHz >> | | | | Gain range PGA: 0.0 to 89.8 step 0.2 dB >> | | | | Bandwidth range: 20000000.0 to 40000000.0 step 0.0 Hz >> | | | | Connection Type: IQ >> | | | | Uses LO offset: No >> | | | _____________________________________________________ >> | | | / >> | | | | TX Frontend: 1 >> | | | | Name: Neon >> | | | | Antennas: TX/RX >> | | | | Sensors: lo_locked, ad9361_temperature >> | | | | Freq range: 47.000 to 6000.000 MHz >> | | | | Gain range PGA: 0.0 to 89.8 step 0.2 dB >> | | | | Bandwidth range: 20000000.0 to 40000000.0 step 0.0 Hz >> | | | | Connection Type: IQ >> | | | | Uses LO offset: No >> | | | _____________________________________________________ >> | | | / >> | | | | TX Codec: A >> | | | | Name: AD9361 Dual DAC >> | | | | Gain Elements: None >> | | _____________________________________________________ >> | | / >> | | | RFNoC blocks on this device: >> | | | >> | | | * DmaFIFO_0 >> | | | * Radio_0 >> | | | * DDC_0 >> | | | * DUC_0 >> >> >> We've spent about 2 weeks on this and tried every combo of things we >> could think of and everything works on our other Ettus devices, but the >> E320 just doesn't seem to play nice at all. Are there any thoughts on what >> the issue is (my gut is saying a configuration in UHD). >> _______________________________________________ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> >> _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
