Passive POE

Has anyone thought about using passive POE injectors to power the new Radio? Anyone have a favorite model?

I personally prefer RJ45s to barrel jacks any day, so I’m very interested in eliminating them if possible.

We just bought a set of these. Thisis the official injector sold by the company that makes the radio.

We’ll report in once we test the injector.

I didn’t really understand the box. Open Mesh makes and supports the ideal device that you can’t use. It’s only one item to add and reduces the connections at the radio. A great idea, but can’t be used.

It’s possible to use the extra wires in the cable with the work around adapters posted above. I’ve used similar ones (mine come from Adafruit for $5.95+shipping with good success in non-mobile applications. But only needing one end would be good.

Any ideas why the GDC decided to not allow the Open Mesh device?

This is powered from a battery (12V), and outputs the required 48V (802.3af)
Poe. If using this, the only connection to the OM5P-AN is the ethernet cable. :smiley:

That will burn the radio up, it does not work on 48 volts. And its against the blue box note about injectors.

Also, 48 volt circuitry is not legal at all.

For the record, all PoE is 44v or greater - the radio will absolutely work on 48v IF THE 48V IS BEING SUPPLIED BY A POE INJECTOR INTO A POE-COMPATIBLE ETHERNET PORT. This is in no way suggests that putting 48v into the standard power connector will result in anything but a crisped radio, but plugging a PoE injector into the radio will work just peachy. It is, however, specifically outlawed in the rules - since there isn’t a 48v source on the robot, you need an active power converter, so even if you take a DC/DC converter and strip the Ethernet cable to give 48v to the radio, all you will have done is created your very own custom injector, which is illegal.

Wrong. 802.3af POE perhaps, but as the acronym stands for Power over Ethernet, any power provided by an Ethernet cable qualifies, hence the labeling on one port of the radio “18-24V POE”.

Hello!

The argument is primary a semantic one, and I doubt I’ll convince you otherwise, but its implications are important enough I think I’ll disagree with you.

PoE is an acronym, certainly, but it alway, ALWAYS, refers to 802.3af. That’s how standards work.‘Passive 12-24v PoE’ is not a standard, it’s a proprietary interface developed by OpenMesh and Ubiquiti that allows for power over ethernet, but, and this is important, it’s not PoE, despite meeting the definition. When something says it supports PoE, it means it supports af, end of story. For the record, I’ve worked as an engineer in wifi testing and have contacts in the networking industry - I’m hip to the lingo.

https://www.open-mesh.com/poe/

Sparks

802.3af is an industry standard that uses ~48vdc, supplies 15.4w, and uses as a minimum cat3 cable

802.3at is an industry standard that uses ~52vdc, supplies 30w, and uses a minimum cat5 cable.

“18-24v POE” is non standard. It will only work with devices specifically designed for it and will probably burn up if used with standard PoE. Use at your own risk.

Back to the OPs post: I would not use PoE on a mobile robot because the RJ45 connector is not robust enough for the vibration our robots see.

I agree, but I still believe it’s better than a standard barrel jack connector. Also, using passive injectors seems to be much easier than dealing with the af standard. The cable length we’re talking about here is ~5 ft max which equates to ~0.4 V drop @ 1 A load. Passive injection is perfectly suited for this.

I am just a software guy, but don’t we already depend on an RJ45 connector for the very vital connection between the RobotRIO and the radio, so how would using it for power make it worse? Do the RJ45 cables bounce more than the barrel connector and arc inside the housing? (genuinely curious, I had previously thought it would be a win)

RJ45 is a loose fit connector and is a standard failure point during shock and vibe testing (bounce causes the contacts to come apart). I don’t really like it for the radio connection, but we have little choice here.

I’d prefer a connector like the Cannon / Amphenol MS3112E12-10P connector.

Standard barrel connectors have 360 degree connection so vibe failures are minimized and the only common failure point is if the connector totally pulls out of the socket.

Out in the the real world there are a plethora of devices using nonstandard voltages for PoE. The devices are marketed as POE devices. I sympathize with you only wanting to call only 802.3af devices POE, but be aware that others don’t follow your desires.

The blue box is strangely worded, but it does appear to allow you to supply the radio power from the VRM to radio thru the Ethernet cable.

Just pointing this out, but it seems that this has never been illegal to begin with! Passive POE is, and has been, legal because the passive injectors are basically cable splices with nice housings around them. There is no rule against splicing ethernet cable or adding additional connectors to your wiring. The only difference this year is that the radio has the ability to eliminate one of the splices.

The rule says you can use the conductors. So this device from Adafruit ID: 435

would work and be acceptable. I’ve used this at events to be able to remotely power a switch that is not near an outlet.

This device is from the Open Mesh, it puts power onto the Ethernet Cable. It lets you feed any power voltage.

http://www.open-mesh.com/media/catalog/product/cache/1/image/1800x/040ec09b1e35df139433887a97daa66f/i/m/img_0909sm.jpg

If you look at the connections on the switch, there are two ports.

http://www.open-mesh.com/media/catalog/product/cache/1/image/1800x/040ec09b1e35df139433887a97daa66f/i/m/img_2848_1_2_2.jpg

So in theory you should be able to use the Open Mesh POE insertion device, power it like you would the radio directly. Plug the other end of the ethernet cable into the POE-18-24V plug.

My question would be does the Open Mesh Insertion device qualify as a way to use the extra wires in the ethernet cable? I would think so, since it’s supported by Open Mesh. But you would need to submit it as a Q&A question.

@Daniel_LaFleur We’ve had ethernet connections on the robot for years. Most people put strain relief near the ends to keep an errant game part from taking the connection out.

I’ve seen/heard of teams that had problems, in every case the tab on the connector has been broken. The connector has decent metal to metal connections so as long as it’s plugged in it should be good. While we all love a screwed in connection, can you talk more about connectors actually coming apart?

Yes, bounce causes the RJ-45 contacts to come apart, for tiny fractions of a second. But they’re small, cheap, and easy to replace on a platform that has minimal life-safety concerns. Besides, the DS protocol uses UDP. Brief periods of unreliability are already a factor!

This is the opportunity for us as mentors to teach our students how to design around these concerns. How can they mount the radio to avoid undue strain on the connectors? How can they strain-relief the cable ends? What else could go wrong to moot those measures, and can those be addressed some other way? They’ll never be perfect, but we can make these connectors very reliable.

You see, we had an off-season exhibition yesterday at the Del Mar Fair. The dual-lock-like mounting tabs on the radio were worn, it fell out, and we lost radio power mid-match. That’s a lesson to remember next year.

I’d prefer a connector like the Cannon / Amphenol MS3112E12-10P connector.

Kids, if you were wondering how to spot someone who’s worked on aircraft, that’s it right there. :slight_smile: If you search Mouser for that, you’ll find that the stocked variant is a $15 part, let alone the special-order spec’ed one, with a lead time that makes AndyMark look like Amazon :wink:

Anyhow, what we can’t address in our shops is the boot time of the radio. 60-90 seconds in a 2-minute match is flat unacceptable, and it’s something that must be addressed by OpenMesh and FIRST. Strip out what isn’t needed, and tighten up initialization. (I have a Raspberry Pi Zero booting to console with USB ethernet attached, which boots in 3 seconds. This is attainable.)

I had hoped that FIRST would publish its firmware source for the OMAPs, (thus interested mentors could investigate such things) but Uncle Charlie has probably squashed that.