Some (like ATMega) are a bit limited in what you can do, while others (like Renesas) even support fractional clock division to let you set more or less any value.
There is an upper bound typically given by the MCU’s main clock, but some MCUs (e.g. SAMD21/51) even allow you to run the timer faster than the main clock (up to 2x as fast on these MCUs).
STM32 has complicated semantics at the moment, which I want to simplify. It tries to work with a fixed PWM range but user-settable frequency.
ATMega has limited options, and allows setting a few different values of PWM frequency.
RP2040 and Renesas allow setting arbitrary frequencies from 1Hz to many 100kHz, whatever the hardware can do. The PWM range (and for the slower speeds also the clock prescaler) adjust to match the chosen frequency.
SAMD and ESP32 (and also nrf52, I think) allow setting the frequency and auto-adjust the range, but at the moment are more limited in the frequencies they let you choose.
Are you running the sensor alignment ?
Sometimes zero_electric_angle ends up being different.
So if you have a good value, use it as a parameter together with the sensor_direction so that it skips the sensor alignment.
Yes, I had motor monitoring on and it showed 0.00 zero angle. I switched the monitoring off, but I could test it again.
I’m still using the default PID values, are they OK for big hub motors?
Maybe take a step back and dial in torque-control first ?
I did the same test with a gd32 board, this implementation as a fixed deadtime:
12000Hz → 0.143A 7.4-7.6 rad/s
14000Hz → 0.141A 7.0-7.2 rad/s
16000Hz → 0.141A 6.7-6.9 rad/s
18000Hz → 0.140A 6.42-6.54 rad/s
20000Hz → 0.140A 6.12-6.24 rad/s
22000Hz → 0.140A 5.7-5.9 rad/s
24000Hz → 0.140A 5.5-5.6 rad/s
The consumption is quite constant, but the speed drops much more than on the stm32.
This is because the deadtime is a bigger and bigger proportion of the pwm period, it makes more sense than the results on the stm32.
I am also confused by the math in the stm32 driver.
The frequency is multiplied by 2 because of the center aligned pwm which needs half the period for the same frequency as the normal pwm.
But this doubled pwm frequency is used for deadtime calculation.
So at 16Khz pwm frequency and 2% deadtime, I get 625ns, but I would expect 1250ns.
@runger I updated my sFOC library to the latest -dev version of 02.09 and recompiled the motor-test I was using before.
I got a pragma-message, but it was flashed anyway
....Arduino\libraries\Arduino-FOC-dev\src\drivers\hardware_specific\stm32\stm32_mcu.cpp:8:49: note: '#pragma message: SimpleFOC: compiling for STM32' 8 | #pragma message("SimpleFOC: compiling for STM32")
It seems to run smoother now, but I feel some misfiring with irregular pattern.
Is it possible to change motor.zero_electric_angle or driver.dead_zone on the fly or do I have to recompile?
You can change zero_electric_angle but not driver.dead_zone.
I suggest you increase the deadtime to 3-4 and reduce the PWM frequency to 16000 to be on the safer side on STM32.
I’ve seen there is a TorqueControlType::dc_current implemented, but is it the sum of the inline currents from (currentSensor.getMagnitude) or can I connect it to the OpAmp of the DC-current shunts?
I’ve already made some tests with this OP-Amp output. There is a minimum readout of “150” ( sampled before driver.init) and it increases to “170” at 1A (measured with external powermeter)
The powermeter has a range of 130A, so it’s not very useful to calculate the gain of the OpAmp.
I could try to identify the resistor values of the output and neg. input and calculate the gain from there, right?
I already identified this as a possible improvement but I am not sure there will be a lot of interest, is this common on other boards ?
Ideally in the same way as the phase current, you need a gain (it’s usually inverted on hoverboard controllers so it’s negative), and offset calculation should be done to find the 0.
I found this useful in the past, it could be valid for your board.
The dc-current mode works with the inline or low side current sensors, and calculates the dc current from these…
As yet there is no way to connect the bus sensor.
To be honest I am always confused about the dc current.
Simplefoc is calculating the euclidian distance with alpha and beta sign*_sqrt(i_alpha*i_alpha + i_beta*i_beta).
But I was reading about euclidian distance with d and q currents.
What is being measured with this shunt, motor current or battery current ?
;TLDR that was a dead end with these splitboards and sFOC
It seems, I’ve got the worst splitboards for sFOC adaption:
M0 MCU with 64k flash
no suitable current sensing
hall sensors which only work good enough when using smoothingSensor
Maybe I could get the halls working with smoothingSensor but flash and math-capacity is already quite limitted.
I thought of adding an external position sensor driven by a GT2 pulley, but there are problems with finding available SPI-pins and the missing current sensors .
I’ve tested the board a bit more with a crippled version of @Candas1 applicaction of smoothingSensor.
I couldn’t use the commander and IDK how to replace the command.scalar(&phase_correction, cmd); thing in doPhaseCorrection
Same to command.scalar(&zero_angle, cmd);in doZero
Anyway it worked a bit better as long as the wheel doesn’t run free. (brake it by hand)
While I was scoping around on the gate driver in- and outputs I noticed a clear signal, when I scoped chassis vs GND. The probe is in 10x mode and I use 12V supply.
I don’t understand where that comes from, unless one of the phases has GND contact?
But I already replaced the motor and both behaved the same.
Any ideas, what I could measure? One of the MosFets dead?
This was for testing the smoothing sensor, I removed those commands from my dev branch.
Entered the value for inductance was also making it a bit smoother with higher speeds in voltage mode thanks to lag compensation.
Why do I see a voltage on chassis? The only connection between chassis and motor/controller is the motor shaft.
The voltage is the same frequency as the PWM signal.
I’ll flash the second splitboard today and see, if it’s gone. But I’d like to know, what I did wrong.
It was perfectly smooth and fast the first day in velocity mode. Now I can merely run it in torque mode…
I am not sure what do you mean by chassis ?
Usually the mosfet’s drain is isolated from the screws with a kind of plastic washer.
Or they use plastic screws
