Your problem is probably the polarity switching. I suggest you try splitting to two files when you do the conversion of your raw data. You should be able to do that with the polarity filter in msconvert.
Without knowing what version of XCMS is running on XCMS online it is probably impossible to guess. If you can get that info and are sure all settings are 100% identical then maybe @johannes.rainer have some idea what change there could be.
A quick suggestion: I think mzdiff should be left at the negative default. Otherwise it does not allow overlapping peaks as far as I know. Maybe peakwidth need to be lowered. Your peaks are less than 10 sec.
If that doesn't work you need to understand if the grouping is merging them. Look in peaks() if there are multiple peaks per sample.
You are looking at tic in masslynx but BPI in mzMine. The spectrum looks weird. Like it is the wrong spectrum. I think the scan numbers could be offset. I suggest doing EIC of for example 195 so you are sure which scans actually correspond.
You have 106,874 features. That is an insane number. About 10 times what I think is reasonable to get. CAMERA chokes trying to build a network between all these features. With 800 pseudo spectra after the first CAMERA step you have an average of ~ 1000 features in each group. Some group might be much larger. You should focus on understanding why you get so many features. It looks like peak picking issues since each sample have a very high number of peaks. Check the sanity of your settings. On the top of my head these are the things that could lead to that: 1) too low ppm (split peaks) 2) too low allowed minimum peak width (spikes could get picked) 3) too low allowed maximum peak width (split peaks) 4) No prefilter or too liberal settings (picking noise) 5) noisy data in general 6) contaminants with persistent presence together with liberal settings 7) Continuum mode data instead of profile mode data (important!)
No it doesn't sound like IMS is to blame to me. Ideas to check: 1) decent number of scans per peak? 2) the data is centroided? 3) peak picking settings makes sense?
To centroid a whole file or a set of files you use "Tools" --> "Accurate mass measure" --> "Automatic peak detection" from the main windows of masslynx. The new set of files will have the files centroided (be sure that your originals are not already centroided) but you still need to check the accurate mass issue.
You can start by trying converting your centroided files with msconvert (to mzML since that is the newer format) without any special parameters. If that doesn't work try the lockmassRefiner filter. Remember to use the scanEvent filter when you use msconvert. It is by far easiest for your down-stream work to have each scanEvent (function in Waters language) in separate files.
The way to check if things worked is to open the centroided raw file in masslynx and open a few ms spectra. Then you open the extract same spectrum in for example mzMine (the mzML file of course). Check a few masses. If they are exactly the same to at least 4 digits you are OK. If not you probably got uncalibrated data. Do this with a few scans just to be sure.
Regarding the cdf files. They should always be correct regarding the masses but you still need to centroid first.
I would say that 2.5 is almost certainly a bad idea... It needs to be true also for the edges of peaks to work well. I used 20 for orbitrap data and I remember that setting it significantly lower gave problems.
How did you convert the files? Do they show something sensible in for example MzMine? You might want to strip the IMS data. I have no experience with this but if you are converting with msconvert the scanEvent filter might be what you need. With Waters files I have also had good luck simpy deleting the IMS data file (the masswolf converter I was using would crash otherwise)...
A short gradient should make no difference as long as there is still a sensible number of scans per peak.