Recent Posts

Pages: 1 2 [3] 4 5 ... 10
Recovered post:

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.

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 :)
Sorry for the late reply.

You are right, the intensities in the LAGEOS-2 report figure are funny. In any case, I wouldn't sweat it trying to match that data. As for the geometry, I get about 111 ps from the retro in the north pole and the third ring. It may be worth checking the expressions for the delay provided in the reports by D. Arnold, just in case what you are using is somehow different...
Dear Jose,

thanks for the reply, actualy both intensity and delay don't match, see the attached figure. The delay between the first and third peak is 95 ps, while in the paper is clearly more than 100. The intensities however are much more in disageement. One thing that surprises me in the ficure 5.5.1 is the ratio between the first and the third peak, which I'd expect to remain constant also when varying the pulse duration. On the contrary, I see that for 10 ps they are almost equal, for 30 ps the first peak si much smaller than the third, for 60 ps they are again similar and for 130 ps the first is again smaller. 


In what way your results don't match those of fig. 5.5.1? The models given in Degnan's paper are based on empirical approximations, if I remember correctly, so I wouldn't expect the intensities to be spot on. But the geometry (delay) should be fine. Did you get this bit right for the orientation shown in the figure, i.e. a laser incident on the north pole of the satellite?
Mission Tracking Feedback / Re: S-NET tracking
« Last post by zizung on June 13, 2018, 05:59:53 PM »
thank you!
Timing / Re: Pulse collision avoidance
« Last post by Georg on June 13, 2018, 11:34:54 AM »
Hello Daniel,

sorry for the late reply - I just saw your questions now ....

In Graz, we have tried to optimize this overlap avoidance procedures / minimize the rep rate losses, using the FPGA on our home-made PC card:

- This PC card creates the laser firing pulses, and triggers the HiQ laser
- The FPGA stores all future return event times of just fired laser pulses (sseveral 100 events for up to GEO satellites) in a FIFO
- On each laser start pulse event, the FPGA checks the time difference between this laser firing epoch, and the next return epoch time
- If the next return epoch time is closer than 100 µs (can be adjusted...), one additional 100 µs delay is inserted before the next laser fire command,
  followed then again with laser firing commands in the usual 500 µs intervals (then referred to this first delayed one)
- When the echo of this first delayed pulse arrives, and the overlap conditions is still alive, once again a 100 µs delay is inserted .... etc....
   as long as the overlap conditions is valid
- This procedure reduces the rep rate only during overlap, and only by a very small percentage (e.g. from 2 kHz to 1960 kHz or so; depends on satellite)

This overlap avoidance procedure can be enabled / disabled by setting a control bit via PC.

Works perfect for 2 kHz (and a bit higher); for > 10 kHz, the 50% operation might be necessary, but this is a rather high price ... it might be better to just neglect overlaps, which could be acceptable in view of much lower energy per pulse (i.e. less backscatter).

Pages: 1 2 [3] 4 5 ... 10