The minimum delay is determined by the combined gate delays of all chips between the CH1 input and the sampling circuit. This is unit-dependent, and there isn't a useful way to calculate it. The easiest method is to simply try smaller delays until you receive an underflow warning (as you've done).
Could you explain the actual hardware/firmware mechanism in further details which sets this warning? Block diagram of that area of the hardware design?
Essentially, the entire delay generator is looped back on itself to form a ring oscillator, and we measure the period to verify the delay. If the calibration is still valid, this should be correct to within 1 ps. If it differs from the target by more than 2 ps, the warning is issued.
If the requested delay is too small, the delay generator will clamp to its minimum delay. This will be caught by the above check, but where this occurs is subject to process variation.
For keeping the unit up to date, I would suggest anything that effects the performance of the scope, automatically send it. I'm not concerned with the cosmetics. If you do decide to start including probes, I suggest sending these out to reviewers as well.
We'll ship you an updated case by EOD tomorrow. Probes are quite far from production, but we'll keep you updated.
Besides decreasing the sampling resolution, is there a way to speed up the sweeps while reducing performance? What limits the sweep rates?
I have not yet measured it but it seems pulling all four channels vs one makes little difference. Same with reducing the number of CDFs. Would adding a mode where you tell the firmware/hardware to sweep a range and just have it stream the data back rather than requesting each delay, speed up the process? I'm not thinking small changes in sweep times but 10X, 100X faster.
If do decide to go after some sort of auto setup mode, it would be nice if it not only set the vertical and horizontal but also the trigger level. I have not attempted to automate this myself.
First, there is the theoretical minimum time needed to take the CDF samples themselves. At 40 ns holdoff, with 20 samples/CDF and 100 triggers/sample (which would give degraded but still "acceptable" performance), this is 80 us per point, corresponding to 12 kCDF/s.
There is a fixed minimum overhead per sample due to FPGA/DAC communication, analog settling time, and MCU processing time. With some optimization, this can be brought down to probably ~10 us per sample, so ~200 us per point.
Then there is the time required to set a delay. Right now this takes ~8 ms, and gives a precision of ~0.1 ps @ 20 ns delay.
We can cut this down to ~50 us by skipping the verification step. This will substantially degrade the ENOB.
Combining the above, this limits the speed to ~3 kCDF/s.
Each CDF requires 60 bytes. Given the 921600 baud rate, this limits the speed to 1920 kCDF/s. Many of the CDF entries are strictly-speaking, redundant, and with pruning we can probably achieve 3 kCDF/s.
The current speed with default settings is ~50 CDF/s. This will take some time to develop, but a factor of ~100x is possible, with degraded noise and jitter performance.
I checked the Signal Path channel yesterday to see if he had his review up yet. I keep postponing mine as you are making so many improvements in such a short time, by the time I release a review, it would be obsolete. I would have a different view if you were not using the feedback I am providing and working at such a rapid pace.
We appreciate the amount of feedback you've provided, and the time you've put into testing the scope. Keep in mind that we won't stop improving the product for the foreseeable future - be careful not to postpone the review indefinitely.