BoxFahrt-- BoxCar for people who can't alter their instrument software. Might even work!

EDIT 5/13/18: Please ignore this post. BoxCar is under testing and is coming to all of us soon! I'm only leaving this post here as a reminder to myself to think before I hit the "Publish" button -- and in case anyone wants to look at what the BoxCar RAW files look like to help understand the instrument method logic.

In my old neighborhood in Baltimore there is a hilarious race each year. It started as a soapbox derby, but due to all the artists and weirdos, it rapidly descended into chaos.

Now -- a bunch of people race down a hill riding old toilets.  I'm not making this up (proof) . Am I on the right blog? I am!

Okay -- so --- I was really really excited about BoxCar, then I saw a Tweet and blog comment that made me realize -- I can't natively multiplex >10 isolation windows in any Exactive Tune I have -and they use 16!!   I went to ProteomeXchange and got some of the RAW data -- and...umm... this is completely custom written software on the QE HF...ugh.... However -- I don't think doing something similar is impossible -- maybe I just have to make some compromises!

I've got the RAW files in front of me, a notebook, a pen that is a monkey with googly eyes, a tablet that thinks it is a Q Exactive HF -- working on this late at night -- so some ethanol might have made it into this espresso.

Time to build something that should simulate BoxCar!  In honor of  something very vulgar I said very loudly when I saw the .XML stuff where the instrument method is supposed to be - which made me think of the Toilet Derbies, I'm going to call this method BoxFahrt.

Disclaimers -- yo. if you've read this far and you think that I'm about to do something smart, shame on you. However, just to be sure -- no guarantees this will work, I won't have a chance to start testing it until at least Monday. But, don't you worry, I'll let you know how it goes.

First off, lets look at the RAW files from ProteomeXchange (you can get them here)  and try to diagnose what everything is doing (without trying to read the .XML used as an instrument file).

Using the plasma samples (smallest set at 3.6GB) as an example this is the method as I see it:

1) MS1 scan at 120,000 resolution from 300-1650
2) 16 BoxCar isolations with a 120,000 (?) resolution MSX orbitrap "full scan"
3) Same as 2, but with altered overlapping windows
4) MS/MS scans -- as I flip through the RAW file, it appears that we're looking at something realistically approaching a "Top5"

First question I have -- how important is #1? 3 MS1 scans at 120,000 resolution, even on the HF, is a lot of time. Let's assume it is important and I'll throw it in later. However --- my first attempt at BoxFart is going to be --

Step 1:  Set up MSX TSIM-ddMS2 runs (in this example 2)

In BoxCar, the authors run from 400-1200(m/z). BoxFahrt will do the same thing. To get this in 2 windows I'm going to need to do 40Da 80 (m/z) windows. If I do 3 x 10, it's going to be smaller isolation windows. For example purposes, I'm going to go with just the two here.  CORRECTION --80 Da windows.  Should be corrected in image above. 

Downsides of this way of doing things (BoxFahrt wasn't entirely meant to be a huge compliment or anything to this parody of a great method) -- if I set it up this way we're looking at the first round of MSX-t-SIM followed by the MS/MS scans selected from that Orbitrap scan. THEN we're looking at the MS/MS selected from the second round of MSX-t-SIM scans.

BoxCar appears to pick them from the two together, but I don't think that makes a ton of difference. The problem here may be the challenge in AGC control.

I don't have fine tune control over the AGC targets I'm going to be using. I can set just one number for BoxFhart. I'm going to say 5e5 and 20ms for my 40Da isolation windows

The logic behind my settings --

We know the QE family can handle 5e6 charges in the C-trap with limited ill effects (no reference, I just have friends who run above 3e6 for MS1 -- I'm sure there are references -- however, I've been working on this for a long time already and I'm getting sleepy.)

If we MSX 10 windows equally, that would allow us to run 5e5 ions per BoxFahrt window.
On a QE Classic or Plus, the 140k Scan is something like 512ms . That would allow us to have a Maximum IT per MSX-SIM of 50 ms, give or take (overhead is around 14ms -- so maybe shoot for 40?)
On the QE HF, 120,000 resolution is about half that. I'm erring on the side of caution and going to 5e5 and 20ms. It might be smarter to raise the target. Again -- this is where I'll start when I can actually have free time on our massively overworked instruments.

Now you need to build an inclusion list.

BoxCar alternates the overlapping windows. Please keep in mind that quad isolation isn't truly symmetrical on any quadrupole, but the Q Exactive classic is an older style (non segmented) quad and the isolation discrepancy on the edges is particularly steep off of symmetrical -- the QE Plus and HF have segmented quad stat are much closer to symmetric. The BoxCar paper goes into how to best deal with the quad isolation issues on the edges. Considering they use the HF -- just keep in mind that you might be looking at some loss in signal at the edges if you use a QE Classic -- or -- Fusion, to lesser degree, Fusion 1 systems.

What we need to do in BoxFahrt is build smart windows and (possibly -- can't say for sure yet) control our MSX ID #s(?)

Don't quote me on this (or anything I write here. that goes without saying, right?!?!) -- but I'd probably first try to run with no MSX ID filled in. If that didn't work great, I'll next put in some MSX ID numbers. Even with an MSX of 10, you can't put in #1 for all the ones in the first batch and #2 for all the ones in the second. I think, therefore, that this feature just allows you to keep your scans in order.

EDIT number 4,212: In older versions of the QE tune software (I definitely think up to 2.2) if I put in an inclusion list like the one below and walked away and came back to the method, I'd find that the list had reorganized itself in increasing order. I...believe....that this is no longer the case, but I've never verified. If you go here, I've put links to Planet Orbitrap where you can get the Vendor notes on Tune versions. If you are on an older version of QE Tune -- you'll have an issue setting up inclusion lists like this. You'll end up getting a 2 phase, over-complicated gas phase fractionation method. That might still work, but will be less cool.

I've spent way too much time on this last night and today -- so I'm going to stop here for now. I won't know anything until I actually try shooting some standard protein mixtures on an instrument or 5, but this is where I plan to start.  You'll note I started with a Loop Count of 5 -- in this setup this would be 5 from each MSX-TSim -- so we're really looking at a spaced out simulation of a Top10.

Honestly -- I think this is going to be easier to simulate on the Tribrids, but I'll probably leave this alone until I have some real data.

WAY WAY too much time spent on this the last 24 hours. Gonna have to save it and end here.

EDIT 5/11/18 later in the day:  What? I'm back to this. I want to address another reader comment -- if you did want to do BoxCar right what would you need?

I presume you'd need the API. You need to contact the vendor to get it, I think. It was on the BRIMS portal for a long time, but I don't think it's there now. The API is a Windows Visual Studio interface that allows you to completely control your Q Exactive.  Some really cool stuff can be done with the Q Exactive when you get the API.

Warning, though, it is a LOT of work to use. It is kind of a blank slate. I'd presume, however, that if you cut the instrument method text out of the BoxCar RAW data that it would have most of the things necessary.  There is a PDF talking about the API (directly opens from this link.)

More Edits late the next day:  I've heard, from a reputable source, a reputable sounding rumor that the vendor is investigating making BoxCar available to the rest of us. Some legal review needs to be done to see if distribution can be done. Stay tuned.

Also -- it was pointed out I had misspelled the name of my method repeatedly in the post. I have made these corrections.