Igon's fork

[Igon]

Fork with on-the-fly current and capacity limit adjustment.

https://github.com/Iggnus/cheali-charger-i1

[Paweł Si]

2014-08-31 17:05 GMT+02:00 Igon <igg...@gmail.com>:

Fork with on-the-fly current and capacity limit adjustment.

https://github.com/Iggnus/cheali-charger-i1

that great news! I'm impressed.

I'm very curious to see how it performs, but unfortunately I won't have time for testing until next month.

Best Regards,

Paweł

[thorroid]

Dne neděle, 31. srpna 2014 17:05:23 UTC+2 Igon napsal(a):

Fork with on-the-fly current and capacity limit adjustment.

https://github.com/Iggnus/cheali-charger-i1

I am testing this new firmware version.
On the fly current limit adjustment works very well. I have found one bug. After current calibration I navigate one level up in the menu and at this point the charger freeze and must be restarted.

My charger is: Turnigy Accucel-6 with yellow PCB (Almost identical with original Imax B6)  Firmware: 50W-5A-20140831-0.33m.hex

Thanks for good work.

[Igon]

Hello thorroid

Thank you for bugreport!

My fault %)  I always flashes EEPROM and forgot to check how the calibration procedure workes..

I will try to fix this at weekend 

[Igon]

Fixed

Hi Jozsef! You have a bug i=i++ in Calibrate.cpp
Must be not all GCC can compile a workable code with that equation

[Igon]

Hi Pawel

Can you help me with placing a call to maximum current check (or to ProgramData::check()) ?

I want to prevent an inappropriate currents to be loaded as-is from saved presets

[Paweł Si]

I'm not sure if this can be done easily,

I'm plaining to rewrite the SMPS.cpp  file so that 

it will accept mA instead of ADC values,

then it should be easer.

In the 0.33 version, you could change the TheveninMethod(.cpp)::normalizeI method (value = maxValue_;) so that the 

maximum current limit changes over time, but you have to do this in ADC values.

Best Regards,

Paweł

[Paweł Si]

hm... 

I finally realized that you actually have two branches (versions):

https://github.com/Iggnus/cheali-charger-i1

and:

https://github.com/Iggnus/cheali-charger-i1-DVF

to this day I thought the first one is the DVF version.

I should read mail's more carefully :/

[Igon]

I mean what if I have a settings (by EEPROM copy) - Pb 6S 4.7A at 50W charger?
You can not create such settings with NORMAL 50W charger, but what if you have it already?
---
ok, probably ProgramData::currentProgramData.getMaxIc() from Monitor::run() will stop this craziness

maximum current limit changes over time, but you have to do this in ADC values.

strange, it seems work fine with mA

[Paweł Si]

to many conversations at the same time,

I'm lost :D

If you want to check if the battery Ic value is ok you just need to call  ProgramData::check(),

you can call the method whenever you like, for example before starting any charge/discharge program:

  

void Program::run(ProgramType prog){

   ProgramData::currentProgramData.check()

   ...

}

if you place something  into Monitor::run() the code will be executed every 0.7s

and as far as I understand you need to execute it only once?

[Daky Tilly]

Igon, I tried your firmware version and it seems to work all right.

I’m using logview to display graph during charge/discharge.

I appreciate you stop sending serial data when program is complete. Now I don’t need to stop logview manually.

I also have another issue: the first serial data send when I start program has “out volt” value to 0, causing logview’s autoscale min value start from 0 and not real minimum value.

Do you think will be possible to correct this?

PS I have already explain this to Pawel and he kindly put it in his TODO list

 

Many thanks Roberto.

[Igon]

I appreciate you stop sending serial data when program is complete. Now I don’t need to stop logview manually.

Actually this is a side effect..  But I like it too :)

 

 

I also have another issue: the first serial data send when I start program has “out volt” value to 0, causing logview’s autoscale min value start from 0 and not real minimum value.

Do you think will be possible to correct this?

I think yes
I'll try to correct 0-voltage issue

[Igon]

Done

[Daky Tilly]

Ok. Tomorrow I'll test it and let you know.

Il giorno giovedì 30 ottobre 2014 20:52:33 UTC+1, Igon ha scritto:

Done

[Daky Tilly]

Hi Igon.

Great. I tried the version “50W-5A-20141030-0.33m.hex” and it works.

UART serial voltage values are ok. Logview autoscale now work from the beginning. And it stop when cycle is complete :)

Charging very small Lithium battery now stop ok. I tried 130 mAh and it stop correctly: current 50 mA

Many thanks.

[thorroid]

Hi Igon,

Would it be possible and safe to add a user selectable charging rates bellow 100mA (30,40,50...) for very small lipos and nimh accus to your firmware?

thanks

[Igon]

Hi thorroid

This is also the question of hardware - some chargers is not capable to deliver 15-20mA currents -
they will not stop before capacity or time limit hitting.
Is it safe? - I think it is not very dangerous if you have set these limits correctly

Yes I can change current limits, or I can pull minimal adjustable current(currently 100mA) and min output current(currently 30mA) to the HardwareConfig.h
It will be easier to setup before compile
If this question about additional setup menus - I do not know how to implement it into EEPROM 

[thorroid]

I think it's worth a try to lower minimal adjustable current from 100mA to 30mA. thanks

[Igon]

Hi Pawel

Can you help me with switch-case?
How can I make something equal to
switch(pgm::read(&chargeScreens[screen_nr])) {
  case Screen::ScreenFirst:
  case Screen::ScreenCIVlimits:
  case Screen::ScreenStartInfo:
  case Screen::ScreenCycles:
}

[Paweł Si]

you mean in the new implementation of Screen::doStrategy()?

or the old one? (currently there are no Screen::Enums)

and what you want to achieve?

--
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.

[Igon]

you mean in the new implementation of Screen::doStrategy()?

 yes, exactly

 

and what you want to achieve?

 regulate currents at "displayFirstScreen"
battery voltage/cells number at "displayStartInfo"
capacity limit at "displayCIVlimits"
and manual scroll for displayCycles pages

[Paweł Si]

I am glad that you are asking, 

I have my thoughts, but of course It's just a proposition

(we can also change the Screen::doStrategy implementation if it will be necessary)

my thoughts (the implementation is not very optimized):

I would probably implement new Screen functions,

and put them into the  Screen::Pages::pageInfo structure:

bool Screen::Editable::editing = false;

void Screen::Editable::displayFirstScreen() {

    Strategy::maxI += getEditDirection();

    if(editing) {

        lcdSetCursor0_0();

        if(Screen::blink.getBlinkIndex()) lcdPrintCurrent(Strategy::maxI, 7);

        else lcdPrintSpaces(7);

    } else {

        Screen::Methods::displayFirstScreen();

    }

}

//maybe not the best name for this method :/

int8_t Screen::Editable::getEditDirection()

{

    int8_t dir = 0;

    if(editing) {

        switch(Screen::keyboardButton) {

            case BUTTON_INC: dir++; break;

            case BUTTON_DEC: dir--; break;

            case BUTTON_STOP:

            case BUTTON_START: editing = false; break;

        }

        //disable scrolling

        Screen::keyboardButton = BUTTON_NONE;

    } else if (Screen::keyboardButton == BUTTON_START) {

        editing = true;

        Screen::blink.startBlinkOn(1);

    }

    if(dir)

        Screen::blink.startBlinkOn(1);

    return dir;

}

What do you think?

Best regards,

Paweł

[Igon]

Oh, I have a routines for current control and etc but I don't know how to determine currently displayed page - switch(pgm::read(&chargeScreens[screen_nr])) is not working anymore..
pageNr_ is 0 for "displayFirstScreen" and also for "displayStartInfo"
it can be 6 or 10 for "displayCIVlimits"

[Paweł Si]

You can put the routine into the "displayFirstScreen" method,

so it would be called when the "displayFirstScreen" is displayed.

(the same is true for "displayCIVlimits")

what is wrong with this solution?

[Igon]

just my brain stucked by switch-case... %)
your solution works perfectly :)

[Igon]

New branch with fork of 0.99 version is ready for tests - https://github.com/Iggnus/cheali-charger-i1/tree/v0.99


Pawel what do you think about these modifications:
energy calculation - https://github.com/Iggnus/cheali-charger-i1/blob/v0.99/src/core/AnalogInputs.cpp#L379

Time::diffU16()  - https://github.com/Iggnus/cheali-charger-i1/blob/v0.99/src/core/drivers/Time.h#L38
it allowed to switch DelayStrategy to seconds

[Paweł Si]

2014-12-07 20:52 GMT+01:00 Igon <igg...@gmail.com>:

New branch with fork of 0.99 version is ready for tests - https://github.com/Iggnus/cheali-charger-i1/tree/v0.99

Great! 

Pawel what do you think about these modifications:
energy calculation - https://github.com/Iggnus/cheali-charger-i1/blob/v0.99/src/core/AnalogInputs.cpp#L379

Definitely better then my method,  I will leave a comment on the commit.

[thorroid]

I have found a small bug in this version. When I start the "storage+balance" mode and then decrease current on the fly then a battery is charged to 4.2V and not to 3.85V.

Charger: Imax B6 original


Dne neděle 7. prosince 2014 20:52:23 UTC+1 Igon napsal(a):

[Igon]

Oh, I played with the lcdprint_opt branch and forgot to fix a bug in this one...

I plan to update the repository tomorrow evening

[thorroid]

Thanks for your help.

[Igon]

Done

I hope I haven't missed EEPROM version...

[thorroid]

Is it possible to use this new version without EEPROM reset? When I have tried to start the charging process then I got a window with reseting EEPROM message and if I choose "NO" then nothing happened. I tried load a backup eeprom from the previous firmware version but I am facing the same issue. Thanks

[thorroid]

I reset and calibrated my charger but after a new power cycle I got a "resetting" window again. Would it be possible to disable an automatic reset routine please or in what could be the problem ?  Do you thing that is necessary to erase the EEPROM from the previous firmware version (imaxB6-original_0.99-20150104_atmega32.hex) ? Thanks for your help.

[Igon]

sorry for the long silence - I was not at home..

No, EEPROM from imaxB6-original_0.99-20150104_atmega32.hex (v.9.2.7) is not compatible with 20150221(v.9.2.8) and newer versions

"I reset and calibrated my charger but after a new power cycle I got a "resetting" window again."

A long time ago, I heard something about this problem..
Probably you need to use "reset default"

In any case I plan to upload new fork based on Pawel's lcdprint_opt branch (it also needs EEPROM erase...)

[thorroid]

That would be great. Thanks

[Igon]

Fork of lcdprint_opt brunch of Pawel`s firmware
(Brunch with per-battery adjustable voltage and current limits, capacity cutoff, temperature, cycles and more)
https://github.com/Iggnus/cheali-charger-i1/tree/lcdprint_opt-i

[thorroid]

Thanks, I try it soon.

[Міша Яніцький]

On Sunday, June 21, 2015 at 11:22:54 PM UTC+3, Igon wrote:

Fork of lcdprint_opt brunch of Pawel`s firmware
(Brunch with per-battery adjustable voltage and current limits, capacity cutoff, temperature, cycles and more)

good firmware, you can do so on NOVUTON 

[Міша Яніцький]

[Igon]

For Nuvoton you need to take Pawel`s lcdprint_opt branch, overwrite original directory "core" by directory from my fork and build project normally

[Micha Chlst]

hello Igon,

I would like to test your firmware - on the fly current change is a very interesting feature, which was supported in the original firmware too.

I've a clone with m0517 chip and its 80W power model. Could you please add support for this board? Its already supported in Pawels master branch.


best regards,
  Michal

[Igon]

Hello Micha

Oo! Looks like there is a new version of firmware!
I need some time to update my fork
If you are about files for nuvoton for v0.99 - I need to buy new HDD first and backup my system SSD.. (files saved from old HDD kills all free space needed for living and for СooCox)

[Igon]

v1.99 hex files are ready  (branch: master)

Nuvoton is still delayed

hm... is it possible to build files for nuvoton without that bulky Coocox?

[Micha Chlst]

I'm compile nuvoton with linux gcc-arm.
I've tried it with the newest branch but got this error:

Scanning dependencies of target cheali-charger-AnalogInputsAnalyzer-50W_1.99-20150820_nuvoton-M0517
[  0%] Building CXX object src/hardware/nuvoton-M0517/targets/AnalogInputsAnalyzer-50W/CMakeFiles/cheali-charger-AnalogInputsAnalyzer-50W_1.99-20150820_nuvoton-M0517.dir/defaultCalibration.cpp.obj
In file included from /home/m/src/chealicharger-igon/cheali-charger-i1/src/core/AnalogInputs.h:23:0,
                 from /home/m/src/chealicharger-igon/cheali-charger-i1/src/core/AnalogInputsPrivate.h:21,
                 from /home/m/src/chealicharger-igon/cheali-charger-i1/src/hardware/nuvoton-M0517/targets/AnalogInputsAnalyzer-50W/defaultCalibration.cpp:19:
/home/m/src/chealicharger-igon/cheali-charger-i1/src/hardware/nuvoton-M0517/cpu/memory.h:21:19: fatal error: cstring: No such file or directory
 #include <cstring>
                   ^
compilation terminated.
make[2]: *** [src/hardware/nuvoton-M0517/targets/AnalogInputsAnalyzer-50W/CMakeFiles/cheali-charger-AnalogInputsAnalyzer-50W_1.99-20150820_nuvoton-M0517.dir/defaultCalibration.cpp.obj] Fehler 1
make[1]: *** [src/hardware/nuvoton-M0517/targets/AnalogInputsAnalyzer-50W/CMakeFiles/cheali-charger-AnalogInputsAnalyzer-50W_1.99-20150820_nuvoton-M0517.dir/all] Fehler 2
make: *** [all] Fehler 2

[Aretm y]

Hello Igon,

Maybe I asking the same question that was asked before by someone else.

But is it possible with current version to set fixed/adjustable voltage ? (Fixed/adjustable voltage power supply)

Is it possible to disable "battery disc."  check ?

Thank,

Artem.

[Igon]

This is not a problem to disable "battery disc."
But these devices needs a huge capacitance or voltage limiter/stabilizer at it's output
And most of a chargers cant work with currents lower 20-50mA...

[Aretm y]

Hi, thank you for answer. 

What part of code(file, procedure ) controls voltage on output. For example when charging LiPo during stage Constant Voltage?

I am trying to experiment/understand with code but I am under Windows 10 and use Notepad.... so it is hard yet.

[Igon]

Actually voltage is controlled by the current changes (This is the hardware ideology of our chargers)
Every next current change calculates by Thevenin::calculateI() (Thevenin.cpp)
All is the same for the Constant Voltage stage but current can't be increased from step to step

Windows7 & Notepad++ ;)
Also I recommend MHV AVR Tools instead of AVR Studio because of size and more appropriate GCC version

As for a power supply - we need a FAST voltage feedback and probably at hardware level. (you can find software voltage feedback at my DVF fork)

[Igon]

Looks like we can turn current feedback of 150W+ chargers  https://drive.google.com/file/d/0B1RXXTatsA1cbkM2dXFxTldjTUU
into the voltage feedback circuit: 

Disconnect R127 from "AA" point and R125 and ground this pin
Connect pin 2 of LM2904 #5 2/1 to "BATT+" through ~240 kOhm resistor

I think it will be easier to control current by voltage feedback schematic than otherwise

[Aretm y]

Hi Igon,

Thank you for answers. It seems that I need time in order to understand this information.... :(

I will Install Eclise and MHV AVR Tools plugin. I am going to try software voltage feedback of DVF fork. Which mode of charging is the best for test as "constant voltage"?

About hardware voltage feedback. I have original Imax B6 charger. Does this modification also applicable for this charger? Or it is necessary to "add" another one LM2904 and connect to some free pin on ATMEL?

Thank you!

[Igon]

Mmm.. that was mostly for Pawel, I mean my last post

another one LM2904 and another one LM393 and a plenty of resistors... :(
no, this is a hard way for 50W family

[Igon]

Long delayed update..
Based at cheali-charger:master at 16.01.2016
Some newer bugfixes added, but missing some features like editable current calibration points, extended error codes, etc due to a size limit :(

[SERG]

Hi Igon and cheali-charger community, Regarding the cheali-charger-i1 update from May 16, 2016, you mentioned that features like "editable current calibration points" were excluded due to size limits. Could you clarify if the current calibration points (e.g., for charge and discharge) are fixed in this firmware version (e.g., 50mA and 1000mA)? Is there any way to change these calibration points (e.g., to 3mA for low current accuracy) without modifying the source code? If fixed, what are the default calibration points used in cheali-charger-i1 for iMax B6? Thanks for any details!

понедельник, 16 мая 2016 г. в 00:30:42 UTC+5, Igon:

[diggit]

Hi,

IIRC you can edit current calibration points in cheali FW, these are defaults for 50W chargers.

If you have calibration points at 50 mA and at 1 A, it does no mean you can't charge/discharge with lower/higher currents.

I have doubts about 3 mA though. Usually the HW can't go that low due to offsets of those cheap op-amps inside.

So if you calibrate at 50 mA and 1 A and then get error when you try to set something low as 3 mA, it is typical indication of such case.

Not sure about Igon's fork.

[SERG]

Hi diggit,

Thank you for your response! I wanted to share that I was able to calibrate my iMax B6 (using the cheali-charger firmware) to accurately work with a current as low as 1 mA. By changing the calibration point (e.g., from 50 mA to 1 mA) and performing the calibration, I achieved precise low-current operation without errors. I'll attach a photo showing the iMax B6 discharging at 1 mA as proof. It seems that adjusting the calibration point overcomes the hardware limitations you mentioned.

Regarding Igon's fork (cheali-charger-i1), I'm still waiting for clarification on whether its calibration points are fixed or editable. Any insights on this would be appreciated!

Best regards,

суббота, 2 августа 2025 г. в 21:07:28 UTC+5, diggit:

[diggit]

If you got errors previously, then re-calibrated with lower point and then used the low value successfully, it is possible, that there is some non linearity. In such case, you should get worse precision somewhere around previous position of the calibration point.

There is no hard limit. Charger only checks that, your request can be solved with linear interpolation.

Let's make simple example:

At 50 mA, charger sees 40 mV on shunt, at 1 A it sees 990 mV on shunt (1mv/1mA, -10 mV offset). When you ask for 1 mA, the expected value on the shunt would be -9 mV, which the ADC can't measure and thus you get error.

In reality, the bottom end near zero current becomes also non linear. You may have calibrated your charger at 3 mA, where it measures e.g. 2 mV. As the calibration is done only in 2 points, you have to choose if you are able to get to extreme values or if you want to have precision in between.

[SERG]

Thank you for the detailed explanation about nonlinearity and calibration!

In your first response, I understood it as suggesting that a discharge current of 1 mA is generally not possible due to hardware limitations.

However, I was only referring to achieving an accurate 1 mA discharge, not switching to other currents like 1 A afterward.

I successfully calibrated my iMax B6 (using cheali-charger) at 1 mA, and it works accurately at this current, as shown in my photo.

The calibration was done at 3.9V. Since I only need specific low currents (like 1 mA or 10 mA) for my tasks,

I’m fine with recalibrating for each task to achieve precision at the desired current.

I don’t plan to use currents like 100 mA when calibrated at 1 mA, so the loss of accuracy in other ranges isn’t an issue for me.

To clarify, does the calibration voltage (e.g., 3.9V vs. 12V) significantly affect accuracy at low currents like 1 mA in your experience? Any tips for optimizing low-current calibration would be appreciated!

суббота, 2 августа 2025 г. в 21:43:53 UTC+5, diggit: