Nieuw project Hulp nodig?
ElektorLabs

Universal Battery Charger

Status: In ontwikkeling
908
16
stemmen
29 mei 2019
dscn71731.JPG
This project discibes the way on building a multi chemisty battery charger, and the way the hardware and softwaredepetment worked to get this done.

First requierments

As with all projects this stated with the idea of having a new multi chemisty battery charger with added abilitys, like WiFi and a nice way to control the userinterface. As chemisty it was decided to support NiCd, NiMh, Li-Ion, Li-Po, LiFePo and lead acid cells and also be able to do for battery packs balacing. As some of colleagues have started a bit of research we haddend to start compleatly from scratch, but needed to do a few basic desisions on the way the charger will look like. Also requested was that the charger can opperate from a DC source in the range from 10.4 to 14.9 volt, as this will suite the homeuse with regulated 12 volt and also the protabel use powerd from the onboard supply of a car.

 

Choose your parts

Well after we got the requierments, we needed to decide how the charge circutry will be realized and what kind of microcontroller will be the brain og the charger. As controller a ESP32 was choosen, even knowing that the ADCs on this chip are not ideal, but it will give us nice software support, a great userbase and wifi for configration and status information. Also a few other components have been considered, as ADC we use a MAX11615 to get at least somthing near 12Bit resultion. The ADC in the ESP32 also have 12Bit on paper, but suffer from inlinearity and a usable voltagerange that clips before vref and also is not going perfectly down to zero. Depending on the amount of added correction you invest you will get the ADC to be usable liniear up to 10bit resulution but still have to deal with the clipping.
In the first spot we considered adding a sd-card slot to the system for logging and storing charging recepies for your rechargible battery packs, but skipped it, as the same feature can be relized through the webserver and internal flash without the hassel of bad connecting sd-cards. The ESP32 can store files in the SPIFFS and we can reserve a few kB for user Settings, we also can write during runtime to the flash like you would write to a sd-card.
The other poit we needed to discuss was the way we will display the statusinformation of the charger. Ideas went form smartphone only to some leds over to a kind of tff display. We ended up with a prototype using a raspberry pi display and started building a UI with littlevgl as graphic library. This will give the user a nice and graphical way of interacting with a touch frendly interface and we don't have to hassle with may I/O-pins for buttons for the user, and enables us to add later user whises to the system in a way it won't be possible just with a few knobs an a two line and sixteen character display. You may ask why we haven't use the nextion displays in this build, as they requiere only a serial connection and 5 volt. If the user must update the system, is will end up in less hassel if only the ESP32 needs new firmware, and not also the display has to be flashed. Also you have with the nextion display a few less features and possibilitys for your layout as with a generic SPI connected TFT. The raspberry pi TFTs are good avalible and provide a resonable speed.

The charging circutry

 

The softwarearchitecture and a basment overhaul

As we have done a lot of ESP32 projects in the last time, we have a set of components we reused in our projects. This componets also evolved over the time and some new functions were requiered. As we have the FreeRTOS at hand we use the functions it provides to divide the work. As opposit to the interrupt dirven or superloop based software we have here the ability to create tasks and divide our work into small steps. Thinks that are more important can get this way a higher priority over things that are less important to deal with. An example is the charging logic and control, that is defintily more important than handling the UI. Based on the former ESP32 projects this meant that for example the WiFi handling needed to be changed to utilize the inter process commuication for wifi scanning and changing settings, to avoid blocking one or even the two cpu cores. Also the API for the Webinterface got a little overhaul in a way that it is now using JSON formated data for the WiFi settings instead of a CSV file. This is only one small example.
Besides UI and webinterface the more important part is the charging itself. As mentioned the ESP32s ADC has some weaknesses we added a eight channel I²C-ADC to the system. This gives us a bit better accurancy and also reduces the input pins requierd on the ESP. What we came accross was the question how good the driver for the I²C-controller can handle clockstretching and handle the 400kHz clock we need to the adc. The I²C is working but gave a bit of a headache in the the first place. As the protoype started on several breadbaords we struggeld a bit with power and signalintegrity problems. This results in the I²C-controller recognizing a hung device on the bus and forcing a reset. Also we have encuntered the usual reboots and misbehaving software if the ESP32 is not feeded propper with power although the supply we used culd serve enough current, the cheap wires, with just an idea of coppen in them can't. A few 100nF and 10uF Caps, with a reassambly on only one breadbaord, later, the components and the ESP32 were up and running as expected. Also we were happy to see that the clockstretching that the ADC dose is handled fine and data is collected as it should.
 

New Userinterface

As mentioned we decided to use a raspberry pi TFT with touch for the userinterface. This gives us many new possibilitys to display data and let the user interact with the system. The first thing you see is the main screen, from where you can access
the main menu. This should be tochfrindly and allow you to change the settings accordingly. At the moment we are using the Littlevgl library in version 5.3 and it seems we need to move now to version 6.0, including cahnges in the API ans some rework in the code. Nevertheless progress is taking place and slowly the parts of the UI become alive. The Wireless part is finished for now and give options we haven't included in the earlier esp32 projects.
You can now choose if it is enabled or disabled, also fore it to accesspoint mode with password protection.
Also some space at the bottom is used to show you the curren state of the wifi network connection. Setting up the charger to wifi shpuld now be an easy job.
What also has gotten to life is the chargesettings menu. An even if it looks not that shiny, some nice triks are involved.

The simple scenario using only one cell means just charing with a given a current. Not fancy and nothing special. Things you will expect from a basic charger. If we go a bit further we see we can see some more options.


Balancing is supported and depending on the choosen cell chemistry you also can choose the end of charge voltage. This one is shown for the Lithum based cells. Also the discharge current can be set individually from the charge current.







 

Webinterface, first impressions


Well for the Webinterface we need also to add the ability to have some interaction with the device, meaning a recreation of a bunch of menus, also screenshots with the camera are nice but nit the rea deal. So we added a websocket based remotescreen function to the webinterface. Currently limited to view-only mode, but working.











Besides this little goddie making screenshots possible we will add more and more items to the webinterface in the comming weeks.

 

DS18B20 a one-wire-way to the temperatures

If you charge batteries you will happy to messure the temperature of the charing ones. The prototype currently has one 1-wire-bus you can attach you well priced DS18B20 to. For one cell this will be perfect, also this can be used for the modern batteriepacks to cut off charging the the values are above a certain level. If you have now four cells and four ds18b20 this means a bit of trickery, as you need to map a sensor on the bus to a certain cell to charge. The core logic is implemented and parts of the UI for configuration exist, so you can have four sensors mapped to four cells for messurment.

The nice thing about this, we can later reuse the code to build something one of the developer needs for it 19" rack at home. But first a few screenshots form the UI components:
   

As you can see, we now are able to select a specific 1-Wire sensor to be used with a battery we like to charge. The values will be fetched from the bus using a seperate thread deleivering us every two seconds a new set of values. If you are on an ESP32 and want to read 1-Wire devices, make sure you use a ESP32 optimized lib, else you will get a lot of garbage, as the code for 1-Wire is timing sensetive, and the RTOS ans Flash-Cache is no help to meet this. For now with four sensors the bus is runnign stable and also reporting if one of the sensors is not found any more. Most of the work is currently done unter the hood, so more nice screenshots are a bit difficult. As the temperaturs are now in place the netx one is to the get the balancer voltage and current for the cells.

 
Lees het volledige stuk
Toon minder

Reacties worden ingeladen...