I have N310's but we don't use GPS. Will start testing issue 4 next week and see if I can reproduce.
On Fri, Jan 25, 2019 at 2:31 PM Nate Temple via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi Sam, > > These are all new issues that we were unaware of. I will follow up with > you off list to debug these issues through your previously sent email to > supp...@ettus.com. > > > Regards, > Nate Temple > > On Fri, Jan 25, 2019 at 2:13 PM Samuel Prager via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> 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 >> > _______________________________________________ > 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
