cheali-charger: pre-release version 0.99

[Paweł Si]

Hi All,

I've uploaded a pre-release version 0.99 to:

https://github.com/stawel/cheali-charger/tree/master/hex/unstable

(the final release will be 1.00)

maybe some of you will have time to test it,

it's mainly a merge of the njozsef and arm_draft branch.

what's new:

1. NiMH/NiCd/Pb battery cycling (njoszef)

2. arm: nuvoton M0517 CPU support (arm_draft)

3. arm: second UART (sasam)

4. charge/discharge time limit (njoszef)

5. some nice animations (njoszef) 

6. additional screens (njoszef) 

7. min. output current setting (njoszef)

8. LiXX overcharge setting

9. LiXX overdischarge setting (now it can be also negative)

10. eeprom CRC check

11. disable LogView logging 3min. after end of charge

12. output power limit in real time (not well tested ;) )

...

what is disabled (but in the branch):

1. LiXX, NiZn battery cycling (njoszef)

2. more animations (njoszef)

what will be in the 1.00 release but is still not ready:

1. README! (as usual)

2. some additional calibration safety features (njoszef)

3. maybe we can merge with Iggnus branch (??)

4. bug-fixing

5. any suggestions?

what will not make into the 1.00 release:

1. 200W chargers: PID

2. ADC: adding random noise

Best Regards,

Paweł

[Samuel Lang]

Hi Pavel,
Thanks for the hard work!!

I'm missing 2 key points:

1. PID bug for ARM on Error/A
2. Great implementation of dynamic power from Iggnus! :(

Please!
Thank you!

--
You received this message because you are subscribed to the Google Groups "cheali-charger" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cheali-charge...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Paweł Si]

2014-11-30 10:00 GMT+01:00 Samuel Lang <ma...@lang-sam.de>:

I'm missing 2 key points:

Thanks for reminding me

 

1. PID bug for ARM on Error/A

I've changed the PWM frequency to 32kHz an increased 

OUTPUT_PWM_PRECISION_PERIOD to 32760

this should be equivalent to changing the "A" parameter by a factor of 21 (??),

I've tested it and it seems to work, 

but If you can, please do some test and if it doesn't work for you as expected

then I need a new "A" value.

2. Great implementation of dynamic power from Iggnus! :(

yes, I forgot about this, sorry, but I should ask Iggnus first,

Iggnus, what do You think, can I merge the "dynamic power" code?

I need your permission.

Best Regards,

Paweł

[Igon]

Iggnus, what do You think, can I merge the "dynamic power" code?

I need your permission.

Of course you can!  »^_^« 

[sasam]

Hi Pawel,

Today I compile your last version for may ARM charger. Most of time I played with ST-LinkV2 trying to remove unlock bit, but without success :(
Also I found that for TxSoftSerial it is necessary to adjust irq for all handlers.
SOFT_SERIAL_IRQ_PRIORITY must be higher priority. When PWM_IRQ & SERIAL_IRQ are same we have sporadic error in serial communication.

With this configuration TxSoftSerial work as expected.

#define SOFT_SERIAL_IRQ_PRIORITY           0

// decrease priority need for TxSoftSerial

#define TIMER_IRQ_PRIORITY                 2

#define HARD_SERIAL_IRQ_PRIORITY           2

#define ADC_IRQ_PRIORITY                   2

#define ADC_C_DISCHARGE_IRQ_PRIORITY       2

#define OUTPUT_PWM_IRQ_PRIORITY            1

How acurate PWM_IRQ timing must be?
https://github.com/sasam/cheali-charger/commits/master

Best Regards,
Saša

[Paweł Si]

2014-12-02 1:36 GMT+01:00 sasam <sasa.mi...@gmail.com>:

Hi Pawel,

Today I compile your last version for may ARM charger. Most of time I played with ST-LinkV2 trying to remove unlock bit, but without success :(
Also I found that for TxSoftSerial it is necessary to adjust irq for all handlers.
SOFT_SERIAL_IRQ_PRIORITY must be higher priority. When PWM_IRQ & SERIAL_IRQ are same we have sporadic error in serial communication.

With this configuration TxSoftSerial work as expected.

#define SOFT_SERIAL_IRQ_PRIORITY           0

// decrease priority need for TxSoftSerial

#define TIMER_IRQ_PRIORITY                 2

#define HARD_SERIAL_IRQ_PRIORITY           2

#define ADC_IRQ_PRIORITY                   2

#define ADC_C_DISCHARGE_IRQ_PRIORITY       2

#define OUTPUT_PWM_IRQ_PRIORITY            1

If you say this works better, so let it be.

 

How acurate PWM_IRQ timing must be?

We are modulating the PWM signal to get better resolution,

fortunately the PWM registers are buffered so it shouldn't be a

big problem (as long as we don't miss any interrupts)

[Dirk Knop]

Hi all,

I updated my B6AC to 0.99 and started first tests (will get deeper into it this weekend - I don't want the charger run without monitoring it closely). The charging curve looks pretty good now, I like that! A little improvement could be done with a Kalman filter which is used for Drones or in robotics pathfinding, I think: http://bilgin.esme.org/BitsBytes/KalmanFilterforDummies.aspx

Thank you for implementing a negative offset for the discharge end! This will also be part of my tests during the weekend. :)

I noticed the charger now beeps every now and then while charging; I didn't take the time, but is that wanted behaviour? I think it beeps every minute, even when I disabled beep in the options.

Thank you for the great work you all spent!

Best regards,

Dirk

[Paweł Si]

2014-12-05 8:12 GMT+01:00 Dirk Knop <dmk...@gmail.com>:

Hi all,

I updated my B6AC to 0.99 and started first tests (will get deeper into it this weekend - I don't want the charger run without monitoring it closely). The charging curve looks pretty good now, I like that!

 

Yes, njozesf added a charge current rising limit to the charger,

and I also added a simple low pass filter.

A little improvement could be done with a Kalman filter which is used for Drones or in robotics pathfinding, I think: http://bilgin.esme.org/BitsBytes/KalmanFilterforDummies.aspx

I've added this proposition to my TODO list (github issues)

I'm not sure if I will find the time, but we will see.

Thank you for implementing a negative offset for the discharge end! This will also be part of my tests during the weekend. :)

I noticed the charger now beeps every now and then while charging; I didn't take the time, but is that wanted behaviour? I think it beeps every minute, even when I disabled beep in the options.

I've corrected this bug,

In fact the beeping occurred only when "Settings->beep:" was set to "No"

(clearly not what I meant :) )

Best Regards,

Paweł

[SileNTViP SileNTViP]

Maybe change

    if(!balance && !v_out && Keyboard::getPressed() == BUTTON_START) {
        ok_++;
    }

to

    if(!balance && Keyboard::getPressed() == BUTTON_START) {
        ok_++;
    }

 to charge the batteries run down to 0V?
And correct CoIDE project...
I don't know why my B6 nuvoton can't calibrate discharge. Maximum value calibration is 1561 and discharge ~52 amp

[Paweł Si]

2014-12-05 15:40 GMT+01:00 SileNTViP SileNTViP <silen...@gmail.com>:

Maybe change

    if(!balance && !v_out && Keyboard::getPressed() == BUTTON_START) {
        ok_++;
    }

to

    if(!balance && Keyboard::getPressed() == BUTTON_START) {
        ok_++;
    }

 to charge the batteries run down to 0V?

For safety reasons it's not a good idea,

but if you have a discharged battery below the safety limit

you can always:

1. set the battery to "Unkn" 

2. set a small voltage (for lipo the safety limit is set to 3V per cell, so set the voltage a little bit higher then that)

3. set the smallest possible current  (100mA)

4. go to charge and wait until the battery voltage goes higher then the safety limit.

But still, the battery voltage should be greater then 0.5V

Or you can just rewrite the code ;)

And correct CoIDE project...

fixed

  

I don't know why my B6 nuvoton can't calibrate discharge. Maximum value calibration is 1561 and discharge ~52 amp

fixed, after flashing go to: "options"->"reset default" and press "yes".

[SileNTViP SileNTViP]

Thank you. Need to add this to manual (readme). And many other things ) to avoid further stupid questions )))

[SileNTViP SileNTViP]

Add this to your docs for nuvoton )

[Paweł Si]

Thanks for the picures.

Best Regards, 

Paweł 

[SileNTViP SileNTViP]

 Strange. But with last firmware my nuvoton don't want calibrating discharge ( with default value 68 on 100ma menu i recive ~5ma and 431 value ~16.5ma. Maybe hardware is damaged?

[Paweł Si]

2014-12-08 8:58 GMT+01:00 SileNTViP SileNTViP <silen...@gmail.com>:

 Strange. But with last firmware my nuvoton don't want calibrating discharge ( with default value 68 on 100ma menu i recive ~5ma and 431 value ~16.5ma. Maybe hardware is damaged?

The default calibration for discharge should be:2856 on 100mA, 9051 on 300mA

https://github.com/stawel/cheali-charger/blob/master/src/hardware/nuvoton-M0517/targets/imaxB6-clone/defaultCalibration.cpp#L50

did you run: "options"->"reset default" ?

[SileNTViP SileNTViP]

After flashing device show reset eeprom and i choose yes. Then i'll try calibrating.

[Paweł Si]

2014-12-08 14:21 GMT+01:00 SileNTViP SileNTViP <silen...@gmail.com>:

After flashing device show reset eeprom and i choose yes. Then i'll try calibrating.

this resets only eeprom parts that aren't valid,

please run "option"->"reset default"

[SileNTViP SileNTViP]

понедельник, 8 декабря 2014 г., 16:29:06 UTC+3 пользователь cheali-charger написал:

Maybe program need write default settings? when eeprom clearing? I try reset. Thank you.

[Igon]

Pawel can we increase accuracy of resistance measuring by doing it at specially generated swings of current?
(measuring at small dI and dV gives us a very inaccurate results - up to two times difference... and sometimes much more)

[Paweł Si]

2014-12-08 23:37 GMT+01:00 Igon <igg...@gmail.com>:

Pawel can we increase accuracy of resistance measuring by doing it at specially generated swings of current?

Yes, this shouldn't be a problem, any big current swing

will update the resistance. 

(measuring at small dI and dV gives us a very inaccurate results - up to two times difference... and sometimes much more)

It's also worth notice that the internal resistance

changes during the charge process, currently we do 2 measurements:

1. at the beginning of the charging

2. when the voltage reaches 4.20V per cell

a more reliable value is the second one.

 

[Igon]

Pawel you switched DelayStrategy to the seconds but did not modify Time:diffU16().. I think it can fail after 18 hours of work

And a question about dV charging with enabled Dynamic Max Power -
What happens if input voltage (and output current) will be decreased during charging NiXX?

[Paweł Si]

2014-12-23 22:43 GMT+01:00 Igon <igg...@gmail.com>:

Pawel you switched DelayStrategy to the seconds

but did not modify Time:diffU16().. I think it can fail after 18 hours of work

I left you a comment on github (on your commit), 

In my opinion this implementation should be fine, we do arithmetic in mod 65536 (uint16_t).

And a question about dV charging with enabled Dynamic Max Power -
What happens if input voltage (and output current) will be decreased during charging NiXX?

hmm... a very good question, I have no idea.....

I would say that with "Dynamic Max Power" enabled it should work just fine,

but when its disabled (the default) and the output power is big enough

the charge might try to compensate the dV fall

[Igon]

sorry, I missed it - still discovering github...
Compiler dependent answer at equation i=i++ make me nervous with "overflow mathematics"

It can't fully compensate dV with LIMITED power level
but the amount of such compensation is a question... 
and this power LIMIT is highly dependent on input voltage (with "Dynamic Max Power")

[Dave Johnson]

I finally jumped from the 0.32-njoszef branch to this 0.99.  The Amperage reporting seems to be improved (more closely matches Fluke inline).  However, just like Nagy 0.32, it won't charge greater than 1.3A on 6S (approximately 30W).  Hardware is Accucel-6 50W 6A but with imaxB6 original ""SK6000A 10/10/2009" board inside.  Stock FW will charge to 50W/6A without an issue.

Is this a common problem ?  Thanks for the software :)

-=dave

[Paweł Si]

2015-01-25 5:22 GMT+01:00 Dave Johnson <davejoh...@gmail.com>:

I finally jumped from the 0.32-njoszef branch to this 0.99.  The Amperage reporting seems to be improved (more closely matches Fluke inline).  However, just like Nagy 0.32, it won't charge greater than 1.3A on 6S (approximately 30W).  Hardware is Accucel-6 50W 6A but with imaxB6 original ""SK6000A 10/10/2009" board inside.  Stock FW will charge to 50W/6A without an issue.

I've checked 2.2A charging current  on 6S and it works for me,

are you able to charge a 3S with current greater than 1.3A? (for example 2.2A)?

could you make a video of your 6S  charging?

[Dave Johnson]

Yes, 3S has same result. All calibrations completed as expected.

http://youtu.be/Mklc20nJE8U

-=dave

[Paweł Si]

definitely there is something wrong,

could you do anther video?

go to: "setting"->"calibrate"->"I charge"->"1000mA"

and try to go up with the current, as high as the current changes on your ammeter,

but go up slowly, I also what to see how the current changer over time.

[Cornelius C]

It's getting better, I like this pre-release, thank you guys! Seems to be realy good, very acurate readings(voltage and current), with turnigy accucell 6 6A( sk6000a pcb) and imaxb6 orig. firmware, I can charge and discharge with 10 mA! very acurate! usefull for small lipo's. Measurements on battery out, at low voltage, are less acurate, about 30 mV less, than multimeter readings (I suppose, it's a hardware issue) . It would be great, to add on the fly ajustments, Igon features.

Regards

[Paweł Si]

2015-02-07 20:42 GMT+01:00 Cornelius C <corn...@gmail.com>:

It's getting better, I like this pre-release, thank you guys! Seems to be realy good, very acurate readings(voltage and current), with turnigy accucell 6 6A( sk6000a pcb) and imaxb6 orig. firmware, I can charge and discharge with 10 mA!

you can change the minimum charge/discharge current in "options"->"settings"->"min Iout: __"

see: https://github.com/stawel/cheali-charger/blob/master/docs/settings/settings.md

 

very acurate! usefull for small lipo's. Measurements on battery out, at low voltage, are less acurate, about 30 mV less, than multimeter readings (I suppose, it's a hardware issue) . It would be great, to add on the fly ajustments, Igon features.

Regards

--

[Cornelius C]

that's right, so I set "min Iout" down to 10 mA and it works good. What about lower end voltage readings on batt out? if i calibrate it right(in expert calibration) on lower end( ex. 1 lipo or nimh cell) then it reads wrong on high end and vise versa. Any ideas?

[Paweł Si]

2015-02-07 23:34 GMT+01:00 Cornelius C <corn...@gmail.com>:

that's right, so I set "min Iout" down to 10 mA and it works good. What about lower end voltage readings on batt out? if i calibrate it right(in expert calibration) on lower end( ex. 1 lipo or nimh cell) then it reads wrong on high end and vise versa. Any ideas?

hmm... I need more info,

can you make a video?

also I've changed a little bit the "expert calibration"  procedure:

see: https://github.com/stawel/cheali-charger/blob/master/docs/calibration_expert.md

in short: you should not use a resistor during calibration.

(use it only to check if your charger can be calibrated).

Best Regards,

Paweł

[Igon]

Pawel, can you check an issue - charger does not show data screens if battery disconnects while D/C cycling process.

may be this line https://github.com/stawel/cheali-charger/blob/master/src/core/strategy/Strategy.cpp#L147
must be changed to that one -- if(!run && exitImmediately && status != Strategy::ERROR) {

btw, why did you decide to disable D/C cycling for NiZN and LiXX?

[Paweł Si]

2015-02-16 22:16 GMT+01:00 Igon <igg...@gmail.com>:

Pawel, can you check an issue - charger does not show data screens if battery disconnects while D/C cycling process.

may be this line https://github.com/stawel/cheali-charger/blob/master/src/core/strategy/Strategy.cpp#L147
must be changed to that one -- if(!run && exitImmediately && status != Strategy::ERROR) {

I look at it this weekend, but You probably are right, there should be "&& status != Strategy::ERROR"

 

btw, why did you decide to disable D/C cycling for NiZN and LiXX?

The main reason was that I couldn't find any research that would say

that cycling does anything good to the battery,  especially in case of LiXX.

It looks like it only shortens the batteries live.

[Igon]

The main reason was that I couldn't find any research that would say

that cycling does anything good to the battery,  especially in case of LiXX.

It looks like it only shortens the batteries live.

 

But cycling is not only a doubtful "training" - this is a convenient way to measure your battery's capacity!

[Samuel Lang]

+1
Format D/C was my very way to get an idea of the real capacity and age of my batteries.

Please re-add!
Thx

--

[Paweł Si]

2015-02-22 19:13 GMT+01:00 Samuel Lang <ma...@lang-sam.de>:

+1
Format D/C was my very way to get an idea of the real capacity and age of my batteries.

Please re-add!
Thx

noooooo :D

ok, If one more person will vote for it I will enable it by default.

Best Regards,

Paweł

[Samuel Lang]

Okay, if you have so much objections then rename it to "capacity check" feature and you are fine ;-)

[Paweł Si]

2015-02-23 17:58 GMT+01:00 Samuel Lang <ma...@lang-sam.de>:

Okay, if you have so much objections then rename it to "capacity check" feature and you are fine ;-)

that's actually a good idea!

currently we are suggesting some sort of "formatting"

[Samuel Lang]

Of course, formatting is senseless for Lixx batteries, my 100% ack!

Well if you agree with that feature, you can slim, shrink and make it simplier and regain some storage if you hard code it back to 3 steps:

1. charge full

2. discharge --> meassure capacitiy

3. charge --> meassure intake power consumption

This gives you a nice overview of the quality of a battery!

--

[Владимир Залогин]

Hello Pawel!

I think, if you make reduce number of cells for battery profile, in result it's may be 20 cells anough. That's give more memory for store settings of battery. That option "enab dV", "NiMH dV", "NiCd dV", "NiMH VCO", "NiCd VCO", "force bal" go to battery profile settings. It's my humble opinion.

Igon don't swear :-)

[Paweł Si]

2015-02-23 21:13 GMT+01:00 Samuel Lang <ma...@lang-sam.de>:

Of course, formatting is senseless for Lixx batteries, my 100% ack!

Well if you agree with that feature, you can slim, shrink and make it simplier and regain some storage if you hard code it back to 3 steps:

1. charge full

2. discharge --> meassure capacitiy

3. charge --> meassure intake power consumption

This gives you a nice overview of the quality of a battery!

ok, I've added  a new program "capacity check". (with 3 stages)

 

 

2015-02-25 10:35 GMT+01:00 Владимир Залогин <zalog...@gmail.com>:

Hello Pawel!

I think, if you make reduce number of cells for battery profile, in result it's may be 20 cells anough. That's give more memory for store settings of battery.

I sill need to remove something, we don't have much "program memory" left,

the "edit name" menu is a good candidate.

 

That option "enab dV", "NiMH dV", "NiCd dV", "NiMH VCO", "NiCd VCO", "force bal" go to battery profile settings. It's my humble opinion.

Ok, I'll do that, but in the next release (next after version 1.0).

[Igon]

Владимир can you explain how you want to use:
"NiMH dV"/"NiCd dV"
"NiMH VCO"/"NiCd VCO"
(I never needed to change these settings)

---

Can anybody describe the situation of usefulness of these settings? especially for per-battery usage!
(I can not see the reasons to disable "enab dV" and per-battery "force bal" or -dV voltage)

[Сергей Лавреюк]

Hello Paul, my name is Sergey. I have Nuvoton M0517LBN and want to upgrade I can not compile your projects, I work with Windows XP, CoIDE_V2Beta, gcc-arm-none-eabi-4_9-2014q4-20141203-win32 tried 4.8 , 4.7. Can you tell what is wrong. Syntax errors, there are many supposedly needed a non-standard compiler. But the projects sasam compiles all but one in Linux is not. The programmer I'm weak but I want to master this craft.I would be very glad if you will help me to understand what is wrong and it would be nice if it told how better to learn C/C++ .Thanks in advance.

воскресенье, 1 марта 2015 г., 12:36:43 UTC+2 пользователь Igon написал:

[sasam]

Dana nedjelja, 1. ožujka 2015. u 12:16:03 UTC+1, korisnik Сергей Лавреюк napisao je:

Hello Paul, my name is Sergey. I have Nuvoton M0517LBN and want to upgrade I can not compile your projects, I work with Windows XP, CoIDE_V2Beta, gcc-arm-none-eabi-4_9-2014q4-20141203-win32 tried 4.8 , 4.7. Can you tell what is wrong. Syntax errors, there are many supposedly needed a non-standard compiler. But the projects sasam compiles all but one in Linux is not. The programmer I'm weak but I want to master this craft.I would be very glad if you will help me to understand what is wrong and it would be nice if it told how better to learn C/C++ .Thanks in advance.

https://groups.google.com/d/msg/cheali-charger/SigcD9qj5wQ/ciaG7Yz7HqoJ

[Владимир Залогин]

Hello Igon! It is very simple and logical, suppose I have 3 types of batteries NIMH (capacity of 700 mA, 2700 mA, 1200 mA and from different manufacturers) for each should I choose VCO and the ability to complete the charge towards the dV. And a few more batteries in poor condition for recovery must be disconnected dV and charge up to a certain voltage (I checked on 700 mA) at low current charge a battery is low on charge dV after 10 minutes, if you disable dV, it is charged to 1.6 V and restores its capacity. If the settings "NiMH dV", "NiCd dV", "NiMH VCO", "NiCd VCO" menu are generally, but not in the profiles of the battery every time battery to charge another I should not forget to switch the setting mode in the general.

With regard to the force balance, it's just need to move in the profile settings battery, because profiles configured number of cells in LiIon battery and this imposes a charge-balanced as well without it.

And I believe that renaming the name parameter memory o.charg and o.discharg in "over.ch" and "over.dis" will be more informative. Not every user clear reduction of "o", but any understand that "ch" and "dis" 'this "charge" and "discharge". Variants are possible, but the word "over" must be present.

воскресенье, 1 марта 2015 г., 13:36:43 UTC+3 пользователь Igon написал:

[Igon]

No, it is simply wrong

It is not possible to find the NiXX battery fullness by measuring it's momentary voltage.
Your method (1.6V) is wrong (it can work for some of the batteries, but this is an exception)
You must set capacity/time limit instead of voltage

Also there is no direct dependency between VCO and battery capacity
And if you are not able to charge a battery at given VCO (it must be 1.8, fixed, not 1.6 and not 2.0!) you have a reason to think about reducing currents to 0.3C and about the health of the battery...

yes... -dV can mistakenly occur at an old batteries at first 5-10 minutes of charging process
(I think it will be fixed)
-dV technology = overcharge protection

disabled "force bal" - doesn't mean disabled balancer, it still will work if connected


P.S.
capacity - mAh
current - mA
It is not easy to understand you sometimes.. even without this mess

[Paweł Si]

2015-03-02 19:45 GMT+01:00 Igon <igg...@gmail.com>:

yes... -dV can mistakenly occur at an old batteries at first 5-10 minutes of charging process
(I think it will be fixed)

Yes, I should add this functionality ("ignore -dV at first 5-10 minutes of charging" - currently it's set only for 30s)

I'll do this probably in the next release.

Best Regards,

Paweł

[Владимир Залогин]

Hello Igon!

Igon don't swear :-) again

And again, i know about mesurement of capacity and current, in text it's just for simplicity :-)

May be you are right about method of mesurement, but in fact Pawel make ability to change VCO for  Nixx battery, then that option must go to profile of battery.

And about "force bal" you are not right, simply try to charge 3 LiIon bateery in series connectionn without balance wires, only "+" and "-" from charger, option "force bal" is "on", the charge will not start, then turn option "force bal" is "off" and voila... 

About bad battery NiMh, i'v charged 700 mAh battery with current 70 mA, after 10 minutes "...compete with dV..." (option "dV" in "on") when i'v turn option "dV" in "off" and see voltage drop equal to -5mV i stopped charging manually, battery has 1,53V

понедельник, 2 марта 2015 г., 21:45:01 UTC+3 пользователь Igon написал:

[Igon]

And about "force bal" you are not right, simply try to charge 3 LiIon bateery in series connectionn without balance wires, only "+" and "-" from charger, option "force bal" is "on", the charge will not start, then turn option "force bal" is "off" and voila... 

I do not need to make such tests - I know this very well.
and this doesn't make my assertion wrong  :D

[Владимир Залогин]

Hello Igon!
Then why did you say "...disabled "force bal" - doesn't mean disabled balancer, it still will work if connected..."?

Do not make fun, and explain why can not I charge 3 batteries connected in series with enabled "force bal" without balancing cable?

[Владимир Залогин]

Hello Pawel!

I think something not correct in "CapacityCheck" when i'v work with NiMH battery. Something like cycle charge-discharge. I have more than one time charge-discharge.

And another question, which can be considered the real capacity of the battery, the capacity of the charge or discharge capacity? If possible, it is best to allocate this value on the main screen, the resulting

[Igon]

enabled "force bal" mean you must connect balancer
disabled "force bal" doesn't disable balancer's subroutine, balancer will work if you connect it

[Владимир Залогин]

Hello Igon!

Then explain to me why this feature is important? After all, the balancer will work anyway

четверг, 5 марта 2015 г., 23:14:39 UTC+3 пользователь Igon написал:

[Maksym Siryk]

Well if you agree with that feature, you can slim, shrink and make it simplier and regain some storage if you hard code it back to 3 steps:

1. charge full

2. discharge --> meassure capacitiy

3. charge --> meassure intake power consumption

This gives you a nice overview of the quality of a battery!

Perfect function, but when I select in settings D/C cycles to 1 or 2 I get 2 cycles (1 charge 2 discharge-charge). Maybe first charge will name 0 cycle, then discharge-charge will be 1st cycle, next discharge-charge will be 2nd cycle, etc.

 

 

That option "enab dV", "NiMH dV", "NiCd dV", "NiMH VCO", "NiCd VCO", "force bal" go to battery profile settings. It's my humble opinion.

Also it will be great if you add to battery profile o.charge, o.discharge, force discharge and min I out (stop charging (discharging) when current is lower than Ic/X (Id/X)) because different current, different wire resistance, different batteries need to define this setting for every battery profile.  

[Maksym Siryk]

force discharge = aggressive discharging in my previous message.

[pschwed...@googlemail.com]

Also it will be great if you add to battery profile o.charge, o.discharge, force discharge and min I out (stop charging (discharging) when current is lower than Ic/X (Id/X)) because different current, different wire resistance, different batteries need to define this setting for every battery profile.  

speaking of wire resistance.. does anyone of you understand how this works? I'd assume Rcell is calculated from voltage drop under Load measured over balance port (whose wires are assumed to be 0 Ohm). Then the whole battery has also a resistance as measured by voltage drop under load, measured by the output connector. The difference is wire resistance.. Does that make sense?

But now I have a (damaged) 3SLiPo with 76 , 6 and 13 milliOhm (total 95milli). Batt. R is 96milli and wires 92milli. I am confused.

[Maksym Siryk]

speaking of wire resistance.. does anyone of you understand how this works? I'd assume Rcell is calculated from voltage drop under Load measured over balance port (whose wires are assumed to be 0 Ohm). Then the whole battery has also a resistance as measured by voltage drop under load, measured by the output connector. The difference is wire resistance.. Does that make sense?

Of course. You must measure difference of voltage on the charger screen and on the battery directly by multimeter. If you know current (you know it) you can easy calculate wire resistance (and it don't depend of battery resistance). R = |Vbat-Vscreen| / I 

So if charger know resistance of wire (and internal shunt resistor, MOSFET, etc) it can compensate voltage to show on the screen voltage on the battery.  

[Igon]

Hello Владимир
I can not explain its importance because I don't consider it important
Actually this question is for you - why you want the "force bal" to be added to a battery's settings..

[Maksym Siryk]

Well if you agree with that feature, you can slim, shrink and make it simplier and regain some storage if you hard code it back to 3 steps:

1. charge full

2. discharge --> meassure capacitiy

3. charge --> meassure intake power consumption

This gives you a nice overview of the quality of a battery!

Perfect function, but when I select in settings D/C cycles to 1 or 2 I get 2 cycles (1 charge 2 discharge-charge). Maybe first charge will name 0 cycle, then discharge-charge will be 1st cycle, next discharge-charge will be 2nd cycle, etc.

Hmmm. I select 3 cycles and got only 2: charge-discharge-charge. Does D/C cycles setting work?

[pschwed...@googlemail.com]

Of course. You must measure difference of voltage on the charger screen and on the battery directly by multimeter. If you know current (you know it) you can easy calculate wire resistance (and it don't depend of battery resistance). R = |Vbat-Vscreen| / I 

So if charger know resistance of wire (and internal shunt resistor, MOSFET, etc) it can compensate voltage to show on the screen voltage on the battery.  

Well.. yeah.. but: There is one unknown too many here. I have to assume that readings of individual cells are without wire resistance, then it (kinda) works. Also, my numbers still don't make sense to me. And then .. voltage of individual cells and charger output are measured by different OpAmps, which might not be 100% accurately calibrated. So this all seems funky. Maybe I am just not getting it.

[Владимир Залогин]

Hello Igon!

I do not correctly formulated question :-)

Initially, I suggested to move the "force bal" in the battery profile due to the fact that if this option exists, it is logical to place it in the battery profile. I personally do not understand the purpose of this function. Perhaps Pawel will explained or remove this function at all.

пятница, 6 марта 2015 г., 23:08:33 UTC+3 пользователь Igon написал:

[Maksym Siryk]

 I have to assume that readings of individual cells are without wire resistance, then it (kinda) works.

Of course not. 

voltage of individual cells and charger output are measured by different OpAmps

You are wrong. See https://groups.google.com/d/msg/cheali-charger/o6lu_N-eBtg/1mVKCKSnkeoJ 

[pschwed...@googlemail.com]

Actually, this schematic proves me right

[Igon]

Hello Pawel

 

Yes Vladimir, I will move all of the batteries settings into the battery profile,
but this will take some time.

Hm... Will we lose a possibility to change this settings for all of the batteries at once?

[Paweł Si]

Yes that's true,

which of the settings would you like to be globally settable?

[Maksym Siryk]

which of the settings would you like to be globally settable?

Temperature (most batteries do not like temperature over 60 degrees)

dT/dt

NiMH / NiCd VCO (because it's emergency values)

D/C cycles

D/C rest

beep

min Iout (mA minimum provided by charger, not termination current)

cap COFF

input low

bal error

anc noise 

uart,etc

 

[Paweł Si]

ok, I agree these settings should be global:

- beep

- min Iout (mA minimum provided by charger, not termination current)

- input low 

- anc noise 

- uart,etc

but:

- Temperature (most batteries do not like temperature over 60 degrees)

- dT/dt

- NiMH / NiCd VCO (because it's emergency values)

- D/C cycles

- D/C rest

- cap COFF

- bal error

these settings really look like they should be in a battery profile,

I'm not sure if it's really a big problem to change them N times.

[Maksym Siryk]

but:

- Temperature (most batteries do not like temperature over 60 degrees)

- dT/dt

- NiMH / NiCd VCO (because it's emergency values)

- D/C cycles

- D/C rest

- cap COFF

- bal error

these settings really look like they should be in a battery profile,

I'm not sure if it's really a big problem to change them N times.

First of all in source code everybody can set up default settings for above settings, so by default every battery will have this default settings (so you don't need to change it for every battery profile) and on some battery user can change settings (if it is needed). Thats why no problem if this settings will not be global. If adding all of this settings don't need many memory, of course.

[Maksym Siryk]

I have a question: how can I save my settings, especially battery profiles, during reflash new firmware? After flashing I must reset all of settings and enter again 12 profiles take many time. Chasnge 2 roes in sourse code, reflash and again manual enter batteries profiles. brrr. 

[Paweł Si]

2015-03-11 16:01 GMT+01:00 Maksym Siryk <mak...@siryk.com>:

I have a question: how can I save my settings, especially battery profiles, during reflash new firmware? After flashing I must reset all of settings and enter again 12 profiles take many time. Chasnge 2 roes in sourse code, reflash and again manual enter batteries profiles. brrr. 

 

A yes, that's a  big problem, almost every firmware update will delete you "setting" and/or battery profiles.

In case of updating  v0.99->v1.00 you will lose "settings".

the best solution would be a "companion" program,

(something similar to "OpenTX Companion" http://www.open-tx.org/ )

maybe someone will find the time to write it (unfortunately it wont be me).

There is however a python script:

https://github.com/stawel/cheali-charger/tree/master/utils/eepromExtractor

that can extract eeproms to python (human) readable form,

and vice versa - it even works sometimes :)

[Igon]

definitely dislike VCO - lower than 1.8V it is useless, higher - dangerous

there is no o.charge, o.discharge and aggressive discharge at battery settings.. I and Maksym were forgotten.. sadly...

[Paweł Si]

2015-03-11 21:29 GMT+01:00 Igon <igg...@gmail.com>:

definitely dislike VCO - lower than 1.8V it is useless, higher - dangerous

there is no o.charge, o.discharge and aggressive discharge at battery settings.. I and Maksym were forgotten.. sadly...

?

I'm no sure if I understand you correctly :)

but if you are talking about the "lcdprint_opt" branch please set "settings"->"menus:" to "advanced" ;)

Best Regards,

Paweł

[Maksym Siryk]

definitely dislike VCO - lower than 1.8V it is useless, higher - dangerous

I agree that this setting must be global. But if there are many free mamory for store battery profiles it can be in battery profile.

 

there is no o.charge, o.discharge and aggressive discharge at battery settings.. I and Maksym were forgotten.. sadly...

I wrote only settings that can be global. Of course all other settings like o.charge, o.discharge, agressive discharge must be in every battery profile. Also there must be Imax (termination current), enabling dV, -dV voltage.

[Igon]

 

there is no o.charge, o.discharge and aggressive discharge at battery settings...

 

yes, at battery profile   not at battery settings

 

[Maksym Siryk]

Is it possible to add setting fo Imax (C/xx) for agressive discharge? Now this setting is for charge and discharge, but in real life I like to charge up to C/25 and if I need agressive discharge, I like to dischatge up to C/10.

[Paweł Si]

2015-03-12 19:11 GMT+01:00 Maksym Siryk <mak...@siryk.com>:

Is it possible to add setting fo Imax (C/xx) for agressive discharge? Now this setting is for charge and discharge, but in real life I like to charge up to C/25 and if I need agressive discharge, I like to dischatge up to C/10.

Yes, it's possible, In fact I already added it. 

 

If you guys would like to see the new "battery profile", it's in the "lcdprint_opt" branch, unfortunately you have to compile it yourself.

You should also set "settings"->"menus:" to advanced.

But I wouldn't try to charge anything, nothing is tested yet.

Best Regards,

Paweł

[Igon]

Pawel what can I use instead of the disappeared ProgramData::changeId/changeIc?


Quite bulky alternative to "nolimit" time-limit setting %)

void ProgramData::AutoTime()
{
   uint32_t bat_ch = battery.Ic * 77;     // 130% of charge
   bat_ch /= battery.capCutoff;

   uint32_t bat_dis = battery.adaptiveDis * 20;
   bat_dis += 100;
   bat_dis *= battery.Id;
   bat_dis /= 110;     // 110% of discharge

   bat_ch = min(bat_ch, bat_dis);
   bat_dis = battery.capacity * 60;     // *60min
   battery.time = bat_dis / bat_ch;
}

[Igon]

void ProgramData::changedIc()
{
   AutoTime();
   ...
}

void ProgramData::changedId()
{
   AutoTime();
   ...
}

[Paweł Si]

2015-03-15 19:44 GMT+01:00 Igon <igg...@gmail.com>:

Pawel what can I use instead of the disappeared ProgramData::changeId/changeIc?

hmm... right, I forgot that you are using it,
I would probably use just this:

    change0ToInfSmart(&ProgramData::battery.Ic, direction);

    ProgramData::check(); 

or we can restore the previous ProgramData::changeId/changeIc methods.

Quite bulky alternative to "nolimit" time-limit setting %)

void ProgramData::AutoTime()
{
   uint32_t bat_ch = battery.Ic * 77;     // 130% of charge
   bat_ch /= battery.capCutoff;

   uint32_t bat_dis = battery.adaptiveDis * 20;
   bat_dis += 100;
   bat_dis *= battery.Id;
   bat_dis /= 110;     // 110% of discharge

   bat_ch = min(bat_ch, bat_dis);
   bat_dis = battery.capacity * 60;     // *60min
   battery.time = bat_dis / bat_ch;
}

I'm not really sure if the time limit is so important,

the capacity cutoff limit does exactly the same thing,

and we have big differences between the charge and discharge

time limits.

 

[Владимир Залогин]

Hello Pawel!

Noticed on two my nuvotot B6AC+ devices, the calibration and verification capacity NiMH batteries, sometimes it hangs the program. After flashing all settings are reset to factory. Just power off resolves the problem. 

https://yadi.sk/i/560HXDsWfKEbA

https://yadi.sk/i/4oQr47kwfKEbG

[Владимир Залогин]

And another problem. In the profile settings NIMH battery tune "Ch"=nolimit, "Time"=nolimit, "Ic"=100mA, "Id"=100mA. In the basic configuration "capCOff"=100%. When the discharge and in "D>C format" current of discharge = 125mA. Any value of "capCOff" does not change the real current of discharge.

[Владимир Залогин]

Today reset device to default. Try to charge NiMH with same paremeters as yesterday, anothe effect, for charge battery flow 132mA, and for discharge flow 100mA

[Paweł Si]

2015-03-17 19:35 GMT+01:00 Владимир Залогин <zalog...@gmail.com>:

And another problem. In the profile settings NIMH battery tune "Ch"=nolimit, "Time"=nolimit, "Ic"=100mA, "Id"=100mA. In the basic configuration "capCOff"=100%. When the discharge and in "D>C format" current of discharge = 125mA. Any value of "capCOff" does not change the real current of discharge.

"capCOff" - only disables charge/discharge when you battery reaches a certain charge value (capacity).

it will not  change the discharge current.

when it comes to the "discharge current = 125mA"

it's probably a problem with the discharge calibration,

could you do a video where you calibrate discharge current
and then discharge a battery? 

[Владимир Залогин]

Pawel, i'v recalibrate device.

But this morning I spent a fully calibrated, and the problem persists, you were right. I saw the video is 1min 20sec, when calibrating the charge current initial value of 36 mA, this is it.

Later

Calibrating

Testing

среда, 18 марта 2015 г., 15:08:48 UTC+3 пользователь cheali-charger написал:

[Владимир Залогин]

Calibrating

[Igon]

hmm... right, I forgot that you are using it,
I would probably use just this:

    change0ToInfSmart(&ProgramData::battery.Ic, direction);

    ProgramData::check(); 

or we can restore the previous ProgramData::changeId/changeIc methods.

Oh, sorry, I asked my question a bit wrong - I mean - need I use some new function or just restore old? 
(at first StaticEditMenu::editItem looks compatibly, but at second it looks too complex) 

So, I restored old functions

I'm not really sure if the time limit is so important,

the capacity cutoff limit does exactly the same thing,

Hm..   You just right! :)

[Igon]

Pawel what do you think about such calculation? -

AnalogInputs::ValueType Thevenin::calculateI(AnalogInputs::ValueType v) const
{
    int32_t i;
    i = v;
    i -= VLast_;                                        // difference between present and desired voltage

    i *= Rth.uI;
    if(Rth.iV != 0) i /= Rth.iV;                     //  dV / R  =  amount of current error
    else return UINT16_MAX;

    i += ILast_;                                        // adding correction to main current
    if(i > UINT16_MAX) return UINT16_MAX;
    if(i < 0) return 0;
    return i;
}


Thevenin::calculateVth(AnalogInputs::ValueType v, AnalogInputs::ValueType i)   - is it open-circuit voltage of a battery?

[Paweł Si]

2015-03-18 20:28 GMT+01:00 Igon <igg...@gmail.com>:

Oh, sorry, I asked my question a bit wrong - I mean - need I use some new function or just restore old? 
(at first StaticEditMenu::editItem looks compatibly, but at second it looks too complex) 

So, I restored old functions

yes, I'm not very proud of  the  StaticEditMenu::editItem code, you are right it's too complex,
but I'm trying to gain some program memory,
I need the memory because I will probably  try to implement a power supply it the (far) future.

2015-03-21 17:06 GMT+01:00 Igon <igg...@gmail.com>:

Pawel what do you think about such calculation? -

AnalogInputs::ValueType Thevenin::calculateI(AnalogInputs::ValueType v) const
{
    int32_t i;
    i = v;
    i -= VLast_;                                        // difference between present and desired voltage

VLast_ - to be more precise it's the voltage measured in the past - but yes, we do update it just before calling calculateI

 

    i *= Rth.uI;

    if(Rth.iV != 0) i /= Rth.iV;                     //  dV / R  =  amount of current error
    else return UINT16_MAX;

    i += ILast_;                                        // adding correction to main current
    if(i > UINT16_MAX) return UINT16_MAX;
    if(i < 0) return 0;
    return i;
}


Thevenin::calculateVth(AnalogInputs::ValueType v, AnalogInputs::ValueType i)   - is it open-circuit voltage of a battery?

It's the Thevenin voltage, yes in some sens it is the open-circuit voltage,
assuming we have no errors in measurements,
unfortunately the errors accumulate in this value.
formula:
Vth = Vout - Rth*Iout

where:
Vth - Thevenin voltage

Rth - Thevenin resistance.

Rth = (V - VLast_) / (I - ILast_)
so it's: how much the voltage changed on some current change.

V - currently measured voltage

VLast_- voltage measured some time ago

Problem is that this  V - VLast_ value is very small, so the relative error is very big.

-----------------------------------------------------------------------------
Some additional info if someone else is interested :-)

when we are charging for example with 2A:
1. we first start with 10%*2A = 200mA,
2. we wait until the voltage stabilizes,

3. we measure the voltage at this point (this is VLast_)

4. after that we rise the current to 2A,
5. wait until the voltage stabilizes,
6. measure the voltage (V)

7. from this we calculate the Rth = (V - VLast_) / (I - ILast_) = (V - VLast_) /  (2A - 200mA)
8. from now on: VLast_  = V (for the next Rth measurement)

*9. we now also update Vth based on Vth = Vout - Rth*Iout because the battery is charging (voltage rises)

we do 1-7 every time we have a big change in the output current,

for example when we reach  4.2V per cell, we do a second internal resistance measurement 

by setting the output current to 0A for a short period of time.

---------------------------------------------------------------------------

back to your question:" Pawel what do you think about such calculation?"

the method calculateI() was meant to calculate the output current (new output current)

when we have: Vth (Thevenin voltage - open circuit voltage), the Rth (Thevenin resistance - batteries internal resistance):

Inew1 = (Vdesired - Vth) / Rth

and you are proposing to change it to (VLast_ and ILast_ where updated before calling calculateI so):

Inew2 = (Vdesired - Vout) / Rth + Iout 

but in fact:

Inew1 = (Vdesired - Vth) / Rth = (Vdesired - (Vout - Rth*Iout)) / Rth = (Vdesired - Vout) / Rth  + Iout == Inew2

is this not the same?

Best Regards,

Paweł

ps. sorry for such a long mail but I forgot how everything works, so I had to refresh my memory.

[Igon]

I need the memory because I will probably  try to implement a power supply it the (far) future.

 

It can be not possible without hardware modifications :( 

 

when we are charging for example with 2A:

1. we first start with 10%*2A = 200mA,
2. we wait until the voltage stabilizes,
3. we measure the voltage at this point (this is VLast_)

 

strange.. because if I try to charge overdischarged LiXX (0V at terminals due to overdischarge protection)
the current stops its raising at 50-90mA. calculated resistance also is very big - 10 ohms and more
(wow! Rth.iV=3137 Rth.uI=35 R = 24092 xmm.. 16bit.. )
 

 

is this not the same?

no! - my variant is easier ;)   It don't need Vth subroutine

Mathematically? - may be
Practically - if(v < VRth) Vth_ = 0;
 

(without modification firmware is not suitable for 2-cell protected LiXX without balance-port)

[Maksym Siryk]

I have a question. 

o.discharge voltage correction - must I enter this voltage per cell? Or for the whole battery? 

[Paweł Si]

2015-03-22 13:29 GMT+01:00 Igon <igg...@gmail.com>:

I need the memory because I will probably  try to implement a power supply it the (far) future.

 

It can be not possible without hardware modifications :( 

You are probably right, I suspect It won't be very stable, but for my LED's it will be probably enough :) 

 

when we are charging for example with 2A:

1. we first start with 10%*2A = 200mA,
2. we wait until the voltage stabilizes,
3. we measure the voltage at this point (this is VLast_)

 

strange.. because if I try to charge overdischarged LiXX (0V at terminals due to overdischarge protection)
the current stops its raising at 50-90mA. calculated resistance also is very big - 10 ohms and more
(wow! Rth.iV=3137 Rth.uI=35 R = 24092 xmm.. 16bit.. )

Yo got me there :)

In fact, we do something  slightly different when we start charging, it's in Thevenin::init(....):

1. we set Rth = (Vdesired - Vout)/ Imin 

   - where Imin = minimum current, in the example its 200mA 

2. run the the algorithm  - let calculateI() determine the output current

 

we set a arbitrary Rth (it's a big value) so that when we start the algorithm

the first calculated output current should be 200mA,

Rth will be updated at the next calculateRth() call (output voltage must be stable).

This approach doesn't work very well when you connect something not linear to the charger,

for example a battery with a protection circuit or a LED :)

but in case of the protection circuit the algorithm should in theory

start working correctly as soon as the protection turns off (at the next Rth calculation)

is this not the same?

no! - my variant is easier ;)   It don't need Vth subroutine

You are right, it would probably even generate a smaller footprint.

Mathematically? - may be

Practically - if(v < VRth) Vth_ = 0;

(without modification firmware is not suitable for 2-cell protected LiXX without balance-port)

hmm... that's interesting,

we don't allow the Thevenin voltage to be negative: "if(v < VRth) Vth_ = 0;"

I'm not sure when this can happen...

I'll have to thing this over :-/

or maybe we should just use your approach :)
have you tested it?

I'm especially interested in the case where we have 2 cells and one cell is overcharged, for example:

1-cell 4.1V

2-cell 4.22V

what will the output current be? 

 

[Paweł Si]

2015-03-22 16:19 GMT+01:00 Maksym Siryk <mak...@siryk.com>:

I have a question. 

o.discharge voltage correction - must I enter this voltage per cell? Or for the whole battery? 

it's per cell

[Igon]

printed from AnalogInputs::ValueType Thevenin::calculateI(AnalogInputs::ValueType v) const
22:28:55> T::calculateI 8400;8244;1092
8400 - v   8244 - VLast_   1092 - int32_t i  - calculated current error (mA)
22:28:55> T::calculateI 4200;4225;-437    - 1st cell
22:28:55> T::calculateI 4200;4225;-437    - ?! hm... 
22:28:55> T::calculateI 4200;4019;2111   - 2nd cell

printed from AnalogInputs::ValueType TheveninMethod::calculateNewI(bool isEndVout, AnalogInputs::ValueType I)
22:28:55> TM 35;0    ( 35 - I    0 - newI_   taken after https://github.com/stawel/cheali-charger/blob/lcdprint_opt/src/core/strategy/TheveninMethod.cpp#L156)
22:28:55> 17;35
17 - printUInt(newI_)  before  newI_ = normalizeI(newI_, I); (line 166)
35 - printUInt(newI_)  after  newI_ = normalizeI(newI_, I);

It works, discharge, storage+balance also tested, nothing extraordinary except doubled 1st-cell calculation (sometimes 1st-cell x2 + 2nd-cell x2)

[Paweł Si]

Ok, so let it be your way,
I will change it in the 1.10 version but unfortunately this will take some time :-/

Best Regards,

Paweł

[Igon]

Ok :)

Will it be merged with lcdprint_opt branch?

---

lcdprint_opt

Unknown battery has a logical problem with voltage * cells and Vc_per_cell (Vd_per_cell)
And it hasn't its own #define COND_Unknown at ProgramDataMenu so  Vc_per_cell and Vd_per_cell <= 5V 

Keyboard.cpp
Original speedFactor was like an unpredictable rocket - 1 2 3 4 5 6 7 8 10 20 1000!
gentle version: static const uint16_t speedFactor[] PROGMEM = {1, 1, 10, 10, 10, 10, 100};
or {1, 1, 10, 10, 10, 11, 100} - it even warn you before final acceleration

[Paweł Si]

2015-03-29 21:49 GMT+02:00 Igon <igg...@gmail.com>:

Ok :)

Will it be merged with lcdprint_opt branch?

 

Yes, although I've changed the branch name to: v1.10

 

---

lcdprint_opt

Unknown battery has a logical problem with voltage * cells and Vc_per_cell (Vd_per_cell)
And it hasn't its own #define COND_Unknown at ProgramDataMenu so  Vc_per_cell and Vd_per_cell <= 5V

Yes, the v1.10 is not ready yet, there are probably much more bugs,

unfortunately I too busy right now to continue with this version :-/

  

  

Keyboard.cpp
Original speedFactor was like an unpredictable rocket - 1 2 3 4 5 6 7 8 10 20 1000!

:D

 

gentle version: static const uint16_t speedFactor[] PROGMEM = {1, 1, 10, 10, 10, 10, 100};
or {1, 1, 10, 10, 10, 11, 100} - it even warn you before final acceleration

ok, I will change this too,

Best Regards,

Paweł