Triggering not reliable.

Hi, I connected the internal square wave source up to channel A, and set it to a >V threshold. It seems to work fine, but depending on the time base, and the precise threshold level, it doesn’t trigger at all!

Here it is working:

And if the only thing I change is the time base, then triggering completely stops:

That can’t be right! Also, if you then scan the threshold up through the voltage range of the square wave, it only triggers at certain parts of the range. It doesn’t seem stochastic; it either reliably triggers with a certain setting, or doesn’t trigger at all.

Edit: This also appears to only occur below 1us/div timebase (i.e. 0.5, 0.2, 0.1 us/div). The trigger also does something even though it never updates the screen, because the ‘none’ trigger mode looks as you’d expect, but ‘auto’, when it is on a dodgy threshold level jumps around looking crazy like this:

I’m using a new DSO Quad with the latest firmware (well I think it was new; the seal was broken and there’s a minor scratch on the screen – bought from – perhaps they just upgraded the firmware).

Anyone know of a reason why this triggering is unreliable?

Actually it seems it doesn’t depend on the time base. Triggering is very unreliable in a number of situations. Please can someone confirm this behaviour?

Can someone comment? Or is there a more direct tech support channel than this forum?

I have had similar experience with faulty triggering on the Quad no matter what version of software.

If you look up the latest DSO NANO (1-channel) firmware update by BenF, that update user guide touches on what is wrong with the factory Nano and quite possibly the factory Quad triggering code. BenF fixed those problems in the DSO Nano updates and it is unfortunate that the Quad factory updates have failed to address this issue. The Quad triggering only works properly for the simplest of waveforms and the reasons are most likely similar to those described by BenF for the DSO Nano factory code.

Bottom line, the problem is not your problem alone, and it needs to be fixed in the triggering firmware.

Hmm interesting, but I’m not 100% sure it is the same issue which is described in BenF’s guide to his firmware. He says triggering is unreliable because acquisition isn’t continuous, so rare signals such as digital packets or ignition systems might be missed.

However, in my case it doesn’t trigger even for a continuous square wave. Any acquisition (unless it is insanely short) will contain a trigger. I could be wrong though. I really hope it can be fixed in software…

I have just had this problem too and found this thread:
Will report back if it fixes it.

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)

Quad catches one pulse in every couple of seconds, let’s say, 1 pulse in every 3s.

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.

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 :frowning:

The triggering issue is one of the first things I noticed with the device. Makes it unusable.

triggering the biggest problem of this device

such trouble:


Confirm such behaviour. Can’t catch neither keyboard presses when sensing USART on 115200, SPI fails, etc etc. Makes the $200 totally unusable (guys, I’m not exaggerating! - YOU CAN’T SEE UART on this thing!). Someone from seeed please comment on this.

will you accept a return? I don’t need such an expensive toy.