If you’ve tuned in on Electronic Design’s articles lately, you’ll know about a series by Mr. Colin Mattson on advanced oscilloscope triggering techniques. In the 1st article, he elucidates on pulse and pattern modes, where the characteristics of a pulse and the uniqueness of a pattern are utilized as the impetus of signal acquisition. In part 2, he delves into edge mode triggering, where the edge characteristics of a signal are used to mark the trigger for waveform capture. In part 3, he covers protocol triggering, where the patterns adhered to by a protocol (such as I2C and SPI) are detected. As of the time of writing, his readers still await his next article on sequence and software search triggering techniques.


A comment on one of his articles reads:

Email on trigger! I thought you were joking, but that’s an incredibly weird and fun capability. As someone who has spent a lot of time waiting for powerline transients to happen (or not), that’s a really nice idea.” – Ed Price


I, too, have not come across (directly) with an oscilloscope that is capable of sending an email wirelessly (IoT-mania?) after a trigger event. In my opinion, such a system would come at a hefty cost. At least, consider the operating expense, the wear-and-tear that’ll decrease oscilloscope lifespan, and the risk of false alarm. 


But a feasible solution to this problem is fun to think about. Perhaps a high-voltage detector would do nicely, its output interfaced to an LVS, then an Arduino hooked to a cheap GSM module (for text messaging) or an ESP8266 (for email). It would be more economical in terms of both money and space. Does anyone have any good ideas on this?


I’ve seen scopes that run on a Windows operating system, so it should be possible for a 3rd party to program the scope to send an email given a trigger event, out an Ethernet cable or Wi-Fi transceiver, if it can be ported to one. Speaking of all this trigger mechanisms, I’ve been pondering on the need for an oscilloscope trigger system that operates in the frequency domain. What if we wanted to monitor a signal that oscillates at a specific frequency, or is characterized by a particular set of frequencies, for a limited amount of time, in the time domain?


You may now be scratching your head thinking - wait, isn’t that the job of a spectrum analyzer? 


Well, not exactly. Even though the trigger is in the frequency domain, the waveform, will still be in the time domain. 


But how can an oscilloscope do that? There is a generic math function that displays the FFT of a signal, but it is implemented in software and thus, becomes impractical for real-time signals. A possible implementation is given below.







Figure 1 Simple flow of algorithm to be used in frequency domain triggering.




A real-time signal will be fed to a DSP implementing the STFT. The window’s length will be defined by the user and must not be shorter than twice the desired wavelength of the highest frequency [remember aliasing and the Nyquist criterion]. As the signal is fed to the DSP, the waveform is simultaneously sampled and stored in a variable-sized buffer depending on window length. At the output of the DSP, the frequency pattern is compared with a reference, also defined by the user. If the comparison is a match, then the scope will display the contents of the buffer. Otherwise, nothing is displayed on the graticule and the buffer is emptied and re-loaded. The sets of data that go into and out of the buffer must not be contiguous, but overlapping.


It sounds simple, but the real challenge lies in the entire system’s speed. Achieving minimal latency requires simplification, pipelining, and optimization at all levels of the design. Can I implement this portion of the system in hardware? Can I remove this portion of code that will go to the DSP without sacrificing accuracy? Can I pipeline this batch of data to this part of the STFT algorithm while the decision-making for frequency of the previous batch is on-going? In addition to these considerations, the answers are further limited by the famous trade-off with cost.


So, what is the trigger system described above good for? A possible application is in the analysis of sporadic interference and noise. Say, a portion of the board where a 200kHz data signal is supposed to be travelling, always ends up with a portion of its packet interpreted as garbage. Of course, given modern error detection and correction techniques, the chances that such a phenomenon will occur is slim. But if it is known that a source nearby, emits a signal with harmonics of 190kHz, 200kHz, etc., then we can program the scope to monitor for such signals and determine whether the sources are indeed the cause of trouble. The common method for this is the use of a spectrum analyzer, then determination of the location of noise source by triangulation.


In the end, all of the above may be a pile of wish wash thinking. But who knows, they may perchance serve as a cornerstone for another solution to another problem.