Electronics > Projects, Designs, and Technical Stuff
Simple way to show ethernet packet timing on scope
<< < (4/7) > >>
ejeffrey:

--- Quote from: mikeselectricstuff on July 23, 2018, 06:35:13 pm ---
--- Quote from: 0xdeadbeef on July 23, 2018, 06:13:10 pm ---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.

--- End quote ---
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.

--- End quote ---

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:

--- Quote from: amyk on July 24, 2018, 02:54:56 am ---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...

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

--- Quote from: Hydron on July 23, 2018, 10:26:13 pm ---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.


--- End quote ---
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.
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod