casainho wrote: ↑Jun 17 2019 6:19am
buba wrote: ↑Jun 15 2019 6:26pm
I might as well mention another improvement that both I and my father wanted to have for a very long time. And you, thineight, have also mentioned this in your feedback.
This is the resolution of motor power for every ADC current step limited by the resolution of the ADC:
My first question: is this a real issue or desire for optimization? -- I ask this because I never felt anything that I think this can the source of an issue.
Sorry for the late reply!
The entire system is based on controlling the current, and it is therefore controlling the motor torque if in the normal operating mode. So the performance of the current control is dictated by how well the current is measured, and this is a function of the measuring frequency, the resolution and the accuracy of said measurements. This together with the user input is what determines the overall feeling and responsiveness of the system.
I just wanted to share my ambition to further improve the system with some possible benefits. It would especially be noticed during startups and other situations where finer resolution of the current control would be more noticeable.
* Smoother throughout the entire power range
* Every start would be more responsive with almost instant assist
* Smooth acceleration
* More continuous power levels
* Drive train would experience less stress
* Possible less consumption when not having to cycle between different power steps
Walk Assist is not controlled with current as the resolution is too coarse for the fine control that is needed. Instead, PWM control is utilized with almost 9 times the control resolution compared to the current control.
casainho wrote: ↑Jun 17 2019 6:19am
When I started this firmware, I had already developed a lot of it on the KT motor controllers OpenSource firmware. The TSDZ2 motor controller uses the same 8 bits 16MHz microcontroller STM8S105xx and so I just reused the most part of the code. The mainly big difference is the way the "low resolution FOC" algorithm is implemented because KT motor controllers has a specific part of the hardware to do it and on TSDZ2 it was to be done on a different way.
The STM8S105xx PWM channels that are in use have 16 bits resolution but I decided to use only 8 bits. The ADC channels have the resolution of 10 bits but I decided to use only 8 bits. The main advantages of using 8 bits are:
1. Faster processing speed
This microcontroller is very limited in terms of processing speed and to handle FOC we need to do it fast as possible. Also, we would like to increase the PWM frequency to make possible the motor to rotate faster with higher voltage and for that, we need more processing speed.
If not using the 8 bits resolution, the variables would be of 16 bits and the processing time would increase to a factor like x5 -- this would mean that probably FOC could not be implemented or would be worst resulting in the motor having less torque and the battery range would be lower.
I have noticed that a lot of work has been put down to optimize the execution time in the motor.c. Never stated to make it slower or make some compromises. Only as fast or faster. Together with improvements. I was not talking about a complete system redesign. The changes are limited to one single variable.
One approach would be to still keep the 8 bit value but convert it to ui8_battery_current_x6 or ui8_adc_battery_current. Then the operations and variable sizes of 8 bit would remain. Only difference is that we convert the 10 bit ADC value to 160 mA current steps during the ADC conversion. Not saying that is the best approach but am trying to convey that there are several ways of doing it and still maintaining speed and even simplifying code.
casainho wrote: ↑Jun 17 2019 6:19am
2. Low pass filter of analog signals
This motor has wires with high peak currents and PWM high frequency, meaning the electric signals should be noisy.
On the analog signals measured by the ADC, the first 2 bits of the 10 bits are being discarded and this results in a fast way that filters the noisy analog signals.
To discard two bits and therefore reduce the resolution with a factor of 4 is one way of filtering the values. This will remove noise that is between the 625 mA steps. But on the other hand you loose the resolution. Could be possible to filter the value in the same way the other measurements are filtered. But without having seen the type of noise and the amplitude I can not say much. Just that I have never used a sensor without some form of filtering. And more often than not it has been software filters.
casainho wrote: ↑Jun 17 2019 6:19am
3. Reducing programming memory usage
This microcontroller has very low memory size and so we need to save it if we want to implement advanced features like FOC.
The operations with 16 bits would increase to a factor like x4 the programming memory usage comparing to the 8 bits.
Am only talking about one variable and not the entire system. And can be made to 8 bit if going with the approach mentioned above.
-----------------------------
I take it as the community sees no real reason to go this path and there are other more important things to prioritize. That is totally fine! But I think it is good to have a discussion.