Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extremely low TIC with Tune 4.0 + iAPI #41

Closed
t0mdavid-m opened this issue Dec 27, 2023 · 5 comments
Closed

Extremely low TIC with Tune 4.0 + iAPI #41

t0mdavid-m opened this issue Dec 27, 2023 · 5 comments

Comments

@t0mdavid-m
Copy link

t0mdavid-m commented Dec 27, 2023

We just upgraded from Tune 3.4 to Tune 4.0 and are observing very low TIC values when scheduling scans via the iAPI. This is shown in the screenshot below. At t=27.67 min. we stopped making iAPI calls and the method scans took over resulting in TIC at expected levels. The same iAPI calls worked with Tune 3.4 (although we previously observed slightly reduced TIC compared to Lumos Method scans).

image

Platform: Orbitrap Fusion Lumos Tribrid Mass Spectrometer + FAIMS Pro Interface

We are performing AGC scans to the IonTrap with the following parameters (Class=FusionCustomScan):

Running Number = 41
SingleProcessingDelay = 3
IsPAGCScan = true
PAGCGroupIndex = 1
Values = {
    "Analyzer" = "IonTrap"
    "FirstMass" = 500
    "LastMass" = 2000
    "ScanRate" = "Turbo"
    "AGCTarget" = 30000
    "MaxIT" = 1
    "Microscans" = 1
    "SrcRFLens" = 30
    "SourceCIDEnergy" = 15
    "DataType" = "Profile"
    "ScanType" = "Full"
    "FAIMS CV" = -60
    "FAIMS Voltages" = "on"
}

We are performing MS1 scans to the Orbitrap (successive to the AGC scans) with the following parameters (Class=FusionCustomScan):

Running Number = Incrementing from 41
SingleProcessingDelay = 3
IsPAGCScan = false
PAGCGroupIndex = 1
Values = {
    "Analyzer" = "Orbitrap"
    "FirstMass" = 500
    "LastMass" = 2000
    "OrbitrapResolution" = 120000
    "AGCTarget" = 800000
    "MaxIT" = 50
    "Microscans" = 1
    "SrcRFLens" = 30
    "SourceCIDEnergy" = 15
    "DataType" = "Centroid"
    "ScanType" = "Full"
    "FAIMS CV" = -60
    "FAIMS Voltages" = "on"
}

Note that we are using different CV values {-60, -50, -40, 0} with respective PAGCGroupIndex {1, 2, 3, 4}. Scans are conducted in the order AGC-MS1-AGC-MS1-.... with the CVs beeing equal for successive AGC-MS1 pairs.

The extremely low TIC values indicate that something might be blocking the ion path. Is there any further configuration required with Tune 4.0 that was not required with Tune 3.4?

@t0mdavid-m
Copy link
Author

t0mdavid-m commented Jan 8, 2024

We used the fusion-example-client to narrow down the issue to the source CID energy. When setting the source CID energy through Tune, it is provided in Volts. However, through the iAPI there are two parameters involved:

SourceCIDScalingFactor and SourceCIDEnergy

We intended to set this value to 15 Volts but setting SourceCIDEnergy = 15 with the default SourceCIDScalingFactor = 0.2 resulted in extremely high source CID, explaining the lack of signal.

Therefore, I would like to inquire how to convert these two parameters in to the source CID energy in Volts.

Thank you in advance!

@jesse-canterbury
Copy link
Contributor

There are a couple of things going on here. First, check the value on your instrument for the source offset. You can find this in diagnostics under Calibration->Calibration Device Settings->Edit Source Offset, and look at the "Normal" value. A typical number is 9V. To this number is added whatever you input for the source CID voltage (15V in your case). Then, the compensation scaling number is multiplied by the source CID number and subtracted from the total offset. In this example, the whole source offset is 9V+15V = 24V, and subtracting 0.2*15=3, the final offset is 21 V, somewhat lower than the value without compensation.

To turn off this compensation, set the scaling factor to zero. In fact, zero should probably be the default value instead of 0.2, so I will take that as a bug to fix for the next software version.

I'm not sure whether this squares with your observations, but I hope it's helpful for you. Thanks for the report!

@jesse-canterbury
Copy link
Contributor

The fix described above (setting the default to 0.0 for the source CID compensation scaling factor) is implemented internally, and will be deployed in the next Tune release. So I'm going to go ahead and close this issue. Feel free to reopen if you need.

@t0mdavid-m
Copy link
Author

Thank you for the quick response and fix! Setting the SourceCIDScalingFactor to zero indeed seems to resolve the issue.

Is setting SourceCIDScalingFactor=0 and SourceCIDEnergy=15 equivalent to setting the source CID energy to 15V via Tune? How does the source offset come into play here? This is important to us as we would like to make scans via the iAPI as comparable as possible to scans initiated via Tune.

@jesse-canterbury
Copy link
Contributor

The source offset is the initial potential of the whole source region, and sets the start of the "downhill" potential for guiding ions into the instrument. Without source CID turned on, it will be that value that you can find in "Edit Source Offset." It is typically set by the instrument calibrations. When you apply source CID, then whatever value you set there is added to that offset. The extra potential ("steeper downhill") is what supplies the additional energy for fragmentation.

So to answer your question, yes, setting the scaling factor to 0 and source CID energy to 15 via the IAPI is equivalent to setting source CID energy to 15V in Tune.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants