Hi Lauren,

When setting the Resolving Power under Transition Settings > Ion Mobility, does this always reference the RP in milliseconds?

It's unitless, actually. Here's the text you should see when you hover the mouse over that control in Skyline: "Determines window size for ion mobility filtering in chromatogram extraction (for example, drift time): For resolving power R at drift time T, the width W of the drift time filter window centered at T is W = 2T/R". So T and W have the same units, and R has none.

I've tried creating a library with only CCS and another with only arrival times to test this but the resulting bounds of the filtered mobility bands appear to be the same.

Perhaps you didn't update the chromatograms with the Edit > Manage Results menu item after changing the library? Also, if your transition list assigned an explicit ion mobility value that will always take priority. Fell free to send an example .sky.zip if this isn't helping.

Thanks for using the Skyline support board!

Brian Pratt

Thanks for the clarification on the units, that makes sense.

I did not add an explicit ion mobility value in the target list and used results to generate an Ion Mobility library and deleted the CCS before saving the library applying the filtering by re-importing the data.
I then repeated the process starting with totally unfiltered data but this time deleted the arrival time form the library.
The bounds on the heatmap appear the same on both conditions as well as the resulting XIC.

Thanks!
Lauren

If I understand you, then this is to be expected.

When you Use Results to create an ion mobility library, Skyline looks for peaks in the IM dimension at the peaks in the RT dimension, then it uses the calibration stored in the mass spec file to come up with the CCS value for each IM peak. That calculation happens in the vendor API, it's a black box to Skyline - we just ask "for this mass and this measured ion mobility in this data file, what's the CCS?". The key realization here is that you can convert from IM to CCS and back to the original IM so long as both conversions use the same calibrations. That is, we can also ask "for this mass and CCS, what's the ion mobility in this file?" and expect a consistent answer.

So if you remove the IM values from the library, the next time you Import Results with that ion mobility library Skyline uses the library CCS values to ask the black box for the IM value. Since it's the same calibration, that will give the same IM as was used to calculate the CCS in the first place.

If you use that library with a different mass spec file containing a different calibration, the chromatogram extraction IM values will be different, which is at it should be. CCS is the ground truth, mobility is a function of CCS and a bunch of things we let the black box worry about.

So Skyline uses the library CCS value whether the IM value is there or not - CCS makes the library usable across different mass spec files with potentially different calibrations. We really only keep the IM value in the library for reference - or for use when there's no CCS for some reason, but that's uncommon.

If you do remove the CCS values from the library, then Skyline just uses the bare IM values for chromatogram extraction. But since in this case those are the same IM values that were used to create the CCS values, it amounts to the same thing.

I hope this makes sense?

Yes, this definitely makse sense, thank you!

I was looking to test whether the range set by the RP was different when using the Ion Mobility value in milliseconds vs the CCS. I think from your first answer we should expect it not to change but wanted to confirm that by testing.
I also tried using a target list with just an Explicit Ion Mobility value for one document and and just an Explicit Collision Cross Section (sq A) value for another and got the same results as the Skyline generated Ion Mobility Library. All of the mobility windows were the same for the same molecule (as expected).

Thanks for painting a clear picture of the filter!
Best,
Lauren