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

Update README.md

parent c86b7f41
No related branches found
No related tags found
No related merge requests found
......@@ -8,9 +8,15 @@ Welcome to the last week of the inductive encoder project (as a part of HTMSTMaA
[<img src="images/spinningIndicator.png" width="800">](https://gitlab.cba.mit.edu/davepreiss/ldcoder/-/blob/master/images/spinningIndicator.mp4)
From the data last week it was clear that my sensor was saturating with copper present (see how it flatlines on the low end in the screenshots from that week). To remedy this, I started by trying to simply increase the air gap between the coils and the copper target, but found that the coils were so sensitive to the increase in axial distance (axial sensitivity is tied very closely coil diameter) that the SNR penalty from increasing the air gap made this a non-factor. So instead what I needed to do was increase my pole count to the next multiple of 12 from 6, so 18. With a given Sin/Cos coil spacing (in this case for me it's 75deg). Jumping to 18 targets was slightly more than optimal, but I was able to resolve a much more sinusoidal signal after doing it, with plenty of resolution between the high and low copper-present peaks.
In machining the smaller targets on the ShopBot Desktop, I noticed that some copper pads appears significantly smaller than others. I confirmed this under a microscope with ImageJ, so machined a last minute replacement on the Roland with much better results. You can see the comparison of the two in the image below. Given this confirmation, I am intending to move my PCB milling operations to the Roland, which showed some really impressive results.
[<img src="images/rotorTargets.png" width="800">]
![encoderError.png](./images/encoderError.png)
It's worth noting that the AMT encoder that I am using as a reference is rated to [0.25 deg of accuracy](https://www.cuidevices.com/product/resource/amt10.pdf). 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 +/-
It's worth noting that the AMT encoder that I am using as a reference is rated to [0.25 deg of accuracy](https://www.cuidevices.com/product/resource/amt10.pdf). So we are definitely within the right order of magnitude for a commercial product. The spec is also ambiguous in that it doesn't specify a +/-
![encoderNoise.png](./images/encoderNoise.png)
......@@ -18,15 +24,15 @@ One big question I had was if EMF from the motor would manifest as noise at the
![revolutionRepeatability.png](./images/revolutionRepeatability.png)
[<img src="images/externalRejection.png" width="800">](https://gitlab.cba.mit.edu/davepreiss/ldcoder/-/blob/master/images/externalRejection.mp4)
[<img src="images/externalRejection.png" width="500">](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)
[<img src="images/encoderCouplingLargeGap.png" width="800">]
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)
[<img src="images/SPItransaction.png" width="800">]
## HTMSTMAA Week 11 - 5/20/21
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment