There should be max power apply delay

[allstone]

There should be max power apply delay somewhere. I.e. maybe cfww has modified that to apply max power faster, thus rising to steep hills faster.

If not this, then there should be something else, like battery voltage setting from which the FW reduces the max power. Maybe even more than 1 setting, like steps. Because with lower battery % CFWw still releases more power quickly, but custom FW does not release it.

P.S. Similar to cruise control delay https://github.com/BotoX/xiaomi-m365-firmware-patcher/blob/0596acf06edd78d3c3184225d6eda3c87a9d7c66/web/app.py#L60

[Kulimeya]

There should also be an option to disable this battery saving mode, when the percentage is low. This seems to start pretty early and I don't want to drive the last 2km home with reduced speed, just because I have 40% battery left. If I want to save battery, I can enable the eco mode. Would be cool if you could find the spot where that happens when you get your ST-Link!

[BotoX]

The reduced speed is due to the voltage of the batteries sinking. There is no software speed limit. Less voltage = less max motor speed, simple physics.

(I'll be building a 12S battery and make compatible BMS firmware for a chinese BMS because this also annoys me - gotta go fast)

[robhu]

Why is it that the drop in motor power happens at different battery levels according to http://spzjulien.royalwebhosting.net/M365/M365Firmwares/Comparatif%20FirmWares%20v4%20graphique.pdf ?

According to that, for some firmware it is at 50% and for others it is at 30%?

[BotoX]

That chart has been generated by people driving around their city and recording the stats in the app. You'd get different results depending on the weather, weight of the driver, how you're driving, how good your battery pack is, etc.

[robhu]

I totally agree, but I think it is noteworthy that half of the firmwares drop the power drawn between 50 and 45 (i.e. at 50% the firmware changes to a more economy budget of power drawn), and the other half (excluding DYOC 801) do so at 30%. Perhaps it is a coincidence and is actually a property of BMS or maybe the DRV firmwares are doing something different? It also seems significant that the chart claims DYOC 801 does not simply switch to a lower power draw at the particular battery level, but instead has a more gradual decline as the battery level declines (they are trying to match something more like the P CFW ideal P (I<20A) line). Maybe DYOC 801 is doing something unique they have coded in that the other ("hex edit some positions" firmwares) are not?

[robhu]

Hmm..

According to https://trello.com/c/LAjrqrDo/16-versiones-y-downgrade the BMS:

1.1.5 (BMS 115). Last version of the controller that shows the most real percentage and has better battery management. 1.0.7 (BMS 107): Old version that has higher watt release and less consumption control. The percentage that shows is contrary to reality (30% is equivalent to 50% real).

So perhaps the two sets of different battery % change positions are due to BMS (matches the 30% and 50%), but the chart claims DYOC801 is doing something different to all of the others...

[BotoX]

All of the dyoc firmwares change the exact same stuff: max speed normal and eco, motor power constant, motor start speed and that one line which idk what it's even for. I can post a diff tomorrow when I'm on my PC. BMS does not control power/amps, all it can do is blow a fuse when something is wrong with the battery. And while there is code which changes the acceleration constant at some unknown condition, it does not touch the max speed. As I said that chart is not really useful, if you want usable data then you'll have to test the scooter on a dynamometer and also plot the cell voltage, temperature, amperage and used capacity. But I'm quiet confident that there will be no difference between the different firmwares at constant load.

I have been experimenting with my own throttle control and have been driving with it myself for a few days, but I'm not quiet convinced of it yet - it feels almost the same. And yeah if I got that st-link and a lot of free time I can dig deeper and make sense of the code.

[robhu]

When you say "And while there is code which changes the acceleration constant at some unknown condition, it does not touch the max speed" are you referring to the "Motor power constant"?

It is my understanding that the chart is claiming that all the other firmwares change the motor power constant at a certain battery % (i.e. 50% or 30%), which the claim being made by the chart is that the DYOC801 beta firmware is changing the motor power constant also at a certain point, but that uniquely for this firmware, the constant continues to change as the battery level falls (which AFAICT is the only way they could get that line).

I'm not sure how they gathered the data for the chart - at one point I believe they were crowdsourcing lots of data from users in to a Google spreadsheet, but I don't know whether that is what they used to construct this chart. The chart seems very useful to me, and matches very well the experience and release notes for the different DRV firmwares. Maybe it's results are wrong, but what it claims and is trying to do appears useful.

Yes of course max speed isn't changing (they're not claiming that), changes occur as cell voltage drops (that is kinda the point of the chart, that's what it is showing), and yeah temperature etc affect things (but will do so to all firmware), but none of that takes away from what the chart is indicating.

I'm just commenting on the sidelines from what I've seen and read in the Telegram chats. I look forward to seeing you dig deeper with your st-link :) Thank you for the site and the research you're doing :)

[AlexeySochiRus]

Greetings from Russia You did a very good job! But there is one point. You made a designer that makes firmware similar to the firmware with the base version 1.3.0-1.4.0. Can you change your constructor so that it can use the base version of CFW2.0Weak or CFW2.0? I use CFW2.0 (with 12s4p "10 wheels 50V 30A = 1500W) because there is a quick response to acceleration. All that I could do in your designer has a slow reaction to the acceleration of the scooter and the scooter is turned off on a large lift. CFW2.0 never turned off the scooter. The temperature of the wheel was within 70 degrees. The motor is varnished. What do you think about the fast response to acceleration in your constructor? CFW2.0 is firmware based on current, but your designer makes firmware based on speed. Can you make changes to the designer?

[allstone]

Alexey you can now enable algorithm based on current ;)

[BotoX]

Fixed by c3987cbb