This whole thread is honestly one of the more interesting deep dives I’ve seen on MK electronics. You basically confirmed what many of us suspected — the MK servo isn’t a true positional servo like the original PF one, it’s more of a continuously driven unit reacting to duty cycle, which explains the flutter and why they likely crippled it to 3 positions in firmware.
Your frequency findings make sense. The hub outputting ~470 Hz while the servo behaves properly closer to ~980–1200 Hz explains the weird compatibility behavior people are seeing. The fact that LEGO PF servos still work proportionally for some users suggests MK may have quietly changed firmware revisions over time.
Moving to GeekServo + ESP32 was the right call. At that point you’re no longer fighting MK’s design limitations, you’re just translating PF-style PWM into proper RC-style pulse width control. And yes, you absolutely need a microcontroller in between — this isn’t realistically doable with just analog components. You’re decoding one PWM scheme and re‑encoding another with timing math in between. That’s firmware territory.
Also, your reasoning about ditching the MK hub entirely is solid. Once you intercept both steering and throttle, you’re basically building your own receiver/ESC logic anyway. Using ESP32 with native Bluetooth and a proper gamepad is cleaner long-term.
Honestly, this evolved from “fix MK servo” into “build a better PF ecosystem,” and that’s way more interesting.
