Recent Posts

Pages: [1] 2 3 ... 10
I have a question especially for HighQ laser users (Matt, Sven, Franz et al.), what chiller are you using? Do you have some model from Lauda, with what specifications (cooling power, temperature stability; @Matt: how big deviations in temperature you had when you noticed the calibration changes?) We need to get a new one to replace our >10 year old Lauda in Metsähovi with a new one, and I'm trying to find the "best" option suited for our needs.

The backround is: we run into problems with the water cooling unit as we are not using our laser that much... even though the chiller has been on most of the idle time (and we have changed the water every once in a while), there was a major blockage inside the post amp. I had to use quite a lot of brute force, nasty chemicals and sharp tools to get the blockage open. Finally after this, everything went fine for some time until suddenly the water connector on the backside of the HighQ post amp analog modules broke down spraying the water all over the laser controller rack. Fortunately pretty much all of the electronics were shut down and everything seems to still work. Now finally the fan inside the cooling unit has stopped working (probably the motor is broken, pretty much impossible to replace) and the unit burnt two fuses while I was trying to operate the laser.
Lesson learned: be cautious and suspicious if you have water hoses connected on top of your electronics rack. Apparently it is the initial design from HighQ, seems that the connector was tightened too hard which had cracked the connector.
Hi all

There are now many EvenTech event timers in operation in the ILRS network.  We bought and installed one at Herstmonceux in 2014 and got good/improved performance in comparison to our HxET event timer, which was built in­-house from two Thales Systems timing modules and a clock module. Our A033-ET runs using a server that I coded in C. See here

Since then it has been collecting simultaneous laser range measurements, as part of a secondary data stream.  I am now developing this part of our system with the intention of making the A033-ET our primary timer.

Working more closely with the timer i detected occasional 1 second jumps in the reference epoch. This is actually mentioned in the instruments documentation:

If the initially defined reference time is incorrect, it can be further corrected using the below described procedures of Time monitoring and Setting. Additionally note that successful time synchronization may become incorrect if during 1.5 hours after performing it the A033-ET has not been used either for the measurement or time monitoring (see below). To avoid this case it is recommended to activate the time monitoring during long pauses between measurements or repeat the procedure directly before the next measurement.

At the time, the C server did not put the timer in 'time monitoring' mode during quiet periods, but did run the time synchronisation regularly.  I have since re-coded the server to switch to time monitoring when not taking measurements.  Now in this monitoring mode, I compare every tick to the local PC clock that is kept closely to UTC using the Linux NTP service. If an incorrect epoch is detected, a correction is applied using the 'set parameters' command.  I think this level of monitoring is enough to ensure that the A033-ET works as needed. I still see 1 second jumps in the timer epoch every few days and will continue to monitor this. I will also be watching to see if any jumps occur during measurements.

How does everyone treat this? Do you see any 1 second jumps? How much of a problem is it?

Also, I wanted to upgrade the A033-ET Windows PC from XP to Windows 7.  This caused me and the guys at EvenTech a long series of headaches so I'll describe here my final set-up.  This parallel port card was recommended to me and it was easy to install. There are W7 and W10 64-bit drivers available. EventTech supplied me with a new version of the A003-ET Server application to work in 64-bit Windows.  An important next step was to change the "EPP PORT = XXXXX/YYYYY" line in the param.cnf file.  These are the DEC numbers of the Control Register addresses of the Parallel Port and Extended Port, which are found in the Port tab in the PCI Card properties in Windows Device Manager. These are listed in Hex and should be converted to DEC and DEC+2 for the Extended Port number.

I did all this and still could not connect to the timer.  First I found that Windows was creating a new param.cnf file in a new folder as part of some virtualisation.  It was this file i had to change to set the correct port.  This still did not work and it wasn't until i copied the complete 'A033-ET Server 1' folder out of the 'Program Files (x86)' folder and on the Desktop that i finally got it running.

I hope this is useful and  I'd be interested in the experience at other stations and any tips you might have.



In-Sky Safety / Re: On telescope camera for plane spotting
« Last post by Matt Wilkinson on April 25, 2019, 12:44:26 PM »
Great you're getting the telescope Serna, good luck with it.

We'll have to start a new topic discussion on directional microphones soon.  We are just thinking about trying some experiments.
In-Sky Safety / Re: FLARM
« Last post by serna_yebes on April 25, 2019, 07:26:10 AM »
The TRX-1500 FLARM rx is not available any more. Another good option, the one we already acquired, is the AT-1 receiver (it is the TRX-1500 successor).
In-Sky Safety / Re: On telescope camera for plane spotting
« Last post by serna_yebes on April 25, 2019, 07:22:24 AM »
Good morning.
We are currently defining our Telescope system (our plan is to buy it this year). It is really interesting your work related with the optical camera for aircraft security. So we will have it into consideration for our system (in addition with ads-b, flarm, all-sky camera, directional microphone...).
Best regards.
In-Sky Safety / Re: On telescope camera for plane spotting
« Last post by Matt Wilkinson on April 24, 2019, 12:02:08 PM »

I am making good progress on our plane detection camera.  I presented the technique in a poster at the 2018 ILRS Workshop

I've made some effort to not detect clouds, but i am triggering on birds and insects.  I will have to see if this becomes a problem.

I'm using a visible spectrum, monochrome camera at the moment.  It has too many pixels and so will only run at 5-7Hz. I plan to test a faster colour camera.

Who is working on optical aircraft detection? Do you expect to build a reliable system??

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
Pages: [1] 2 3 ... 10