Oscilloscope and Logic Analyser

• The three controls that matter: timebase, vertical, triggerTimebase sets the horizontal window, vertical sets volts per division and offset, and the trigger decides which moment in time gets drawn. Most 'my scope shows nothing' problems are trigger problems, not signal problems.
• Triggering is a deliberate actEdge trigger on a specified level and slope is the default. Beyond that, pulse-width triggers catch runt pulses and glitches, and single-shot capture is the only way to see a one-off event. Auto mode free-runs and will happily draw noise as if it were a signal; Normal mode draws nothing unless the trigger condition is genuinely met, which is more honest.
• Bandwidth, sample rate and aliasingA scope's analogue bandwidth is where a sine wave is attenuated by 3 dB. Rise time you can measure is roughly 0.35/BW. Sample rate must exceed the Nyquist rate or you will see convincing, entirely fictitious low-frequency waveforms.t_rise(measured)^2 = t_rise(signal)^2 + t_rise(scope)^2. Scope t_rise ~ 0.35 / bandwidth.
• Probes: 10x, compensation, and the ground leadA 10x probe divides by 10 but raises input impedance and lowers capacitance, which is why it is the default for anything fast. It must be compensated against your scope with the built-in square wave. The long crocodile ground lead adds inductance and turns fast edges into ringing that is not in your circuit — for edges faster than a few nanoseconds, use a ground spring at the probe tip.A 15 cm ground lead adds roughly 150 nH, which rings against the probe's ~10 pF at about 130 MHz.
• Logic analysers see many channels, one thresholdA scope shows you the analogue truth on a few channels; a logic analyser shows you 8, 16 or more channels reduced to ones and zeros against a threshold. Use the logic analyser for protocol and timing relationships, and the scope when you suspect the analogue shape is the problem.
• Protocol decodingBoth PulseView and most modern scopes can decode UART, I2C, SPI and more from raw edges. Decoding turns 'there are wiggles' into 'the device NAKed address 0x48', which is the difference between guessing and debugging.

ProblemAn I2C sensor at 400 kHz occasionally fails to respond, maybe once every few thousand transactions. How do you capture the failing transaction?

1. 1
   Free-running edge trigger will show you thousands of good transactions and you will never see the bad one. You need a trigger that fires only on the fault.
2. 2
   Characterise the fault: a missing ACK means SDA stays high during the 9th clock pulse of a byte. That is a specific, triggerable condition.
3. 3
   Option 1 - protocol trigger: many scopes can trigger on 'I2C: missing ACK'. This is the direct answer if your instrument supports it.
4. 4
   Option 2 - timing trigger: if the failure causes the transaction to take longer, trigger on a pulse width or a timeout on SCL.
5. 5
   Option 3 - firmware assist: have the microcontroller toggle a spare GPIO when its I2C driver returns an error, and trigger the scope on that GPIO. This is nearly always the fastest route and works on any instrument.
6. 6
   Set Normal (not Auto) trigger mode and Single-shot acquisition so the capture stays on screen when it fires.
7. 7
   Set the timebase so the whole transaction fits: a 9-bit byte at 400 kHz is ~22.5 us, so a 100 us window with the trigger positioned at 70% gives you pre-trigger context.
8. 8
   Probe SCL and SDA with 10x probes and short grounds. Add channel 3 on the error GPIO and channel 4 on the sensor's supply rail — a supply glitch is a common cause and you want it in the same capture.
9. 9
   Capture, then use the protocol decoder to read the address and data of the failing transaction and the transaction immediately before it.

AnswerTrigger on a firmware-asserted error GPIO in Normal/Single mode, capture SCL, SDA, the error flag and the supply rail together over a 100 us window, and decode. The supply channel is the one most people forget and it is often the answer.

Tool: PulseView (sigrok) with a low-cost logic analyser

• Install PulseView (GPL). Any inexpensive 8-channel FX2-based logic analyser works, as do many entry-level USB scopes; check sigrok's supported hardware page.
• Connect at least: the bus signals you care about, and a ground. Ground first, always.
• Open PulseView, select your device, and set the sample rate to at least 10x your bus clock — for a 400 kHz I2C bus, use 4 MHz or higher. Undersampling here is the single most common mistake.
• Set the sample count to cover the event you want. Start generous, then narrow.
• Click Run and capture. You should see edges. If you see flat lines, check the threshold voltage setting and your ground.
• Add a decoder: click the decoder button, choose I2C (or UART/SPI), and map the decoder's SCL/SDA inputs to your captured channels.
• The decoded row now shows START, addresses, R/W bits, data bytes and ACK/NAK. Zoom into one transaction and read it byte by byte.
• Stack a second decoder on top of the first: for example, put an 'I2C -> specific chip' decoder over the raw I2C to get register names instead of numbers.
• Save the capture (.sr file). This is a shareable, replayable artifact — attach it to bug reports rather than a photo of a screen.
• Use the cursors to measure the actual SCL period and confirm it matches the configured bit rate.

• PulseView user manualopen licencedoc~60 minRead the capture setup and the protocol decoder sections. The decoder list on the sigrok wiki is worth skimming to see what is available.
• EEVblog - oscilloscope tutorial seriesfreevideo~120 minSearch for 'oscilloscope tutorial' and 'probing'. The probing and ground-lead-inductance material is the part that changes your results immediately.
• Keysight / Tektronix free 'XYZs of Oscilloscopes' primersfreereference~90 minA genuinely good vendor primer, free PDF. Read the trigger and probe chapters carefully.
• sigrok decoder documentationopen licencedoc~30 minThe full list of open-source protocol decoders. Find the ones for the buses you use and read their options.

Produce a measurement report on a running digital system: capture a serial bus, decode it, verify its timing against the specification, and demonstrate one probing artefact you created and then eliminated.

Deliverables

• A PulseView .sr capture file of a real bus (I2C, SPI or UART) from any device you have — a sensor breakout, a USB-serial adapter, even one microcontroller talking to another.
• A screenshot of the decoded transaction with an annotation explaining what each field means, and what the device was actually being asked to do.
• Timing verification: measure the actual clock period, the setup and hold times of data relative to clock, and any required bus timing (for I2C, the start/stop setup times) with cursors. Put these in a table next to the specification limits from the bus standard.
• A probing artefact demonstration: capture the same fast edge twice, once with a long crocodile ground lead and once with a short ground spring or a very short ground wire. Show both waveforms and quantify the ringing frequency and amplitude difference. Explain the ringing frequency using the ground lead inductance and probe capacitance.
• An aliasing demonstration: capture a known signal at a sample rate below Nyquist, screenshot the fictitious waveform, then capture correctly and show the truth. State the sample rates used.
• A one-paragraph statement of what your instrument cannot see (bandwidth, sample rate, channel count) and what that means for the kinds of faults you could miss.

Acceptance criteria — how you know it is good enough

• The capture decodes cleanly and the student can explain the meaning of every decoded field.
• Timing measurements are taken with cursors and compared against real specification numbers, not eyeballed.
• The ground-lead artefact is demonstrated with two captures and the ringing frequency is estimated from L and C, landing within an order of magnitude of the measured value.
• The aliasing demonstration shows a clearly wrong waveform and the correct one, with sample rates stated.
• The instrument's limits are stated in numbers.

If you want to push further

• Write a custom sigrok protocol decoder (Python) for a device-specific register map layered over the stock I2C decoder.
• Capture the same bus with both a logic analyser and a scope simultaneously and identify a signal-integrity problem visible only on the analogue trace.

• I can set up a trigger deliberately to catch a specific event rather than free-running.
• I use Normal and Single-shot modes when hunting intermittent faults.
• I compensate 10x probes and I use short ground connections for fast edges.
• I can explain and demonstrate ground-lead ringing and aliasing.
• I can capture and decode a serial bus with open-source tools and read the result.
• I verify bus timing against the standard's numbers with cursors.