diff --git a/firmware/cl-step-controller/src/drivers/step_cl.cpp b/firmware/cl-step-controller/src/drivers/step_cl.cpp
index dd58fcfe09e84d072cf76874a83359aa25c9016a..1569014e5228ee92b94db5842d1deeb10c867fc2 100644
--- a/firmware/cl-step-controller/src/drivers/step_cl.cpp
+++ b/firmware/cl-step-controller/src/drivers/step_cl.cpp
@@ -122,13 +122,25 @@ void Step_CL::run_torque_loop(void){
}
#define MAP_7p2_TO_1 (1.0F / 7.2F)
+#define TICKS_PER_SEC 50000.0F
volatile float _ra;
+volatile float _ra_last;
+volatile float _ra_s; // real angle / sec
volatile float _pa;
void ENC_AS5047::on_read_complete(uint16_t result){
if(step_cl->is_calibrating) return;
_ra = lut[result * 2]; // the real angle (position 0-360)
_pa = lut[result * 2 + 1]; // the phase angle (0 - 1 in a sweep of 4 steps)
+ // want to calculate speeds,
+ //here
+ // need to calculate speed but in context of wrap'd angle: is there a quick way?
+ // then test with scope
+ // then do JS running some loop, maybe 1khz possible? *awk face* send cmd effort down, retrieve datas
+ // probably just will want to retrieve speed ... then see about sweeping the field to build your table,
+ // then next step would be real calib against something known ?
+ _ra_s = (_ra - _ra_last) / TICKS_PER_SEC;
+ _ra_last = _ra; // upd8 for next tick
// this is the phase angle we want to apply, 90 degs off & wrap't to 1
if(step_cl->get_torque() < 0){
_pa -= 0.25; // 90* phase swop
diff --git a/log/2020-10-16_cl-step-speed-01.mp4 b/log/2020-10-16_cl-step-speed-01.mp4
new file mode 100644
index 0000000000000000000000000000000000000000..fbb6181b87218769c5370b647b52a39d5cf26f2f
Binary files /dev/null and b/log/2020-10-16_cl-step-speed-01.mp4 differ
diff --git a/log/2020-10-16_cl-step-speed-02.mp4 b/log/2020-10-16_cl-step-speed-02.mp4
new file mode 100644
index 0000000000000000000000000000000000000000..a7acc143978811780e7c7045e53385aca09e4974
Binary files /dev/null and b/log/2020-10-16_cl-step-speed-02.mp4 differ
diff --git a/log/2020-10-16_cl-step-speed-03.mp4 b/log/2020-10-16_cl-step-speed-03.mp4
new file mode 100644
index 0000000000000000000000000000000000000000..48f651206db8065cf815a76c7b0aa4e9223df68d
Binary files /dev/null and b/log/2020-10-16_cl-step-speed-03.mp4 differ
diff --git a/log/cl-step-control-log.md b/log/cl-step-control-log.md
index 2d3394ea8175455642a277d2ebbf0c56e1a4edad..5866df8ada158874aea894a8319647284dae93b3 100644
--- a/log/cl-step-control-log.md
+++ b/log/cl-step-control-log.md
@@ -1037,8 +1037,33 @@ OK, so my loop is now more like:
and runs 2.4us. The whole loop is now nicely just around 10us, so I could choke the whole micro and run 100kHz and probably trip up, or I'll try running ~ 75kHz, or I could be satisfied with 50 and leave overhead for the processor to do ... well ... other stuff, haha. I.E I will probably want this headroom for positioning PID, etc. Maybe I should just get it mounted on an axis and proceed with the next steps instead of fiddling with speed before I know it's necessary or warranted.
-- consider writing another LUT for RA -> Phase Angle (PA)
- - could do in RAM at startup, might crash ur shit tho
-- do commands from the browser to jiggy jog
-- put on an axis, see how fast it can swing it
-- begin the maths, the control, etc... see if you can optimize that loop, high speed is ur friend
\ No newline at end of file
+### What Now
+
+So, this is great the LL hardware / control strategy / calibration works. Now starts the real business.
+
+There are two things I want to do, first is use these in machines: that means reliably positioning, rolling a PID (maybe) or some other kind of control loop around the thing, to recieve a 'goto pos' command and execute it. In this case, I just want an entry point into the controller to be that 'pos' field, and have a loop running to control around that.
+
+The second thing is to build this 'real torque / virtual effort' calibration: I suspect I want a 2D Table here so that f(effort, speed) = torque. To do this, I would want to build an interface that let me command various efforts, and read back resulting speeds... to build accelerations, calculate forces, and write that table doing some LERPing.
+
+The second thing is actually, probably, easier than the first: since it doesn't require me to do any control. Later, when I *am* doing control, it will be interesting to try to re-align the two studies, to see if, indeed, the accelerations that happen are the ones I expected.
+
+Since that seems easy, I'll start there. Going to get another motor solder'd up, throw it on that axis, and then tool around in JS and CPP writing down motor-efforts & reading-back speed values. Then I should be able to plot some things, and see about writing a routine that sweeps thru a handful of speeds & efforts to try to build that 2D LERP table...
+
+Shiiiit this is tite. I wonder if I should move the logs to the project repo...
+
+
+
+
+
+So I am a bit distracted with just tooling around with this thing, but it feels pretty slick and I'm stoked. Videos above. I need to get into the actual control. The first note, though, is that there is certainly some missing control parameter that is like 'phase advance * velocity' - when velocity ticks up, the commanded current should lead a little longer than 90 degs, but probably no more than 180 degs.
+
+So the first move is to build in to the lower level a velocity measurement. For units, since I have real angles, I should do degs/sec as a unit, and this means I'll have to deal with wrapping angles... hopefully I can find a fast way to do that.
+
+## 2020 10 17
+
+What's a reasonable 'end spiral' for this?
+
+- do phase advance parameter,
+- do js interface for tc down, degs/sec up, plot on loop
+- see about sweeping parameter space, learning real torque
+- measure against real values, from, what?
\ No newline at end of file