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
