Talon SRX encoder cable max length


We have a few CTRE magnetic encoders on our robot connected to Talon SRX motor controllers. One of them is located on the intake which requires a longer cable run. No problem making some longer cables, that’s the easy part although 0.05" pitch ribbon cable is a little delicate.

The encoder signals are single ended and I doubt there’s an impedance match source/cable/load. I located a previous thread Talon SRX Magnetic Encoder Cable Issues noting 128" length caused some issues due to signal degradation.

Is there a maximum recommended length? Splice in a shielded cable? Add RC filter? What’s your experience with longer cables.

Another solution we looked at was locating the Talon SRX closer to the intake and running long power + CAN instead. How does the SRX like being so far away from the battery? It’ll have a smallish value capacitor on the front end and I’m concerned the ripple current is going to be higher that the designers anticipated because of a long power cable run. Probably of no consequence in this application because the motor won’t be heavily loaded but interesting to know.


I don’t know what is the recommended max length. But we had issues with some approximately 65" extension last year. I attributed it to poor connections but I never put an ociliscope on it or anything. We didn’t use any kind of filter. This year we relocated the motor controllers to use more pre made cables.


I was going to make a separate thread for this question but it’s applicable here.

We need some feedback on the top of our elevator (wrist driven by a VP with integrated encoder) and our current plan is to have the Talon SRX on the elevator.

The logic was that we need to run long power cables regardless (either PDP->Talon or Talon->Motor). So the decision was between having the Talon on the main board and having long encoder cables, or having the Talon on the elevator and having long CAN wires. With CAN being probably more fault-tolerant than the analog signal on the encoders, we made the decision to put the Talon on the elevator.

Presumably other teams had similar designs last year (wrist on top of the elevator driven by a VP with integrated encoder. Which configuration do you recommend?


I concur that twisted pair CAN is likely to be more fault-tolerant than those tiny gadgeteer cables over a long run. However, note that encoders are not an analog signal. (I would agree even more if you are using an analog sensor!)


More specifically, the Talon SRX encoder (VP integrated encoder) works over either a quadrature interface or PWM for an absolute reading. Both are types of digital signals.


We faced this dilemma on the wrist on our elevator carriage last year. We initially decided to put the long run between the PDP and Talon, with a short encoder cable per CTRE guidance. We ran into brownout issues whenever the Talon would draw significant current (the long wire run could cause significant voltage drop on the Talon’s input side). We switched to using a CANifier (with a boosted power supply) for the encoder and never had issues after that - twisted pair CAN wires are totally fine in a long (by FRC standards) wire run.

I think the long PDP --> Talon run would have been fine had we not drawn close to stall current regularly on this mechanism, or if we had spliced a boosted power supply to the encoder.


The issue here is that when the talon browns out and reboots, the encoder position accumulation resets. Even with a boosted power supply to the encoder, this will not solve the problem. We mitigated this issue in software by tracking the hasReset flag of the talon and pre-seeding the previous recorded value of the encoder to the talon after a reset. This wasn’t a perfect solution but it did help. The reason we didn’t want to use a CANifier was the delay of the value transmission over CAN to the talon for closed loop control.


Our Talon was not rebooting. The problem was the 5V supply line on the data port was sagging.


The sag on the 5v line is almost impossible unless the Talon itself is browning out, since it’s run off an LDO. We had the same symptoms you are describing when I was talking to Tom last year and I made a 5v inline regulator for the encoder to power it and it didn’t solve the issue. Did your position accumulator in the Talon not reset? You only lost encoder counts?


I believe the max recommended encoder cable length is 18". I’ve developed a solution for transmitting this signal much farther using a differential signaling converter to make the signal more robust. The boards are connected with cat6 ethernet cable in between. I plan on selling these from my company soon, once I reach production readiness.


The only symptom we had was a loss of encoder counts, and the LED on the mag encoder going out. Our Talon had no faults. My assumption was the only way the position accumulator on the Talon would reset is if the entire unit lost power. So our working theory was that the +5V line would drop out before the Talon totally browned out either incidentally or perhaps as a deliberate load-shedding strategy. That’s just guesswork, though.

We also attempted to hack together a boost supply for the encoder unsuccessfully, but I don’t think we did it correctly (we were applying boosted +5V back to the Talon through the data port, which isn’t what we wanted).

The CANifier worked but was not ideal for control. Your solution would be the preferable one.


You got me thinking that maybe there’s some kind of powershed in the talon instead of raw LDO, so I measured it with a scope to see when the 5v rail in the gadgeteer connector would drop out. I’ve uploaded the results. The 5V rail doesn’t start to lose power until the input voltage approaches 5v, which is expected with the LDO. So when the voltage is at 5v, the LDO output was 4.24 volts and the encoder actually was still functional at this point. The only situation where the voltage dropped low enough to cause the device to stop being powered was 3v volt input to the talon, which also caused the talon to stop operating as well. So I wasn’t able to find a condition where it seemed the encoder didn’t work while the talon still did. Only when the talon was also off, did it stop working for me.

In the scope photos:
Channel 1 Vtop = Vbus measurement
Channel 2 Vtop = 5v rail measurement

In the last photo, channel 2 is the PWM signal from the encoder, just to check that it was still functioning properly


Encoder function at 5v Vbus


We ran long (5 ft+) encoder cables in 2016 and 2018. The only issue we had was they broke once or twice a year.


Hi Joe,

Long encoder cables can introduce an issue to the talon where EMI from motors can interfere with the encoder signal and cause inaccuracies. In addition to this, there have also been issues reported where a long encoder cable can act like an antenna and cause an ESD into the talon, causing it to reset (usually on high velocity systems with a lot of static, like a shooter wheel). For this reason, direct encoder runs this long are not recommended. And like you say, they also break easier, due to the thin wire.


[quote=“guitar24t, post:14, topic:344552”]
Long encoder cables can introduce an issue to the talon where EMI from motors can interfere with the encoder signal and cause inaccuracies. In addition to this, there have also been issues reported where a long encoder cable can act like an antenna and cause an ESD into the talon[/quote]

Standard industry practice is to avoid running the signal wires in parallel with the noisy power wires (output AND inputs of the motor controllers). If they must run parallel, they should be separated. At these power levels, a few inches would be sufficient. Running the encoder wires down one side of a 2x1 arm tube and the power wires on the other side would be sufficient. Alternatively, run one set of wires inside the tube. Just be careful when drilling into the tube, as we found a few years ago :-/

Running the wires inside the tube should mostly take care of the ESD.


Last year we had a number of sensors out on the manip. To avoid any coupling issues, we ran through the breakout boards and used twisted pair, shielded cables through the cat track with micro fit connectors. They ran in the same track with the motor power cabling and we did not have any issues. TWPR shielded cable, especially in smaller gauges isn’t expensive and is easy to source. Could be another option for you.


This is really cool! Our team would be interested in getting one of these when they are ready to be sold! Let us know!



At this point, the only remaining possible explanations for what we saw can be:

  1. The Talon was actually browning out, but did so in a way that did not produce any faults visible to our program (no UnderVoltage sticky faults or dropped CAN messages).

  2. The LDO was dropping out due to AC effects; it couldn’t keep up with a rapid dip in Talon supply voltage.

  3. The EMI/something else non-brownout related, and switching to a CANifier incidentally fixed our problems simply by changing our wirepaths (really unlikely given how much we poked around trying to diagnose and fix the problem).


I would be very interested in purchasing a set of these. Where can I find updates on this?


Thanks all for the insights and it’s great to see someone working on a differential tx/rx pair to solve this problem. The engineer in me jumped to this conclusion too but as a rookie team we’re time poor already.