Hello, We are experiencing a number of issues with our N300s. We would like to know if these are known issues and whether or not they are being addressed.
We have recently updated the filesystems, FPGA images and UHD/MPM to 3.13.1 (currently up to date with UHD 3.13.1 release, commit 711ec8a). We are using our N300s in embedded mode. All software/rfnoc firmware has been previously tested and used on X300s and E312s. I have uploaded a few supporting images to a google drive folder. (Link: https://drive.google.com/drive/folders/1b1T69G7AAA2-QlIByBYp9UQ_gs8_1253?usp=sharing) 1) GPSDO Locking and Synchronization: - The time to obtain and GPS lock, even when outside is long and often unstable. Code used to query GPSDO lock: > uhd::property_tree::sptr tree = _usrp->get_tree(); > uhd::fs_path path; > std::vector mboard_names = tree->list("/mboards"); > path = "/mboards/" + mboard_names[0]; > try { > path = "/mboards/" + mboard_names[0]; > try { > tree->access(path / "sensors" / "gps_locked").get().value; > } catch (std::exception &) { > } catch (std::exception &) { > std::cerr << "Error: No response from GPSDO" << std::endl; > return false; > } > //Check for GPS lock > uhd::sensor_value_t gps_locked = tree->access(path / "sensors" / > "gps_locked").get(); > return(gps_locked.to_bool()); > } This is a printout of the N300 sensor values when GPSDO is in a non-locked state: > ----------------- Sensors ----------------- > Clock Source: gpsdo > Time Source: gpsdo > ref_locked: true > gps_locked: false > gps_time: 1548206414 > gps_tpv: {"ept": 0.0050000000000000001, "speed": 3.7040000000000002, "epv": > 73.599999999999994, "device": "/dev/ttyPS1", "eps": 141.21000000000001, > "lon": -118.169881667, "epy": 109.009, "epx": 101.339, "alt": > 367.69999999999999, "lat": 34.200626667000002, "class": "TPV", "epc": 92.0, > "track": 318.0, "time": "2019-01-23T01:20:14.000Z", "mode": 3, "climb": > 32.200000000000003} > gps_sky: {"hdop": 9.3000000000000007, "class": "SKY", "device": > "/dev/ttyPS1", "pdop": 9.8000000000000007, "vdop": 3.2000000000000002, > "ydop": 7.2699999999999996, "tdop": 3.6200000000000001, "gdop": 11.09, > "satellites": [{"PRN": 30, "az": 53, "el": 71, "ss": 26, "used": false}, > {"PRN": 28, "az": 327, "el": 67, "ss": 0, "used": false}, {"PRN": 135, "az": > 205, "el": 47, "ss": 34, "used": false}, {"PRN": 7, "az": 101, "el": 44, > "ss": 33, "used": true}, {"PRN": 17, "az": 188, "el": 44, "ss": 32, "used": > true}, {"PRN": 13, "az": 308, "el": 38, "ss": 0, "used": false}, {"PRN": 11, > "az": 80, "el": 32, "ss": 34, "used": true}, {"PRN": 1, "az": 99, "el": 17, > "ss": 27, "used": false}, {"PRN": 19, "az": 199, "el": 17, "ss": 28, "used": > true}, {"PRN": 18, "az": 70, "el": 14, "ss": 28, "used": true}, {"PRN": 8, > "az": 39, "el": 11, "ss": 0, "used": false}, {"PRN": 9, "az": 164, "el": 10, > "ss": 27, "used": false}, {"PRN": 15, "az": 321, "el": 7, "ss": 0, "used": > false}, {"PRN": 5, "az": 255, "el": 4, "ss": 0, "used": false}], "xdop": > 6.7599999999999998} > fan: 4320 > temp: 42.0 This is a printout of the N300 sensor values when GPSDO is in a locked state: > ----------------- Sensors ----------------- > Clock Source: gpsdo > Time Source: gpsdo > ref_locked: true > gps_locked: true > gps_time: 1548215759 > gps_tpv: {"lat": 34.200188333, "class": "TPV", "speed": 0.0, "device": > "/dev/ttyPS1", "epv": 112.7, "ept": 0.0050000000000000001, "alt": > 341.10000000000002, "mode": 3, "time": "2019-01-23T03:55:57.000Z", "climb": > 0.69999999999999996, "lon": -118.169401667, "epc": 225.40000000000001, > "track": 148.09999999999999} > gps_sky: {"hdop": 3.2999999999999998, "class": "SKY", "satellites": [{"used": > false, "el": 80, "az": 318, "PRN": 19, "ss": 12}, {"used": false, "el": 58, > "az": 32, "PRN": 17, "ss": 13}, {"used": true, "el": 49, "az": 199, "PRN": > 133, "ss": 35}, {"used": false, "el": 47, "az": 205, "PRN": 135, "ss": 31}, > {"used": true, "el": 42, "az": 159, "PRN": 6, "ss": 31}, {"used": false, > "el": 36, "az": 311, "PRN": 24, "ss": 0}, {"used": true, "el": 35, "az": 75, > "PRN": 28, "ss": 29}, {"used": true, "el": 24, "az": 221, "PRN": 13, "ss": > 32}, {"used": false, "el": 19, "az": 258, "PRN": 15, "ss": 17}, {"used": > false, "el": 17, "az": 189, "PRN": 2, "ss": 23}, {"used": false, "el": 16, > "az": 146, "PRN": 30, "ss": 21}, {"used": false, "el": 8, "az": 290, "PRN": > 12, "ss": 15}, {"used": false, "el": 5, "az": 35, "PRN": 1, "ss": 0}], > "vdop": 4.9000000000000004, "device": "/dev/ttyPS1", "pdop": > 5.9000000000000004} > fan: 4320 > temp: 38.0 We note that in the ‘unlocked’ state, based on the gps_sky and gps_tpv reports, there are actually more satellites being used for the position calculation (‘used’ set to ‘true’). Additionally, the signal strengths (’ss’) in general are as good, if not better, than those in the ‘locked’ state. This is a consistent problem across multiple N300s. In some cases, gps_locked is not being asserted for hours despite good signal reception. 2) GPSDO/GPS PPS drifts in both ‘gps_locked=true’ and ‘gps_locked=false’ states significantly. We have setup 2 N300s with RX/TX channels cross connected in a bistatic loopback to test GPSDO synchronization. N300 A: TX0 -> N300 B: RX0 N300 B: TX0 -> N300 A: RX0 We transmit 100MHz LFM chirps and plot the autocorrelation peak as a function of time (X axis is ‘Free space range’). The TX/RX is ‘triggered’ by the every second by GPS PPS. The result is the same whether or not the individual N300s report as being locked to gps: Over 20 seconds, the relative drift is .5 us. Orders of magnitude worse than what the jackson labs GPSDO should be capable of. (See n300_bistatic_gpsdo_drift_plot.png) For reference, we have attached plots of relative 50MHz LFM chirp waveform autocorrelation peak drift obtained using similar software, environment and setup but with two E312s: The relative peak drift is contained to ~+-10ns using the PLL locked to the GPS pps signal, as expected. (See sync_pps_drift_e312.png) The code that performs the pps clock synchronization is: > uhd::property_tree::sptr tree = _usrp->get_tree(); > uhd::fs_path path; > std::vector<std::string> mboard_names = tree->list("/mboards"); > path = "/mboards/" + mboard_names[0]; > double rate = _radio_ctrl->get_rate(); > double time_set = 0; > > std::vector<std::string> sensor_names = tree->list(path / "sensors"); > int gps_time=0; > if(std::find(sensor_names.begin(), sensor_names.end(), "gps_time") != > sensor_names.end()) { > gps_time = tree->access<uhd::sensor_value_t>(path / "sensors" / > "gps_time").get().to_int(); > } > else if(std::find(sensor_names.begin(), sensor_names.end(), > "get_gps_time_sensor") != sensor_names.end()) { > try{ > gps_time = tree->access<uhd::sensor_value_t>(path / "sensors" / > "get_gps_time_sensor").get().to_int(); > } > catch (std::exception &e) { > std::cerr<<“Error: caught exception while accessing > get_gps_time_sensor: "<<e.what()<<std::endl; > return -1; > } > } > else{ > std::cerr<< "Error: gps_time sensor field not found"<<std::endl; > return -1; > } > uint64_t last_pps = _radio_ctrl->get_time_last_pps().to_ticks(rate); > uint64_t curr_pps = last_pps; > while (curr_pps ==last_pps){ > curr_pps = _radio_ctrl->get_time_last_pps().to_ticks(rate); > boost::this_thread::sleep(boost::posix_time::milliseconds(20)); > } > double gps_time_next_d = (double)gps_time+2.0; > uhd::time_spec_t new_gps_time = uhd::time_spec_t(gps_time_next_d); > _radio_ctrl->set_time_next_pps(new_gps_time); > time_set = gps_time_next_d; > return 0; 3) Spectrum asymmetry for TX gain >= 35 dB. - When the TX gain of the N300 is >=35 dB, the spectrum becomes asymmetric w/r/t DC. This is true for LFM chirp waveforms of any bandwidth and with zeros pre-appended. Here we have configured a single N300 in external loopback: N300 A: TX0 -> N300 A: RX0 We've attached plots of 100MHz and 25MHz bandwidth chirp spectra. Reducing TX gain to 34.5 dB solves this and the spectrum looks normal. We have 30dB attenuators in all paths and are far from receiver saturation. This problem is consistent for both channels across multiple N300s. Plots show the spectrum of the RX waveform as well as the expected waveform spectrum. (See n300_chirp100mhz_trim.png, n300_chirp25mhz_trim.png) 4) Randomly appearing impulse with magnitude ~255 at multiples of 2048 samples. - An impulse will appear in the time domain RX signal randomly, but often, at multiples of 2048 samples. Again, this behavior is seen on multiple N300s. I've included plots of the RX signal, when only noise is present (no TX). (See spp_impulse_two.png, spp_edge_impulse_zoom.png). 5) MPM Speed and Performance - In general MPM and operations (frequency tuning, streaming, etc) and communication with the N300s in embedded mode is slow compared to E312's. With identical pulsed waveform sample lengths, algorithms and pulsed streaming operations that run smoothly on the E312 cause late stream commands and need to be throttled to run on the N300. 6) Complete phase incoherence for tuning frequencies <300MHz - Within a single tuning, the low frequency/low band conversion path of the N300 seems to be unstable. The phase varies rapidly with time making the <300MHz band completely unusable. We have not completely characterized the statistics of this phase incoherence, but for a time-coherent/timed TX/RX pulsed waveform loopback on a single N300 the phase seems to be random from pulse to pulse. If anyone is able to provide insight to these issues, it would be greatly appreciated. We are happy to provide additional details about the problems we are seeing. Thanks, Sam
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
