Recent Posts

Pages: [1] 2 3 ... 10
Hi Andrew

No, I checked and 5 is correct.

It is not the 'Epoch Event' flag that i am using here, but the next entry called the 'Filter Flag'. 

Thanks.  Let me know how you get on
Data and Software Questions / Re: - orbit adjustment and normal point software
« Last post by dmai on February 26, 2019, 12:00:48 AM »
But there is one question.
According to the format description (
   I1 Epoch Event - indicates the time event reference
takes a position 5, hence in python it should be 4.
In the program in line 741 is used 5.

elif a[0]=='10':
    if(Unfilter) | (a[5] == '2'):

Is it correct? Did I understand correctly?

Best wishes, Andrew.
Dear all

The orbit adjustment and normal point formation software is now available for download on the ILRS Software webpage:

It was developed from FORTRAN code at the SGF, Herstmonceux UK. It includes a README file and an open source license.

A Python3 installation is required, with Matplotlib, NumPy and SciPy (>0.17) libraries. runs from the command line and can process full-rate CRD files or raw epoch-range data using a corresponding CPF prediction file. Please see the examples in the README file. Post any issues here and I will help to resolve them.

To see the code, open it in a text viewer. If you find any bugs, errors or typos please let me know.  I would welcome any assistance to develop this code. 

I hope this is useful to the community as an analysis tool and example code for reducing SLR data.

Dear Laser Tracking Colleagues,

G'Day from Tokyo.

In the 21st International Workshop on Laser Ranging (conference site:, proceedings site:, I presented station-by-station performance charts (printed on 1-metre-long sheets) during the Clinic Session 3 co-hosted with Jose Rodriguez.  Here are the short summary of the analysis and the links to the charts.

Period: July 2017 to June 2018.
29 Stations with > 200 LAGEOS passes in the 1 year span.
More details about the analysis: See

Unlike the previous years' ones, this year's charts are organised PER STATION.  Matrix charts are also provided (printed on the reservse side) to help investigate the cause.

The first part contains:
  Residual wrt Range rate (negative in ascending (first) half, and positive in descending (second) half of a pass)
  Residual wrt Local time (defined by the station longitude, slightly different from the local standard time)
  Residual wrt Range rate (as specified in normal point data)
  Residual wrt Single-shot RMS (as specified in normal point data)
  Residual wrt Skew (as specified in normal point data)
  Residual wrt Kurtosis (as specified in normal point data)
  Residual wrt System delay (1), (2),.. (per system delay 'group')
  System delay (all sat) (including calibration data for other satellites not included in this analysis)
  System delay (A), (B), ... (vertical scale magnified as above)
  Calibration interval (cumulative) (typical calbration interval is at median (50%))

The matrix chart (second  part) labels, top-to-botumn = left-toright,  mean:
  Mon 17: Months from January 2017 (13 for January 2018)
  Hour: Local time
  # ret: Number of returns per NP bin
  Return rate
  RMS: Single-shot RMS
  Kurt: Kurtosis
  Range rate
  System delay (1), (2), ...
  O-C: POD residuals
7090 (Yarragadee)
7941 (Matera)
7825 (Mt Strolmo)
7237 (Changchun)
7105 (Greenbelt)
7810 (Zimmerwald)
7840 (Herstmonceux)
7110 (Monument Peak)
7501 (Hartebeesthoek)
7841 (Potsdam)
7821 (Shanghai)
8834 (Wettzell)
7839 (Graz)
7119 (Haleakala)
7819 (Kunming)
1887 (Baikonur)
7838 (Shimosato)
7249 (Beijing)
7827 (Wettzell)
7407 (Brasilia)
1873 (Simeiz)
1879 (Altay)
7845 (Grasse)
1893 (Katzively)
1891 (Irkutsk)
1868 (Komsomolsk-na-Amure)
1889 (Zelenchukskya)
1886 (Arkhyz)
7811 (Borowiec)

Best Regards,
Toshimichi Otsubo (
Hitotsubashi University
Data and Software Questions / Python library for (new) CRD format
« Last post by ZhipengLiang on October 24, 2018, 04:12:45 AM »
Hey everybuddy,

Today, while writing my own CRD-parsing python3 code, I felt a little bit wheel-reinventing :-\

Since the new CRD/CPF format is going to release at the Canberra meeting, I guess it's time to think about our new CRD2.0 python library?
It should have following functions: verify the CRD2.0 format, extract data, etc.

I found in GitHub the CRD/CPF library from Olli Wilkman:

Could be a good start.
Links to Publications / The next generation of SLR systems
« Last post by Matt Wilkinson on October 09, 2018, 03:31:33 PM »
As part of the Journal of Geodesy Special Issue on Satellite Laser Ranging. My co-authors and I published an article titled The next generation of satellite laser ranging systems

SLR stations around the world are upgrading and redesigning. Some stations are specialising in new, complementary applications. Yet there remains challenges for the future

Dear Jose,

I didn't check the forum for a while, however I made a comparison between the formula I found on some Arnold's papers and the one I was using, here are the results:

Peak           Arnold     my simulation
1-2            28.9680   24.9776
1-3          110.7177   95.8031
1-4          243.2109  211.6056
1-5          423.1052  370.6967

the new value seems to reproduce correctly the data from RETRO. Now I'll try to see what can I do on the peak intensities.

Thanks again

Station Equipment Questions / Re: Meteorological station
« Last post by serna_yebes on July 20, 2018, 08:00:48 AM »
Good morning Jorge, and thank you very much for your comments.
I need to verify the current sampling rate of the meteo station at Yebes.
The local microclimate is not also a problem here, as I told you the meteo station is about 60 meters from the planned SLR location. And yes, it has an anemometer. We will use the info from the anemometer (jointly with the rain on/off detector) to control the dome in case of risk.
We are buying a good all-sky camera and a rain detector to be installed in the SLR roof. We will buy also a cloud detector.
So I think we will install, in the SLR station optimum position, a new meteo station (JUST pressure, temp and RH) and share the other data from the meteo station in the observatory. This way we´ll also have redundant info from the barometers.

Station Equipment Questions / Re: Meteorological station
« Last post by delpino@riga on July 19, 2018, 12:46:10 PM »
Serna Yebes

I think that all participants on the Networks and Engineering Standing Committee Forum will agree on the following points:

•   The coordinates and in particular the height difference between the barometric sensor in use and the telescope invariant point should be included, measured and known in the local geodetic network.

•   The sensors (and in particular the barometer, which is the most difficult to calibrate “in situ”) should be calibrated periodically, (how we define “periodic” will be another looooong discussion).

•   What is now the sampling data rate of the current Yebes meteorological station?
Most SLR and GPS stations works at 10 minutes (at sharp second) sampling rate.
Remember that the pressure resolution asked is 0.1 milibar, and most of time, the pressure change rate in 10 minutes is less or equal than that.

•   The meteodata should be time tagged and available immediately at the local network, not only the last measurement done, but also the proceeding ones.

•   This is because the best practice is to include both pre- and post- meteorological values on the Normal point and this Normal Point file should be generated and delivered as soon as possible.
But if you do the “batch filtering” every few hours, you need to have access to the data of at least the last couple of days (to have a monthly file is a good compromise)

•   If the “local microclimate” at Yebes is (more or less) the same at the meteorological and SLR places, for example both places are surrounded by grass, this distance is not a problem.
In Riga we are using a common meteorological station at a distance of 32m (GPS) and 50m (SLR)

•   Do the current meteorological station has an anemometer?
Do you have strong winds at Yebes?
Because for really strong winds, automatically closing the roof/cupola/clamshell will be a good security measure against flying objects.
At the new buildings at GFZ Potsdam, all the windows have external Venetian blinds connected to a central anemometer. When the wind reaches a limit all the blinds are automatically lowered to protect the windowpanes

•   Invest the money on the best clarity/rain sensor in which the rain/snow alarm can be used to automatically close the SLR roof AND on a high quality all-Sky camera!
When several satellites are visible and it is partially cloudy, the all-Sky camera is the best tool for the on-the-spot tracking optimization.

And if you have a LOT of money project, and buy the independent, well calibrated SLR basic meteorological station situated at the SLR invariant height, no one at the SLR community will complain!.

Station Equipment Questions / Re: Meteorological station
« Last post by serna_yebes on July 19, 2018, 11:06:09 AM »
Good morning.
We are thinking about the optimum meteorological station for our new SLR system.
In the observatory we have a complete meteo station (pluviometer, anemometer, pyranometer, temp, pressure, humidity...).
Do you think we could use the data from this station for our SLR system? it is more or less 60m away from the planned SLR location.
Or could it be better to have a new station just close to the SLR station?
Perhaps we can share the data from the pluviometer, anemomenter, pyranometer...and install close to the SLR station in the optimum position-height the pressure-temp-humidity sensors + the rain detector on/off.
Thank you :)
Pages: [1] 2 3 ... 10