Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

802.3ab GigE 1000base-T tester 1

Status
Not open for further replies.

zappedagain

Electrical
Jul 19, 2005
1,074
0
0
US
We integrated a new 6-port GigE switch integrated circuit into our circuitry to replace an older 4-port switch. Everything works well on the bench but the board has an integration issue with an adjacent board (also new) that also works well on the bench.

With my PC set to GigE, when the Cat5e cable is plugged in the channel starts the negotiation process. If I make an unrelated connection (i.e. not part of the RJ45 connection - ground loop, shield, etc., I don't want to get into that detail) the GigE channel establishes a link and maintains the link after the unrelated connection is disconnected.

With my PC set to 100M, making the unrelated connection allows the 100M link to happen and 100M data to flow. Disconnecting the unrelated connection breaks the 100M link.

Can anyone suggest an analyzer that can show me what is failing in the negotiation process? I'm open to renting equipment to help figure this out.

I have a high speed scope with a differential channel on one of the four pairs (DB+-) and don't see any signal anomalies in the 100M waveforms, so I'm hoping to look at the data the PC/analyzer and seeing what is causing the GigE negotiation failure symptom and/or the 100M link failure symptom. That will help me get to the root cause. While I can move my scope to other pairs, that seems moot as the GigE channel functions normally after it starts. Termination and pulse shape look good on the DB+- pair.

Z

 
Replies continue below

Recommended for you

Yeah, kinda need to know what this "unrelated" stuff is before making any valid conclusions... the signaling differences that happen between 100M and Gig traffic can be royally messed up with something else on the line.

Dan - Owner
URL]
 
I'm looking for Ethernet test equipment at this point. That's why I don't want to get into the other details. I have a noise problem so I have a source, a path, and a receptor. I'm concentrating on the receptor at this point trying to find out more detail of the exact failure so I'll have more data to go after the path and the source. I may start an EMI related thread later.

Z
 
I see a lot of equipment that can verify the cable quality, and a lot of equipment that can analyze the link after it is established. I seem to be in a gray area in between trying to figure out why a link is not getting established after I've tested the cable quality.

Z
 
Is Wireshark applicable in this situation: I've never used it myself...

Usually, when odd things like "unrelated" connections make or break a link, it's likely a grounding or common-mode problem. It used to be that NICs had transformers, which eliminate common-mode, but I don't know that currently extant NICs have that or not.

TTFN (ta ta for now)
I can do absolutely anything. I'm an expert! faq731-376 forum1529 Entire Forum list
 
Dan suggested, "...(physical)....job for a scope."

Yep. Digital systems typically aren't very communicative about the physical layer. You may need to see the signal that the systems are seeing to figure it out.

(At lower bandwidths, you can often use your ears; but that doesn't work with high bandwidth signals.)

If it's 60 Hz noise (for example), then you wouldn't need anything more than a normal (cheap) oscilloscope to reveal it. Worth checking that if you haven't already. Acknowledging in advance that most Ethernet systems include 'magnetics' to reduce the risk of such issues.

Gb Ethernet is "only" 250 MHz per pair, but you'd still need an GHz expensive scope with very advanced triggering to make it visible.

This is all assuming that the problem lies at the physical layer. Of course, Ethernet has plenty of room for settings and configuration nonsense in all the other layers (ref. ISO 7-Layer model).

 
Well we solved it without analysis from the Ethernet end. I had a ground loop and poor soldering issues compounded together so it made it tricky to debug. I'm so glad we skipped the inspection process to get the PCBAs a day early so I could then spend 9 days debugging an issue that would have been caught in X-Ray inspection...

Z
 
Bah, that's nuttin! We had a PCBA that was partially shipped until someone decided we needed to run a test that was normally skipped. Needless to say, the test failed, and a few days of head scratching until it was determined that the PCB supplier made the entire batch with 2 missing layers.

TTFN (ta ta for now)
I can do absolutely anything. I'm an expert! faq731-376 forum1529 Entire Forum list
 
IR,

I lost several days debugging a VERY high-priority board a couple of years back. Most things appeared to work, but certain features on a BGA (like some GPIO) were heavily intermittent. Long story short, the board house's CAM guy widened the clearance around some buried vias in one of my power planes and failed to do a final electrical check. He widened the openings so much, my already swiss-cheese power plane became two separate power planes.

The stress of that project took a solid year off of my life, I believe...

Dan - Owner
URL]
 
Status
Not open for further replies.
Back
Top