Open source hardware for cheali-charger

[TBmax]

Hello all

I was unfortunate enough to get stuck with the uncompatible Imax B6 clone from the ebay.
So I decided to design new compatible circuit board from scatch. It has been from the start with the intention to make fully open source published project, so that everyone can use the work already done and improve from there, or just more easily make their own version.

So far I have no experience with the cheali-charger software whatsoever. I just do not have any compatible hardware... yet.

At the moment the design is reached the version I am quite confident with that it probably works when assembled (prossibly with little tweaking however).

Took the quote for the prototype assembly it is $584 for 10 boards (only SMD components assembled). It is little too much for me alone to afford to spend at the project in the moment. So I decided to publish all already no matter untested. Maybe it is better also to get some comments beforehand about the design. All comments and ideas welcome.

Pdf schematic attached to the post here.
More notes and things (gerber files etc.) at the moment contcentrated here:http://www.digiwood.ee/2-uncategorised/9-tbmax-charger

Regards
Teemo

[A. Ross]

Brill! Been wanting a floss charger hw for ages.

You might find the quite educational update posts about designing products using cheap easy to source components in china and his experiences of interest . from this crowd fund:
https://www.crowdsupply.com/eoma68/micro-desktop/updates

I would be interested in pledging for a ready made product in a crowd fund.

[TBmax]

I have made several updates to the circuit an the boards. Trying to optimize and improve the circuit to my liking. At the moment waiting for the first boards to arrive to start making and testing the prototype.
I attach here the latest schematic.

BR
Teemo

[diggit]

Why not optimize a bit more and use proper gate drivers like MCP1402T?

4051 should work with 5V logic levels, using 3 op amps for level conversion is wasting.

There is CD4067 which is dual 8 channel mux.

MCU AVCC should have better decoupling.

Each MCU VCC pin should be decoupled with capacitor.

I suggest adding small trimmer to U5B feedback to tune CMRR.

C6 should be low ESR too.

There are better MCUs than Atmega32. eg. STM32 are cheap and easy to use. I guess you are not FW developer so that is the reason to to stick to AVRs.

About schematic, why do you use MCU pin names as (global) net names? It makes much more sense to name nets according to their purpose rather than pin number.

Do not be discouraged by this reply ;)

[TBAmax]

Hello, I am not discouraged at all! On the contrary I like good discussion!

The gate drivers seems a bit pricey for the application. Hoping so much to get away with only those 2n7002 and PNP pairs :)

For the 4051 mux I studied the datasheet and reached the conclusion that their driving voltage is proportional to the supply, so needs level amplification, and the opamps were there readily available. There was some misleading information about 4051-s ability to perform level conversion, it needed some negative supply. I have no sample of 4051 at the hand yet, so had no chance to make real measurements, only go by the datasheet. The current understanding is that it needs level conversion.

 When routing the board I noticed that with the two MUXes the routing bitween them is a bit of a mess so that could use some improvement. The CD4097 would be ideal candidate for that, yes, but must check availability. To be honest related to that, I already changed to the two 4052-s (2x4ch mux) in the next improvement version (not finished yet). 

I do not understand what you mean about tuning CMRR?

C6 was intended to be the same as C7 I just forgot to make note about it in the schematic.

I am a little worried indeed about the software and how I would get it running. All the calibration and stuff. Been looking the code a little, but must admit it is quite unclear to me at the moment.

I tried to import the code to the Eclipse IDE to get the glimpse of general structure and what calls to where, do not know if this is the right way to go.

Took the pin names directly from the IMAX reverse engineered circuit and left them same to preserve compatibility. That is all correct that I was scared to change the CPU because I am not enough familiar with the code, so do not want to get stuck with uncompatible CPU.
I guess you are reffering that it would be easier to whack in another replacement CPU when names clear. That is good idea, and definitely work in progress already :).

As for the notes from the routing the board I actually would prefer CPU with less pins and use SPI port and shift registers for output extenders. Also the MUX-es are very much my liking. It is quite big work and headache routing all the wires across the board to the single many pins CPU.

I've been interested in the digitalWrite() part of the code, very much would like to snoop out from the disassembly listing how the compiler optimizes those functions. For example  for Arduino there is digitalWriteFast library that makes extensive use of macros to optimize port writes basically to the single machine insturction, and since digitalWrite is used  many times in the code it makes huge speed and flash savings. I would very much like to know if the compiler optimizes the function same way when there are calls to inline functions as in sheali. The peak for me about the code in the moment is that I was able to compile the code sucessfully following the instructions provided.

[diggit]

On Monday, October 29, 2018 at 12:57:25 AM UTC+1, TBAmax wrote:

Hello, I am not discouraged at all! On the contrary I like good discussion!

The gate drivers seems a bit pricey for the application. Hoping so much to get away with only those 2n7002 and PNP pairs :)

yes, it is trade-off between price and simplicity.

For the 4051 mux I studied the datasheet and reached the conclusion that their driving voltage is proportional to the supply, so needs level amplification, and the opamps were there readily available. There was some misleading information about 4051-s ability to perform level conversion, it needed some negative supply. I have no sample of 4051 at the hand yet, so had no chance to make real measurements, only go by the datasheet. The current understanding is that it needs level conversion.

oh, sorry, specs are for 15V and if you expect even 18V input voltage, 5V may not be enough for logic High on input. I'd do level conversion using pullup resistor and pulling it down using eg. 2n7002. There would be signal inversion, but that is not a problem...

 When routing the board I noticed that with the two MUXes the routing bitween them is a bit of a mess so that could use some improvement. The CD4097 would be ideal candidate for that, yes, but must check availability. To be honest related to that, I already changed to the two 4052-s (2x4ch mux) in the next improvement version (not finished yet). 

I didn't check availability, sorry

I do not understand what you mean about tuning CMRR?

When you build differential amplifier wit op amp, you have to match specific resistors to suppress common voltage for both input OP amp pins.

 

C6 was intended to be the same as C7 I just forgot to make note about it in the schematic.

I am a little worried indeed about the software and how I would get it running. All the calibration and stuff. Been looking the code a little, but must admit it is quite unclear to me at the moment.

I tried to import the code to the Eclipse IDE to get the glimpse of general structure and what calls to where, do not know if this is the right way to go.

Took the pin names directly from the IMAX reverse engineered circuit and left them same to preserve compatibility. That is all correct that I was scared to change the CPU because I am not enough familiar with the code, so do not want to get stuck with uncompatible CPU.
I guess you are reffering that it would be easier to whack in another replacement CPU when names clear. That is good idea, and definitely work in progress already :).

As for the notes from the routing the board I actually would prefer CPU with less pins and use SPI port and shift registers for output extenders. Also the MUX-es are very much my liking. It is quite big work and headache routing all the wires across the board to the single many pins CPU.

not sure what form factor you are targeting but original board is not extremely stuffed with components and traces.

Mux solution with one differential op amp is interesting (only one CMRR tuning), but I wouldn't go for shift registers for digital signals, there is not much benefit from that

I've been interested in the digitalWrite() part of the code, very much would like to snoop out from the disassembly listing how the compiler optimizes those functions. For example  for Arduino there is digitalWriteFast library that makes extensive use of macros to optimize port writes basically to the single machine insturction, and since digitalWrite is used  many times in the code it makes huge speed and flash savings. I would very much like to know if the compiler optimizes the function same way when there are calls to inline functions as in sheali. The peak for me about the code in the moment is that I was able to compile the code sucessfully following the instructions provided.

C code is here. IMO not much code even in functions called inside. I don't see benefit from doing optimizations there.

That is another disadvantage of small AVR MCUs. They do not have debugging interface, so no instruction stepping though code...

[TBAmax]

Hello! I have received the PCB boards for the ver1.9 and built up the circuit. There was one small connection error that LCD backlight voltage polarity was reverse. Fortunately that was relatively easy to rewire.

Then for the firmware I now used ImaxB6-original, but I added "#undef ENABLE_SIMPLIFIED_VB0_VB2_CIRCUIT" to the HardwareConfig.h and recompiled. This is because I have full diff amps for all cells. I hope that is correct. Also I had to cut mux address 0 input and wire it to the batt- because it was unclear where it is used in the code, all info about that is welcome. So far success!

For the fuses flashed -Ulfuse:w:0xAF -Uhfuse:w:0xC9. And it is alive!

But there is problem with the charging current. Calibrated the voltages and currents, but now the testing shows that current displayed when charging is not correct. When set to 1000mA, it shows 1000mA, but actual current to the battery is only about 560mA (During the 1000mA current calibration real current and displayed current is matching).

[TBAmax]

On Monday, November 19, 2018 at 8:40:28 PM UTC+2, TBAmax wrote:

But there is problem with the charging current. Calibrated the voltages and currents, but now the testing shows that current displayed when charging is not correct. When set to 1000mA, it shows 1000mA, but actual current to the battery is only about 560mA (During the 1000mA current calibration real current and displayed current is matching).

I solved the problem with the charging current. It was me measuring current in the battery minus wire, and half of the current went around via the balance port batt- wire! So it is all good!
Now let me enjoy the charging - discharging all of my batteries for a while :) ...

[TBAmax]

Been playing with the charger now.

There seems to be missing the calibration for the Vbatt? It is in the calibration menu but can not be activated.

Calibration point is selectable in the menu there is 0 and 1. Do not know it that is working or not? Is it meant to be to calibrate one point with empty battery and one with full?

I get the about 0.6 volts reading on the  next cell after the one that is connected. This is becuse the opamp still sees last cells full voltage at its negative input and is then unable to drive fully close to the 0. Then seems the software thinks that there is 6 cells connected instead of 5 and for some reason refuses to charge at all. So the current status of the charger is still unusable.

[diggit]

There seems to be missing the calibration for the Vbatt? It is in the calibration menu but can not be activated.

Vbat is calibrated to sum of all (active) balancer voltages. When you confirm cell voltages, charger takes sum of all cell voltages and calibrates Vbat as equal to it.

 

Calibration point is selectable in the menu there is 0 and 1. Do not know it that is working or not? Is it meant to be to calibrate one point with empty battery and one with full?

Each calibration can be done in 2 points to calibrate ratio and offset. By default you do it only for currents (that is reason for 2 calibration values.)

Due to untrimmed resistor divider in diff amp for cell measurement (bad CMRR), it does not make much sense to do calibration in 2 points. There is 3rd element influencing measured value - common mode voltage. Volteage sum of all lower cells and it changes :/. So good measurement precision is only around calibration points. (Calibrate balancer on fully charged battery).

 

I get the about 0.6 volts reading on the  next cell after the one that is connected. This is becuse the opamp still sees last cells full voltage at its negative input and is then unable to drive fully close to the 0. Then seems the software thinks that there is 6 cells connected instead of 5 and for some reason refuses to charge at all. So the current status of the charger is still unusable.

"becuse the opamp still sees last cells full voltage at its negative input" not sure why this happens. You can change threshold when cheali considers cell as not present. I believe it is now set somewhere around 0.4V.

[TBAmax]

"becuse the opamp still sees last cells full voltage at its negative input" not sure why this happens. You can change threshold when cheali considers cell as not present. I believe it is now set somewhere around 0.4V.

It is normal. When all cells are not connected then there are some floating inputs. And next amplifier after the last connected cell has one input connected and other floating. The connected input acts as extra pull up (via feedback resistor) for the opamp. This is why we get larger reading for the following(missing) cell after the last one connected in line. (LM324 opamp simply is not strong enough to pull output low so heavily very near to 0V.) I have raised the cell present treshold to 0.7V for my circuit at the moment, and it works fine, no problems. So it is really no problem for the current application, as long as it is accounted for in software. This is same for both, the classic mux after differential amplifiers circuit, and my circuit where muxes are before opamp.

This is the waveform from the balancers to the ADC.

I been having problems with the balancers measurement stability. There seems to be some drift. And I have had the muxes burn down on some occasion. I have the circuit where the muxes are brought forward and using only one opamp so the muxes supply voltage is higher. But the output should be more less the same. As we can see from the picture the duration of the measurement from one channel is only 2ms. This is way too overkill quick. I am currently suspecting that my muxes are overheating because of the currents from the transitional processes and this causes them to burn down (alternatively there is a chance that the muxes I have are not up to spec on maximum supply voltage, because I got them off the ebay). For the application it would be quite sufficent to switch the channels much less often, say once in 20ms or even 200ms. When in operation muxes get slightly warm to the touch.

[TBAmax]

Just want to let know that I have managed to get the circuit working and stable now.
The main problem was that relying on the HCF4051 muxes internal input protection diodes was not sufficent. Adding external protection circuit did the trick, and it is working stable now. The parts count specially resistors is still smaller than would be with the separate diffamps for all channels(cells). CMRR problem is still theoretically unresolved because although the circuit have less resistors thus less variables in the equation, it is still not tuned specifically against CMRR problems. Tests with 1% resistors shows that it is enough accurate for the purpose with the usual calibration as it is. Alhough I have not tested the wost case cenarios where the resistors would be radically at the oposite ends of tolerance spec. So I call that as sufficent.

I add the pictures here with the modification and the chematic explaining also New parts being D8-D11 and R4. The diodes clamp excess voltage from the mux inputs.
Some other minor modifications must also be made for example I have changed R14 and R16 values to prevent meltdown without firmware.
And a fan circuit is reverse logic as happened.
And it  must be noted that maximum input voltage can not exeed 18V or the muxes will burn. So the acceptable input voltage range is now 15.1V-18V when charging 6cell LiPol which is little limiting now, (can go lower for less that 6cells).

Last but not least I am quite impressed by the current Cheali-charger firmware. All very intuitive to use, and just for the technically knowleable people. Dynamically changing menus and stuff...  Would not believe it is possible with the processor as simple as Atmega32A is. Huge respect to Pawel and all other contributors who have taken it to this point!

[TBAmax]

Hello all

Just a little update about the project.

I have done one extra intermediate prototype(ver2.3) with the Arduino Nano. I just relaxed and let the imagination run. Towards the ideal version in my mind at the time. 

Features:

-Arduino Nano

-Dedicated hardware SMPS using TL494 -> Higher switching frequency ->possibly more power! Slightly overlapping buck-boost operation.

-Improved balancers drive, uses all same resistors for all channels, easier to assemble.

-Fits 10x10cm cheap PCB board manufactoring limits.

-Possibly programmable without dedicated programmer(using Arduino bootloader).

-UART -> USB converter already built in to the Arduino.
-balancers transistors placed under power resistors to save space.

Cons for example:

-Arduino supply voltage regulator only accepts up to 15V, as I unfortulately after discovered. Supply voltage limited to 15V max.

-by screw holes fits to the standard fake Imax B6 casing, but difficulties with input output connectors and fitting Arduino under the LCD.

-Maybe: More chips on board, and more code because of input output extenders. (I do not consider big problem, it is quite elegant to drive LCD and other stuff via SPI, with suitable libraries)

Conclusion:

-Unable to adapt the circuit(ver2.3) for cheali-charger software at the moment, because too different hardware, and uncertainty about what funtions would need to be rewritten (hardware layer boundaries). So only some Arduino code for basic testing of the concept of TL494-s based SMPS.
-No real usable production version, but yes I am having fun with it. Next will be back to the ATMEGA32A
-will not publish this PCB design for now. But willing to share in case somebody interested in some aspect. Who interested please feel free to contact me directly.

[TBAmax]

Hello All

I have released circuit ver 2.4

Seems this is as good as it gets with the Atmega32A based design.

Some of the improvements in this design

• Improved input voltage range(10-24V)
• net names according to their purpose
• mistakes in PCB design that was in previous versions all corrected, no modding of traces nessesary any more

[Alex Bustamante]

Hi,

NICE work !! i Want to build one. Whats the easiest / cheapest way of getting the PCBs printed?

Thanks  !

[Craig Brown]

Good day,

I've run a batch of these through JLCPCB. This was literally my first endeavor into EE, so I just printed the base files without resolving the layout in 2.7. The 7805 voltage regulator wasn't actually placed in the PCB layout, along with the battery connectors, so they were left out of the final print.  It seems that these were redundant and not actually required, as the through-hole planes are adequate for mounting the Deans connector, instead of the more difficult-to-find banana barrels. 

After taking care of the missing footprints for the "Tplug", instead of removing them, by changing them into 1x1 touchpads and adding the 7805 regulator to the front. Additionally, the TL431/TL432DBZ chips have different pinouts, so ensure that you're using TL431*DBZ, or flip the 1 and 3 pins on both of these if you're going to be sourcing TL432*DBZ voltage sources. (For some reason, it offset the silkscreen layer slightly, so I believe that was an error on my side)

Additionally, would you happen to have the design files for an adequate replacement balance board? The original, purchased clone I had, used offset slot holes and didn't fit at all. Much thanks for the reverse engineering efforts that you've already performed, 

[Craig Brown]

After getting this fully assembled, and trying TL432 chips, the voltages seem to be reflecting better during calibration. However, when charge and discharge calibrations are run, my amp meter only shows 0.0020 on the charge, and never registers negative voltage. My DMM is a Fluke, so is fully capable of registering these voltages. What might the issue be? I have a feeling it's in the MUXes somewhere, and I'm fairly certain I have legitimate chips, as they were sourced through Mouser. 

Any help would be greatly appreciated. I'm also slowly updating the last version of this with more available components, such as the AO4409 which has been marked EOL through Alpha/Omega. My main goal is to minimize the amount of through-hole components and move towards SMD wherever available, to allow the use of small aluminum heatsinks.