Laser logs can save a lot of time when setting up selections in iolite. Rather than painstakingly reviewing each bit of data and assigning it to a selection/group, the time stamps in a laser log and the analysis annotations can be matched up with mass spec data to automate this process. Usually this works great. However, there are certain combinations of instruments that just cannot seem to agree on the timing, and when this happens it can be very frustrating as what should take seconds is now taking minutes or even hours!
When a laser log is synchronized in iolite using the normal procedure (i.e. via the import log button and subsequent dialog), the laser log in its entirety is synchronized with the data using an algorithm similar to the one below. That means if the laser computer and mass spec computer do not agree on the timing, the two may be not always be in sync, and how they differ may not be predictable. This results in automatic selections starting/ending before/after they should and, more importantly, inaccurate and/or imprecise results without manual intervention. An example is shown below where the laser log has been optimally synchronized with the data, but certain analyses do not line up.
Synchronizing two signals
The task of synchronizing the laser log and the mass spec data boils down to working out the crosscorrelation between the two. Usually, the laser log is represented by a square wave with ‘up’ and ‘down’ events corresponding to the laser ‘on’ and ‘off’ events recorded in the laser log, and the mass spec data is represented by the TotalBeam (sum of all input data).
There are, of course, many ways to accomplish this task in practice, one of which is included below (copied from here) and is very similar to the C++based implementation used internally by iolite. This approach employs numpy‘s speedy fast Fourier transform (fft) routines and some fancy math to work out the time offset between the two signals much faster than a more verbose and nonmathematicianreadable implementation (e.g. using numpy’s correlate function).


For those interested in experimenting with synchronization in iolite, the above bit of python code is a good starting point. If instead you do not care about the synchronization details, but just want to get it done, you can use a helper function included as part of iolite’s python API:


Getting and manipulating the required data
iolite’s python API (introduced here and mostly documented here) provides everything we need to get the required data, synchronize, and update the laser log samples. Note: setting laser log sample start/end times via python is only supported in iolite v.4.3.10+.
Channel time and data can be access as:


Laser log samples can be accessed and manipulated from iolite’s python API as follows:


The methods available for QDateTime objects can be found here.
Synchronizing individual laser log samples
Putting it all together, we can optimize the synchronization of each individual laser log sample locally using a script as follows.


Which, for the problem illustrated at the beginning of this note for OGC3, produces an adjusted laser log sample as shown below. New selections created from the laser log samples will now have improved synchronization.
And that’s it!
Click here to discuss.