Autonegotiation issue on GigaBlox

– Copied from a customer email (with consent) –

We have a GigaBlox switch that we are using to managed network communications in a small remotely operated vehicle. The GigaBlox has 5 devices connected for Ethernet comms, including the following:

  1. A sonar (100 MBps capable)
  2. A velocity sensor (100 MBps capable)
  3. A fiber optic multiplexer (1000 MBps capable)
  4. A Raspberry Pi4 (1000 MBps capable)
  5. A custom Arduino based PCB (100 Mbps capable).

We are currently only able to achieve 100 Mbps, full duplex comms through our Fiber Optic multiplexer, while we expect that we should be receiving 1000 Mbps through this link. Is it possible that the GigaBlox is auto-negotiating the link speed for all ports to the lowest speed that all devices can achieve, or is auto-negotiation done port by port?

Is there anything else that you might suspect would limit our speed on the fiber optic multiplexer port? We have made the connection using BotBlox supplies RJ-45 to Pico blade cabling, and have 4 twisted pairs going to each of the ports that are connected to 1000 Mbps capable devices.

Attached is a picture showing the installed GigaBlox and the connected devices. There may be some untwisting of conductor that has occurred during cable routing, but we have done our best to maintain the integrity of the twists. These Ethernet lines do pass near some power lines, running at ~ 24V DC. Could that have any effect on the link speed?

Thanks in advance for you suggestions,

Note that the fiber optic multiplexer we are using is a Focal Technologies Model 914-HDE-H1, in case that is helpful:

The auto-negotiation function on GigaBlox (and on all our boards, for that matter), is on a per port basis. Each port will negotiate the highest possible speed with the link partner, irrespective of the state of the other ports.

As an example, say you connect port 1 of GigaBlox to a 100Mbps device, and port 2 to a 1000Mbps device. Port 1 will autonegotiate to 100Mbps, while port 2 will autonegotiate to 1000Mbps.

However in the above scenario, don’t expect to get 1000Mbps of meaningful data transfer between the two devices. Ultimately the device on port 1 can only generate/receive 100Mbps of data to/from the device on port 2, so while port 2 has autonegotiated to a 1000Mbps physical rate, the actual rate of the data you receive from the device on port 1 is limited to the speed of the device on port 1.

This may be what is happening in your case, however you have a raspberry pi that can operate at 1000Mbps, so we should still expect to see the fiber optic mux being able to transmit at 1000Mbps.

To fault find this, let’s first check the physical rate of the port (port 3) connected to the fiber optic mux. It should be 1000Mbps. This means the LED activity indicator should be flashing green. If it’s flashing red or orange, this means the speed is 100Mbps or 10Mbps. If this is the case, then there is some physical issue in your system. Sometimes this can be a poor cable, or an issue with the ethernet PHY on the link partner.

If the light is green, then the issue is higher up. To debug this, can you setup an iperf test between your raspberry pi on port 4 and, say, another computer connected to the other end of the fiber converter? You should be able to transmit 1gbps between the Pi and your computer if so. If that works, the issue could relate to how data flows between the multiple 100Mbps devices on the ports. I would presume you want the various 100Mbps speeds from the devices to “aggregrate” into the 1gbps port.

Anyway, can you get back to me at least on the colour of port 3 LED and we can debug from there.

1 Like