Absolute encoder keeps returning strange values

We are currently trying to get brand new encoders working before diving into the next build season, as we have never used absolutes before (but we have successfully used magnetic “hall effect” encoders).

We’re using the standard MA3 (am-2899) with the cables they came with, plugged into the RoboRIO Analog In ports. The issue is that simply calling getValue() on an instantiated encoder only returns a constant, arbitrary, high value, regardless of how it is turned. (On RoboRIO analog ports, the value is around 3575, and on MXP ports it is around 2700). This value constantly flickers by one, but not with any relation to actual movement.

When we unplug the encoder, the value begins to flicker around 205.

Calling getVoltage() has similar results, only the returned values are scaled down significantly.

After extensive troubleshooting (we have many additional encoders and cables to mess around with), it seems that the programming is the only possible source of the problem here. But the code is so simple that we cannot understand what would be going wrong.

All we do is call:

AnalogInput encoder = new AnalogInput(port);

in our variable definitions, then we call:


and print the result to the driver station.

If anybody might have some insight on what the problem could be, we’d greatly appreciate the wisdom.

Are you sure the wiring is connected properly? I’ve seen similar output behavior when we’ve had wiring issues on encoders, although we haven’t used these ones specifically.

Just to check … at the DuPont connector, did you swap the orange and blue wires? The orange is 5V and the blue is the signal. At the RIO, the orange should be in the middle.

If so, try using a voltmeter between 0V/black and signal/blue to see if you get the same results as getVoltage().

Sounds like wiring to me. If I remember right, there is a 5, A, G on the top of the MA3 for 5V, signal, ground. The pins are not in the same order on the Roborio. They go signal, 5V, ground from inside to outside.

Thank you everyone for your swift replies.

Yes, when we soldered the encoder wires to female PWM connectors, we actually did actually swap the orange and blue wires, as we noticed that the output pins on the encoder do not line up with those on the RoboRIO.

We have not yet tried measuring the voltage with a voltmeter, but doing that sounds like the best course of action from here. I will try it the next opportunity I get.

UPDATE: The voltmeter returned the same values pulled from our code, so it does not seem to be a code issue.

However we swapped in a fresh battery, and all of a sudden one of our encoders started working perfectly. We tried implementing four encoders, thinking we had solved the problem, then all of a sudden none of them worked anymore. Now, two of them are reading a constant (flickering) voltage between 3-4, and the other two are reading virtually no voltage.

Any help would still be appreciated

There are a lot of potential causes for the problem. Take a slow, methodical approach by breaking the process into distinct steps, each of which is designed to tell you something. Is this encoder working, or is it the problem? Is this port working, or is it the problem?

So, I would try the following.
Unplug them all, then plug in just the one that’s working.
Verify the one is still working.
Plug in a second one.
Verify both are working.
Do the same for the third and the fourth.

When you get to a situation where it’s not working, you can do some investigation with a multimeter:

  • What is the voltage between the ground and +5V pins, both before and after you plug in the one that isn’t working
  • Measure the current draw for everything you have hooked up to the analog ports.
  • Unplug the encoder that introduces the problem and plug in another one in its place.
  • Try plugging the encoders in in a different order, or to switch around the order you plug them into the ports.

The goal here is to try to find out what exactly the problem is. If there’s a short somewhere, it could cause the +5V rail to turn off. If memory serves, the analog ports can only supply a max of 3A. If one of the encoders isn’t wired properly, or is broken, it could cause a similar issue. Swarf down in the pins could cause the issue when you plug something in to a specific slot.

+1 with Jon’s advice. You may want to add a general inspection/vacuum for swarf (metal shavings/scraps) and do tug tests as you unplug things.

Update 2: After trying everything suggested (to no avail) for over an hour, we put together a new cable that was connected by bullet splices instead of soldering. This cable (individually) caused all four of our encoders to work perfectly as intended.

We’re not sure what went wrong with the soldering, but we’re gonna make up three more new cables with the bullet splices instead. Seems like everything should go smoothly then, but if not I’ll come back here.

Once again, thank you everyone for your assistance.

The most common issues for electrically poor solder connections are cold joints and too little (or burned off) flux. Did you measure the resistance across the cables? It should be 0 ohms, or so close that only a lab style meter can detect the difference. Sometimes just reheating the joint until the solder flows throughout will solve the issue.

Cold joint seems like the most likely culprit, but in all honesty we’re not willing to figure out how to fix all four of our cables (with three soldered wires each). We’re just going to use physical connectors for this one.

Welp, we jumped the gun again. When we swapped the soldered cables out for a single one that had physical connectors, it temporarily fixed the problem. But after we made multiple similar cables, of course, all of the encoders stopped working, and no matter what we did afterwards for any of the cables, we couldn’t get any single one of them to work anymore.

I don’t understand. All of our analog ports are properly sending 5V through their pins. The voltage reading from the signal channel just never wants to change.

I might kick this one over to a new thread in a different sub-forum; this one’s getting longer/more drawn out, and less related to programming.