| Electronics > Projects, Designs, and Technical Stuff |
| Simple way to show ethernet packet timing on scope |
| << < (5/7) > >> |
| mikeselectricstuff:
--- Quote from: AndyC_772 on July 24, 2018, 08:28:59 am ---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. --- End quote --- 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:
--- Quote from: mikeselectricstuff on July 23, 2018, 08:24:26 pm ---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.. --- End quote --- 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. |
| Navigation |
| Message Index |
| Next page |
| Previous page |