README.md

Inductive Encoder

HTMSTMAA Week 12 - 5/27/21

Welcome to the last week of the inductive encoder project (as a part of HTMSTMaA. Getting to a state of a working encoder took some pretty abominable debugging/hacks (see video below), but the results are promising and I am excited to integrate it into a motor driver.

It's worth noting that the AMT encoder that I am using as a reference is rated to 0.25 deg of accuracy. So we are definitely within the right order of magnitude for a comercial product. The spec is also ambiguous in that it doesn't specify a +/-

One big question I had was if EMF from the motor would manifest as noise at the sensor, which fortunately seems to not be the case at all. Noise levels did not change with the motor running or not running, and the error down to +/- 0.25 deg appears highly repeatable. To test this, I ran the motor through a full 720 deg sweep, and then took the difference between errors in the first and second revolution, by manually lining up the data. Ignore the +0.25 deg offset, as that's just a result of my lining things up poorly.

I definitely beleive there's some sort of potential for cross talk between the two sensors on the board, as with larger target spacing distances there would be bizzare artifacts at frequency inflection points, when both sensors approached the same value. You can see that shown in the screenshot below to a mild extent, but I unfortunately deleted some captures that showed the issue much worse at greater air gap thicknesses.

With respect to speed, my SPI bus is clocked at only 3MHz, and transactions are currently taking 50us to transfer two 24 bit integers on a single SPI line. With a 50us transaction, I am able to resolve new rotor angles at 20kHz. A few steps I will take to increase speed are to break out each sensor onto its own SPI bus, which halves the total communication time. I can also increase the SPI bus to 8MHz, and chop off some of the dead time between bits and chip select lines. At the end of the day I believe it should be possible to increase the angular position refresh rate to closer/above 50kHz, which would correspond to a well commutated stepper motor spinning at 15kRPM (well above what any stepper is capable of, so this bandwidth is more useful for BLDCs).

HTMSTMAA Week 11 - 5/20/21

I spent the majority of this week (and last) stuck in debugging world with the encoder peroject. I actually only got everything back up and running last night, so my documentation is a little rushed here.

Below is a video of the system working. The motor I am attached to is unpowered, so I have been spinning it with a pair of vice grips, while trying to keep the jaws far enough away from the PCB to create noise. The motor is dual shafted, so on the top is the inductive encoder, and on the bottom is the CUI AMT102-V, which is a capacative, quadrature, through-shaft encoder that provides a total of 13 bits of noise free rotary position data (so 0.044 deg of resolution). I also considered just powering on the stepper and sweeping through full steps to normalize my encoder data, but have heard steppers can be trusted to +/-5% (which honestly seems quite conservative considering they're just stamped steel). In the end I also wanted to try and configure a quadrature decoder hardware peripheral on an ST micro, which was exciting and simple to get up and running, so I went with the designated encoder.

With both encoders, I can now plot my dubious encoder data against a known source, and begin to get an idea for how linear/sinusoidal my signal is, how repeatable it is peak to peak (remember this is a 6 pole encoder that was machined on a desktop router), and start to see what I am up against in terms of calibration. The results aren't quite as clean as I was hoping, but all of the makings of a solid encoder are there.