Oscilloscope Triggering modes
Bean
Posts: 8,129
The side business I'm part of is developing a hobbyist instrument using the propeller.
The instrument has 2 scope channels and I'm working on the triggering code.
My question is "What triggering modes are useful / needed / wanted in a hobbyist environment ?"
Each channel already has:
Rising edge (low-high to trigger)
Falling edge (high-low to trigger)
Falling edge pulse (low-high-low to trigger)
High level (high to trigger)
Low level (low to trigger)
The edge triggered modes all have programmable hysteresis.
The triggering can be sequential (channel 1 must trigger, THEN channel 2 must trigger).
Here is what I'm considering adding, if it is worth my time:
Rising edge pulse (must see high-low-high to trigger)
Trigger Holdoff (don't trigger again until some time later)
Trigger delay (start capture some time after trigger)
Pre trigger (show data before trigger condition, right now only show AFTER trigger condition)
Count (trigger must happen N times before capture)
I'd like some feedback on if these would be useful or not. Or any other special triggering modes that might be useful.
P.S. The max sample rate is 1Msps so NTSC or anything like that is probably not possible.
Bean
The instrument has 2 scope channels and I'm working on the triggering code.
My question is "What triggering modes are useful / needed / wanted in a hobbyist environment ?"
Each channel already has:
Rising edge (low-high to trigger)
Falling edge (high-low to trigger)
Falling edge pulse (low-high-low to trigger)
High level (high to trigger)
Low level (low to trigger)
The edge triggered modes all have programmable hysteresis.
The triggering can be sequential (channel 1 must trigger, THEN channel 2 must trigger).
Here is what I'm considering adding, if it is worth my time:
Rising edge pulse (must see high-low-high to trigger)
Trigger Holdoff (don't trigger again until some time later)
Trigger delay (start capture some time after trigger)
Pre trigger (show data before trigger condition, right now only show AFTER trigger condition)
Count (trigger must happen N times before capture)
I'd like some feedback on if these would be useful or not. Or any other special triggering modes that might be useful.
P.S. The max sample rate is 1Msps so NTSC or anything like that is probably not possible.
Bean
Comments
Pulse Width , or some call it Window.
Trigger only when a pulse width is between a min and max value.
And of course the inverse of this when a pulse is wider or narrower than the min/max values.
Duane J
Of the ones listed, I'd suggest the following priority level:
1 - Pre-trigger
2 - Trigger delay
3 - Count
4 - Trigger Holdoff
5 - Rising edge pulse
With the exception of #3, which I have often wished for I have found these very useful for troubleshooting.
I think Duane hit on it ... "Pulse Width , or some call it Window.
Trigger only when a pulse width is between a min and max value."
In a High-Low-High trigger , set the duration that the Low pulse must be in order to be considered valid. Likewise for a Low-High-Low in setting the duration of the High pulse.
On some scopes you have a Video Sync Trigger that look for the color burst frequency.... if you could "dial in" a specific frequency to be used as a trigger that might have several useful advantages.
Beau,
There is a low-high-low already (falling edge pulse). Adding a high-low-high trigger wouldn't be too hard.
Some of the triggering methods (pre-trigger, pulse width, etc) may only work at a somewhat slower sample rate. Maybe 200Ksps. At 1Msps there is only so much processing that can be done.
Bean
Pre-trigger with variable delay I see is near the top of everyone's list. It is often possible to generate a strategically timed external trigger, and it would be nice for that to come into a separate trigger input, rather than using up one of the main channels.
Deep memory is always good. Will the trace data be confined to Prop RAM?
Oh, yeah I forgot about the basic single shot, normal, auto, stop modes.
The device also has a very basic 8 channel logic analyzer that samples at 6.25Msps and one of those could be used for an external trigger.
Right now the scope has 1000 word values for each channel, but there is a 10K buffer used for the logic analyzer. That would give another 5K points (or 2.5K for each channel) if the L.A. was not being used.
Yes, it is limited to the propeller RAM.
Bean
Triggering on video syncs to examine an entire frame or a specified line would also be useful, but rather more difficult.
-Phil
Bean
I would highly recommend looking at what was done on the open sourced software used in the:
Xprotolab by Gabotronics.
While it is somewhat limited in speed because of the tiny size it really does have a lot of capabilities.
It can operate as a Sniffer for RS-232, I2C and SPI interfaces.
One really nice feature would be if the scope could run as a tiny terminal display.
The Xprotolab operating as a sniffer almost does this but not quite as if just displays characters.
A terminal would at least need to be able to use CR/LF but some of the VT-100 courser ESC commands would be nice.
Duane J
Can you add Quad SPI SRAM for more storage, or does that bump the size too much ?
-Phil
Sounds cool. Is that using external ADC ?
What display does this have ?
One 'trigger mode' I think would be very useful is a hybrid of Scope and Logic analyzer.
That is a Pin-change time-stamp store.
This can then expand to allow Advanced Counter features, like Pulse Width, Time intervals, and even Frequency Counter.
It also has excellent dynamic range, and precision.
By storing changes, the memory can be better utilized, and ideally, you can stamp down to the 10ns fsys
Values are streamed to PC on a FIFO basis. Yes, there is some limit on edge rate, that will be a bit less than 6.25Msps, but the edge-store design has much better dynamic range.
( The simpler but faster clocked capture mode would still be there to cover a range or two.)
If you have room to map 1 COG to rise-tags and 1 COG to Fall-tags, then this can work down to 10ns Pulse width, for PWM duty style measurements.
Upper Freq limit is the time needed to capture and store patten/timestamp, and above that, frequency counter modes would be more useful. (I think for that 50MHz is the limit ?)
Examples of use :
Think you have the right Baud rate ?
Send any char (typically "U" ) to the capture and every edge is stored with 10ns precision
At 115200, you can check baud settings to close to 0.01%, enough to catch off-by-one slipups,
Developing one-wire code, and are not sure you have all timings a right ?
Send a packet, and check the edges.