ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

Open-source Management Software for our Tiny Ethernet Switches


Totally new to the forum, and I have a new project to announce!

I have developed a series of tiny Ethernet switches for use in robots and drones. Full disclosure, the hardware is not open-source, however, we (my brother Aaron and I) have developed open-source (MIT License) switch management software.

At present this software allows port-based VLANs and port mirroring, however any of the features on the onboard ethernet switch chip we use (the IP175G) will be possible.

Our intent is to build an open-source software toolchain to allow managed ethernet switch functions to run on very tiny ethernet switch hardware. We believe there is nothing like this that currently exists and it could enable a massive amount of functionality and smarter internal networks inside drones/robots.

At present, the software is in two parts.

Part 1 is firmware that runs on the STM32L011D4P7 onboard. This firmware takes UART commands and parses them into MDIO commands to configure the onboard ethernet switch IC.

Part 2 is the software that takes command line arguments and parses them into UART commands to send to the hardware.

You just need any USB to UART converter to make the connection between the PC and switch.

Currently, the software only runs on our 10/100Mbps switches but we will be creating something for a new tiny 1Gbps switch we are developing too.

The full writeup is here, including links to the confluence and github pages.

I’d welcome any collaborators, questions, or criticism to help make this software something special.


As a satisfied customer of Botblox, I would add that they not only offer the managed (smart) 100 Mbit switches whose size takes your breath (the 3-port version is just 1"x1"), but they also offer an unmanaged (dumb) 5-port Gbit switch with the size of 4.5x4.5x2 cm (or approx. 2"x2"x1"). I haven’t seen any smaller switch, and still, Gigablox works without a glitch and provides all the performance we need. And we’re really looking forward for the managed version of Gigablox, and maybe even a bit more for the 2.5/10 Gbps tiny switch. We’re in the process of developing a 5-/6-camera panoramic camera composed of smart ethernet cameras and this is exactly the piece we were looking for.

I strongly suggest everyone who works with robots smaller than a car to give Botblox a try :slight_smile: Byebye, Netgear and D-Link :smiley:


Wow, very nice! I have wished for something like this for a long time. I will definitely be ordering some to try out.

The “learn” link on your main page seems to be broken.

Is the picoblade connector used in any other networking devices or is that a connector and pinout that you chose yourself?

Would this be compatible with Time Sensitive Networking?

Do you have any plans for boards with more ports, like 16 or 32?

I would be even more excited about this if you also open-sourced your hardware, but I know there are legitimate worries about how to make money with open-source hardware.

1 Like

Switchblox rugged has a mechanism for “stacking” two boards together, which yields a 10-port 100 Mbit switch. The throughput between the two stacked boards is 1 Gbit, which means the stacking connection will not be a bottleneck.

Thanks for the kudos, Martin.

I really think there’s so much untapped potential here. The combination of compact networking hardware with open source configuration software could potentially open up a lot of avenues for more sophisticated compact networking. What we’ve done so far merely scratches the surface, in my opinion.

That picoblade is something we defined. We’ve done signal integrity testing to characterize it at speeds up to 1Gbps (125MHz clock with 1000BASE-T), but it’s not an industry standard or anything.

SwitchBlox isn’t compatible with Time Sensitive Networking (The IP175G chip doesn’t support it).

SwitchBlox Rugged uses a microchip KSZ8567S, which does support TSN I believe. That board has the same STM32 microcontroller onboard too, but we haven’t started firmware or software for it yet.

We’re planning a stackable, managed version of our GigaBit board, GigaBlox that will allow expansion up to 10 ports. Failing that, you can daisy chain ports between boards with a cable, though that does have a performance hit.

On the open-source hardware side, probably something I’ll consider when we’re closer to sustained profitability.

1 Like

I really like how the picoblade allows you to fit so many connectors onto such a tiny board. It is very unfortunate, though, that those connectors create dependencies on custom cables in your system. You may want to reconsider that, if at all possible, on your future designs.

I used to enjoy making custom cables and wiring harnesses as they allow you to use whichever connector is most ideal on either end. Now I avoid custom cables as much as possible. They require skill to make properly, so that makes them expensive and difficult to source when you are scaling up to lots of units. It is way easier to find pcb manufacturers than to find custom cable assemblers and that may end up being an issue for your company in the future if you want to sell lots of your switches.

Defective cables can create all sorts of annoying system problems that can waste lots of time debugging. I now think it is far better to use standard cables that are made in bulk with quality control and sold from many suppliers, even if the connectors are not ideal.

Are there no miniature ethernet connectors that are becoming standard throughout industries around the world?

1 Like

Hey Peter,

I think that’s a valid point though we very rarely make cables ourselves. Certainly not on anything we send out.

We use a supplier who has the proper equipment for high-volume crimping. In general, I’ve not found it a problem. Cables are relatively low cost and the main issue we have is the lead time on getting them.

On all the orders we’ve shipped (around 1k), all issues so far have been related to either (a) poor solder joints, (b) misaligned ICs, or © faulty transformer parts. We haven’t had a single cable fault yet, or at least nothing reported yet.

At the volumes I order (500+ boards), I’ve had way more trouble finding a PCB manufacturer that can reliably put out boards that work, than I have had with our cable manufacturer. We’ve been through 3 PCB houses before we’ve found one we like, whereas we’ve not changed our cable manufacturer from the start. So I don’t necessarily agree that finding a cable manufacturer is harder than finding a PCB manufacturer, though maybe that’s just my specific experience.

Fully defining functional tests on our boards to run at the PCB manufacturer has solved our issues on sub-90% PCB yields. The cost goes up but the headaches go right down.

Typically when we’ve had custom cable requests we put that customer in touch with our cable manufacturer or place the order for them. Of course, that only works when volumes exceed 20 boards or so (100 cables total).

Essentially, in lieu of a standard on tiny and cheap ethernet connectors, we shot first and defined one. Many pros and cons I suppose.

For miniature ethernet, this is the closest I’ve found to a new standard. It’s certainly what we’re using on our newer products. Cost is still relatively high on these connectors/cables though, so I don’t see these being used on our SwitchBlox series.


It seems that Botblox isn’t the only one who’s using Picoblade for Gigabit and 100Mbit Ethernet:

Connecttech then has one bigger card with MiniTek connectors:

So there seems to be no standard in this niche of miniature Ethernet devices, but Picoblade is close to becoming one. However, it seems you can buy ready-made cables from

And ConnectTech should also sell Picoblade-RJ45 cables, named CBG383, but I couldn’t find any seller.

1 Like

Awesome, that is encouraging! Do they they use the same pinout?

Are you planning to add monitoring functionality? Would be nice. In the data center domain there’s still some SNMP used however it get’s replaced by NetFlow more and more. Probably there are other standard protocols in addition.

We’re limited by the capabilities of the ethernet chip we’re using, the IP175G.

We’ve implemented port mirroring that allows the ingress/egress data from one port to be mirrored onto another for sniffing, which seems similar to SNMP, but I’m no expert on that.

1 Like

I was lookin at the chip capabilities, and it seems it has no capabilities to collect statistics of the traffic. It is not “managed” in the classical way that it would get its own IP address and it would be possible to configure it over IP network. These switches are configured via UART. So there’s also no possibility for the switch to support SNMP or NetFlow in the future (since they probably assume that the statistics collector has an IP address).

I must say I also consider this as a real pain point, because it is very pratical to be able to look at the bandwidth and error counts of the ports of the switch. However, I understand that it’s not possible to get everything from tabletop/rack switches in this small form factor.

1 Like

Yes, agreed. It’s pretty basic.

Let’s see what we can do with the new boards we’re making that use the KSZ8567.

This is a much more capable chip in general.

Random question, is there any interest here on PTP (IEEE 1588-2008)

1 Like

PTP and auto-sensing between different Ethernet protocols would be great. Not sure if the PHYs you use support it but would love love love to see Base-T1 (automotive 2-wire) Ethernet capable settings as well.

Good to know!

We have developed a 1000BASE-T1 converter, but we’re having issues with the config code to get it to work. This is definitely going to happen very soon though.



1 Like

Ah, ok. Network monitoring solutions usually support at least SNMP. The newer ones NetFlow in addition or instead of SNMP. However probably it would be possible to add support for your switches in case they provide an “collector” plugin API or something like that.