# Inexplicable Offset in Satellite Laser Ranging (SLR) observations

I am struggling with the implementation of a Satellite Laser Ranging (SLR) validation tool.

The situation is as follows: I am provided with a framework which gives me the position of a SLR observation station and the position of a satellite at a specified GPS time. Those positions can be assumed to be sufficiently correct for the given task. From those positions I calculate a reference distance which I will use for comparison with given SLR observations. The observation files I use as input are in CRD format and provided by data centers like http://edc.dgfi.tum.de/en/. From those files I extract, for each observation record, the GPS time stamp and time of flight in seconds. According to the simplest observation equation for SLR given by $$d = c * \frac{\Delta t}{2}$$ I calculate the distance between station and satellite and compare it to the distance provided by my framework.

The problem is the distances deviate seemingly randomly with deviations ranging from 1 to 300 meters in both directions. I am aware that the simple observation equation is missing all correction terms but even without those an accuracy of up to 10 meters should be feasible.

So far I thought I was dealing with a station clock or observation clock bias but adding offsets in positive as well as negative direction to the observation times always resulted in greater deviations of the two distances.

The only thing I am constantly experiencing in all observations is (surprisingly) a greater deviation at steeper elevation angles, which is in contrast to my expectations, since this results in far shorter absolute distances.

One example of my results is the following observation from Graz Lustbühel of the 22 June 2017 monitoring the GRACE A satellite.

 | standard Deviation 156.32185
|  Time               | Ref Distance| Obs Distance| Deviation   | Elevation Angle
| ------------------------------------------------------------------------------
| 2017-06-22_13-57-47 | 573630.53   | 573510.16   | -124.37518  | 34.1093
| 2017-06-22_13-57-51 | 550922.4    | 550796.16   | -130.05672  | 35.989845
| 2017-06-22_13-57-56 | 528348.25   | 528215.69   | -136.19948  | 38.060675
| 2017-06-22_13-58-00 | 507464.43   | 507325.52   | -142.39058  | 40.19135
| 2017-06-22_13-58-06 | 484607.77   | 484461.27   | -149.80929  | 42.81356
| 2017-06-22_13-58-11 | 465610.45   | 465457.04   | -156.57817  | 45.279134
| 2017-06-22_13-58-16 | 449075.77   | 448915.81   | -162.99763  | 47.689646
| 2017-06-22_13-58-20 | 435233      | 435067.11   | -168.8336   | 49.94278
| 2017-06-22_13-58-25 | 424230.88   | 424059.89   | -173.84746  | 51.921769
| 2017-06-22_13-58-30 | 415972.62   | 415797.47   | -177.94548  | 53.540971
| 2017-06-22_13-58-35 | 411432.82   | 411255.13   | -180.45426  | 54.491375
| 2017-06-22_13-58-40 | 409363.89   | 409184.61   | -182.0285   | 54.951053
| 2017-06-22_13-58-46 | 411421.31   | 411242.31   | -181.76171  | 54.532429
| 2017-06-22_13-58-50 | 416021.81   | 415844.36   | -180.23949  | 53.598194
| 2017-06-22_13-58-56 | 427050      | 426876.64   | -176.23183  | 51.499173
| 2017-06-22_13-58-59 | 433701.19   | 433530.31   | -173.80953  | 50.323281
| 2017-06-22_13-59-06 | 452168.09   | 452003.85   | -167.28999  | 47.357755
| 2017-06-22_13-59-11 | 468417.38   | 468258.68   | -161.8747   | 45.049964
| 2017-06-22_13-59-15 | 487200.93   | 487048.25   | -155.9925   | 42.663639
| 2017-06-22_13-59-21 | 509791.27   | 509645.32   | -149.43676  | 40.116813
| 2017-06-22_13-59-26 | 532186.88   | 532047.1    | -143.43855  | 37.873845
| 2017-06-22_13-59-30 | 555171.16   | 555037.25   | -137.7555   | 35.809979
| 2017-06-22_13-59-35 | 580787.28   | 580659.4    | -131.91771  | 33.744171
| 2017-06-22_13-59-40 | 607376.04   | 607253.94   | -126.36003  | 31.816812
| 2017-06-22_14-00-11 | 792767.05   | 792675.37   | -97.569278  | 22.258777


Is there any phenomenon explaining this varying offsets?

• You calculate the distance between a satellite and a ground station from the time interval. But what value do you use for the speed of light? The vacuum value is valid above the atmosphere but not within. GPS uses a correction for the influence of the atmosphere to the speed of light. Of course the correction depends on air pressure at the altitude. But this error is very small, for a GPS satellite 5 ° above the horizon up to 25 m. If you want a accuracy better than 10 m, the lower speed of light within atmosphere should be considered. But errors up to 300 m are not explained by this effect. – Uwe Jan 3 '18 at 15:46
• During one nanosecond, a distance of about 0.3 m is covered by light. For a precision of less than 10 m, the resolution and precision of time measurement should be less than about 10 ns. – Uwe Jan 3 '18 at 15:58
• For the speed of light I have used the constant given at [en.wikipedia.org/wiki/Speed_of_light]. I am aware of the atmospheric delay and I have already implemented respective correction functions based on the algorithms by Marini and Murray as well as Mendes and Pavlis. But I have switched them off again for debugging since they influence the results only marginally. – lenxn Jan 3 '18 at 16:01
• I didn't find the precision of the time of flight in the format specification ilrs.cddis.eosdis.nasa.gov/docs/2009/crd_v1.01.pdf, but since biases are given in ps and the data being meant for exactly this calculation I am quite sure the error is not due to insufficient precision. – lenxn Jan 3 '18 at 16:08
• The framework uses GPS time and the observations (according to the format specification) too. – lenxn Jan 3 '18 at 16:31

A few things to consider:

1. Refraction- The atmosphere will bend the light somewhat, which might cause it to take longer.
2. Speed of light changes- Light moves a bit slower when going through more of the atmosphere
3. Timing accuracy- The position of the satellite might be off in time slightly, which would result in a deviation.
4. Positional accuracy- This results if you don't know the location of your source point exactly.
5. Floating point errors. Floating points are accurate to about 7 decimal digits. That means it is accurate to about a meter, give or take. Not likely to be the source of your error, but it could crop up in the time estimates.

To narrow this down a bit, try the following:

1. See if there is a correlation between the error and the line of sight angle. If the distance is most accurate when straight overhead, it could be a refraction or speed of light error.
2. Make sure your GPS location and time are accurate.
3. Try plotting various of your values vs others.
4. Determine the distance to a known source. I recommend using the Lunar laser reflectors on the moon. With these, you can get great results. If you are able to do this with satellites, consider using one of the GPS satellites, as their exact positions can easily be calculated.

Looking at your data, I found a few things of some interest.

1. The higher the elevation, the higher the error. This would indicate an overcorrection.
2. The relative error is highest at the highest angles.

Thinking about this, that indicates that when the overhead motion of the satellite is the most, the error is the most. Also when the Doppler change is the most, the error is the most. I rather strongly suspect the issue is some kind of a timing issue, where the exact position of an object isn't as well determined as you think it is. Try some of the tests I indicated (Moon and GPS satellites) if you can to further validate this.

• Single precision floating point error is about 7 decimal digits, but double precision is 15 to 17 digits. There is also quadruple precison using 128 bits giving 33 to 36 decimal digits. – Uwe Jan 3 '18 at 20:33
• If it's not the issue with single precision, double precision won't be an issue. But yes, if one was tracking a ~1m error, then going to double precision would greatly drop that error. – PearsonArtPhoto Jan 3 '18 at 20:35
• The time of flight in seconds are given with 12 decimal digits, so double precision should be sufficient. Hence all calculations have been conducted with double precision. – lenxn Jan 4 '18 at 11:46