cheali-charger: pre-release version 1.99

[Paweł Si]

Hi,

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

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

(the final release will be 2.00)

what's new:

- all battery settings are now in the "edit battery" menu

- two types of menus: "simple", "advanced"

  (see: "options"->"menus: ....")
- 200W/400W chargers fan fixed

- second voltage calibration point

- simple LED support

- removed: edit battery name

to see all possible setting set "options"->"menus:" to "advanced",

Best Regards,

Paweł

[Micha Chlst]

Hi Paweł,

thanks for the new version. I've already flashed it and I like the new settings menu and the ability to set the discharge and storage stop voltage.

pozdrawiam,
  Michał

[Paul Verburg]

Hi Pawel,

while calibrating the charge current there appears to be a 20ma current left after stop current.

ie start calibration adjust number stop current still 20ma there on both low and high calibration options this is on a nuvoton charger?

[Paweł Si]

2015-08-06 21:26 GMT+02:00 Paul Verburg <paul.v...@gmail.com>:

Hi Pawel,

while calibrating the charge current there appears to be a 20ma current left after stop current.

ie start calibration adjust number stop current still 20ma there on both low and high calibration options this is on a nuvoton charger?

 

it's the same on all 50W chargers. 

you shouldn't worry about that,

it's just a side effect of the fact that your charger can not go down with charging current  below a certain value

(see also "settings"->"min Iout")

now we set the calibration current to 0mA when you don't "edit" the calibrated value,

rather than disabling the smps,

but certainly this should be fixed in the future.

Best Regards,

Paweł

[Paul Verburg]

Thanks,

I will ignore it.

I wanted to dump all the eeprom settings "in windows" then found you had done all the hard work in python but could not make it work in windows so started an xubuntu machine and going back to the darkside LOL.

No output of the script yet but learning heaps.

Paul V.

[Ivo H]

Just flashed and started to explore the new features. Is the LED support for to use the charger as a power supply for a high power led, or am I way off?  

[Paweł Si]

2015-08-09 21:42 GMT+02:00 Paul Verburg <paul.v...@gmail.com>:

Thanks,

I will ignore it.

I wanted to dump all the eeprom settings "in windows" then found you had done all the hard work in python but could not make it work in windows so started an xubuntu machine and going back to the darkside LOL.

This python script is not very well written, I'm still learning :)

but if you need help just let me know,

(in theory it should also work on windows :) )

[Paweł Si]

2015-08-10 3:05 GMT+02:00 Ivo H <iv...@live.com>:

Just flashed and started to explore the new features. Is the LED support for 

to use the charger as a power supply

unfortunately it's not a power supply, it's more a current source 

with a settable cutoff voltage.

 

for a high power led,

yes :-)

you can power with it high power leds,

in fact for LED's it is better to use a current source than

a voltage source, 

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

Hello Pawel!

It's me again with starting test your new version of FW :-) Nuvoton 50W

Firs of all - congratulations, interface more better than FW 1.0, 

Today try to store+balance 3S Li Ion battery, all work perfect, but resitance of every battery have strange values

Turn off device, and try to do same thing (store+balance)

 

Turn off device, and try to do other thing (charge+balance) it's the same battery

Ready to reproduce the situation again, ask about thing your need

[Paweł Si]

2015-08-24 9:07 GMT+02:00 Владимир Залогин <zalog...@gmail.com>:

Hello Pawel!

Today try to store+balance 3S Li Ion battery, all work perfect, but resitance of every battery have strange values

Ready to reproduce the situation again, ask about thing your need

Hi  Владимир,

it would be great if you could make a LogView log for this

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

Hello Pawel!

here you are 

понедельник, 24 августа 2015 г., 14:56:51 UTC+3 пользователь cheali-charger написал:

[Paweł Si]

2015-08-24 21:17 GMT+02:00 Владимир Залогин <zalog...@gmail.com>:

Hello Pawel!

here you are 

Thanks for the logs,

when it comes to the large internal resistance values at the beginning - you shouldn't be worried,

they haven't been measured yet, so we set them to some arbitrary (big) value, not related to the actual internal resistance,

a relevant measurement is ready after about 10-20 seconds

but the 0mΩ is a different story,

we shouldn't allow such a small value (I will do a bugfix for that when I have some free time)

but in your case the problem occurs because you've set the

"settings"->"min Iout:" too low,

Your charger is not capable to deliver a smaller current than ~50mA

[walla...@gmail.com]

 Hi Paweł
Sorry to bother you. I am a senior student, I will graduate from the college next year.Now I'm doing a  graduation project about rechargeable for easy 2S lithium battery for AVR  , I wonder if you have the relevant schematics and codes? Is it possible to send me for studying ? My mailbox is walla...@gmail.com. Any relevant data will be helpful. Thank you.                                                                                                                                                                                             

Best Regards,

Wallace    

在 2015年7月27日星期一 UTC+8下午10:25:52，cheali-charger写道：

[Maksym Siryk]

Hello. 

Did you include this fix for 4-wire connection https://groups.google.com/d/msg/cheali-charger/o6lu_N-eBtg/kSiffMmCsFwJ to 1.99 version? If not, is this code still work on 1.99-2.00 version if I'll change source withthis code myself?

Thank you.

[Paweł Si]

2015-09-12 17:28 GMT+02:00 Maksym Siryk <mak...@siryk.com>:

Hello. 

Did you include this fix for 4-wire connection https://groups.google.com/d/msg/cheali-charger/o6lu_N-eBtg/kSiffMmCsFwJ to 1.99 version?

hm.. I'm not sure why but no,

see https://github.com/stawel/cheali-charger/blob/master/src/core/AnalogInputs.cpp#L515-L519

 

If not, is this code still work on 1.99-2.00 version if I'll change source withthis code myself?

yes, It should work

I've added a ticket for that

[Igon]

Hi Pawel

Can you check CooCox project? It looks outdated and not compatible to v1.99..

---

[cc] c:/program files (x86)/gnu tools arm embedded/4.9 2015q2/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld.exe: cheali-charger.elf section `.co_stack' will not fit in region `ram'
[cc] c:/program files (x86)/gnu tools arm embedded/4.9 2015q2/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld.exe: region ram overflowed with stack
[cc] c:/program files (x86)/gnu tools arm embedded/4.9 2015q2/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld.exe: region `ram' overflowed by 56 bytes

Does this mean my fork is too big for nuvoton?!

[sasam]

Could you check compiler options on you project? 

If I remember correctly option -Os is the option responsible to optimize by size.

 

[Igon]

Misc Controls
-fno-rtti; -fno-exceptions; -std=c11; -std=c++11

Compiler Control String
-mcpu=cortex-m0; -mthumb; -Wall; -ffunction-sections; -g; -Os; -fno-rtti; -fno-exceptions; -std=c11; -std=c++11; -fno-exceptions;-fno-rtti;-DM0516LBN; -DSUPPORT_CPLUSPLUS; -I.;

-Os is already here...

[sasam]

On ARM M5017 we have 4K RAM for variable, heap & stack and you code are very close to this limit.

One approach is to reduce STACK_SIZE in startup_M051Series.c from 0x00000180 to 0x00000170 or lower. I successfully compiled you code with STACK_SIZE 0x00000170, but I have older gcc compiler (GNU Tools ARM Embedded\4.8 2014q2\bin).

Program Size:

      text   data    bss    dec    hex filename

     33576   1132   3944  38652   96fc cheali-charger.elf

Take in mind that I didn't flash this code to my charger, so I don't know is it work correctly and is it safe to reduce stack_size on this way.

Also you can check map file if you are interested how compiler allocate memory.

$(project_folder)\CoIDE\cheali-charger\Debug\bin\cheali-charger.map

Best regards,

Saša

[sasam]

Other approach is to reduce RAM usage. You can find one my attempt here: https://github.com/sasam/cheali-charger/commit/1fbe03f806b3caba4f506cffe81980cd7d3145d2

[albejanon]

Hi, pawel...

I am testing your new release and by now works fine... this is the first time I use custom firmware on my SKYRC IMAX B6 original and I want to say thanks and congrats... Your release is at astronomical units from the original firmware... Any bug or problem I will report here...

I also wanted to learn to program those microcontrollers (I have some little experience on programming PIC's) and I wonder if you do not mind to tell me what IDE did you used to program and if do you mind let me try some changes under my responsability... I have some experience on fixing (deep cycling, cycling, charging, capacity tests, etc. and other real avionics equipment) on actual aircraft systems batteries and I wanted to help with some ideas if you want or even try some changes with your source code, always under your permission if you are ok with it and if the harware allows the mods.

Anyways I want to thank you and say you can count on me as a beta tester ;-).

[Kamil Gorecki]

can you add Ic change on the fly?

same as  iggnus firmware.

[alex alex]

Hi,

check out this https://github.com/stawel/cheali-charger/blob/master/docs/building.md#nuvoton-m0517---windows (I tried this and it worked) and some other interesting stuff here https://groups.google.com/forum/#!searchin/cheali-charger/CoIDE/cheali-charger/EIXeBsOPQ5Y/wYVENXHgpPcJ (and more other details in other posts on the forum).

Regards,

[alex alex]

Hi guys,

have you tried the external temp sensor with the 1.99 version? Mine is not working and I want a confirmation this is not 1.99 issue before looking into the sensor itself. 

Thanks,

[Igon]

Thank you Sasam :)

Looks like the nuvoton project was compiled successfully

---

I always thought nuvoton has a plenty memory to play with, and what? It's gone already!

[Maikl Januk]

https://github.com/Iggnus/cheali-charger-i1/tree/master/hex/Nuvoton/Not%20tested%20-%20no%20hardware%20to%20test%20with       It does not start 

[sasam]

Dana subota, 26. rujna 2015. u 15:01:02 UTC+2, korisnik Igon napisao je:

Thank you Sasam :)

Looks like the nuvoton project was compiled successfully

 

Yes it compiled successfully with both approach :).
For my opinion better approach is with default stack size, and save RAM using the same buffer for TxSoftSerial & TxHardSerial routines.
Unfortunately I haven't enough time to test if serial routines work as expected.

---

I always thought nuvoton has a plenty memory to play with, and what? It's gone already!

 

We have plenty of EPROM (64KB), but only 4KB RAM.

 

[Jorge Pascoal]

Ext temp is not working with this version 1.99, it was with 1.00...

On the other hand UART on pin 7 is working wonderfully, just put a HC-05 bluetooth module inside my IMAX B6 nuvoton clone and it's working great for "wireless" logging.

[Micha Chlst]

I've flashed Igon's firmware for nuvoton. But it is not working. It stucks at battery edit menu. Or when I try to change current on the fly.

[sasam]

I finally try my last patch on iggnus version and it seem that this approach for RAM saving work as expected. Iggnus version are based on version 1.99 so it share same bugs. It seems that menu for enable/disable temp sensor is missing, or maybe idea is to automatically disable temp sensor when soft serial function is active. Anyway temp sensor not work as expected.

Other strange issue or maybe feature on version 1.99 is possibility that serial port on pin 7 and pin 38 can be used in parallel. Same data can be transmitted over both port in the same time. On my charger I have wire on bot pin. First I tested serial transfer over temp sensor, and after that on pin7 than on pin38. When i switch on port38 i show that data is still coming over port7. When switch back to port7, por38 continue to work.

 

[Igon]

So... I do not know how to compile appropriate firmware for nuvotons (and I do not have any nuvoton-based charger for figuring out the problem)...

[Igon]

Pawel can you look at the Screen::displayAnimation() -
Why it works significantly slower while you holding + or - key?
at v0.99 it is the same, but there was no such effect at 0.33 version (Jozsef's fork)

How can I switch from Keyboard::getPressedWithDelay() to the Keyboard::getPressedWithSpeed()?
getPressedWithDelay() is not enough fast for calibration...

[jry]

I must confirm this problem, it took me several minutes to change values during calibration of latest unstable build.
There should be speed up or acceleration after you hold button for a while.

Dne čtvrtek 5. listopadu 2015 23:32:59 UTC+1 Igon napsal(a):

[Paweł Si]

2015-11-05 23:32 GMT+01:00 Igon <igg...@gmail.com>:

Pawel can you look at the Screen::displayAnimation() -
Why it works significantly slower while you holding + or - key?
at v0.99 it is the same, but there was no such effect at 0.33 version (Jozsef's fork)

hm.. I did some refactoring but I'm still not sure it this fixed the problem.

 

How can I switch from Keyboard::getPressedWithDelay() to the Keyboard::getPressedWithSpeed()?
getPressedWithDelay() is not enough fast for calibration...

I've restored the Keybord::getSpeedFactor() method,

now you can use getPressedWithDelay() and still have the speed factor.

 

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

hm.. I did some refactoring but I'm still not sure it this fixed the problem.

 

yes, the problem is still here
m.b. we need to block the keys acquisition while displayAnimation() is in progress? or till new screen is printing?

 

I've restored the Keybord::getSpeedFactor() method,

now you can use getPressedWithDelay() and still have the speed factor.

But it will not speed up current adjustment by itself? (at calibration process, if you need to roll the calibration value, for example from 5500 to 7000)

I have made an additional changes
https://github.com/stawel/cheali-charger/blob/master/src/core/calibration/Calibrate.cpp#L339
to
changeMinToMaxStep(&value_, dir, 1, maxValue_, Keyboard::getSpeedFactor());


https://github.com/stawel/cheali-charger/blob/master/src/core/drivers/Keyboard.cpp#L33
to
static const uint8_t speedFactor[] PROGMEM = { 1, 1, 1, 11, 11, 10, 100};

11, 10  is not a mistake - it is for indication - next step will be a full speed, m.b. it is time to release a key

[Paweł Si]

2015-11-08 17:46 GMT+01:00 Igon <igg...@gmail.com>:

hm.. I did some refactoring but I'm still not sure it this fixed the problem.

 

yes, the problem is still here
m.b. we need to block the keys acquisition while displayAnimation() is in progress? or till new screen is printing?

 

hm.. I've tested the displayAnimation() method, I it looks like we aren't doing anything during it's execution.

We do use Time::Time::delayDoIdle(10) in it, and my tests  showed that we do a 10ms delay (as we should).

I did also a 0.33v to 1.99v side by side comparison and I did't see any differences.

 

I've restored the Keybord::getSpeedFactor() method,

now you can use getPressedWithDelay() and still have the speed factor.

But it will not speed up current adjustment by itself? (at calibration process, if you need to roll the calibration value, for example from 5500 to 7000)

I have made an additional changes
https://github.com/stawel/cheali-charger/blob/master/src/core/calibration/Calibrate.cpp#L339

 

to
changeMinToMaxStep(&value_, dir, 1, maxValue_, Keyboard::getSpeedFactor());

To be honest I'm no a big fan of this change,

from  my perspective it's much saver if someone has to wait little bit longer during calibration

this way, the current will not jump suddenly, and (in theory) you should do the calibration only once.

https://github.com/stawel/cheali-charger/blob/master/src/core/drivers/Keyboard.cpp#L33
to
static const uint8_t speedFactor[] PROGMEM = { 1, 1, 1, 11, 11, 10, 100};

change added. 

 

11, 10  is not a mistake - it is for indication - next step will be a full speed, m.b. it is time to release a key

I worked a while with the new Keyboard  implementation, 

and I'm not quite happy with it.

Did you noticed that on some chargers 

you get a "double click" when you press a button once?

I will probably have to improve the "debounce" routine.

[alex alex]

Hi,

I like LED feature. Very useful to me.

Thank you Pawel,

On Tuesday, August 11, 2015 at 1:34:16 PM UTC+3, cheali-charger wrote:

2015-08-10 3:05 GMT+02:00 Ivo H <iv...@live.com>:

Just flashed and started to explore the new features. Is the LED support for 

to use the charger as a power supply

unfortunately it's not a power supply, it's more a current source 

with a settable cutoff voltage.

 

for a high power led,

yes :-)

you can power with it high power leds,

in fact for LED's it is better to use a current source than

a voltage source, 

 

or am I way off?  

 

[Igon]

 

hm.. I've tested the displayAnimation() method, I it looks like we aren't doing anything during it's execution.

We do use Time::Time::delayDoIdle(10) in it, and my tests  showed that we do a 10ms delay (as we should).

I did also a 0.33v to 1.99v side by side comparison and I did't see any differences.

 

Hmm.. the speed is same for 5ms delay
but new firmware feels slower because of long afterglow of symbols 255

Not very important, just interesting why is that

 

Did you noticed that on some chargers 

you get a "double click" when you press a button once?

Is it a feature or a bug of such chargers?

[JagiChan Sir]

I flashed the latest and greatest firmware on my B6, and I have noticed something strange. Everything seems to work, except that the charging mosfet and the discharging mosfets are getting quiet hot even at 1A charge/discharge, when the mosfet's are removed from the heatsink (I mean the mosfet's on the bottom of the PCB are not touching the case, they are just hanging in the air). I did some experiment and figured out the very low duty cycle does not turn on the mosfet's fully, keeping them running in the linear region (thanks to the stupid LM393 design). The entire enclosure made of metal is able to absorb the heat, but in reality, the mosfet's should not heat up as their Rds is very low. Any one else observed this behavior?

On Monday, July 27, 2015 at 7:55:52 PM UTC+5:30, cheali-charger wrote:

Hi,

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

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

(the final release will be 2.00)

what's new:

- all battery settings are now in the "edit battery" menu

- two types of menus: "simple", "advanced"

  (see: "options"->"menus: ....")
- 200W/400W chargers fan fixed

- second voltage calibration point

- simple LED support

- removed: edit battery name

to see all possible setting set "options"->"menus:" to "advanced",

Best Regards,

Paul

[JagiChan Sir]

Update: I did this experiment with the charger. I setup a discharge current of 1A, and I saw that the IRF44 is heating up like hell. So I decided to investigate the matter further. I measured the Rds (Drain Source Resistance) using a Agilent 4 wire multimeter when the circuit was powered on (this multimeter draws 10pA,so the loading on the FET is next to nothing) . To my surprise, I saw that the Rds was 14.5 ohms. Now 1A in 14.5ohms is 14.5W. No wonder the FET is heating up like crazy when it is not connected to the case. If the design were correct, then the Rds would have been in milliohm range and the FET would not need a heat sink. Using the datasheet we can see that we need a heat sink with 5.2 deg C/W, which is about 50x50mm. The case is acting like a massive heatsink, but overall this is not a very good design. No wonder a lot of chargers are blowing up their FET's when continuous charging/discharging etc...

No wonder the discharge is also limited to 1A even though the FET is capable of 49A. Imagine if we changed the discharge current to 2A max, then the power dissipated in the FET would be (2x2x14.5 = 58W) and the case will not be able to dissipate all that power. As an engineer, I'm totally unhappy with IMAX B6 charger design, and those chargers which copied IMAX B6 are also equally useless.

[Diogo Carvalho]

The Imax B6 discharge current is controlled by the rds on of the mosfet. It is running in the linear region.

I'm improving the various blocks of my charger. What circuit you suggest for the discharge block?

[JagiChan Sir]

That is not a very good way of controlling current thru a mosfet. Essentially, it is wasting a lot of power. It is not engineering at the finest. Also I noticed ringing on the gate line, which contributes to reduced life of the mosfet. I remember from our Automotive design that we did for the fuel injectors, we were using a dedicated gate driver, developed in house by Bosch. The gate driver can provide 3A of current into a 3000pF capacitor with a rise time of 100ns and it can sink 2A in 150ns (unfortunately, you cannot buy that gate driver separately as it is integrated into another chip) . now that is engineering at the finest. Have you ever seen FET's blowing out on the engine control unit developed by Bosch? Never, that is because it was designed correctly with a lot of safety margin (of course with age components will die).

What you need is essentially a dedicated gate driver with fast rise and fall time. with some circuity around the gate to protect the driver in case of Drain to Gate or Source to Gate short circuit. Additionally, we also need have some kind of clamping circuits around the gate so that the gate is protected from the transients in case high loads (remember, the batteries are connected with a wire to the charger. The wire is basically a crude inductor, which will induce back emf of L*di/dt). So basically, the B6 is a flawed design. I'm trying to see what best can be achieved with that circuit. I'll post my developments as they occur.

[Diogo Carvalho]

The actual discharge circuit is completely analog. It could be used with a bjt transistor but with a mosfet not make much sense.

A gate driver is not sufficient.

The entire circuit would have to be redesigned to apply to the gate a PWM signal directly and not an analog signal.

For the smps block (buck / boost) only the gate driver is necessary. I will use anything like the IR2110

[Igon]

>To my surprise, I saw that the Rds was 14.5 ohms. Now 1A in 14.5ohms is 14.5W.
>No wonder the FET is heating up like crazy when it is not connected to the case.

>No wonder the discharge is also limited to 1A even though the FET is capable of 49A.
>Imagine if we changed the discharge current to 2A max, then the power dissipated
>in the FET would be (2x2x14.5 = 58W) and the case will not be able to dissipate
>all that power. As an engineer, I'm totally unhappy with IMAX B6 charger design,
>and those chargers which copied IMAX B6 are also equally useless.

FET`s Rds is nonlinear - your measurements and calculations are questionable
Discharge FET's power is limited at 5watts by software
And it MUST be connected to the case because it MUST work in the linear mode.
There is nothing so terrible in linear mode for the FETs

>The gate driver can provide 3A of current into a 3000pF... .. .

>unfortunately, you cannot buy that gate driver separately as it is integrated into another chip

Ofcourse we can, but we don't need it at our frequencies and power levels

----

>For the smps block (buck / boost) only the gate driver is necessary. I will use anything like the IR2110

Gate drivers are not very important at our frequencies
I think it is better to use something like lm5118

[Diogo Carvalho]

I think it is better to use something like lm5118

Lm5118 have an internal oscillator, it is used as a standalone smps, and most of the times for a aplication where the vout is consntant.

We want atmega controlling the mosfets and adjusting the output voltage.

[JagiChan Sir]

On Sunday, November 29, 2015 at 11:23:32 PM UTC+5:30, Igon wrote:

>To my surprise, I saw that the Rds was 14.5 ohms. Now 1A in 14.5ohms is 14.5W.
>No wonder the FET is heating up like crazy when it is not connected to the case.
>No wonder the discharge is also limited to 1A even though the FET is capable of 49A.
>Imagine if we changed the discharge current to 2A max, then the power dissipated
>in the FET would be (2x2x14.5 = 58W) and the case will not be able to dissipate
>all that power. As an engineer, I'm totally unhappy with IMAX B6 charger design,
>and those chargers which copied IMAX B6 are also equally useless.

FET`s Rds is nonlinear - your measurements and calculations are questionable

Discharge FET's power is limited at 5watts by software

And it MUST be connected to the case because it MUST work in the linear mode.
There is nothing so terrible in linear mode for the FETs

Agreed, Rds is non linear that is how a mosfet characteristic is. But here is the catch, I have not gone by theory, I'm doing real world measurements, when the fet is ON and draining 1A current. By the way, I connected a SLA 7AH battery to the charger while making the measurements. My problem is not the linear mode of operation of FET, it is okay for an amplifier, but when used for switching I will say it "wrong way of doing things". By the way, yesterday night, I did make some modifications to the circuit and now the FET heat's up not within 5 seconds, but it takes about 45 seconds to reach the same heat. So there is something not correct in the circuit. You can see a lot of videos on youtube telling you how the IRFZ44N lost its magic smoke and so on...

>The gate driver can provide 3A of current into a 3000pF... .. .
>unfortunately, you cannot buy that gate driver separately as it is integrated into another chip

Ofcourse we can, but we don't need it at our frequencies and power levels

Definitely you can buy drivers from Micrel or IOR but not from Bosch (they will want an arm + leg + an eye) ;) 

----

>For the smps block (buck / boost) only the gate driver is necessary. I will use anything like the IR2110
Gate drivers are not very important at our frequencies
I think it is better to use something like lm5118

Agreed, but then why are the mainstream guy's like SkyRC, Bantam and others not using these chips?

[JagiChan Sir]

Ok finally, I got hold of a lowside FET driver and I did some experiments with the current B6 configuration and also changed the B6 drivers to a FET driver.

Attached you can find a PDF with the scope plots of the original FET waveforms and my modified one with a FET driver.

Okay, now my B6 is screwed due to the multiple modifications and now it does not fit into the case and there are multiple traces cut and pasted :(

Please don't make modifications to your B6 and screw it, this is just for your info in-case you are planning to use FET's in your next projects remember to always use a FET driver, it is expensive but gives you reliable results, so that you can concentrate on the real aspect of your project rather than debugging FET driving issues.

[Juha-Matti Sidorow]

So if you change fet driver, you can use higher charge / discharge current? Can someone make it possible with this software?

[Jake Stewart]

Great work!  Any updates?

I just got my charger running and thought I'd poke around in the code and make a few cosmetic changes.  Hate to work on old code when a new major version is in beta already.  Is the 1.99 in one of the forks?

[JagiChan Sir]

Technically what you say is correct, but reality is different. Changing the FET driver is one part, then you have to redesign the electronic load part which is composed of LM2904.

If you observe carefully, the PWM from OC1A is fed into the LM2904 which is partly used as a comparator and partly as Opamp. Unfortunately, the Opamp outputs when used as a comparator are not very well suited for fast turn on/turn off (because of their inherent characteristics), hence just the FET driver will not help here. Of course some software modification is required, which should be easy for our software guru's here on this forum. Given all these hardware issues, I think it is best to stick with the B6 hardware as it is and use it till it works, instead of "futzing" and screwing up a working charger (I screwed my charger with all those FET modifications, you should NOT. Just read the post and learn how people can make bad electronics design and yet make the money).

Look at the V_IN reverse protection. It uses a N channel fet as a crowbar. If you connect reverse polarity at the input of the charger the VT2 (AO4468) [or something similar] will definitely blow up (unless the power supply is limiting the voltage and current). Try reverse polarity input (V_IN) using a car battery and you'll see the magic smoke from the charger (happened to me, while I tried it. I removed that FET and put in a regular SB560 diode. Oh well, there is 0.4V drop, but who cares there is no magic smoke when I make reverse polarity even with car battery).

The point of my whole exercise has proven that B6 (either original or its clones) are faulty by design, and the flaws are being covered using software magic, which after sometime shows up as hardware failures (like mosfets burning up). You can google and invariably you'll see 90% of the posts showing how the MOSFET is fried and what is the value for replacement and so on...

[Igon]

>>Lm5118 have an internal oscillator
is lm393 4 2/2 not an oscillator? - https://drive.google.com/file/d/0B1RXXTatsA1cbkM2dXFxTldjTUU
(upper-left corner, last page)

>>it is used as a standalone smps, and most of the times for a aplication where the vout is consntant.

Hmm.. And what? lm5118 is an adjustable controller

>>We want atmega controlling the mosfets and adjusting the output voltage.

Directly? Without current feedback like 150W+ chargers has?
(I think these feedback can be easily turned into voltage feedback, this is acceptable for chargers and extremely helpful for power supplies)

----

>>By the way, yesterday night, I did make some modifications to the circuit and now the FET heat's up not within 5 seconds, but it takes about 45 seconds to reach the same heat.

Is it about "charging" FETs or not?

>>Agreed, but then why are the mainstream guy's like SkyRC, Bantam and others not using these chips?

Because of $6 LM5118's price? = 20x LM2904

[JagiChan Sir]

On Friday, December 4, 2015 at 3:45:33 AM UTC+5:30, Igon wrote:

>>Lm5118 have an internal oscillator
is lm393 4 2/2 not an oscillator? - https://drive.google.com/file/d/0B1RXXTatsA1cbkM2dXFxTldjTUU
(upper-left corner, last page)

Ok, i see you are looking at the 150W charger. I have the IMaxB6 and I'm looking at the schematics from the RC groups.

>>By the way, yesterday night, I did make some modifications to the circuit and now the FET heat's up not within 5 seconds, but it takes about 45 seconds to reach the same heat.
Is it about "charging" FETs or not?

Yes, all the FET's need to have dedicated drivers. The bipolar transistor design is okay but if you want fast switching with minimal losses, then FET driver is the way to go. See the links below for lots of posts about Mosfets

Look here, this post has some interesting info and conclusions

http://electronics.stackexchange.com/questions/73041/why-mosfet-is-getting-very-hot

http://www.microchip.com/forums/m855528.aspx

http://powerelectronics.com/power-electronics-systems/mosfet-selection-switching-power-supply-systems

>>Agreed, but then why are the mainstream guy's like SkyRC, Bantam and others not using these chips?
Because of $6 LM5118's price? = 20x LM2904

You answered you own question :) But the problem is that it results in bad design which will eventually kill the goodwill of the company :(

[JagiChan Sir]

I managed to fix the N Channel mosfet driver with a changed design. The IRFZ44 is now running much cooler :)

Check out the attachment for the changes that I have done and also see the measurements.

You'll need to see the respective schematic for your charger and make those changes.

Regards,

Jagichan 

[Igon]

Look here, this post has some interesting info and conclusions

http://electronics.stackexchange.com/questions/73041/why-mosfet-is-getting-very-hot

http://www.microchip.com/forums/m855528.aspx

http://powerelectronics.com/power-electronics-systems/mosfet-selection-switching-power-supply-systems

Oh, this is a well known things :)

>> New_Driver_Design.pdf
The most important gate's voltage for the FETs switching are between 2 and 7 volt, so who cares about ringing at 0 and 12
It is interesting to see the difference between original and modified schematic
And especially with FET's drain voltage

btw Did you change VT16 IRF7413 with IRFZ44 ? (http://www.rcgroups.com/forums/showatt.php?s=df7049bcbafdb5d7d06765c264e5c4bb&attachmentid=3693125&d=1293732709)

[JagiChan Sir]

On Monday, December 7, 2015 at 2:29:56 AM UTC+5:30, Igon wrote:

Look here, this post has some interesting info and conclusions

http://electronics.stackexchange.com/questions/73041/why-mosfet-is-getting-very-hot

http://www.microchip.com/forums/m855528.aspx

http://powerelectronics.com/power-electronics-systems/mosfet-selection-switching-power-supply-systems

Oh, this is a well known things :)

Generally, we tend to ignore well known things and that is what becomes the cause of our misery ;)

 

>> New_Driver_Design.pdf
The most important gate's voltage for the FETs switching are between 2 and 7 volt, so who cares about ringing at 0 and 12
It is interesting to see the difference between original and modified schematic
And especially with FET's drain voltage

btw Did you change VT16 IRF7413 with IRFZ44 ? (http://www.rcgroups.com/forums/showatt.php?s=df7049bcbafdb5d7d06765c264e5c4bb&attachmentid=3693125&d=1293732709)

(1) Yes, I changed the IRF7413 with IRFZ44, because the former has lower power dissipation in that package form (unfortunately, the IRFZ44 is a TO220 package and it does not fit on the PCB, so I had to solder some wires and let it hang on the underside of the PCB. No wonder nothing fits in the box anymore). I also used this circuit for the FET on the electronic load and it is working very nicely without killing the FET.

(2) The entire electronic load made of LM2904 was removed, and I have to design another load but that is a different topic. I still have to see how to utilize the existing circuit.

Alright, let me see if I can make some measurements of the Drain voltage vs Gate voltage and so on...

By the way, excuse my tardiness, I forgot to add the 10uF cap in the schematic across the collectors of the transistors. The 10uF cap is very important because it will provide the transient high current needed to charge the FET gate. Please add a 10uF cap across the collectors of the BJT transistors (the cap has to be as close as possible to the transistor collectors).

[JagiChan Sir]

On Monday, December 7, 2015 at 2:29:56 AM UTC+5:30, Igon wrote:

>> New_Driver_Design.pdf

The most important gate's voltage for the FETs switching are between 2 and 7 volt, so who cares about ringing at 0 and 12
It is interesting to see the difference between original and modified schematic
And especially with FET's drain voltage

Sorry for the delay, I was out of town on business trip to Germany and USA for the past few days, so now I'm back home :)

Check out the attached plots of gate and drain voltage. There is some ringing on the drain, but it is within acceptable limits.

Unfortunately, I cannot make comparison between old and new, as I have modified the B6 beyond bringing it back to original state.

If there is anyone who is interested and has original B6, can you please make some measurements and plots of the the FET curves during charging/discharging.

Regards,

JagiChan

[JagiChan Sir]

Okay, after reading and re-reading the schematics and using some engineering theory, I figured out a very simple way to fix the heating of that Discharging Mosfet without changing the original design and screwing up the B6. (The mosfet I'm talking about is VT6, see the schematics here http://www.rcgroups.com/forums/showatt.php?s=df7049bcbafdb5d7d06765c264e5c4bb&attachmentid=3693125&d=1293732709)

If you look carefully, R45 is the discharge resistance of 0.5 ohms which is very small and is pretty much like a short circuit of the drain-source resulting in the death of the mosfet when 1A of current is being requested from the battery (especially SLA's/LiPo/LiIo are very good at providing such currents without any issue). So what I did was I removed the resistor and replaced it with a 5W car bulb (the bulb is from the interior dome light). Now what happens. To get 1A of current thru the bulb we will need like 6V (I got this value by experiment. I connected the bulb to a variable power supply and increased the voltage until the bulb was drawing 1A), so the controller opens up the the PWM duty to be pretty high, which results in the Vgs > 4V. Now at Vgs > 4V, the Mosfet is pretty much in saturation and the mosfet does not need a heatsink and it is cool as ice. I'm okay with the bulb, because instead of killing an expensive FET due to heat, I can let the bulb glow, heat and fail with usage. (Either way to discharge a battery the energy has to be converted from chemical to heat or light or something like that).

By the way, you can also use a resistor of 5ohms/10W/20W (at 1A the resistor will dissipate 5W, so you take 10W/20W to be on the safe side and avoid excessive heating of the resistor), that is if you are not comfortable handling the bulb ;-)

Additionally, you can also command higher discharge current, without risking the MOSFET dying. Look at the curve from the datasheet (attached), you can see that at Vgs = 4.5 and Vds >= 1V the MOSFET can handle 10A easily. Of course some changes need to be done to the software.

With this I think, I have solved the mystery of the MOSFET and the heating issue.

Regards,

JagiChan

[Diogo Carvalho]

You can change the resistor, yes and the power will dissipate less in the mosfet and more in the resistor.

In the original schematic the purpose of the resistor is not dissipate power but get the feedback of the current.

So if you change the value of the resistor don't forget to adjust the gain of the first ampop to have the same voltage at it's output for the same current value.

More problematic is if you put a 5ohm resistor, because for 1A you have 5V on it and in the pin 6 of the opamp you can only have a maximum of 2.5V, so the first opamp need to have gain less than 1.

[JagiChan Sir]

On Tuesday, December 15, 2015 at 9:58:47 PM UTC+5:30, Diogo Carvalho wrote:

You can change the resistor, yes and the power will dissipate less in the mosfet and more in the resistor.

In the original schematic the purpose of the resistor is not dissipate power but get the feedback of the current.

Correct! but the problem in the original circuit is that the MOSFET is working like a resistor dissipating the power and getting heated. And as we know the hotter the MOSFET gets the more current it allows and so on until it reaches thermal runaway and eventually dies, if not properly heat-sinked (which I'm pretty sure is the case with our B6, because the MOSFET is not mounted but is just touching the metal case, which may not be able to provide effective heat sinking).

So if you change the value of the resistor don't forget to adjust the gain of the first ampop to have the same voltage at it's output for the same current value.

More problematic is if you put a 5ohm resistor, because for 1A you have 5V on it and in the pin 6 of the opamp you can only have a maximum of 2.5V, so the first opamp need to have gain less than 1.

Very true, you need to make some changes to the opamp for current measurements, but that is not such a big issue as we can easily calculate the Rf/Ri values to arrive at the needed gain for the opamp. (FYI: I removed the electronic load an fed the PWM directly into the FET using a BJT driver as described in my previous posts, and the duty cycle of the PWM is being adjusted based on the readings of the current being sampled from the new resistor. Okay, I know I did too many modifications that now my B6 is no longer original or clone)

 

Regards,

JagiChan

[Igon]

Pawel what did you think about such modification? https://groups.google.com/d/msg/cheali-charger/EuhUAoyecso/Doj3F2fBEgAJ
It will let us to turn high-powered chargers into a power supplies

[Paweł Si]

Hi guys, 

I see a interesting discussion here, 

but I would like to clarify something:

The discharge circuit uses the IRFZ44N MOSFET transistor 

to dissipate the discharged energy,

the transistor should be hot by design.

The MOSFET shouldn't work as a switch

(work only in the "full-ON" "full-OFF" state),

it should only be in the "saturation region" or "linear region" (ohmic mode),

and this is the case when we look at the more advanced 150W and 200W chargers.

When it comes to the Imax B6 we do see some switching,

but personally I would consider this switching as a (not very important) "design bug".

It's because the Imax B6 doesn't have (and should not have) the C18, C19 capacitors 

(see https://drive.google.com/file/d/0B1RXXTatsA1cbkM2dXFxTldjTUU/edit )

ps.

If you guys have a important topic you would like to discus,

it's probably better to create a new threat for that.

[Paweł Si]

2015-12-16 21:28 GMT+01:00 Igon <igg...@gmail.com>:

Pawel what did you think about such modification? https://groups.google.com/d/msg/cheali-charger/EuhUAoyecso/Doj3F2fBEgAJ
It will let us to turn high-powered chargers into a power supplies

looks interesting, 

have you try it? 

[Igon]

>> When it comes to the Imax B6 we do see some switching,
>> but personally I would consider this switching as a (not very important) "design bug".
>> It's because the Imax B6 doesn't have (and should not have) the C18, C19 capacitors

We (all?) have "C19" and "R141" and RCgroups schematic has a mistake.. -- imaxB6-original-front_cr.jpg
So, "C19" = 0.1, "R141"=100k (checked at unnamed and Accucel-6 6A chargers)
R140 - R21 (imax)
R139 - R22 (imax)

>> looks interesting,
>> have you try it?

No, I do not have such charger yet :(

[Paweł Si]

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

>> When it comes to the Imax B6 we do see some switching,
>> but personally I would consider this switching as a (not very important) "design bug".
>> It's because the Imax B6 doesn't have (and should not have) the C18, C19 capacitors
We (all?) have "C19" and "R141" and RCgroups schematic has a mistake.. -- imaxB6-original-front_cr.jpg
So, "C19" = 0.1, "R141"=100k (checked at unnamed and Accucel-6 6A chargers)
R140 - R21 (imax)
R139 - R22 (imax)

Ok, I take it back :-)

sorry, my mistake, previously I did only a simulation based on the RCgroups schematics.

now I've checked  the IRFZ44N gate during discharge with an oscilloscope

and I see only a constant voltage.

JagiChan how did you measure the switching pattern in B6_FET_Analysis.pdf?

[Juha-Matti Sidorow]

Is there any change to increase mAh bigger than 31 000mAh? When chargin car batteries this is too low value. I have now 55Ah battery chargin with 31Ah settings..

[JagiChan Sir]

I had measured that on the original B6 with the original firmware it had before I flashed the cheali firmware and made lots of modifications to the hardware.

[Paweł Si]

2016-01-07 11:57 GMT+01:00 Juha-Matti Sidorow <jus...@gmail.com>:

Is there any change to increase mAh bigger than 31 000mAh? When chargin car batteries this is too low value. I have now 55Ah battery chargin with 31Ah settings..

regression fixed.

Best regards,

Paweł

[Igon]

Pawel, can you explain how the voltage calibration works -

As I understand - the first point - input voltage.. What about second point?

Also how to use p1 & p0 correctly and can such calibration help with Thunder's crater between 1 and 15 volts?

(Y axis - difference between Vout indication and real voltage in calibration mode, balancer is not connected)

T610out - output voltage error of HW-modded Thunder T610 in LED mode

Strange but PWM "DAC" linearity is much better than ADC

Do we have some more eeprom space for multipoint voltage calibration

For example for 1-2-5-10-20v?

[Igon]

How can I make eeprom file with compiler?
C:/Vox/Cheali/src/hardware/atmega32/targets/Turnigy-Accucel-6-50W-5A/defaultBatteries.cpp:25:16: error: expected initializer before 'capacity'
uint16_t EEMEM capacity = 2000;

It were possible with November's version, but now it stops with this error

The idea is to make eeprom filled with the favorite batteries
Not sure if it possible due to CRC check...

[Paweł Si]

2016-04-24 23:40 GMT+02:00 Igon <igg...@gmail.com>:

How can I make eeprom file with compiler?
C:/Vox/Cheali/src/hardware/atmega32/targets/Turnigy-Accucel-6-50W-5A/defaultBatteries.cpp:25:16: error: expected initializer before 'capacity'
uint16_t EEMEM capacity = 2000;

It were possible with November's version, but now it stops with this error

I'm guessing EEMEM is not defined, it's a avr specific keyword, try:

#define EEMEM

but if you need to edit a eeprom there is a "simpler" (in my opinion) way, in:

cheali-charger/utils/eepromExtractor is a program called eeprom.py written in python,

https://github.com/stawel/cheali-charger/blob/master/utils/eepromExtractor/eeprom.py

it can read an existing eeprom.bin and you can also edit the eeprom with it.

(although i didn't use it a while, so it may need some updates)

[Igon]

 

I'm guessing EEMEM is not defined, it's a avr specific keyword, try:

#define EEMEM

It seems I forgot "#include memory.h"
But my additions brokes the EEPROM size :(

 

but if you need to edit a eeprom there is a "simpler" (in my opinion) way, in:

cheali-charger/utils/eepromExtractor is a program called eeprom.py written in python,

https://github.com/stawel/cheali-charger/blob/master/utils/eepromExtractor/eeprom.py

it can read an existing eeprom.bin and you can also edit the eeprom with it.

(although i didn't use it a while, so it may need some updates)

 

Is it not only an extractor?
Can't figure how to make eeprom.bin with calibration and batteries data..

[Paweł Si]

2016-05-02 21:21 GMT+02:00 Igon <igg...@gmail.com>:

 

Is it not only an extractor?
Can't figure how to make eeprom.bin with calibration and batteries data..

I've added a working example to eeprom.py

just remove line 42:

https://github.com/stawel/cheali-charger/blob/master/utils/eepromExtractor/eeprom.py#L42

 

[Paul Verburg]

Works very well now I don't have to re add my batteries after an upgrade.

Thanks so much for this extra feature!

Paul V.

[Paweł Si]

2016-06-07 20:56 GMT+02:00 Ronald Zonneveld <ron4ld.z...@gmail.com>:

is it also possible to flash a new fw version and adfter that  write back the previous eprom data?

eg going from 1.99 april release to the 1.99 june release

depends if I added something to the eeprom, but

you can always try, if they aren't compatible the firmware will reset the eeprom.