Simple way to show ethernet packet timing on scope

[mikeselectricstuff]

Is there a simple way to see the duration and timing of 100Mbps ethernet packets on a scope ?
I'm trying to get a feel for timings when receiving UDP data with a W5500, and would like to see the timing of the packets on the wire relative to when I get an interrupt 
Scoping the Rx pins on the magjack just shows a random-ish waveform with no obvious pattern regardless of whether it's idle or transferring. I do have control over packet content so can transmit specific byte values.

[Nusa]

I believe it's a differential signal, which means you either need a differential probe or you need to set up two scope channels to get a similar result.

[mikeselectricstuff]

I believe it's a differential signal, which means you either need a differential probe or you need to set up two scope channels to get a similar result.

It's differential but driven symmetrically, so looking at one line gives you all the info.

[Kjelt]

Packet timing? Why a scope?
Just a cheap portmirroring networkswitch and a laptop with wireshark and you get the timing of your packets.
If you want flank-timing its more difficult, no idea but this looks interesting using a diff probe and tek scope with ethernet bus decoding built in

[mikeselectricstuff]

Packet timing? Why a scope?
Just a cheap portmirroring networkswitch and a laptop with wireshark and you get the timing of your packets.

That doesn't show the relative timing to me pulling the packets out of the W5500, nor the length ( though that could be calculated). I basically want to know how fast packets can be sent before any get missed, and this is a function of several things, like W5500 latency, buffer size and how fast I can pull the data out.

[0xdeadbeef]

I understand that 100Mbit ethernet uses 4B5B encoding, scrambling and a three level transmit (MLT-3). So looking at only one differential line will not do the job at least for decoding.
I'd still think that using normal edge trigger with holdoff should to trigger on a packet.

[mikeselectricstuff]

I understand that 100Mbit ethernet uses 4B5B encoding, scrambling and a three level transmit (MLT-3). So looking at only one differential line will not do the job at least for decoding.
I'd still think that using normal edge trigger with holdoff should to trigger on a packet.

I can trigger on the packet via the W5500 int pin no problem. What I want to see is the timing on the wire leading up to the W5500 deciding that it has got the packet.
 

[0xdeadbeef]

Hm, I'd think it should be possible to determine the start of a packet visually, but triggering on it could be harder than imagined. Obviously the idle pattern (11111) is encoded into a multilevel signal that alternates all the time. So I guess anything that breaks this idle pattern is the start of a frame. I guess without dedicated HW (FPGA or whatever) that can detect the presence/absence of the idle pattern would be the only proper solution.

[tautech]

Holdoff should be your friend here, can you get it within the range you need Mike ?

[T3sl4co1l]

Maybe more practical, set up another Ethernet chip for sending packets and measure the end-to-end delay (including transmitter and receiver)?

Tim

[mikeselectricstuff]

Once again I don't need to trigger on the packet, just see where it is relative to me reading it out of the W5500 - ideally start and end.
Sounds like the encoding makes it a lot less straightforward than I expected..

[tautech]

Once again I don't need to trigger on the packet, just see where it is relative to me reading it out of the W5500 - ideally start and end.
Sounds like the encoding makes it a lot less straightforward than I expected..

What about a Period trigger ?

[ajb]

If you were to hook up an external PHY to the same link via an ethernet hub (not a switch!) or a passive tap, scoping its RXDV signal should give you a reasonable idea.  PHYs usually require minimal configuration, so it should be pretty easy to get a cheap PHY breakout PCB up and running for the purpose.  You might not even have to touch the SMI.

[Hydron]

If you can dig out another Ethernet device with a separate MAC and PHY chip, you could try passively splitting the incoming data pair to both devices and sniff the MAC->PHY connection - it should have a deterministic latency given in the datasheet and handy pins like "receive data valid" etc if you don't want to sniff the whole bus. You probably want something using the full MII interface rather than RMII, and may need to force it to not auto-negotiate or auto crossover.

If that's not workable then maybe find said separate MAC/PHY device and put it on the transmit side? No need for any sketchy signal splitting etc in that case. Might get lucky and find a switch to use like that (I have an old gigabit switch here in London that has a separate PHY per port - let me know if you get desperate and I can chuck it on the scope to see what I get out in 100Mbit mode)

Edit: ajb - looks like I had the same idea at the same time as you! Bit slow typing it out on the phone, and it didn't give me the desktop version's new post summary thing.

[amyk]

Don't know which scope you have but apparently some of them can do 10M/100M Ethernet decode. 100baseTX has no long-term scrambling to speak of but uses 4B5B and MLT3 to transform the bits so you might be able to trigger on a packet start if you work out what the resulting waveform should be (start of frame is very distinctive above physical layer, it may still be just as distinctive there.) Dig into IEEE 802.3 and have a look...

[ejeffrey]

I understand that 100Mbit ethernet uses 4B5B encoding, scrambling and a three level transmit (MLT-3). So looking at only one differential line will not do the job at least for decoding.
I'd still think that using normal edge trigger with holdoff should to trigger on a packet.

I can trigger on the packet via the W5500 int pin no problem. What I want to see is the timing on the wire leading up to the W5500 deciding that it has got the packet.

I don't know if this will give you the information you need, but you could try forcing it down to 10 megabit which has a much simpler encoding.  If you have a managed switch you may be able to force it to 10/half.  Otherwise, some NIC drivers will let you select which speeds it advertises for auto-negotiation.  Obviously the packets will have 10x longer duration, but you should be able to see the timing between the packet completed and the interrupt pin.

[mikeselectricstuff]

Don't know which scope you have but apparently some of them can do 10M/100M Ethernet decode. 100baseTX has no long-term scrambling to speak of but uses 4B5B and MLT3 to transform the bits so you might be able to trigger on a packet start if you work out what the resulting waveform should be (start of frame is very distinctive above physical layer, it may still be just as distinctive there.) Dig into IEEE 802.3 and have a look...

My MSOX3000T has envelope trigger so if I can capture a start sequence it may be possible to trigger on that

[mikeselectricstuff]

If you can dig out another Ethernet device with a separate MAC and PHY chip, you could try passively splitting the incoming data pair to both devices and sniff the MAC->PHY connection - it should have a deterministic latency given in the datasheet and handy pins like "receive data valid" etc if you don't want to sniff the whole bus. You probably want something using the full MII interface rather than RMII, and may need to force it to not auto-negotiate or auto crossover.

That was my next thought....

[Hydron]

Had a poke around on the switch I have with separate PHYs - couldn't immediately find the TX_EN pin (has BGA PHYs and a mystery switch ASIC so can't lookup pinout of either) but can definitely see the data as it's being sent out on the parallel bus (ping once a second via switch = triggered once a second).
Something like this should be enough to do the job of sniffing when packets go out once PHY and cable latency had been taken into account - PM me if you can't find an alternative solution in your junk pile and would be interested in the switch as a donation.

[AndyC_772]

100Base-TX uses scrambling on the wires, so the line is always humming with activity even during idle periods.

Personally, I'd get an Ethernet hub, or a switch with port mirroring capability. (Many managed switches can do this; you just need to dig around in the UI to find that feature).

Then, plug it in between the two devices you want to monitor, and attach the mirrored port to a separate Ethernet device that you can probe.

On that device, look at the MII RX_DV pin with the scope.

You still don't know the latency through the switch, but it may be small compared to the times you're looking to measure.

I'm not sure whether it's possible to passively sniff a 100BaseTx line. Can't hurt to try, I suppose.

[mikeselectricstuff]

100Base-TX uses scrambling on the wires, so the line is always humming with activity even during idle periods.

Personally, I'd get an Ethernet hub, or a switch with port mirroring capability. (Many managed switches can do this; you just need to dig around in the UI to find that feature).

Then, plug it in between the two devices you want to monitor, and attach the mirrored port to a separate Ethernet device that you can probe.

On that device, look at the MII RX_DV pin with the scope.

You still don't know the latency through the switch, but it may be small compared to the times you're looking to measure.

I'm not sure whether it's possible to passively sniff a 100BaseTx line. Can't hurt to try, I suppose.

A passive tap works fine with wireshark, so that should work OK. I believe 100baset is designed for about 100 metres of cable, so a couple of metres should have plenty of margin to drive two receivers

[AndyC_772]

Yes, it's designed for 100m and is generally quite robust against all sorts of abuse on short cables. My concern was over the protocol; if a PHY requires the ability to transmit in order to establish a connection and synchronise with the far end, then it won't work if that capability is disconnected. I've designed dozens of Ethernet devices, but always wired them point-to-point as per the spec.

I guess an easy way to tell is to disconnect one pair between two devices, and see if you can still send packets one way. You'll need to disable auto-MDIX to prevent them from trying to work out which pair is which.

[bson]

100M (-TX) is only 31.25MHz and you can easily probe this between the magnetics and the PHY.  However, it's 4B5B encoded (https://en.wikipedia.org/wiki/4B5B) in 3 levels, MLT-3 (https://en.wikipedia.org/wiki/MLT-3_encoding).  This is how it only needs to be 31.25MHz.  This means unless you actually have the ability to decode it it's going to be hard to identify specific IP datagrams.

[nctnico]

Once again I don't need to trigger on the packet, just see where it is relative to me reading it out of the W5500 - ideally start and end.
Sounds like the encoding makes it a lot less straightforward than I expected..

Hook up an ethernet phy to the ethernet pair you receive the packets on and use the parallel interface to trigger on. If there is data, the data strobe will be high.

[mikeselectricstuff]

Just played with a Microchip KSZ8061 PHY chip, and that does exactly what I wanted - works fine in passive tap mode.

Annoyingly their eval board ( https://www.digikey.co.uk/products/en?keywords=AC320004-6%20 ) doesn't have a clock, so needs a bit of additional soldering to get working.

Scope shows 4 UDP packets, W5500 interrupt and my code pulling packets from its buffer.
Also useful to see exactly how fast my PC code is sending packets.

I might have a play with hooking it to an FPGA to turn the RMII data to 8-bit parallel to show on the scope bus display

Interestingly that Phy has a mode where you can tie two of them back-to-back to act as a repeater - that plus an FPGA might have some interesting applications for low-level realtime man-in-the-middle & fuzzing applications without any buffering delays you'd get using a normal ethernet interface.