Skyline currently does not report any numbers related to the asymmetry of peaks, but I am supposed to implement this new feature in the next version of Skyline (which will probably be released in about six months):
https://skyline.ms/issues/home/issues/details.view?issueId=812

I do not understand your question about lock spray stability but I think someone else will probably be able to give you an answer about that.
-- Nick

1. Thanks you, that's great news!

2. I mean, for Waters Xevo data acquired with a lock mass compound for mass drift corrections, can we see the TIC of the lock mass channel, or see the peak areas of the lock mass (e.g., leucine enkephalin at m/z 556.2771).
Since Skyline accesses the lock mass data to correct the acquired raw data, i was wondering if it can also present the lock mass data somehow.
I tried adding the lock mass to the transition list, but it didn't work.

Hi Natalia,

Actually, lockmass correction isn't done by Skyline - it's handled in the DLL that Waters provides for use in the ProteoWizard library used by Skyline (and msconvert and SeeMS etc). ProteoWizard actually goes to quite a bit of trouble to make sure that the lockmass channel information doesn't get presented to the applications reading the raw data since it's not experimental data per se.

There might be a Waters-level way to trick the system into presenting that as experimental data (copying it to another channel, maybe?) but I don't know. (That's why we use the ProteoWizard library, we don't want to have to know the details of each MS vendor's proprietary format.) But even then, it would be presumably be presented to Skyline in lockmass corrected form, so we wouldn't learn much from it.

It's a clever idea to use the lockmass channel as a full time system suitability element, though, so arguably ProteoWizard's current view of that data as something to be left behind is worth reexamining. I'm not sure exactly now much work that would be on the ProteoWizard+Skyline side, nor how much would involve asking Waters for changes to the DLL they provide.

One thing you could do, I suppose, is make sure that lockmass correction is not applied at runtime (i.e. the raw data is left alone for later correction rather than recorded with correction applied, which is an option I think), then import a run into Skyline twice - once with lockmass correction and once without, and compare the results of m/z's other than 556.2771.

Not exactly the answer you hoped for, I"m sure, but I hope it is at least helpful.

Best regards,

Brian Pratt

Thank you, Brian!