LEGO's original DCMotor PWM pattern / pybricks implementation?

[ArneFOL]

I am working on mimicking the duplo train functionality in my (son's) City trains, especially run/stop by pressing the train button. I would like to restore the original behavior of the train when operated with the remote, including pwm "sound" and pulling "force" (efficacy) at ten different speeds.

For people not familiar with term "pwm": Pulse width modulation is often used to drive a device (lights, motors, etc.) with pulses of constant voltage but with different duration in a fixed interval. Visual example:
10 % --> x_________x_________x_________
60 % --> xxxxxx____xxxxxx____xxxxxx____
90 % --> xxxxxxxxx_xxxxxxxxx_xxxxxxxxx_
Due to the constant interval of voltage spikes (above "picture" shows 3 cycles), a motor produces a noise with constant frequency (with a modulation in harmonics, for the music lovers) at varying "power".

I "discovered" that the train motor does not give it's usual pwm sound when driven by the DCMotor.dc(duty) command. It also simply does not move the train engine when von duty<30. I got the impression that there is no pwm present in the pybricks DCMotor.dc command.

So I startet making my own "pwm" function, but it does not really work, at least not for pulse width below 1.0 ms. It "feels" like there is an interference with an existing pwm pattern that I cannot hear.

My questions now are:

1. Is there pwm in pybricks' dc motor command - and if so: why is the train performing so badly compared to the original lego pwm pattern?
2. Have you analyzed Legos pwm pattern (for "all" 10 speeds the remote offers)? If so, could you please share the results so one can copy code that?

[dlech]

Pybricks uses a 10kHz PWM while LEGO uses a 1kHz PWM, which is why they sound different. This is hard-coded in the firmware, so can't be changed at runtime.

The LEGO scaling is probably not linear. In other words, their level 1 might actually be 30% duty cycle rather than 10%. Or they even could using some sort of feedback loop to get a constant speed.

Also the Pybricks firmware is using a clock with a 1ms tick, so it isn't possible to get accurate timing for anything below that. So that probably explains your observations of trying to make your own PWM.

[lgrahl]

Thanks for your explanation! I was wondering why the original firmware produces PWM whine but Pybricks doesn't. Honestly, no PWM whine is a huge win for me because the PWM whine of the LEGO firmware is abysmally loud on a larger LEGO train layout.