Simple way to show ethernet packet timing on scope - Page 1
Forum section: electronics / projects

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 23, 2018, 05:11:28 pm
content: 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 interruptScoping 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.

author: Nusa
author_rank: Super Contributor
timestamp: July 23, 2018, 05:51:07 pm
content: 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 23, 2018, 05:55:35 pm
content: Quote from: Nusa on July 23, 2018, 05:51:07 pmIt's differential but driven symmetrically, so looking at one line gives you all the info.

author: Kjelt
author_rank: Super Contributor
timestamp: July 23, 2018, 05:58:14 pm
content: 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

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 23, 2018, 06:01:06 pm
content: Quote from: Kjelt on July 23, 2018, 05:58:14 pmThat 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.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: July 23, 2018, 06:13:10 pm
content: 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 23, 2018, 06:35:13 pm
content: Quote from: 0xdeadbeef on July 23, 2018, 06:13:10 pmI 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.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: July 23, 2018, 07:17:13 pm
content: 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.

author: tautech
author_rank: Super Contributor
timestamp: July 23, 2018, 07:22:14 pm
content: Holdoff should be your friend here, can you get it within the range you need Mike ?

author: T3sl4co1l
author_rank: Super Contributor
timestamp: July 23, 2018, 08:16:39 pm
content: Maybe more practical, set up another Ethernet chip for sending packets and measure the end-to-end delay (including transmitter and receiver)?Tim

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 23, 2018, 08:24:26 pm
content: 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..

author: tautech
author_rank: Super Contributor
timestamp: July 23, 2018, 09:07:20 pm
content: Quote from: mikeselectricstuff on July 23, 2018, 08:24:26 pmWhat about a Period trigger ?

author: ajb
author_rank: Super Contributor
timestamp: July 23, 2018, 10:17:47 pm
content: 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.

author: Hydron
author_rank: Super Contributor
timestamp: July 23, 2018, 10:26:13 pm
content: 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.

author: amyk
author_rank: Super Contributor
timestamp: July 24, 2018, 02:54:56 am
content: 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...

author: ejeffrey
author_rank: Super Contributor
timestamp: July 24, 2018, 03:57:50 am
content: Quote from: mikeselectricstuff on July 23, 2018, 06:35:13 pmI 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 24, 2018, 06:49:56 am
content: Quote from: amyk on July 24, 2018, 02:54:56 amMy MSOX3000T has envelope trigger so if I can capture a start sequence it may be possible to trigger on that

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 24, 2018, 06:50:43 am
content: Quote from: Hydron on July 23, 2018, 10:26:13 pmThat was my next thought....

author: Hydron
author_rank: Super Contributor
timestamp: July 24, 2018, 07:59:14 am
content: 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.

author: AndyC_772
author_rank: Super Contributor
timestamp: July 24, 2018, 08:28:59 am
content: 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 24, 2018, 08:40:45 am
content: Quote from: AndyC_772 on July 24, 2018, 08:28:59 amA 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

author: AndyC_772
author_rank: Super Contributor
timestamp: July 24, 2018, 09:09:45 am
content: 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.

author: bson
author_rank: Unknown
timestamp: July 26, 2018, 04:20:57 am
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: July 26, 2018, 05:37:57 pm
content: Quote from: mikeselectricstuff on July 23, 2018, 08:24:26 pmHook 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 28, 2018, 06:23:21 pm
content: 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 displayInterestingly 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.

author: LapTop006
author_rank: Unknown
timestamp: August 29, 2018, 03:48:55 am
content: Quote from: mikeselectricstuff on August 28, 2018, 06:23:21 pmHandy for electrical to optical converters & similar. Similar designs are used by some simpler wavelength division multiplexing systems.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 31, 2018, 06:12:57 pm
content: https://youtu.be/SYnO9CsTEqQ

author: benSTmax
author_rank: Regular Contributor
timestamp: November 05, 2018, 11:41:03 pm
content: Thanks for another great video.One other option for a cheap HW decoder might be to use the DP83848 in back to back mode and a CPLD/small FPGA for decoding the RMII.DP83848 provides a demultiplexed RX_DV signal which can be connected straight to the other's TX_EN. Then, the CPLD can decode both data streams and capture the traffic both ways.Check chapter 6 at the following link:http://www.ti.com/lit/an/snla076a/snla076a.pdf﻿

author: t1d
author_rank: Super Contributor
timestamp: November 06, 2018, 10:21:04 am
content: This is not my area of expertise, but would one of those $7 Ebay Logic Analyzers, with free Sigrock and PulseView programs, help? They actually have a descent rep. I have not used mine, yet, but it is rather well made. See YouTube instruction videos.The programs are here:https://www.saleae.com/downloads/Saleae is aware that people are using their free software with this cheap devices and seem to be unconcerned, due to selling professional grade equipment.Example only. I know nothing of this vendor.https://www.ebay.com/itm/Useful-ARM-FPGA-New-8CH-USB-Cable-Debugging-Tool-Logic-Analyzer-Analysis-Device/173622196213?epid=6025499068&hash=item286cb077f5:g:-IMAAOSwEJZb3j70:rk:10:pf:0

author: cdev
author_rank: Super Contributor
timestamp: November 09, 2018, 09:47:00 pm
content: I am almost 100% certain that one can't use a cheap logic analyzer to decode Ethernet.Also, the designs for inexpensive Fx2 logic analyzers, including the various commercial vendors I am pretty sure,were all based on the original dev board reference design from the chip manufacturer. Or so Ive heard. That doesn't make it morally right to use their software without having bought their hardware. Still, its important to recognize that the company that makes the chips the logic analyzers use, wanted people to buy them in quantity so they made a great reference design.Then several companies brought logic analyzer designs to market that were all functionally similar to that reference design. Both Saelae and usbee were quite successful for a while but eventually their low end products were impacted by widespread availability of clones which were built in cheap cases or came as bare boards without slick rainbow colored mini grabbers.. but still did the job.People do have a choice of using a really good piece of free software, pulseview, for them which is part of the sigrok suite.Sigrok software (sigrok.org) for the FX2/FX2LP chipset is totally free and quite feature rich.Compatible mini logic analyzers can be bought for $10 and up.Although at least one of the hardware companies now sells their commercial program as an add on for people who dont own their hardware, a business model that I like, that works with my LA (usbee) and comes with support, and Ive thought about it, I still have not pulled the trigger because to date, I am not so proficient yet, I am still mucking around so I have never needed to, not having outgrown the capabilities of the free software yet.

author: t1d
author_rank: Super Contributor
timestamp: November 09, 2018, 10:16:47 pm
content: Quote from: cdev on November 09, 2018, 09:47:00 pmThanks for that clarification edit, because I wasn't quiet sure what I was in error about. Yeah, I didn't know, if it would be helpful, but I was trying to be helpful;-)Quote from: cdev on November 09, 2018, 09:47:00 pmAgreed. And, if I had not seen an article about Saelea's position, I would not have downloaded their program. I'm sorry, but I did not bookmark the reference. I did watch the PulseView author's YouTube video and, IIRC, it is open source and he has turned over its continued development to the community. But, it has been a good long while, since I looked at this stuff.Thanks, for the info. It was interesting.