create a poe list for remote

    The Profiler Model referred to in this thread is ...
    ☑️ Profiler Head/Rack

    hello I would need all the kemper users to create a complete poe list! the manual indicates almost more non-compatible poe than compatible in their short list.... So to help everyone who may already have a compatible device at home to connect the remote it would be more practical and above all better for the planet to know, so thank you all for helping me put the list here below up to date.

    list:

    compatible

    -

    -

    -

    not compatible

    -

    -

    -

    I am waiting for your help and feedback to be able to complete it, thank you in advance to all participants....

    Kemper manual list:Here is a list of materials that we have successfully tested: sorry list in french !

    Injecteur PoE

    • TP-LINK® TL-POE 150S

    • TP-LINK® TL-POE 160S

    • Cudy® PoE 150 30W

    • Cudy® PoE 200 30W

    Commutateurs PoE::

    • TP-LINK® TL-SG1008P (commutateur gigabit 8 ports avec 4 ports PoE)

    • Commutateur Allnet® ALL8085 (8 ports 10/100TX)

    • Commutateur Intellinet® 8 ports Fast Ethernet POE+ (disponible avec kit d’installation en rack 19”)

    Les dispositifs PoE suivants ont été validés par des utilisateurs:

    • TP-LINK® TL-SG1005P (commutateur gigabit 5 ports avec 4 ports PoE+)

    • Commutateur Trendnet® TPE-TG44G PoE+

    Les injecteurs PoE suivants ne sont pas compatibles et ne peuvent pas être utilisés:

    • Swissonic® 466331

    • Ubiquiti Networks® U-POE-af

    • Ubiquiti Networks® POE-48-24W-G

    ✓Si vous utilisez un commutateur POE, branchez le PROFILER à ses prises Ethernet PoE et au(x) Remote(s).

    It's unfortunately slightly more complicated since the PoE part of Profiler and Remote do not fully comply with the corresponding IEEE specs.

    The Profiler manual states that PoE switches compliant with 802.3af-2003 and 802.3at-2009 and using Mode A are supported.

    That means, any PoE or PoE+ switch should work, as long as it uses "Mode A" for powering the connected devices, since the Remote only supports "Mode A" (that is one point where the Remote violates the spec, which requires powered devices to support both, "Mode A" and "Mode B").

    Hooking up the Remote to a switch that uses "Mode B" will not work and even includes a slight risk of damage (here is the second point where the specs are violated. Though the Remote supports "Mode A" only, it still (ab)uses the signal pins specified for powering according to "Mode B" for powering the Remote when its connected directly to a Profiler. They could have just done that by implementing a spec compliant "Mode B" powering in Profiler and Remote or a spec compliant "Mode A" in the Profiler (then there would be no need for forum threads like this) but unfortunately they didn't. Instead, the Profiler supplies a voltage of 4V, expected by the Remote in a certain polarity to power a directly connected Remote, which also severely limits the possible cable length between Profiler and Remote).

    So the simplified rules are: Use any PoE or PoE+ switch powering in "Mode A" only and don't connect the Remote or Profiler to a switch or injector using "Mode B". PoE++ switches (can) use all signal pairs for powering and should hence not be connected either.

    BTW that is, why following specs is (or would be) such a great idea: You could just interconnect any Ethernet equipment without having to care about such details. There would not only be no risk of damage, it would simply work, literally, plug and play.......

    Edited once, last by Jandalf (July 4, 2024 at 3:04 PM).

    Quote from Jandalf

    BTW that is, why following specs is (or would be) such a great idea: You could just interconnect any Ethernet equipment without having to care about such details. There would not only be no risk of damage, it would simply work, literally, plug and play.......

    When the KPA is based on Ethernet/IP and there are PoE-enabled chip-sets readily available I struggle to even understand why they would deviate from the standard. What were they thinking?

    Quote from Ruefus

    To my knowledge, there is no requirement to support mode a and b.

    Then i suggest that you check with ISO/IEC/IEEE 8802-3:2021(E):

    (PD = Powered Device, which applies to the Remote)
    ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    33.3.1 PD PI

    The PD shall be capable of accepting power on either of two sets of PI conductors. The two conductor sets are named Mode A and Mode B
    [...]
    The PD shall be implemented to be insensitive to the polarity of the power supply and shall be able to operate per the PD Mode A column and the PD Mode B column in Table 33–13.

    NOTE—PDs that implement only Mode A or Mode B are specifically not allowed by this standard. PDs that simultaneously require power from both Mode A and Mode B are specifically not allowed by this standard
    ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    I would say that "specifically not allowed" leaves little room for interpretation (my teenage son might disagree though)

    Edited once, last by Jandalf (July 5, 2024 at 10:30 AM).

    Quote from heldal

    When the KPA is based on Ethernet/IP and there are PoE-enabled chip-sets readily available I struggle to even understand why they would deviate from the standard. What were they thinking?

    I haven't seen any integrated one-chip solution for a PoE powered Ethernet interface yet. You still need a PHY (physical layer chip) and a power acquiring circuit and a (preferably isolated) step-down converter to bring the PoE voltage to a lower level as required by your device. There are integrated chips containing the power circuit and the converter and the Remote uses such a chip. Basically, everything required for an implementation supporting both modes on the Remote would have been already there.
    However the Remote was released way later than the Profiler, where they had already made that bad decision to go for a propietary and spec violating solution. So they probably took the easy way, which was to just continue with that bad decision when designing the Remote instead of using the opportunity to get this right. As to what they were thinking, i have no idea and i'm not sure if we'll get an official comment on that.

    Quote from Jandalf

    I haven't seen any integrated one-chip solution for a PoE powered Ethernet interface yet. You still need a PHY (physical layer chip) and a power acquiring circuit and a (preferably isolated) step-down converter to bring the PoE voltage to a lower level as required by your device. There are integrated chips containing the power circuit and the converter and the Remote uses such a chip. Basically, everything required for an implementation supporting both modes on the Remote would have been already there.
    However the Remote was released way later than the Profiler, where they had already made that bad decision to go for a propietary and spec violating solution. So they probably took the easy way, which was to just continue with that bad decision when designing the Remote instead of using the opportunity to get this right. As to what they were thinking, i have no idea and i'm not sure if we'll get an official comment on that.


    Here are power-sourcing IC's (need to be fed the correct voltages): https://www.ti.com/power-manageme…t/products.html

    These are circuits for the receive/consumer side: https://www.ti.com/power-manageme…s/products.html

    I bet several other manufacturers can offer something similar to those from Texas Instruments. It is a point that the KPA predates many of these products, yet most of the relevant IEEE-standards predates the KPA.

    MERCI BEAUCOUP POUR VOTRE RETOUR C EST HYPER CLAIR ET JE VAIS SUIVRE VOS RECOMMANDATIONS A LA LETTRE

    A BIENTOT CORDIALEMENT