Xcalibur improbable s/n values

[Tony]

Hi,
We use Xcalibur for targeted peak detection and integration for both GCMS and LCMS data. One thing that always bothers me is that the s/n values returned by the default integration algorithm (ICIS) always returns a ridiculously high value - e.g. in the order of 100-1000 when visually looking at the extracted ion chromatogram I would say it's in single figues or even noise! The older algorithm (GENESIS) seems to fare better, but is not as good at peak finding. Does anyone have any advice on how to get a realistic s/n value out of Xcalibur? I've tried many, many different combinations of the peak detection settings....

Failing that, is there any third party software I could import a chromatographic trace into (i.e. RT vs Instensity as a txt file exported from Xcalibur) to get an independent s/n estimate?

thanks
Tony

[lmh]

I'm afraid I have to agree that Xcalibur's noise calculations are completely unfriendly, and it's worse than you've described, because even within just one of the integration algorithms supplied, you can get very different S/N values depending on further settings, and there's little explanation why.

For one typical peak (albeit in an unreasonably peak-filled chromatogram) I get the following:

Genesis 61 "peak to peak" or 220 RMS
ICIS using INCOS noise algorithm 18886 or 28280 RMS
ICIS using repetitive noise algorighm 349 or a 15-digit number(!) as RMS

I can't find any information on how Xcalibur defines S/N in its various algorithms, and in the absence of any clue, I treat the values as a relative indication of how a sample or peak is doing compared to a known good peak, rather than an absolute meaure of anything.

Personally, though, I get on well with Genesis, which I thought was newer than ICIS?

I'd be grateful for others' experience, and help if anyone knows how Thermo define noise?

[pfranco1]

This is an answer I got from someone from Thermofisher's customer support (I wanted to know how their S/N is performed--> algorythms are patented and therefore "top secret"):

“The process of magnifying the baseline gives an overestimate of peak-to-peak noise.

The signal to noise algorithm gives your choice of a better estimate of peak-to-peak noise or an estimate of rms noise. The exact formulas and algorithms we use are proprietary, but I can explain the concept.

In the MSMS experiment, noise 'blips' appear very infrequently. The rest of the time there is no signal at all except when your peak is eluting. This is a difficult kind of noise to measure.

Most signal-to-noise algorithms will average the background signal over a portion of the baseline to get an average peak-to-peak noise value. If we choose to do an rms calculation, we will instead calculate how wide a band includes most of the data points. Either one of these is a sensible approach when there is noise at every time point. However, let's imagine doing this in the MSMS situation I've just described.

Imagine we have a chromatographic peak that gives 100 counts at its apex. Now imagine we have a single noise spike in the baseline that gives 1 count. If we magnify the baseline, we will conclude based on that single spike that we have a signal to noise value of 100:1.

If we average 10 points in the baseline (including the noise spike), the average noise is 1 count/ 10 points, or 0.1 counts. Using this value for our peak-to-peak noise gives 1000:1 signal to noise.

Now if we add an rms calculation to the 10 points of baseline noise, we would wind up reducing the calculated noise to something normally between 1/3 and 2/3 of that 0.1 value. Now we have a noise value of somewhere between 0.0333 and 0.0666, giving a signal to noise value of somewhere between 3000:1 and 6000:1.

You can see why different approaches to signal:noise calculations are going to give very different values under the extreme condition where there is almost no baseline noise, even if they might give similar results under more typical conditions.

This is why we expand the baseline in the system test procedure: so that we apply the most stringent possible test, so that the customer can be satisfied whether the software algorithm makes sense to them or not.â€

[lmh]

Thanks for posting that, pfranco1. There are two thoughts that spring to mind:

(1) If Thermo won't let on how they calculate S/N, then their values are unfortunately unusable in standard procedures that demand a particular S/N, since we can't be sure they've been calculated in the way envisaged by whoever defined the procedure.

(2) The difficulties your Thermo friend described are exactly the reason why S/N is (I think) troublesome in the context of SRM experiments on many instruments.