Skip to content

These general notes are still correct – but I am moving towards providing all of this information via gitHub and using python.  Most of these steps will be automated. Please stay tuned.

  • Make sure that your GPS/GNSS data are in the RINEX format.  Typically this is RINEX version 2.  If someone gives you binary files, learn to convert them to RINEX. I use the UNAVCO program called teqc, and a binary converter for Trimble data, but there are many other programs that will do this.
  • I use the  SNR observables. In RINEX speak, these are called S1, S2, and S5 for the SNR data. They correspond to the data from the L1, L2, and L5 frequencies. Sometimes people forget to put S1,S2 (and S5) in their RINEX files, but that doesn’t mean the receiver failed to compute these values. All GPS receivers calculate SNR values.  You might have to go back to the binary files to make sure the data show up in the RINEX file.
  • If you have inadvertently made a RINEX file without a sensible receiver position in it, you need to fix it. You can do that using teqc. For reflections, you do not need an accurate receiver position. Within a few hundred meters is fine. If your site is on a fast moving glacier or ice sheet, then you should take care of that. My gitHub code allows you to use a site position (at a given epoch) and velocity, so feel free to use that.
  • You can write your own code to decode the RINEX file.  You can also use my code to do this if you want – but it is in Fortran. You will need to download and compile it.
  • You need a source for the GPS orbits.  My gpsSNR code uses the navigation message. My gnssSNR code uses any sp3 file – so you can in principle use translate non-GPS satellites.
  • Once you have converted your RINEX file into a snrfile, you need to decide in which directions (azimuths) you are going to look for reflected signals. For now, let’s assume we are going to figure this out from the data themselves.
  • You should load the snrfile into memory, and loop through all possible GNSS satellites, and all azimuths.  You get to decide which azimuths to use. I generally use 30 or 45 degrees (0-45, 45-90, 90-135 etc) as this allows me to go through the data pretty easily and avoid satellites that rise and set in the same azimuth bin.
  • For GPS, I strongly prefer L2C and L5, but most historical datasets won’t have them. You can start with L1 and try L2 to compare. Note: some receivers have good L1 data – and some do not.
  • Generally speaking, once I’ve established what are the good azimuths, I simply compute periodograms for all tracks that make it through my QC metrics and write those to a file.  A couple easy quality control metrics: the peak amplitude or the ratio of the peak to the noise.
  • Later you take all your results and run a median filter on each day to find and remove gross reflector height outliers.  At that point you just take the mean, and you have a daily reflector height.