In my experience trigger reliability seriously depends on the timebase setting.
I’m trying to catch the acknowledge signal of a CAN bus running at 125kbps, directly at the Tx pin of the transceiver. It is a 5V TTL level, 8us wide negative pulse, repeating in every 10ms. (100Hz)
Quad HW 2.6, SYS 1.5, APP 2.5, FPGA 2.5, chn A, DC 2V, trigger mode normal, negative edge, threshold ~2V. (half of the supply)
0.1us-20us:
Quad catches one pulse in every couple of seconds, let’s say, 1 pulse in every 3s.
50us-100us:
Triggering looks continuous, curve refreshed at least 10 times per sec. In 50us, it freezes sometimes for approx 200ms, then continues. When sending the frames by hand, one at a time, it is obvious that at least half of the pulses are missed.
200us:
Excellent! Refresh continuous, no pulses missed in single shot. I wish I worked this way in all settings.
500us and slower:
Triggering gets more and more unreliable. In 500us, more than half of the frames are missed, above 10ms it hardly triggers, maybe once or twice in a minute.
The failure at slow timebase is understandable (however not acceptable): most probably the sampling frequency is too low (as the screen resolution is), most of the times the pulse is not sampled at all. Resolution: Quad should sample at its maximum speed when looking for trigger events. But I cannot understand why is it not triggering at fast timebase. It is expected to “see” hundreds of samples in the pulse. Bug!!!
Another problem:
I monitored the same signal, when the node was sending frames, one at a time. Quad was expected to trigger on the initial falling edge, scan through the frame, and then stop, waiting for the next trigger. Instead the frame flashed on the screen for a moment, and then Quad sampled a blank screen. It happens always. I was unable to set it to catch one frame and then stop. All other DSOs I’ve tried, including cheap chinese desktop scopes worked properly.
And a missing feature:
There is no “holdoff” option. You know, after finishing a sweep, Quad should be able to ignore further triggers for a configurable period. It is useful sometimes. And either megazoom, like in the Agilent/Lecroy scopes (Ok, I know, there is not enough RAM), or at least the digital emulation of a double timebase (you know, delayed sweep feature in the analog scopes) would be really useful.
Please try to fix it. At least, the triggering MUST be fixed. In this current form, it is simply unusable. You never know whether there is no signal, or the bus is working at 90% load, but quad fails to catch even one trigger 
