OK all, as some will have seen on the Register (www.theregister.co.uk) we think we have got to the bottom of this. Here is a letter from Eben sent to the Register, who had asked what was up after some of their readers got in touch.

We’ve been looking at this over the last week, and have a good handle on the underlying mechanism: it’s an interaction between the fairly low-frequency switching regulator on the HAT, and one of the two brands of USB current limiting switch that we use on the main board. Because the regulator operates at a fairly low frequency, each time it switches it moves quite a large chunk of energy into the three USB reservoir caps via the current limiting switch: this large instantaneous current is fooling the switch into thinking that a genuine over-current event is occurring. We missed it in product testing because (dumb luck) our heavy-load testing was done on boards with the other brand of switch, and most of our field testers were only using the board to power mice and keyboards, which works fine on all the HAT/Pi pairs we’ve tested.

There will be a blog post of gory details, probably tomorrow, but for now the summary is:

– A significant proportion of HAT/Pi pairs are limited to delivering <200mA of downstream current to USB. This is generally enough for mice and keyboards, but not for e.g. hard drives.
– We will fix this issue in a subsequent spin of the PoE HAT.
– In the meantime we’ll be adding a note where the HAT is sold, documenting this limitation.
– We will provide a couple of hand-mod options for adventurous users. These are likely to be:
– Removing reservoir caps from the main board (an easy, clean mod if you can use a soldering iron, but limits USB hotpluggability).
– Inserting a small amount of series impedance in the current path from the HAT (this one will be a bit fiddly to implement).
– Users who have bought a HAT and are inconvenienced by this issue should return it for a refund.

The moral of the story: do more testing, particularly where we have multiple vendors for key bits of silicon.

I hope that covers all the questions that have been asked above.

drgeoff wrote: ↑

Tue Sep 11, 2018 3:33 pm

raspy1 wrote: ↑

Mon Sep 10, 2018 8:03 pm

An extra question: is anyone knows if there is a power priority management if both 5V PSU & PoE are connected?

I can’t see that is any different from powering via the micro-USB socket and the GPIO header at the same time.

There is no sensing upwind of the output side of the polyfuse which could be used to know that both micro-USB and GPIO header (PoE HAT if fitted) are powered. And even if there was there is no controllable switch on the micro-USB input to turn off supply of power from there.

No there is some prioritisation going on here, though how/what/where will need to be explained by others.

If I power up the Pi with PoE then connect a micro USB power supply, then disconnect the USB, the hat power cycles. Removing the network cable doesn’t cause the Pi to power cycle. The network switch shows that as soon as I connect the micro USB Power supply it stops delivering power over Ethernet.
If I power up the Pi with Micro USB power supply and then add the Ethernet Cable, power is only drawn from the Micro USB supply, at least as reported by my PoE Switch.

Martin