In Part 2 of this Q&A series, based on the EE Training Day, Ben Ellis, Technical Applications Engineer at Pico Technology, walks through mixed-signal debugging methodology, how to tailor oscilloscope data for different audiences, and when it makes sense to embed a scope into an automated production system.
Q: In the webinar, you walked through a mixed-signal example where a known I²C packet wasn’t producing the expected output. How do you approach something like that systematically?
A: The first thing I try to do is stop thinking of it as one big mystery and start treating it like a black box with inputs and outputs. You have something going on, in this case a known I²C packet from a debugger, and you’re not seeing the expected behavior at the output: an LED that should be turning on. So instead of guessing, you interrogate the circuit one step at a time. We traced back from the output toward the input. The I²C bus looked suspicious first, so we dug into that. Then we noticed the microcontroller was resetting sporadically; its reset pin was occasionally dropping. That pointed us away from the bus and toward the MCU’s power supply. Sure enough, the supply was dipping below the minimum required voltage, causing brownouts. Traced that back one more step and found a failed capacitor on the input. That’s the process: go back one node at a time until you hit the root cause.
Q: What tools made that chain of investigation practical?
A: A combination of the digital bus decode and the power integrity techniques from Part 1, really. The serial decode let us see what was happening on the I²C bus and rule it out. Then we used the same AC coupling and measurement approach to characterize the supply rail and confirm it was dropping out. What advanced tools give you in these situations is speed. On a simple system, yeah, maybe two quick probes and you’re done. But on a more complex one, being able to layer triggers, decode protocols, and log measurements simultaneously is what gets you to the answer in minutes instead of hours.
Q: Once an engineer has identified a fault and captured the data, how should they think about sharing it?
A: The biggest mistake I see is treating all audiences the same. Who you’re sharing with completely changes what you should show them. Other engineers? Give them the full waveforms. They’ll expect it, they know what they’re looking at, and that detail is exactly what they need to give useful feedback. A technical manager who’s somewhat familiar with the system probably just needs the key numbers: peak-to-peak, RMS, pass/fail, not a waveform they have to sit down and interpret. And a technician on a production floor, or a non-technical stakeholder, just needs a clear pass or fail. Each format has its place; you just have to pick the right one for the person in front of you.
Q: What about communicating urgency to someone non-technical, where a subtle anomaly is actually a serious problem?
A: That’s a real challenge. You can put up a beautiful waveform showing a tiny blip on a power supply, and a non-technical manager will think, ‘That doesn’t look that bad.’ So you have to translate it. Boil it down to the consequence, not the measurement. Say there is a fault, and I can prove it, but the point is, this will cause failures in the field. And if that still doesn’t land, talk about dollars. Recalls. Schedule slips. When you frame a 10mV anomaly as ‘this will cost us three months and a recall,’ people pay attention. A technical manager who understands the data can help carry that message, and sometimes it’s better to go into that conversation as a team.
Q: You talked about a real-world example with a pipe manufacturer where oscilloscope data fed directly into a production control loop. Can you describe how that worked?
A: Sure. They’re manufacturing pipe continuously: sheet metal comes in, gets rolled, welded, and cut to length. They needed a way to detect faults in real time and maintain traceability on every section that shipped. The approach was to monitor the current draw from both the induction coil and the electric welder as the pipe moved through. If the material is heating and welding consistently, those current profiles are stable. A deviation, say a thin spot in the sheet metal burning through or a section that’s not welding cleanly, shows up as a change in that current signature. Using the scope’s API, we can flag the fault, mark the section, and log the data automatically. Every good section gets serialized with the proof to back it up. In a medical or government application, that traceability isn’t a nice-to-have. It’s a requirement.
Q: I’m not a strong programmer. Is there a middle ground between the standard scope interface and a full SDK or API?
A: Absolutely. In PicoScope, we call it measurement logging. You set up whatever automatic measurements you want: peak-to-peak, RMS, phase, frequency, whatever applies to your signal, and the scope continuously writes those to a CSV in the background. So instead of trying to store and analyze eight hours of raw waveform data, which would bring Excel to its knees, you’ve got a manageable file of metadata about your signal. Pull that into a spreadsheet, build a histogram, and you can immediately see whether your signal is behaving consistently over time or whether something is slowly drifting. Taking Measurements one step further, we have Actions that can then DO something useful in reaction to specific criteria, such as a failed limit on a measurement. It’s a very accessible middle ground, and no programming is required.
Q: Why would an engineer choose an off-the-shelf oscilloscope over building their own data acquisition hardware?
A: It really comes down to where you want your engineers’ time to go. Yes, a capable team could design a DAQ system from scratch: ADCs, analog front end, firmware, calibration standards, the whole thing. But that’s a side quest, not the main quest. The scope manufacturer has already solved that problem, maintains calibration, provides an API or SDK, and stands behind the hardware. That engineer’s specialty might be medical sensors, robotics, or RF. Diverting them to build a DAQ is a waste of their talent, and it might cost you months of schedule. Buying the right off-the-shelf tool and integrating it can get you operational in days or weeks instead.