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<mailto:ja...@gardettoengineering.com>> wrote: Do you need anything from my side of things? ________________________________ From: Nate Temple <nate.tem...@ettus.com<mailto:nate.tem...@ettus.com>> Sent: Thursday, July 18, 2019 3:49 PM To: Jason Matusiak <ja...@gardettoengineering.com<mailto:ja...@gardettoengineering.com>> Cc: Ettus Mail List <usrp-users@lists.ettus.com<mailto: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<mailto: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<mailto: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
