NEO vs. 775Pro

We’ve killed a NEO because of the encoder cables before. Not very fun.

If you’ve ever read the NASA robotics alliance project design paper, the description for JST connectors (the connector the encoder cable uses) says “Not recommended for applications that require frequent connection and disconnection cycles.”

Really hope they fix this in the future.


I have worked on products that used JST connectors from the same product family and they worked well over many tens of thousands of units. In that application, the connectors were mated once when assembling the product and the are never separated again during the life of the product. I recall looking up the datasheets for that connector family when I saw them being used on the Spark Max. If my memory is correct, those connectors are rated for a relatively low number of mating cycles, indicating that they were meant to be used in applications like the one I encountered at work and not applications like the Spark Max.

1 Like

Absolutely. The NEO we killed only saw around 10 or so disconnect/connect cycles as we frequently used it for quick one-off tests. For teams that are testing NEOs for the first time and probably switching it around to different test boards and robots, it’d be quite discouraging for the NEO and possibly the Spark MAX to break after a few test cycles.

At the very least, once you’re done testing and wiring it, it generally won’t come undone (lost a couple fingernails trying to get an encoder cable out before :sweat_smile:).!

1 Like

The trouble is that the FRC environment is much like the R&D environment at work. We disconnected those connectors many times to do our R&D work. We are disconnecting our Spark Max’s to do some repair work on the chassis. We are also reusing them on new robots.


It is an interesting design for sure because the same connector style but 4pin used on the CAN pigtails does not seem to have issues with wires breaking (they are MUCH larger wires) and we always unplug those by hand by pulling the wires evenly. Fingers crossed REV can find a way to make an improvement to this part of the SparkMax/NEO combo, almost all failures we have had are where the aluminum wire itself actually breaks where it is crimped in the JST PH crimp meaning bigger wires will probably help. (but I do not have sufficient evidence to prove this). The wire size used on JST PH 6-pin Extension Cable - 4 Pack - REV Robotics could be a good choice and we use pre-crimped wire of this size to make repairs usually.

I will say however that we had 13x NEO installed on our robot this year and 5x NEO 550s and did not have a single failure in competition.


Yeah that’s where ours failed as well. Luckily we also never had a NEO [550] fail on our robot, though we didn’t have many.

We’ve been pretty lucky with motor controllers ever since we stopped using Jaguars (2015 last year). 1 controller failure, no connector failures, 1 wire breakage.

We’ve lost 3 Elim matches from a failed connector on alliance robots.

Please treat your connectors with tender loving care.

1 Like

Lot of really smart people on here. Curious what they’d consider to be an appropriate 6-pin connector? Could easily make a pigtail with the JST on one end and the better connector on the other, then replace the connector on the cable to the motor. (Have to check the rules for allowed modifications). Then, there’d be no need to ever disconnect the JST connector.

This is something we are actively pursuing and going to try to test in off season events. We are messing around with a couple other solutions too.

Our team standardizes to Molex SL, so that what we are trying to use.


I’ve been following the encoder board progress on Facebook- is that how you’ll integrate these with the spark?

Do you plan to publish the ecad files?

We use molex SL for most things and this would be a nice upgrade.

It is 1 method we are messing with too but so far it’s not my favorite. The real beauty of that board is the ability to plug in our custom encoder design (or the ttb encoder with some modifications) directly into the spark, eliminating the need for a Cancoder on a swerve. More on that once we test more :slight_smile:

The issues with the encoder port we added is that we can only mount sockets to the board, and it seems the sockets work better in the small gauge wire on the motor too. If we do that’s we need another cable with 2 plugs, which puts a lot of connectors in a chain.

We also lose access to the temperature pin on the neo, which we have never used anyway, but maybe should start.

I’ll post our ECAD once we get something we are happy with. I don’t want too many “bad” designs posted as we learn and test.

1 Like

Since we are stuck with the JST connector on the Spark. for the indefinite future… We are stuck with training. Only allow trained people disconnect the JSTs. Try to design the robot to minimize the number of disconnections required. (that looks like what Lexo is trying to do with the extra connector) Manage your wires so the JST plug is properly stressed relieved.


This one is key, and I think what we missed in our 2022 robot. I think if not properly strain relieved, those tiny wires in the JST connectors will eventually fail. I’d like to see this point emphasized more by REV. It’s easy to overlook.


A little off topic… Carol Smith, a legendary race car crew chief, designer, has a series of books xxxx to win. They really should be required reading for anybody in a demanding engineering field. The big take away is that successful teams perform by paying attention to every detail. One of his few books that does not have win in the title is Nuts, Bolts, Fasteners and Plumbing Handbook. It breaks the complicated world of fasteners down to fairly simple terms. Apologies of off topic. I blame it on the squirrels in my brain.


If you have not seen it, you might want to check out

I’m a bit confused. What advantages does this board offer compared to using a Cancoder (avoiding the connections to the Rio), or a Thrifty Absolute Encoder (avoiding the connections to the Spark Max data ports)?

The use case (in the link I posted) is using an SRX MAG ENCODER with a SPARK MAX – this is the out-of-the-box setup with SDS modules. The recommendation is to just connect the encoder to the RIO, and to leave out the SPARK MAX. The reason for doing this is documented at the link.

Just using a Cancoder is another option, of course. But, the comment I was replying to said “𝘛𝘩𝘦 𝘳𝘦𝘢𝘭 𝘣𝘦𝘢𝘶𝘵𝘺 𝘰𝘧 𝘵𝘩𝘢𝘵 𝘣𝘰𝘢𝘳𝘥 𝘪𝘴 𝘵𝘩𝘦 𝘢𝘣𝘪𝘭𝘪𝘵𝘺 𝘵𝘰 𝘱𝘭𝘶𝘨 𝘪𝘯 𝘰𝘶𝘳 𝘤𝘶𝘴𝘵𝘰𝘮 𝘦𝘯𝘤𝘰𝘥𝘦𝘳 𝘥𝘦𝘴𝘪𝘨𝘯 (𝘰𝘳 𝘵𝘩𝘦 𝘵𝘵𝘣 𝘦𝘯𝘤𝘰𝘥𝘦𝘳 𝘸𝘪𝘵𝘩 𝘴𝘰𝘮𝘦 𝘮𝘰𝘥𝘪𝘧𝘪𝘤𝘢𝘵𝘪𝘰𝘯𝘴) 𝘥𝘪𝘳𝘦𝘤𝘵𝘭𝘺 𝘪𝘯𝘵𝘰 𝘵𝘩𝘦 𝘴𝘱𝘢𝘳𝘬”. The reason I posted the link was because there’s a lot of detail there on interfacing an encoder with SPARK MAX, which seemed topical.

The Thrifty encoder is a good option – I believe the board at the link I posted predates this offering.

1 Like

Good engineering requires thorough attention to detail. It is possible to get an acceptable result even if one or two details are missed. Miss more and the quality of the design declines rapidly.

Something I should mention about using 775Pro’s is to try and make vent holes on your motor mount to align with the vent holes on the motor. This definitely helps with cooling.