Live data from Hacker News

From Oscilloscope to Wireshark: A UDP Story (2022)

mattkeeter.com

21–30 of 35 posts

Re: From Oscilloscope to Wireshark: A UDP Story (2022)

#22

Could anyone recommend a budget tooling (has most features desired, please explain) to capture on wire like an oscilloscope. Help understand what kind of sample rates needed etc. features desired, cost and any recommended brand/models to get by. Thx!

The QSGMII signals in this blog are very high speed. Beyond the range of what you can measure with budget tooling. Even the probes for such lines are thousands of dollars.

There are some budget sampling oscilloscopes on the market, but budget is still mid four figures and up. That's before probes, cabling, and other things you'd need. Sampling oscilloscopes are only useful for repeating test patterns sent by SDK tools, not for capturing normal data as it goes by

It's possible to look at Ethernet signals with oscilloscopes in the budget range but you would need appropriate fixtures to tap the line. Even at those speeds, touching a regular oscilloscope probe on to a wire disturbs the circuit so much that it might stop communicating.

Re: From Oscilloscope to Wireshark: A UDP Story (2022)

#24

Could anyone recommend a budget tooling (has most features desired, please explain) to capture on wire like an oscilloscope. Help understand what kind of sample rates needed etc. features desired, cost and any recommended brand/models to get by. Thx!

The QSGMII signals in this blog are very high speed. Beyond the range of what you can measure with budget tooling. Even the probes for such lines are thousands of dollars. There are some budget sampling oscilloscopes on the market, but budget is still mid four figures and up. That's before probes, cabling, and other things you'd need. Sampling oscilloscopes are only useful for repeating test patterns sent by SDK tool…

At the other end of the scale, looking at classic 10M Ethernet signaling is perfectly doable with a sub-$1k scope, and 100M should also be fine with anything 500MS/s or higher. Note that Cat5 is rated for a bandwidth of 100MHz.

Re: From Oscilloscope to Wireshark: A UDP Story (2022)

#25
post #17

Earlier quoted context omitted.

I understand, but that's my point, it's not interpolated! The number he's referring to is in units of samples per second. It's not doing interpolation between samples, to achieve a high samples per second, because that's not possible, which is my point. Interpolation results in an imagined value, but samples are measured values. It would be correct to say that the values between samples are interpolated, but the subj…

Ah you are referring to the 'sps' bit. Ok, but I think the extra sentence is enough clarification of what they mean, even if they're wrong about what the device is doing. The only time these are interpolating is when they are visualizing, there is no point (hah) in storing interpolated data, you can generate that whenever you want.

Not the original reply, but I support the correction here. Regardless of how pedantic/nitpicking it seems, I remember getting confused about this a lot when learning digital signal processing. Simply because its really easy to upsample.. or look at an upsampled result and get confused by that

Re: From Oscilloscope to Wireshark: A UDP Story (2022)

#26
This reminds me of back in the day (1985) on my final year project, I'd designed a (6502 or 8080 based) SBC, my PCB design, my assembler and on first boot ... nothing happened.

With only a voltmeter in hand, I measured the voltages on the address lines - thankfully my dumb programming error was a very tight loop so it was easy to deduce where the looping was happening !

Some things were easier back in the day.

Re: From Oscilloscope to Wireshark: A UDP Story (2022)

#27
University professor here: showing and decoding wire signals has become a staple in my teaching - very effective, eye-opening even for students that find the OSI layers too abstract to grasp on paper. Btw, I’m using this nice demo board (I’m not affiliated with the brand): https://www.batronix.com/shop/demoboards/Batronix-MSO-Demo-B...

…typically we decode I2C.

Oh, I‘ve equipped the lab with all kinds of oscilloscopes. I find a lower mid-tier product (like Rigol DHO 900/1000 series) most suitable: good enough resolution and nice quality-of-life features (many physical buttons / dials and input channels go a long way!), yet not too feature-packed and physically compact to still be approachable.

Re: From Oscilloscope to Wireshark: A UDP Story (2022)

#28

University professor here: showing and decoding wire signals has become a staple in my teaching - very effective, eye-opening even for students that find the OSI layers too abstract to grasp on paper. Btw, I’m using this nice demo board (I’m not affiliated with the brand): https://www.batronix.com/shop/demoboards/Batronix-MSO-Demo-B... …typically we decode I2C. Oh, I‘ve equipped the lab with all kinds of oscilloscope…

Interesting.

Do you happen to know if that batronix board useful to have even if you have a Rigol DHO 924S without the logic probe (PLA2216)?

Re: From Oscilloscope to Wireshark: A UDP Story (2022)

#29
post #9

Earlier quoted context omitted.

But you can't use equivalent-time sampling for something non-repetitive like network packets.

For measurements like this the SDK will usually include some utilities to send the same data over and over on a port.

Even if it's the same data, the bit stream will be a variety of 0 and 1s. The period of that waveform will then be 1 frame length / data transfer rate (or rather 1/4 frame length / data transfer rate as this is a QSGMII link). I wonder how the scope triggers on that. Trigger criterium would be a bit pattern, say the Ethernet frame preamble of 7 octects (* 10/8) spread across four streams ...

Otoh, at 5Gbps, a sample rate of "just" 10GS/s would be sufficient (barely).

I rather suspect the oscilloscope is capable of 1TS/s equivalent time sampling, but that mode wasn't used.

Re: From Oscilloscope to Wireshark: A UDP Story (2022)

#30
post #25

Earlier quoted context omitted.

Ah you are referring to the 'sps' bit. Ok, but I think the extra sentence is enough clarification of what they mean, even if they're wrong about what the device is doing. The only time these are interpolating is when they are visualizing, there is no point (hah) in storing interpolated data, you can generate that whenever you want.

Not the original reply, but I support the correction here. Regardless of how pedantic/nitpicking it seems, I remember getting confused about this a lot when learning digital signal processing. Simply because its really easy to upsample.. or look at an upsampled result and get confused by that

I think 'upsample' is the root cause here. Technically that is a misnomer.
Post reply on HN