Skip to content
Snippets Groups Projects
Commit 8e7ca8a4 authored by David Preiss's avatar David Preiss
Browse files

Update README.md, images/encoderCouplingLargeGap.png,...

Update README.md, images/encoderCouplingLargeGap.png, images/SPItransaction.png, images/spinningIndicator.mp4, images/spinningIndicator.png files
parent e34f4085
Branches
No related tags found
No related merge requests found
......@@ -4,7 +4,7 @@
## HTMSTMAA Week 12 - 5/27/21
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.
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.
[<img src="images/spinningIndicator.png" width="800">](https://gitlab.cba.mit.edu/davepreiss/ldcoder/-/blob/master/images/spinningIndicator.mp4)
......@@ -14,9 +14,19 @@ It's worth noting that the AMT encoder that I am using as a reference is rated t
![encoderNoise.png](./images/encoderNoise.png)
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.
![revolutionRepeatability.png](./images/revolutionRepeatability.png)
One big question I had was if EMF from the motor would manifest as noise at the sensor.
[<img src="images/externalRejection.png" width="800">](https://gitlab.cba.mit.edu/davepreiss/ldcoder/-/blob/master/images/externalRejection.mp4)
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.
![encoderCouplingLargeGap.png](./images/encoderCouplingLargeGap.png)
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).
![SPItransaction.png](./images/SPItransaction.png)
## HTMSTMAA Week 11 - 5/20/21
......
images/SPItransaction.png

951 KiB

images/encoderCouplingLargeGap.png

47.1 KiB

File moved
File moved
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please to comment