Yes you can buy faster hardware. Compared to the area of science I came from your new chip is molasses.

If it isn't a flash ADC in the GHz range it's slow. Big experiments also handle incredible amounts of data.

The Atlas experiment at CERN discovered the Higgs Boson. Atlas digitizes 40,000,000 events per second and each event has 1.6 MB of raw data. That's 64,000,000,000,000 bytes per second.

This data is processed by fast hardware in real time and most is discarded. Atlas only records 320 MB/sec, one event in 200,000.

The first level processing has 72 racks like this:

I record 100 KB/sec in my sketch, a factor of 3,200 less.

All of this little use to the average hobbyist. I find few takers for my fast AVR logging programs.

The typical email I get asking about fast logging is for something like an accelerometer with three channels at 1000 samples per second. Most hobbyists don't realize that digitizing all channels of an event at the same time and at precise time intervals is key to good data.

Here many of the STM32 chips have something to offer. Some of the STM32 chips have three ADCs that can be trigger at the same time.

The single ADC in AVR chips make it impossible to digitize multiple channels properly. You can use several self-clocking external ADCs to do much better.

I like playing with the AVR because it is a challenge to do good measurements. I did a lot of work on this sketch to reduce jitter and signal to noise.

I start the ADC on a timer compare event, not an interrupt. I make sure the timer triggers at a multiple of the ADC clock period. This reduces time jitter. I use DIDR to disconnect the pin's digital input. An analog input floats all over the place, and causing the digital input to constantly toggle high and low. This creates excessive noise near the ADC.

..in early '93 I spent some time at DESY, walking through the underground pipe, touching all the detectors.. The beam was off, of course I would be happy to see LHC as well.. Even Desy and Hera were monumental gadgets, so I cannot imagine the size of the LHC detectors.. That is one thing I would be curious about - the detectors and the input ADCs etc. I guess the events are something like nanosecs events (pulses) coming from semiconductor detectors (at least desy had it) you have to catch and S/H for further ADC..I built a homemade detector with PIN diodes and a preamplifier, so I get needle shaped pulses 5-200mV++, ~10-50usecs long, random of course (5 to hundert a minute based on irradiation). Since then I am thinking about how to make a spectral analyser (a histogram with energy bins) with an MCU. I have to detect the pulse (ie. comparator), then catch the amplitude, then ADC it.. I've been thinking on direct sampling the signal at ie 1MSPS and to do the analysis of the data on the fly so I must not mess with analog stuff.. Would be interesting to see the spectra of various sources then

At 100 ksps I must clock the ADC at 2 MHz so the above test says I get an ENOB of a little under 7.5. Not too bad since I am recording 8-bit data.

The Atmel spec says you won't get full 10bit accuracy above 200 kHz ADC clock, nor below 50kHz. The site from which you pulled the graph shows that the hit from running beyond the spec is not as bad as one may imagine. Though I have not has the time to see what is really meant "effective" in ENOD. It's some statistic that needs to be understood before jumping to conclusions.

A major problem is that adc clock is a binary sub multiple of system clock meaning the only in spec possibility is the default arduino which is not that high. (circa 75kHz IIRC)

Changing the main clock has knock on effects in library routines like millis() and probably on SPI timings etc.(ie downloading a sketch to Arduino) Needs to be done with care.

Clearly if you are only looking for 8bit data the spec sheet range is not applicable, you can sample quicker but don't forget all the errors in a single 8 bit reading. Probably +/- 2LSB

I'm also working at getting a fast ADC logging to SD.

Could you give more details about your "experiments" an what you found?

When I made a multichannel digital delay line in 1985 (12 bit sampling at I forget what speed, storing in SRAM, reading back out after a delay time, mixing the 4 channels of delay with opamps and feeding some back to the input for fadeout, all data done in parallel) I experimented with what sounded good by ear for the filtering to use. All wirewrap, LS logic, ran kinda warm! I've thought about redoing it with a menu for selecting stuff vs read out of values on 4 7-segment displays, and PCB vs this big wirewrap card.All done in software these days (and back then even) with high speed processors and different hall/room effects, so kind of a moot point, but an interesting project none the less.