SwitchBlox Rugged : data loss and auto-negotiation issues

BotBlox Hardware
1

Product : SwitchBlox Rugged (10/100MB Ethernet switch 5port, 4.45cm Square electronic board)
SKU : BB-SWR-G-1

Market : DigiKey
Order-date : 09-JAN-2026

Hello,

We have encountered two issues while performing UDP communication tests with the SwitchBlox Rugged.

Environment

  • We are using the SwitchBlox Rugged with a 5 V power supply after purchase.
  • No additional firmware has been installed. The switch is running in its default unmanaged mode.

1) Auto-negotiation repeatedly fails

One of our devices uses the W5300 Ethernet controller.

When the SwitchBlox powers on, auto-negotiation sometimes never completes and continuously repeats. If we move the Ethernet cable to a different port on the SwitchBlox, the link may suddenly come up successfully.

Once the connection has been established, it remains stable, and even repeatedly power-cycling the SwitchBlox does not cause any further connection issues.

However, when the connection fails initially, repeatedly power-cycling the SwitchBlox does not resolve the problem. The auto-negotiation continues to fail.

2) Random packet loss when using four of the five ports

When four out of the five ports are connected and we perform UDP communication tests, random packet loss occurs.

Test conditions

  • Communication interval: 100 ms
  • Maximum packet size: 100 bytes
  • Connected devices: 4

Network topology

Master device (1) ----- SwitchBlox ----- Slave devices (3)

Communication flow

  • Slave → Master (request)
  • Master → Slave (response)

Test method
Each transmitted packet contains a sequence number. Every device increments its sequence number by one for each transmitted packet, and the receiving device verifies that the sequence numbers are continuous.

Observation
Errors were continuously detected on the slave side, so we captured the network traffic using Wireshark on one of the slave devices.

The capture showed that approximately one packet was missing every 1–2 seconds.

Has anyone experienced similar issues, or are there any known compatibility issues or configuration recommendations for this setup?

Thank you.

2

Hi,

Thank you for the detailed report. Here are my thoughts.

SwitchBlox Rugged is an unmanaged 10/100 Mbps Layer 2 switch, so the ports are relying on normal Ethernet PHY auto-negotiation. There is no way to configure the switch (unless we use static firmware, more on that later).

From the symptoms you describe, I would initially separate this into two possible issues:

  1. Link establishment/auto-negotiation issue
  2. Packet loss after the link has already been established

Link establishment/auto-negotiation issue

For the first issue, the fact that moving the cable to another port can cause the link to come up is a useful clue. Can you tell me which ports worked and which didn’t. Port 5 uses a slightly different transformer to ports 1-4, so if port 5 is the one showing the issue, we can narrow this down to a marginal signal issue.

Packet loss after the link has already been established

For this one, can you help with the following questions.

  1. Confirm all devices have unique MAC addresses
    This is very important with WIZnet-based designs. If several slave devices are running the same firmware image or example code, please confirm they are not using the same MAC address. Duplicate MAC addresses on the same Layer 2 network can cause the switch forwarding table to constantly relearn the same MAC on different ports, which can look like random packet loss.

  2. Compare against a direct connection
    Please test Master ↔ one Slave directly, without SwitchBlox Rugged, using the same UDP test. Then repeat through SwitchBlox Rugged with only that one slave connected. This will help separate a W5300/application/socket-buffer issue from a switch/multi-port issue.

  3. Capture on the master side as well as the slave side
    A capture on one slave only tells us that the packet did not arrive at that slave. It does not tell us whether the master actually transmitted the response, whether the response went to a different MAC/port due to MAC learning, or whether the W5300 application dropped it before transmission.

  4. Check whether loss follows the device, cable, or port
    Please try:

  • same W5300 device on all five SwitchBlox ports
  • same port with different W5300 devices
  • different known-good short cables
  • the supplied BotBlox cable assemblies, if available
  1. Check the 5 V supply at the board
    SwitchBlox Rugged can run from 5 V but this is close to the minimum required voltage input. What is the maximum current output of the 5V supply you are using?
    What kind of power supply is it?

I want to let you know that very occasionally we do see auto-negotiation issues when SwitchBlox Rugged is connected to certain older ethernet designs. The chip on SwitchBlox Rugged has some errata in the silicon which we’ve found generally causes these issues,

In these cases we developed an alternate version of the firmware that fixes these issues (at the expense of worse EMI performance). I’m not yet fully sure that this is the issue you’re seeing, so I’ll wait to see your responses first.

I should also mention that we developed SwitchBlox Industrial, which uses a different chip and we’ve never see these issues with it. This board also runs firmware so that auto-negotiation can be turned off, to fix these issues. Happy to send you a sample Switchblox Industrial so you can test with it, just send an email to info@botblox.com and my team will arrange that.

Thanks!

Josh