Update README.md, images/dyno/comparePlot1.png, images/dyno/comparePlot2.png,...

Update README.md, images/dyno/comparePlot1.png, images/dyno/comparePlot2.png, images/dyno/timerRegisters.png files

README.md

 # Dynamometer
 
-## Week 3
+## Week 4 - 3/25/21
+
+This week I focused on improving data analysis (see the nicely interpolated speed-torque curves below), speeding up test times, and slogging through the endless process of finding bugs and improving repeatability.
+
+![comparePlot1.png](./images/dyno/comparePlot1.png)
+
+Becuase getting an idea of repeatability involves running tests over and over again, I wound up writing a good deal of code to minimize test length. The bulk of the speed up efforts stem from the effects of the back-emf produced by the absorber as it is being spun by the test motor. If my absorber produces 10V when being spun at 500RPM, I need to overcome this voltage before I can actually start producing torque on the test motor. Imagine I am sweeping absorber voltages with 0.1V increments. Unfortunately this means that I am sweeping through absorber voltages (either actively or passively), it means I would need to sweep from 0 to 10V (100 measurements at 0.1V increments!) before I actually started producing any torque on the motor. That's why you can see a lot of points clustered at the bottom of each RPM sweep, where many of effectively the same measurement are being taken, before we have overcome the back-EMF of the motor. The code that I ultimately settled on is to measure a torque floor at the start of each RPM measurement, and then tick up the sweep counter until torque surpases the torque floor by some threshold. The associated sweep counter becomes the new starting point for the counter, so I waste less time sweeping all the way up to that counter value each time. This step saves on the order of 10's of minutes if sweeping over smaller RPM intervals, like 25 RPM or 50 RPM. What might be better (assuming I am commited to this particular brushed DC absorber motor) would be to really measure the KV of the absorber, and then actually just start PWMing at the voltage directly under the assumed back-EMF for an associated RPM. Oh well, might resort to that later, but it was late at the time and it's working now...
+
+All of this trouble has certainly had me questioning the use of a brushed DC motor as an absorber. An eddy current brake or even a mechanical disc brake for example would be able to generate a linear and continuous torque response, indepedent of what's happening with the test motor.
+
+Another speed-up effort was switching to low pass filtering rather than averaging for current sensing, which is still contributing more nosie than I would like considering the current measurements are very small and on the order of noise + voltage is constant. This results in occasional anomalies in the efficiency data. A huge bottleneck in test speed is the 80Hz sample rate of the HX711 load cell amp. I currently average 10 samples in rapid succession to also smooth out some noise, but because there can be very real jumps in torque data, I am not quite sure that a low pass filter that spans torque sweep steps is a good idea here as well...
+
+I also caught an interesting bug that was manufesting as all of my torque measurements shifting up or down on the order of 10 N*cm between tests for the same motor. I believe this stemmed from taring the torque sensor after energizing the test motor. This would generate not-insignificant amounts of torque to overcome friction in the slewing bearing and absorber motor, depending on where the test motor had come to a rest during the last stall from the prior test.
+
+Before I mentioned the problem of back EMF creating a threshold voltage that you needed to reach in order to start generating usable torque. In the plot below you can see that really clearly, with the 3 clusters of sample points pointed at by the callout. What's happening here is that the RPM sweep begins in passive mode, so just PWMing between open and closed absorber motor windings. At lower RPM (150, 200, and 250), there isn't enough back EMF to stall the motor, so the controller switches over to active mode. When this happens, we start at PWM of 0, so we again have to sweep all the way up to a voltage that overcomes the back-EMF of the motor. At higher RPM, this transition happens at higher and higher torque, as shown in the plot below. You can also get an idea of my current repeatability between the two tests run above and below. Efficiency data is sort of all of the place, and the very coarse torque increments at later RPM result in lots of uncertainty in terms of where peak torque for a given RPM will land (despite relatively consistent data for lower RPM).
+
+![comparePlot2.png](./images/dyno/comparePlot2.png)
+
+I had a suspicion that the default Arduino analogWrite's PWM frequency (about 1.8kHz for the M4 feathers) was slow enough to be on the order of cogging in the stepper and/or the absorber, resulting in weird harmonics causing early torque stalls where the torque might jump as it hits a harmonic. With some help from Jake, I switched over to routing timers and setting up PWM on the register level for the SAMD51. Despite having access to a 120 MHz clock, the prescalar and PWM resolution increments are quite coarse, so the best I could do as an improvement was getting to ~8kHz with the same 8-bit resolution. In the end I intend to switch over to 16-bit PWM resolutionm which actually takes me right back to 1.8kHz. Because the KV of my absorber is large enough that I only resolve extremely coarse torque steps at higher RPM (see the plots above), while the 256 step sweep is more than enough for lower RPM, I will need much more for higher RPMs.
+
+![timerRegisters.png](./images/dyno/timerRegisters.png)
+
+Overall this week was a humbling lesson in why it's easy to protoype something that appears to be working on a surface level, generate a bunch of beautiful data or create a nice working demo, and still only have done 50% (if not less) of the work to create something truely reliable and useful. 
+
+## Week 3 - 3/18/21
 
 [Here's video of the dyno running as of last night.](https://vimeo.com/525624403) I thought I remembered it being possibleto embed youtube/vimeo links directly into gitlab markdown, but it doesn't seem to be working atm.
 
@@ -35,7 +59,7 @@ One very useful parameter space to explore will be the bounds on peak torque thr
   <iframe src="https://player.vimeo.com/video/525624403?badge=0&amp;autopause=0&amp;player_id=0&amp;app_id=58479" frameborder="0" allowfullscreen="true"> </iframe>
 </figure>
 
-## Week 2
+## Week 2 3/11/21
 
 [<img src="images/3_10_21_frame.jpg" width="900">](https://gitlab.cba.mit.edu/davepreiss/motor-testing-data/-/blob/master/images/3_10_21.mp4)
 
@@ -47,7 +71,7 @@ Below is a high level overview of the dynamometer showing each major subsystem (
 
 ![alt_text](images/dyno/overviewTemp.png "image_tooltip")
 
-## Week 1
+## Week 1 3/4/21
 
 ### RPM Measurement