We have integrated the GigaBlox Nano into our own PCB design.
When we communicate with multiple devices through the switch we see heating up to 68C. It’s not clear to us whether this is a total bandwidth thing or a multiple devices issue.
When we connect through the RJ45 daughter board we do not get this issue. We were wondering if there might be anything wrong with our design? The schematic follows:
This is just one of the ports, the others are the same. R401 is not populated. U400 is a Pulse H5008 magnetics module H5008NLT Pulse Electronics | Transformers | DigiKey
We supply the GigaBlox unit with 24V.
The only difference we could find was that we tie all the center taps of the PHYs side transformers together before running them through a capacitor to ground. Could this cause the issue we are seeing?
That certainly does seem a bit strange, but it may be expected behaviour. To confirm what temperature do you see on GigaBlox Nano when using the RJConn daughter board.
68C is pretty toasty but not completely unreasonable with the right ambient conditions and a full data load. What is more strange is that you don’t see a similar heat when using the RJConn daughterboard.
I took another look at your magnetics implementation and I think I see the issue.
The center taps of the external facing side of the transformers are all essentially shorted together. In theory this isn’t an issue because that should be a neutral point with all transformer pairs sharing the same voltage there, but in practice that’s probably not the case.
Basically, you are not doing bob smith termination. I’m not an expert in what the specific implications of not doing bob smith termination are, but the link below is quite informative.
I would not be surprised if the lack of bob smith termination causes issues when connected with a transformerless device like GigaBlox Nano. In that way, it’s not a surprise that the issue goes away when using GigaBlox Nano + RJConn (which does include transformers).
Nearly all of our designs use Bob Smith termination, take a look below.
Unfortunately this probably means you gotta remake the board. I’m curious, why did you terminate the pairs in your design like this? Were you following a specific application note? The vast majority of application notes for ethernet just recommend doing Bob Smith “Bob Smith it, and it’ll be just fine”.
Upon further investigation we do actually see 68ish C on the daughter board as well. I think maybe during initial testing we weren’t fully loading the switch? We don’t have a very high degree of control over the devices we’re testing with so it’s possible it wasn’t stressing the switch until later tests?
I think on the external side, the side with the 75 ohm resistors, we did do the Bob Smith termination? That’s the right side of your image and the left side of my image.
On the internal side we did do it wrong though. All your center taps pass through capacitors in yours and then go to GND. In ours all the center taps tie together and then pass through a capacitor to GND.
I’ve been trying to track down where this error came from and funnily I think it was from copying the implied schematic in the RJ45 jack in the Daughter Board.
Upon further investigation we do actually see 68ish C on the daughter board as well
I don’t understand what you mean by this? Which daughterboard, RJConn or PicoConn. I’m going to assume you mean you also see 68C on the RJConn daughterboard, same as the PicoConn daughterboard. In which case, yeah 68C is not impossible to see on GigaBlox Nano when all ports are at full load. You can purchase a small off-the-shelf 10mm x 10mm, adhesive backed heatsink to put on the chip if this is a concern.
I think on the external side, the side with the 75 ohm resistors, we did do the Bob Smith termination? That’s the right side of your image and the left side of my image.
Ah you’re right, your external side is on the left and you did terminate that correctly.
On the internal side, in all likelihood, those center taps are going to be at the same/similar potential. But the idea that imbalances can flow between the ethernet pairs is probably not something you want; I’d say implement a fix to it in your next revision but if it’s working as is, no worries.
