20130228 Laser Energy Meter Comparison
SLink energy meter arrived back from recalibration. Also, it's externally triggered so it should be better. However, last time we observed that it missed quite a few pulses even when externally triggered. Just now, a handheld meter is used that isn't triggered, but the laser is more reliable than the slink so it's not too much of a problem. I asked about the triggering issues, but like their detector, Gentec seemed unresponsive.
- Use caEventRate on ip:laserenergy. Leave until 6th iteration - around 5 minutes total averaging time. Do three times for comparison.
- extlw:cherenkov 3.12 +- 0.07Hz, 3.12 +- 0.08Hz, 3.11 +- 0.07Hz
For a trigger, I used the lab table camera trigger as it's easily identifiable, goes to the right place and is independent - ie no other things use that gate generator. Originally set to 'THRU' for camera as camera can add its own delay. Set to '10MS' on blue gate generator in middle of bottom NIM bin and fiddle screw beside knob to adjust while looking at output on software. Adjust to maximise measured energy.
- SLink, original method, 2.93 +- 0.49Hz, 2.72 +- 0.23Hz, 2.74 +- 0.26
The SLink spews out zeros as fast as it possibly can - terrible design - and the vi simply evaluates to see which ones are non-zero and if they are, publishes them to the rest of the vi, and therefore to epics. It looks for the number of bytes at the port and reads out only that amount. If it reads out the wrong number, the value could be misinterpreted or missed entirely. Therefore, try a fixed number of bytes - doesn't wait to receive the full number - every time.
- 500 bytes (guess from monitor its normal readout - no readout at all
- 600 bytes - works a charm!
- SLink, fixed byte method, 3.12 +- 0.08, 3.09 +- 0.08Hz, 3.10 +- 0.09
Also, laser was still warming up while I started this, but seems to be close to the right temperature now - 87.1, 87.3 ideal. However, it seems really quite stable since the tuning to the seed made it more stable.
- 100 pulse log to record this performance 20130228_1457_log.dat
- Values are automagically multiplied in analysis software because use of an attenuator is assumed. Real values approx 16mJ here
- Energy: 76.36 +- 0.77mJ -> around 1% stability - this is almost too good - will verify with handheld energy meter
- I did check selecting different pulses and the energy did change as well as blocking the laser and reading out zero several times...
- Energy meter readouts out 16.4 +- 0.3mJ - around 1.9% so not too dissimilar.
Energy Readings using Slink
Current Method - Solo2 Handheld beside chamber
Ran laser downstairs and up to high energy (as it has attenuator on it). Tweaked up green while I was doing this anyway.
- Solo2 handheld, 3.07 +- 0.10, 2.98 +- 0.45, 3.06 +- 0.12, 2.98 +- 0.44
Try setting trigger level to 3.0% vs 1.0% before.
- Solo2 handheld, 2.98 +- 0.23, 2.96 +- 0.20, 3.05 +- 0.05, 3.04 +- 0.09
Ok, seems to be a little better, but it doesn't trigger if the laser drops out and the value is just repeated in the data because the PV never updates. Also, it crashes about once every two hours - more so recently - bringing up a serial read error. Simply clicking ok makes it continue without crashing fully so seems a bit of a stupid error if it can keep going.
It would seem better to install the SLink to measure the energy.
Also, with Solo2 handheld meter, checked syncrhonicity / latency. It's about 120ms on average which should mean that it's caught at the right time in our data as the cbpms are usually 150ms after extlw:cherenkov. However, it is close.
Solo2 Handheld meter publishing times
Take 1000 pulse log while changing laser energy to get better correlation.
Actually, this isn't such a good way to do things. Changed scanning script to include laser - woo!
But we really need is energy as a function of laser photodiode to linearise the laser photodiode signal. Still need to come up with a function for this that can be reliably fitted.
Anyway, this isn't too bad just now, but should be even better with the SLink energy meter.