– Copied from customer email –
I hadn’t realized before that our main computer uses gigabit ethernet which has a completely different pinout scheme. I’m wondering if you know if there’s a way to wire 100base t to gigabit ethernet? Will it just auto-negotiate and figure out which pin is intended for RX and which is for TX?
Nearly all gigabit ethernet ports support autonegotiation, meaning that they can run at 10/100Mbps.
GigaBit ethernet contains 8 pins (4 pairs), whereas 10/100M ethernet contains 4 pins (2 pairs).
Two of the pairs used in GigaBit ethernet can be used for 10/100M ethernet. The diagram below provides some help here.
Note that pins 1, 2, 3 and 6 on the RJ-45 connector can be connected to a Gigabit ethernet port, and that port will then autonegotiate to 10/100Mbps. This works on our gigabit ethernet switches and nearly all gigabit ethernet ports. In other words, you can connect your 10/100M device to a gigabit ethernet port by simply connecting these pins. The caveat is that it the gigabit ethernet port must support autonegotiation (which nearly all ports do, unless you’ve specifically turned it off for some reason).
Just to add a bit of a caveat to this, it is a generally good assumption to say that auto-negotiation just “works”. You can connect a 100BASE-T device to a 1000BASE-T device with a 4 pair cable, or a 2 pair cable and it will work. you can connect a 1000BASE-T device to a 1000BASE-T device with a 2 pair cable, and it will autonegotiate to 100BASE-T. 99% of the time, this will be your experience.
This is the idea anyway. Of course, being in the business of ethernet, you realise this isn’t always the case. The autonegotiation process is actually pretty sophisticated and thus, there are times it just fails. We don’t get a huge amount of support issues, but of the ones we do get, I’d say 70% are to do with autonegotiation fails “My device doesn’t play nice with my BotBlox switch and I have no idea why”.
There’s many reasons this can happen, but the most usual reason is actual design bugs in the silicon from the ethernet chip vendor. I’m talking actual oversights made by the chip designer during the IC design phase. Microchip parts are notorious for this, (just google “KSZ8567S Errata”, and read some of the glaring issues with this chip).
Of course, most of these errata can be fixed by configuring the chips in specific ways, and Microchip sure as hell aren’t going to drop a couple million to redesign a 10 year old chip that only shows issues some of the time.
In any case, what we’ve found is that when these kind of issues occur, the simplest and quickest thing to do is just turn off autonegotiation on the BotBlox switch. You lose the flexibility but you get reliability. Of course, that assumes that the BotBlox switch you’re using has the ability to be configured, not all can (SwitchBlox Industrial can easily be configured using BotBlox ARIES, while UbiSwitch has its own recently released command line interface for this kind of thing. Some of our other boards include a microcontroller for static firmware configuration; it’s not elegant but it works.
If you’re using a standard SwitchBlox though, there’s no way to configure that, and so you’re basically forced to migrate to SwitchBlox Industrial to gain configurability.
We are in the process of standardising our boards to provide CLI config interfaces to nearly all of them, which will give us a universal tool for stopping annoying autonegotiation issues, but as it stands, in the rare case a customer sees an issue on autonegotiation, we just suggest them to use either SwitchBlox Industrial or UbiSwitch.
