RoadTest: Raspberry Pi4B (4GB) plus POE Hat
Evaluation Type: Development Boards & Tools
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?: This was the only product evaluated. No product comparison analysis was done.
What were the biggest problems encountered?: Issues related to Integrating old and new technology.
My thanks to the RoadTest Review committee and the product vendor for giving me an opportunity to test this product.
One of the criticisms from RoadTest Review applicant's is their applications never gets selected. It is important to me, that there is full disclosure of my application The goal of this RoadTest Review is to comply with what is in the application.
(c) Why did you apply for this particular roadtest?
I’m am curious to explore power over Ethernet (PoE). I have a project that could benefit from the application of PoE. It would remove the requirement to run AC power.
I have no experience with the is PoE technology. I have questions that I believe are best answered from doing. Assemble a Pi with PoE support, construct the cables, install power and make it work in an existing network. Nothing fancy just determining what is needed to make this PoE component work.
I would like to install a system that uses the PoE module and answer some of my basic question. I manually construct cables, what if anything is required to support PoE regarding cabling? What about the length of cables? I'm assuming PoE is good over the maximum length of CAT5? No assumption, I will build a cable to test maximum. CAT5 cables with 568A & 568B pinout does it make a difference? What do you need for power when introducing a PoE device into a network? I have legacy network devices, what do I need to do to accommodate PoE? What are some reflective costs of investing in PoE?
My proposal is to apply PoE on a Pi so I can understand some of the practical knowledge required in order to use the technology. I noticed the RoadTest suggests the PoE is Pi3B+ compatible. Of course the tests now have to be done using the Pi4 and a Pi3B+ I have as a Pi3+B for this testing.
(d) What do you know about Power over Ethernet? (Please Explain)
I have no experience using PoE. I have the skills to apply the technology once I gain the application knowledge. My initial investigation (i.e. questions to this post) indicate there is a power requirements developed for this technology. I suspect I will have to make some purchases to further my findings.
(e) What is your testing procedure or project plan (Be as specific as you can)?
1.Bench setup of PoE. Using a short commercial cable establish working unit and investigate power requirements.
-sufficient power to operate Pi(s)
- ability to communicate with Pi(s), using ssh on a network.
2.Conform bench testing works with Pi(s) using local built cables.
-test cables 568A & 568B
-test cables maximum CAT5 length
3.Integrate Pi with PoE into legacy network
-establish requirements and understand limitations.
4.Perform tests with Pi4 and Pi3B+
This review summaries the details found in a series of blog posts created during the knowledge gathering process. If the truth be told, my RoadTest applications has always lacked a Yes response to the question regarding blogging in the E14 Community. I can now answer yes to the question, since I used the blog to document the findings during the process to develop this review.
During this blog summary section I have peppered my commentary with three symbols , & . The first symbol is to indicate a testing value. The second symbol is to identify a feature I felt was a plus. The final symbol is to identify a feature that I feel a user needs to be aware of. It doesn't necessarily mean a negative but something to we aware of.
A variety of 586A & 568B cables, commercially made and home rolled were used in support of testing the Pi & Hat combination. No issues were discovered. The Qualitative Test (documented later) cable was constructed from a box of industrial grade CAT6 buried cable. A few neighbours questioned why I had a cable wrapped around my house that terminated in a basement window. I needed 300 feet of space to stretch out the cable. Reminds me, I have to give that cable back to the local high school. I borrowed a box from them for testing.
My network does not have a network device (i.e. switch) capable of supporting a PoE devices. I purchased an external power supply to provide power to the PoE Hat and enable network communication. In addition the Pi4B supplied for testing, required an external power supply that I purchased.
It took considerable time to receive the required parts to conduct this RoadTest review due to shipping issues caused by the COVID-19 pandemic.
While waiting for parts to test the Pi4B, a Pi3B+ was employed to develop the CPU software load test. If a Pi has optional heat sinks installed (mine did) the PoE Hat installation will conflict. PoE Hat will fit only if the Pi heat sinks are strategically placed. Using a local power to supply the Pi3B+ & PoE Hat combination, the supply voltage on GPIO pin 2, dropped from 5.11 to 4.78-4.83 when the CPU was software loaded. The PoE Hat fan engages when the CPU temperature reaches 50 degrees Celsius. Installing a PoE Hat consumes all the Pi GPIO pins. Testing is pending to determine if GPIO header extender will expose the GPIO pins for use. A Pi & PoE Hat combination doesn't fit into a standard Pi case. A Pi3B+ case was modified *badly) to fit the combo. No Pi4B cases on hand to perform a similar test.
The Pi4B power supply arrived enabling some testing. A Pi4B network connection is labelled as unknown when identified by nmap. Pi3B+ is identified as an Raspberry Pi. The local power supply voltage dropped from 5.23 to 5.17VDC when the CPU loading application was applied.
During load testing development I was distracted by CPU throttling supported on the Pi's. CPU testing demonstrated the benefits of the fan that is provided by the PoE Hat and when and how CPU throttling is engaged.
Introduction of new technology has the potential to create issues that may need to be resolved. The Pi4B would not negotiate a 100M connection on my Netgear switch. An alternate D-Link switch worked. The same issue did not exist on the Pi3B+. Employing a PoE Hat results in 100M network connection. 1G connections are not supported. Two pairs of the four pair cable are being used to provide power. 1G connections are not possible.
Compare the operation of a Pi powered using a local power supply verses the PoE Hat. To determine if the Pi was working and to establish communication an ssh session was established over a network.
Operate a Raspberry Pi4B on the maximum length of home rolled (not commercially made) CAT5E (328 feet) cable while under a heavy load (high current draw). Complete a similar test on a Raspberry Pi3B+. Heavy loading is accomplished using software to maximize the cycles of the quad CPU's. Alternately heavy loading is created by using all GPIO outputs configured to sourcing current for a one blue LED attached to each. Measure the power on the Pi before and during the operation.
OUTSTANDING: GPIO header extender on order. Will complete test when available.
This RoadTest review gave me the knowledge to consider purchasing a PoE Hat to power a Pi that did not have readily available power. The PoE Hat DC power delivered to the Pi's was stable under load and also when using a cable of considerable length. The cable requires no special care and can be constructed locally.
Users deploying this technology need to be aware of some caveats that can impact installation and operation. External PoE power supplies add additional cost to installations. PoE supported devices have a reduced Ethernet connection speed. 100M connection speeds are the maximum.
Ethernet speeds related to PoE power supply and not a function of the PoE Hat.
Gough Lui commentary on May 10, 2020 identified a possible error in my determination of network speeds.
A test of network conductivity with the Pi3B+ and Pi4B using a TP-Link Gigabit PoE Injector TL-POE150S supported the commentary. All Pi's connected at gigabit speed when the TL-POE150S power unit was inline (no power). Only 100M network conductivity was available with the L-COM PS4820-POE-1 power unit inline. Gigabit ethernet was supported when Pi's were powered from the TL-POE150S. Only 100M network conductivity when powered from the L-COM PS4820-POE-1.
The issue of the Pi4B & PoE Hat combo using the L-COM PS4820-POE-1 for power not being able to negotiate a 100M connection on the Netgear JGS524 switch did not occur with the TL-POE150S.
Using TL-POE150S power to supply the Pi4B & PoE Hat combination with 325 feet of home rolled cable installed, the supply voltage on GPIO pin 2, remained at 5.07 VDC when under software loading.
These findings highlight an important understanding when considering deploying PoE. The Ethernet conductivity is a product of both the PoE Hat and what is used to provide power.
Documentation for the PoE Hat is poor. It would benefit the user if the PoE Hat vendor provided some guidance on PoE power requirements in their documentation. The TL-POE150S unit specifies a compliance standard and the other two units did not. If the PoE Hat documentation had of contained this knowledge, the Ethernet speed conductivity issues would not have been present.
Outstanding from this RoadTest review was testing the PoE Hat under an electronic loads (i.e. driving an LED from each GPIO) connected to GPIO. In order to accomplish this task a header extender The Road to Raspberry Pi4B/ PoE Hat RoadTest Review (comparison Pi3B+) for the Raspberry Pi was needed to make the GPIO pins accessible with the PoE Hat installed.
With the GPIO header installed the standoffs supplied with the PoE Hat come up short as seen in the front and back pictures. I feel it would be appropriate for the PoE Hat vendor to provide an option that makes the GPIO ports accessible by providing the correct length of spacers and the required headers. If the user has no intentions of using GPIO they purchase a PoE Hat that doesn't have the option. It is frustrating to purchase a product that doesn't have all the parts needed to use the Pi to its full capability.
Below is a table of voltage readings from the Pi 5VDC GPIO pins from three tests using three different DC power sources. Two load scenarios were tested. 28 LED's connected to GPIO ports and the LED's combined with the CPU burn test The Road to Raspberry Pi4B/ PoE Hat RoadTest Review (baseline Pi4B)
Even with the additional electrical load of LED's the PoE Hat power supply didn't sag. Great design from the PoE Hat team!
An observation while doing this testing. The anomaly about the Pi4B not being identified in nmap observed in The Road to Raspberry Pi4B/ PoE Hat RoadTest Review (baseline Pi4B) appears to have been addressed.
The terminal window screen shot (top) of the nmap output back in April is now different (bottom) when the network was scanned for devices. Note in the bottom line nmap output the hostname of the Pi4B is displayed. The hostname is not displayed in the top screen shot. I'm assuming nmap has undergone an update in order for this condition to exist.
When I was working performing electronic maintenance on equipment in remote sites, I would stand in the door of the site and look at the equipment with the lights in the building off. The visual pattern created from the lights and meters gave me an indication if the equipment had any issues. I trigger on patterns. Indicator lights when all is working forms a pattern. That pattern changes when there are faults. I tried explaining these observations when I mentored the new guys. Some of them looked at me like I had two heads.
I can't tell you what data is in the lines of the output from an nmap command. I chuckle when my brain twinges telling me something is different. I can't always find an answer but I rarely ignore the twinge because it has been so reliable
If you are considering using the technology, test legacy legacy network devices (i.e. switches) for supported speeds. Just because it indicates the speed is supported doesn't necessarily mean it will.
Removing the network cable on a PoE device removes power. This is not natural in a network environment. Pi's can behave badly if power is removed unceremoniously. It is something to get use to when troubleshooting.
The Pi & PoE Hat combination requires a housing to support the increase in physical size. The standard Pi case doesn't contain sufficient space to house both units.
Care must be taken when installing optional heat sinks on Pi components to avoid conflict with the PoE Hat.
I would like to see the PoE Hat come with the header extender and spacers to use the GPIO pins with the unit or at least the option to purchase them.
I think you've met your goals, and it's possible there's no need to get a GigEth compliant injector (unless you can return the other one as Gough says, or if you really want it), because your testing…
At the start of this review I considered purchasing one of each type of inline PoE power supply. I talked myself off that ledge thinking the review was to focus on the Hat and not the supplies. I was thinking…
The Raspberry Pi PoE HAT should not interfere at all with Gigabit capabilities. The 802.3af PoE standard may use pairs to carry power, but that does not mean that they also cannot be used with data - this…
At the start of this review I considered purchasing one of each type of inline PoE power supply. I talked myself off that ledge thinking the review was to focus on the Hat and not the supplies. I was thinking, what if I have problems and need a second avenue to troubleshoot. Around this time COVID-19 resulted in a cancelled contract leaving me with less discretionary spending money. So it was one power supply.
Gough Lui commentary leaves me feeling the review comes up short. I state, expect 100M conductivity. I could not get 1G network conductivity through the inline supplies. I have no documentation that suggests it should. I have network hardware that has proven to not be up to the task of providing 1G service to the Pi4B. I rather feel this part of the review is lacking.
After reading the 1G commentary, I made a rash choice and jumped online to purchase an injector from Amazon. 20/20 hindsight would suggest a more fiscally responsible approach would be to have purchased a PoE capable network device from the very start. In the end I will have accumulated enough parts to build three PoE devices.
I have a myriad of network cables, I consider good. I have access to cases of CAT5 network cables removed from a television production studio. I have the tools to assemble my own. I think my issue falls with network devices. If I can narrow it down, I will arrange a test in a network that has more recent hardware.
I still have some outstanding tasks on the review. Establishing the requirements to use the GPIO pins with the Hat is needed. Then those same pins to load the power supply on the very long cable. I rather like hardware loads than software loads. I don't think there is sufficient space between the Pi and the Hat for a GPIO extender without changing the spacers and dealing with PoE header connection. I'm sceptical of the suggestion just use a header extender. I think there is a little finagling required.
Thank you for pointing out the review meets the goal. I have a tendency to lose site of that fact in the pursuit of knowledge discovery. I want to know what I don't know! The whole exercise has given me insight. It has reinforced my perspective of being wary of unforeseen surprises when new and old technology is integrated. I stand by my position that it is never easy, at it is suggested. There seems to always be some piss-ass thing that needs to be done.
I think you've met your goals, and it's possible there's no need to get a GigEth compliant injector (unless you can return the other one as Gough says, or if you really want it), because your testing has already proved the operation of PoE with the long length cable which is what I think you wished to test. Since that test works, there's no reason why the GigEth injector would not work, because the additional transformer circuitry on the additional 4 wires is passive [and there could be a distance issue as Gough says, but that wouldn't be a fault of the Pi or HAT and would impact any PoE device you attached], and so is guaranteed (bar a physical fault on the Pi, which can be tested without needing PoE, by just optionally confirming that a 1000Mbps connection can be established to the existing switch) to isolate the DC from the signaling.
Personally I wouldn't order a second injector, because it could be better to just spend on a PoE switch (again if you optionally want it) since they are cheap second-hand from ebay ($20 or so, at least for 100Mbps last time I checked, but I just noticed that even a new GigEth PoE switch is £45 here, so maybe $60 USD). But as mentioned, for what it's worth I think this is unnecessary too, unless you really plan to expand use of PoE by (say) buying more PoE HATs or other PoE devices in future. I've got several things in the home that require PoE, but it's still not a consumer technology (unfortunately) although that could change. The PoE HAT is not for home use (much). I don't know raspberrypi.org intent when they developed it, but it is possible their focus was on prototyping for business or industry. The device in the photo below is probably home-office use.
Sorry - I must have missed that one. I've been in and out chasing my own squirrels ...
I hope it does change the result, as for most people, PoE devices are typically used with a PoE switch rather than an injector and a switch. In theory, an injector might actually degrade the signal quality due to having an additional set of magnetics within it although I cannot be certain about this. The advantage in that situation is that companies and facilities can move towards PoE switches in the same form factor as non PoE switches and that would provide the facility to power VoIP desk phones, surveillance cameras, in-ceiling wireless access points and other products as they upgrade - but also not spoiling compatibility with non-PoE devices or damaging them as the case may be for passive PoE which sends power down the stolen pairs regardless. It can make sense in this regard, so perhaps the PoE hat fits the niche where the Pi may be deployed in a remote location providing digital signage output for example, or perhaps it's outside running an SDR near an antenna to avoid coax losses. Granted, PoE doesn't exactly respect the Pi in terms of signalling impending power down - but the other benefit is when a PoE switch is used, a hard power cycle can often be achieved via the switch's web administration panel - thus solving the issue of a "hung" Pi with no way to recover.
The need for PoE at the home is usually less - I know a few people who have PoE switches at home to power surveillance cameras, but otherwise, it's a rarity. My experience with PoE via switches is that it generally just works - I can't remember an incidence where I had any issue of link speed not negotiating correctly or power not being supplied. Theoretically, long runs can bring some things close to their limits, but the standard accounts for this. There will always be issues with borderline quality cable (lots of stuff out there marked Cat 5e/Cat 6/Cat 6a are not really compliant to the spec). I've not used a power injector that is 802.11af capable myself, but I do have some pre-standard passive PoE stuff ... and some of them are Gigabit capable too and seem to work just fine.
It could just be your specific combination of cable, injector and Pi that has the issue - adding PoE to the pairs shouldn't change the link rate assuming everything is working right - it's adding a common mode voltage to the data signal that is filtered out anyway. My suspicion would be perhaps bad cable or injector ... I presume you have verified that running the same Pi sans Hat via USB was giving you a gigabit connection?
EDIT: If you were using the L-Com unit you had listed on the blog - that should be a decent unit. I've had generally good experiences with their cables in the past. Perhaps you have a cable or contact issue - dirty Ethernet pins can cause issues or bent pins ... just double check because that was a fault that caused me issues with my Harting MICA RoadTest where a reboot did not establish Ethernet, but if I unplugged and replugged the cable post reboot, it would work. That one drove me nuts, but the fact you seemed to have issues more with one switch than another suggests to me there is something wrong at the physical layer - best to separate this into PoE/non-PoE, check all your cables and if possible, use good quality cables of short lengths to start with or try a different port.
I do understand your frustration when things don't work as you might expect or as might be written on paper, and then having to chase parts/people/ideas. Costing more than the item sometimes happens ... but I suppose with Amazon, you might be able to return items as well ... just a thought. Hopefully by the end of it, we might learn something ...
Also - "A Pi4B network connection is labelled as unknown when identified by nmap." - the identification is based only on the first three bytes of the MAC, also known as the OUI. The new boards probably use a new OUI and the database nmap is using has not been updated yet. This is true for any newly made network device when a new OUI range is allocated to the manufacturer.
You raise some interesting discoveries that I currently don't have a configuration to challenge. I have ordered a TP-LINK TL-PoE150S PoE Injector Adapter with IEEE 802.3af Compliant from Amazon to further the testing.
I confess this has to be my last purchase chasing my desire to gain more knowledge through this RoadTest. Pi4B power supplies, SD cards, PoE power supplies, GPIO header extender and now a PoE injector have cost me more than value of the equipment supplied. At this rate, I will have to start paying Randall to not select my application. It would be cheaper
Your question causes me reflect on the lack of documentation provided with the PoE Hat. I found no recommendations to power the PoE Hat. A search of Newark Canada return results for two PoE power units. Neither one of the units are called an injector. I elected to purchase the more expensive unit. My lack of knowledge gave me no cause to question.
One of the frustrations in implementing new technology in networks is understanding the requirements. If I desire 1G throughput and need special devices to achieve this, I think it only fair the vendor provide that recommendation. Pretty pictures in a brochure do little to assist in defining requirements.
I will add the injector to the OUTSTANDING tests for this RoadTest Review. I'm curious if it will changes the results for the resident switch that doesn't supporting 1G on the Pi4B. Thank you for sharing your insight. Hey come to think of it, where were your comments when I posted The Road to Raspberry Pi4B/ PoE Hat RoadTest Review (power supply) discussing power?
The Raspberry Pi PoE HAT should not interfere at all with Gigabit capabilities. The 802.3af PoE standard may use pairs to carry power, but that does not mean that they also cannot be used with data - this is only true for "passive" pre-standards non-compliant PoE systems which "steal" the two unused pairs from 10/100Mbit/s Ethernet. For standards compliant stuff, instead, the data is an AC signal riding on the DC bias which powers the end product which all gets separated by the appropriate centre-tapped isolation transformers at each end. If you don't use a suitable 802.3af compliant Gigabit-capable injector, then you might get link negotiation problems and fallback to 100Mbit/s.
For example - this review on MagPi which tested the hat with an older Pi3B+ had no problems negotiating 1Gbit/s link rate, although the 3B+ is a USB-to-Ethernet solution, hence the throughput was only about 200Mbit/s in real life.