My team has decided to use the new magnetic encoders on this years robot, however, we are having lots of trouble getting them to work. We are unsure if it is due to the position of the magnet over the motor or if it is something else. Is anyone else using these encoders and either are also having difficulties or have figured them out? Thanks 
Lucy,
You need to provide part number so we are sure we are on the same page.
Are you talking about the magnetic encoders from FIRST Choice?
http://www.andymark.com/FIRST-Choice-p/fc13-062.htm
We got a pair, but havenāt tried them out yet.
We too are having difficulty with the AS5145B encoder. So far we canāt get them to deliver any quadrature signal. Weāll keep you posted if we find out why
After looking at the data sheet it looks like these are a replacement for a potentiometer, not an encoder. One device returns absolute position, the other returns relative position.
It looks like there are a few different ways to communicate with this chip. One is a digital method much like a SPI device and the other is like it was a pot (a pwm signal through a filter which just gives an analog DC-like voltage out; not sure if the filter to do this is on the PCB though). I donāt see connections for quadrature output.
- Bryce
One fundamental to keep in mind is these devices are intended to give angular info over a 360 degree rotation. These do not replace rotational encoders they are a ārotational position sensorā.
From what the data sheet says, they are supposed to have incremental outputs as well as absolute position output.
How have you wired it up? And have you picked the magnet size/spacing appropriately? Alignment is very important.
I do not see that in the data sheet. Can you provide a page number where you see that? Thanks.
- Bryce
Here is the Austria Microsystems link to the data sheet.
http://www.ams.com/eng/content/download/50206/533867/34237
For the AS5145B, on page 29 it says that the default firmware has the incremental mode set up for use.
Well hereās WPIās instructions on how to AS5145B Magnetic Encoder with the FRC Control System. Not sure how much itāll help, but just my 2 cents
Ok. Well thatās just a little weird. Who names their pins Test* and then uses them in normal operation? Bizarre.
So it looks like sg999 has it right. Take a look at the WPI instructions. The only gotcha is that the CSn pin needs to be pulled low to use this feature. Then it works just like a standard encoder.
On a side note, it looks like this chip can take rotational speeds up to about 15,000 RPM. It looks like to go this fast would require putting the chip in high speed mode, but it really is unclear.
Good find!
- Bryce
Just make sure youāre not asking any one DIO channel to count faster than 38,000 pulses per second.
How are you mounting these encoders? We just got ours today, only to realize they donāt fit on the encoder shaft of the mini tough boxes we were planning to use.
Also, has anyone figured out if putting the encoder too close to the motor will actually cause interference, as our backup plan for mounting these encoders also involves putting the encoder almost touching the motor.
EDIT: No, putting the encoders right next to the motor doesnāt cause (noticable) interference, we tested them today.
Iām a bit confused. In table 4, it says the max input frequency for the magnet is 153 rpm @4096 positions/rev. In table 7 it says that you can go up to 9766 rpm@ 64 samples/rev. Then in 9.6.3 it says it can go up to 30,000 rpm and refers to table 7. Maybe by going lower than 64 samples/rev?
In any case, I canāt find where to change the samples/rev. Any ideas?
That is simply not true. The this yearās magnetic encoder allows for absolute and incremental reading. Reading A/B pinouts on the magnetic encoder allows for one to record the āticksā the encoder has read for incremental output.
I donāt know how the encoder truly works, but one can, with the WPILIB, read the amount of ticks(in one direction) the encoder has moved since the start of the robotās program. The get() function of the Encoder class will give you the ticks (1024 per full revolution of a shaft). Say you move the shaft 3 revolutions counterclockwise since the start of the encoder class; the get() function would read 3072. Move the shaft 1 revolution clockwise, and the get() function will read 2048.(I donāt know which way ā clockwise or counterclockwise, reads āpositive ticksā)
The library(or encoder) accounts for ticks read in the opposite direction One can also see what direction the shaft the encoder is reading and weather the encoder is moving or not(which is probably donāt at the library level).
We noticed the readout value jumps all over when using the encodersā analog output. This seems to be caused by the slow PWM it uses. Aliasing issues occur when the cRIO samples its analog inputs. I added a simple RC filter and that seems to have sorted it out. I just used a 4.7k in series and a 1uF after that. That seems to have smoothed it out, but as always some tweaking might be necessary depending on your application.
EDIT - For more info, just found the datasheet actually mentions this on page 18ā¦
I believe it defaults to 4096 bit but can be changed through the digital interface.
We have tried this encoder on a shooter wheel and it can swamp the cRio pretty quickly. IMHO this encoder would probably best shine in a lower speed continuously rotating system or as a positional sensor.
- Bryce
The datasheet is a bit unclear to me. Can pins 3 & 4 be configured to output a square wave quadrature signal or can they not?
Has anyone successfully done this with this sensor?
Iām guessing your comment above is based on not using the A & B quadrature output?
The datasheet is unclear regarding the max rpm the sensor electronics can support in incremental quadrature mode and still produce a usable output.
Sorry to be unclear in my last post. Yes, we were using the magnetic sensor in encoder mode. Were did seem to be getting good feedback. I didnāt scope it, but we were getting count rates that seemed consistent and direction was also detectable.
All this was possible only at slow speed though. We could hit the Nyquist frequency for the cRIO input at very low speeds - maybe 15% or less of a CIM motor output, I canāt remember the exact figure. At around this speed the encoder rate sign would change. We also would get very quantized numbers for speed (e.g., always something like dancing between 20142.464 and 21439.264 that were repeated exactly).
Just a thought, is it possible that having 4096 bit resolution that could correspond to 4096 ticks on an optical encoder and that the transitions actually happen 4x that speed? That would make matters even worse for sure.
So we gave up pretty quickly using the magnetic sensor and went to US Digitals instead. In hind sight I probably should have just rotated the shooter wheel one revolution and checked how many clicks it producedā¦
Pretty sure itās 1024 cpr equivalent. 4096 transitions per rev.