Passive POE

[Foster]

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.



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



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?

[jlindquist74]

Originally Posted by Daniel_LaFleur

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.

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. 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

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.