Tag Archives: mppt

Solar Charger in Hackaday Prize Finals

I’m delighted to tell you that my MPPT Solar Charger has been nominated for this year’s Hackaday Prize Finals taking place on October 22nd.  I’ve submitted it in the Power Harvesting Challenge category a while ago and was just informed that it was picked as one out of twenty projects submitted to the finals. Check out the original article here. Of course, any support is highly appreciated.

If you check out the project description on hackaday.io you will notice that my blog is somewhat lagging the latest developments. But don’t worry, I hope to post more updates as well as a few videos soon.

MPPT Solar Charger Testing II

It’s time to follow up on the MPPT Solar Charger project. Progress has been slow since I’m currently working full time and doing a master’s degree at the same time. Given that this blog has previously been something close to a 50% job at times things will necessarily slow down a bit. But all the projects, including this one and the ultrasonic anemometer are alive and well and I’m working on them whenever I find some time.

20161012_userinterfacereva_014

User Interface

So what’s new with the MPPT solar charger? First of all, it got this nice user interface. Unfortunately there were still some issues with the first version so there is an identically looking but much-improved and bug-free Rev B.  I’ll do a separate post on that documenting all the things I’ve changed.

I re-used the white-on-blue display from the initial version for the Rev B. as opposed to the black-on-white used with the Rev A. They are pin compatible so you can use whichever you prefer. I more and more start liking that black-on-white look. It’s about 10 bucks cheaper as well. What’s your opinion on this?

img_4334

Solar Panel drains Battery

My intention with this design was to just leave the solar panel connected to the input of the buck converter. There’s a problem with that, however. The input of a buck is always at least at the output voltage minus a diode drop. With a 12V lead-acid battery at the output the input (i.e. where the solar panel is connected) the voltage never drops much below 12 volts.

That’s a serious problem since even a small solar panel like the monocrystalline 30W panel I have here sinks around 10mA at that voltage. So whenever the panel is not providing any power it considerably drains the battery.

Try a Diode

Obviously we need a way to avoid that. The first solution that comes to mind is a diode. But there’s a problem with that, too. To keep the power loss in the diode acceptable, the diode needs to have a low forward voltage. However, any diode with a low forward voltage also comes with a high reverse leakage.  Physics seems to dictate that.

Leakage can easily be in the range of milliamps for a diode that can handle, say, 4A like needed here. And that reverse leakage is also highly temperature dependent. It may be ok-ish at room temperature and then detoriate by an order of magnitude at 50 degrees centigrade.

To get an acceptable reverse leakage one needs to tolerate at least half a volt of forward drop which is something like 3% in efficiency. Since our converter operates at around 97% efficiency that would mean doubling the energy dissipated.

P-Channel or N-Channel Mosfet

So the next obvious thing to try is a mosfet acting as a switch.  Yes, a mosfet also has a body diode that also has a reverse leakage. But the body diode is a bad diode in terms of forward drop and has a correspondingly low reverse leakage.

A nice way of solving our problem would be to use a p-channel high-side switch disconnecting the battery from the converter whenever the panel is not producing. That not only disconnects the panel but powers off the entire buck including the input and output caps and everything. Where there is no voltage no power can get wasted. Perfect.

img_4342

Unfortunately, powerful (i.e. low Rds-on) p-fets are relatively large,  rare and expensive. As a rule of thumb a p-fet needs twice as much silicon area for the same performance compared to a n-fet. Besides that, that would be another type of component and I’m trying to not use too many distinct components.

So the other solution is to use an n-fet as low-side switch just disconnecting the panel. We already have 6 powerful n-fets in our design and they are cheap, too. So this is what I’ll do in the next version.

For now I’ve used one of the power outputs to connect the panel. I’ve cut some traces and soldered in some wires so that the fet is on whenever the buck is powered on.

Buck Software

During early testing of the buck converter I managed to kill the bottom fet several times. Since I was able to run the buck at relatively high power levels for prolonged periods of time without any issues (and without getting hot) I suspected that this was caused by carelessly written software. This seems to have been the case indeed. Whenever I killed a fet it happened at startup or shutdown, usually the latter. In the mean time I’ve written well-defined startup and shutdown routines and never had any issue since.

bootstrapcapacitorcharging

Synchronous converters are dangerous in this respect. It is very easy to short the battery to ground via the bottom fet. All it takes is a duty cycle that’s too low or a timer is running too slow or not at all. Or you stop the PWM module at a time when the bottom fet is on and it will stay on forever.  Or at least a few milliseconds until it’s dead.

Asynchronous topologies are much more forgiving in this respect since you can’t short anything. So an easy solution would be to start up and shut down in asynchronous mode. We can easily make this an asynchronous converter in software by just not utilizing the bottom fet. The diode in parallel with it will then automatically take over.

Unfortunately we cannot start up in asynchronous mode. Why? To enable the upper fet we need a bootstrap voltage above the input voltage. And we don’t have that unless the converter is running. It’s a chicken and egg problem, really. So we need to start up in synchronous mode at least for a few switching cycles for the bootstrap diode to charge up.

That’s exactly what the startup routine does. It completes 16 cycles in synchronous mode at a neutral duty cycle. What do I mean by neutral? Simple: Duty Cycle = Output Voltage / Input Voltage. That means no current actually flows on average. So this is a nice, soft way to start up. After those 16 duty cycles the buck enters asynchronous mode. As the screenshot above shows, the bootstrap capacitor is fully charged after just one full duty cycle so that number is more than sufficient.

This routine is critical. If it doesn’t do precisely what it should chances are high that the buck is destroyed. So I’ve checked it carefully by both looking at the code and the scope. I’ve run it many times and observed closely what it does just to be sure it starts up nicely very time.

Why run in asynchronous mode? Because it’s more efficient at low power levels. Once the current rises above a software-defined threshold the converter will change to synchronous mode. If the current later falls below a second (lower) threshold, the buck changes back into async mode.

The optimal values for the two threshold will have to be determined experimentally but will likely be in the range of a few hundred milliamps.

buckturnoff

The shutdown sequence is simple. The buck is shut down if the current falls below a very low threshold (say, 10mA) below which it cannot run profitably. If the current falls even lower we are better off shutting down the buck and entering a low-power mode. Since the current is low when we shut it off, the converter is already in async mode. So shutting it down is now easy and uncritical. We just turn off the top fet and can then also turn off the timer and supply voltage to the buck. The screenshot above shows an example of that.

Conserving power

A main feature of this solar charger is it’s ability to (hopefully…) run at a very low (<100microamps) current when not in use. So we obviously need to turn off everything we don’t need and run the PIC at a much lower frequency as well.

The PIC’s maximum operating frequency is 48MHz. This is the frequency it runs at when the buck and/or USB (not yet implemented) is on. These two features need that clock frequency to perform their task.

If both the buck and USB are off we can clock the PIC down to 8MHz which already saves a great deal of power. At 8MHz we can still do everything else, including running the user interface. Updating the display and particularly calculating the display content consumes quite some computation time and so we need a few MHz to do this.

If the user interface is not used for a certain time (say, 10 seconds), it is turned off. We can then lower the board voltage to 2.3 volts and lower the CPU frequency even further to 32.768kHz.  This is the frequency of the real-time clock that is running anyway. At such a low frequency the PIC’s computational power is low but still sufficient to do some housekeeping tasks.

One can wake up the user interface at any time by pressing the push button. Turning the encoder won’t help because that, too, has been powered off.

While in this low power mode every 6 seconds the board voltage is raised to 3.3 volts and all temperatures as well as the input and output voltages are measured. That all happens at 32.768kHz. After the measurement is complete the PIC decides if the panel voltage is high enough to start harvesting energy or not. If this is not the case the board voltage is lowered again and a new set of measurements is captured 6 seconds later.

img_4336

Despite all those efforts the board consumes something like 530 microamps which is much more than it should. About 100 microamps comes from the voltage divider used to measure the panel voltge. That’s an easy to solve design problem that I’ve described earlier already. But that still means that something is drawing 400 microamps. Not much at all but still way too much.

I’ve spent an evening trying to find the problem but I still don’t know. I’ve suspected the capacitors but when I measured some spare caps of the same type they hardly drew any current at 12 volts. I also un-soldered the buck’s mosfet driver but that made hardly any difference so that’s also not the problem. It may even just be some near-short on my board homemade board. So I leave that for now and check again once I have a revised design with a proper PCB.

Buck testing

I’ve saved the most interesting part for last 😉 I’ve established before that this converter has a similarly high efficiency than the Arduino version published some time ago. But at that time I was only able to test up to 35 or so watts.

This solar charger is capable of handling much more power than that. Testing how much was a bit more difficult than expected. Unless the battery is very empty it won’t draw as much as this charger is able to provide. And you don’t want to discharge a lead acid battery too much, they don’t appreciate it at all. So once again my constant current dummy load came to the rescue.

img_4339

With the dummy load at one of the power outputs I was able to draw some serious current. I set the dummy load to 4 amps and the battery absorbed (or provided) whatever was left. Obviously, I can only do that for a limited amount of time until the dummy load gets too hot. It automatically shuts down once the heat sink reaches 70 degrees centigrade which is soon the case at 4 amps.

I let the charger draw 4.5 amps at a bit more than 17 volts for as long as I could. The coil got quite warm, slightly hot even, maybe something like 60 degrees. The mosfet only got lukewarm and I’m not sure if this was because of their own power dissipation or due to their proximity to the coil.

img_4341

So from this test I’d conclude that this was about the power which the charger can handle for a prolonged period of time. So I think something like 75 watts is a realistic power rating.

I’ve also had another look at the datasheet of the coil and it pretty much confirmed my findings. 75 watts at (say) 13 volts output corresponds to 5.8 amps through the coil. The datasheet states that the coil starts saturating at 8.2 amps which means we’re still safe with 5.8 amps plus the ripple current. The datasheet also states a 40 degree temperature rise at 5.3 amps. So thermally the coil is pretty much at its limit at 75 watts. That, too, seems realistic to me having touched it after some time at that power.

The road ahead

So how to continue? As we have seen, there is a number of design issues but the general concept works. During testing and debugging I’ve cut and re-soldered many traces and also made some modifications like the one with the n-fet described above. I’ve unsoldered and changed many components as well. All of that doesn’t improve the reliability of the board. At some point it makes sense to design a new version, build it and take it from there. A clean slate kind of.

I think this point has been reached here. So I will work on a new revision from now on. The concept won’t change at all but I’ll try to apply what I’ve learned so far. I also hope to reduce the number of different components, reduce the size and total cost while not sacrificing performance. In other words move a step towards a design that may one day be built as a small series. Let’s see.

MPPT Solar Charger Design

I’m currently waiting for the boards for my Ultrasonic Anemometer Rev B to arrive from Hong Kong and this gives me some time to write about the MPPT Solar Charger design that I did quite some time ago. I published a series of posts on a Arduino MPPT Solar Charger Shield and got a lot of encouraging feedback. But that shield was more of a proof-of-concept than a finished product.  While it generally performed well it drew way too much current when idle to actually be deployed unless you can count on plenty of sunshine every day.

SolarChargerEagleTop

Aiming for very low power consumption

While I like the Arduino platform I had to admit that it’s probably not ideal for a low-power design. Yes there are some things you can do to reduce the 50mA or the Arduino draws but it will never be truely low power. So I designed a stand alone version with plenty of extra features that I hope to draw only a small fraction of the current. I particularly care about the idle current, i.e. the current it pulls when the solar panel is not producing any energy. In winter, the panel might be covered by snow for weeks and you don’t want your charger to drain the battery during that time. With this new design I’m aiming for an idle current in the tens of microamps. Even if it ends up being 100 microamps that is still 500 times less than an Arduino uses just by itself. And that means it draws less than 1Ah (ampere-hour) per year so you will never drain the battery no matter how little sunshine there is.

SolarChargerSchematic1

PIC18 series microcontroller

At the core of the design is a PIC18F26J50 in a 28 pin SOIC package. It’s capable of running at down to 2.15 volts and consumes extremely little power when running at lower clock speeds. And apart from that it features USB so we can have all the benefits of USB without any external components except, of course, a USB socket.

The PIC has two crystals at its disposal. A 8MHz crystal which will be boosted up to 32MHz by its internal PLL. That’s what the PIC will run on when there is work to do. And then there is a 32.768kHz crystal that will be used to run its real-time clock (RTC). When there is little to no work to do this low-frequency clock will also be used to run the CPU which will greatly reduce power consumption. Power consumption is approximately linear in frequency so this should cut power consumption by a factor of about 1000 compared to full-speed operation.

SolarChargerSchematic2

Switch mode power supply

Now we can run the microcontroller at only a few volts but our power supply is a 12 volt battery. So one of the most straight forward things to do in order to save power was to use a switch mode step-down regulator aka buck.

I looked around and found the Texas TPS62120. It’s only capable of providing 75mA but that’s more than enough for us in this case. It works at a switching frequency of 800kHz and only consumes a bit more than 10 microamps with no load at its output.

It needs a 18uH inductor as well as some ceramic capacitors to work. The output voltage is set via a pair of resistors acting as a voltage divider. I’ve added a n-channel mosfet that allows the PIC to increase the output voltage from 2.2 volts to 3.3 volts when needed. Because while the PIC can run on down to 2.15 volts the display can’t. And even the PIC needs 3.0 to 3.6 volts for USB operation.

Synchronous / asynchronous operation

The actual MPPT converter has changed only little. I’ve changed the mosfet driver to a MIC4605.  Unlike the IR2104 used last time, this model has adaptive dead-time (as opposed to the longish 540ns fixed) and separate inputs for each mosfet. This will allow us to either operate in synchronous (using both mosfets) or asynchronous (only using the upper fet and relying on the diode) mode. Asynchronous operation has a certain efficiency advantage at low power levels so this might come in handy.

The MIC4605 consumes quite little quiescent current for a mosfet driver, only 100uA typical. But that’s still too much for our purpose. So the PIC can power the whole thing off via a NPN transistor and a p-channel mosfet. That BUCK_ON signal also serves as the supply voltage for the INA213 current sensors already used in the last version. So the entire converter can be powered off and should consume precisely zero current when not in use.

What about the voltage divider necessary to measure the battery voltage? That’s been taken care of, too. That divider is interrupted by a (low threshold voltage) n-channel mosfet unless a signal from the PIC turns on the mosfet and closes the circuit.

SolarChargerSchematic3

Port expansion

I soon ran out of GPIO pins with that PIC so I had to add an I2C port expander (MCP23008) to gain another 8 I/O pins. I’ve also added a PCA9546 I2C switch in order to translate between different voltage levels.

It’s probably not the most elegant solution and a future version might trade these 3 chips for a higher pin-count PIC. But I had all components here already so that’s what I’ll use for now.

Precise measurements

In order to precisely measure input and output voltages and currents there is now a MCP3424 4-channel 18-bit ADC. To be sure, we don’t need 18 bits of precision here but we’ll trade some of that precision for speed and work with 14 or 16 bits.

The ADC has its on-board voltage reference and PGA with gains up to 8.  Since it only consumes a maximum of 1uA in standby mode it is always powered on.

There are also a total of 3  LMT86 temperature sensors, one on the board and 2 external ones. The external ones are intended to measure the temperature of the panel and battery, respectively. The maximum voltage for a battery is quite dependent on temperature so that’s a useful information to have. The inputs from the temperature sensors are measured directly by the PIC.  For that purpose there’s also a ADR361 2.5V voltage reference.

Measuring temperatures requires the board voltage to be high, 3.3 volts nominally. So both the voltage reference and the temperature sensors are only powered on when then VCC_HIGH signal is set.

User interface

To communicate with a human user there is a 4×20 LCD display that is controlled via I2C in order to save some I/O pins. There are quite a few external components needed to run it at 3.3 volts so it has its own PCB and connects via a 5-pole wire. There is 3.3 volts and ground for power, SCL and SCD for I2C communication and a PWM singal in order to control the display brightness. Because that’s a rather universal board I will document that as a separate post.

As an input device there’s a rotary encoder with push button. Together with the display (and some decent software) that should allow for a pleasant user experience.

The inputs from the encoder are debounced in hardware via a 74HC126 that serves a double purpose. With its 3-state outputs it allows us to use the pins that are otherwise used for in-circuit programming of the PIC.

Both the rotary encoder (except the push button) and the entire display unit can be powered off when not in use. The push button is always powered on so the user can wake up the user interface at any time by pressing the button. When the user interface is not actively powered on the 74HC126’s outputs are in high-impedance mode and the PIC can be programmed without being affected by the rotary encoder.

SolarChargerSchematic4

Data logging

One might be interested how much energy has been harvested by the solar charger over the last hours, days, weeks or months. So there’s some non-volatile storage as well. The 24FC256 connects via I2C and offers 256kBit of memory. It consumes only 100nA in standby so it can stay powered on at all times.

Fan control

As mentioned, there’s a temperature sensor on the board. If it gets too hot, a fan can be powered on via the FAN_ON signal controlling an n-channel mosfet.

Outputs

There are 4 power outputs, each controlled by a separate signal from the PIC. There should be some PWM modules left on the PIC so some (two I think) can be PWM controlled. A typical application would be LED lighting which can be controlled and dimmed directly from the solar charger via the rotary encoder. Each output channel has a beefy  mosfet of the same type as the MPPT switcher (IPB136N08N3).

Each has its own FAN3111E mosfet driver. They have a separate input for the reference voltage so the PIC can easily control them when running at only 2.2 volts. The FAN3111 should only draw 5uA (10uA max) when idle but there are 4 of them so they can be powered off (all togeher, not individually) when not in use.

SolarChargerSchematic5

USB charging ports

One of the first thing one wants to do when there is power is to charge one’s cell phone or similar device. So there are two USB charging ports capable of delivering some 2 amps of current at 5 volts in total.

They are powered from the 12V batter via a TPS54231 buck converter. So there are a total of 3 buck converters on this board… It is always connected to the 12V rail but the PIC can turn it off when not in use. The regulator’s shutdown current consumption is only 1uA typical (4uA max) so that should be adequate.

Manufacturers of mobile devices have all come up with nasty ways of making their devices incompatible with other manufacturer’s chargers. They basically abuse the otherwise unused (for charging purposes) data lines to recognize their own chargers and discriminate against any others. That might mean they won’t charge at all or only at a slow rate.  So there are two charging ports on this board, one emulating an iPad charger and the other one a popular Samsung scheme. So pretty much any device should be able to charge on at least one of these ports at a reasonable speed.

Summary

As you can see, there’s a lot of functionality in this new design just waiting to be unlocked by some clever software.  I’ve already milled a board and I’m looking forward to populating it and bringing it to life. I guess that will be quite a bit of work but I think its well worth it. Thanks to all of you who have kept asking about this project – I very much appreciate all your feedback.

There are only Eagle files (including PDFs of the layout and schematics) at this point. They can be downloaded on the overview page. There’s now also a prototype. First test results are presented here.

Arduino MPPT Solar Charger Shield – Testing

20160203_Projekte_004
First tests are being performed on the Solar Charger Shield

In my last post I’ve introduced a proof-of-concept Arduino solar charger shield. I went through the hardware as well as the way it works – or at least is intended to work. It was prominently linked on dangerousprototypes.com as well as some other sites and got quite a bit of publicity as a result. Thank you all for sharing this post.

By the way: here’s an overview over all posts on this project.

20160203_Projekte_001
DUT hooked up to my Constant Current Dummy Load

This time I’ll show you some results of the testing that I’ve done. The basic test setup is shown above: The solar charger is hooked up to my home-brew constant current dummy load, together with a pair of DMMs at the output in order to precisely monitor output voltage and current. For the input I’m relying on the lab supply to provide these measurements. And yes, the shield does its own measurements of both input and output currents and voltages. Once calibrated they are even quite accurate but I won’t rely on them for things as calculating the converter’s efficiency.

no_load_overview
Vin=17V, no load

But first we need to see if our converter works at all. As the scope screenshot above demonstrates – it does. For all the tests shown in this post, the input voltage was provided by a lab supply set to 17 volts. So we’re not yet testing the software and its capability to draw just the right amount of current.

no_load_closeup
Vin=17V, no load

As you can see, since the converter can draw any (reasonable) current at the input, it provides the maximum voltage (set in software) of 13.8V at its output. In order to do that, the upper FET is on approximately 80% of the time. The signals all seem nice an clean and there is no noticable ripple at the output at 1V/div and no load. And the switching frequency is 62.5kHz (16MHz / 256) as expected.

1Amp_closeup
Vin=17V, Iout=1A

At 1 Amp output current, the software has to increase the duty cycle somewhat to 82% (above) and even further to 84% at 2A (below). Besides that, everything still looks very similar under load conditions.

2A_closeup
Vin=17V, Iout=2A

In my last post I’ve raised the question if the FET driver’s dead time of 540ns according to the datasheet is not a bit excessive. Well, let’s look at the dead time on the scope. First of all we can observe that the dead time of the IR2104 is in line with the data sheet. I don’t have it in front of me right now to check the min/max specs but the measured 522ns seem reasonably close to the theoretical 540ns.

deadtime
The IR2104 has a built-in dead time of 540ns according to the data sheet. We’re measuring 522ns here – close enough.

From looking at the screen shot above, the dead time does seem a bit long. The reason dead time is introduced is to prevent shoot-through. If both FETs are on there is a short-circuit from the input to ground. Together with the input capacity and the FETs low Rds-on, very large currents could flow, possibly destroying the FETs and at least detoriating efficiency. So introducing a bit of time when both transistors are off seems reasonable. But too much of it also costs efficiency since current has to flow through the diode instead of the lower FET. The main reason for using a synchronous topology is to prevent this in order to gain efficiency. So obviously one has to find a balance. I think here we’re a bit far on the conservative side but never mind for now.

20160203_Projekte_005
Let some current flow

So now that our converter is working, let’s take a look at efficiency. I’ve measured the efficiency at output currents ranging from 100mA to 2.6A in 100mA steps with the input voltage at 17V. I didn’t use the sense-wires connections on the lab supply so I had to compensate for the voltage drop on the input leads manually.

20160203_Projekte_007
There was a drop of up to 220mV on the input leads so the voltage reading of the lab supply is not quite accurate

The results are quite impressive:

  • 95.5% @ 100mA (worst)
  • 96.9% @ 200mA
  • 97.9% @ 400mA
  • 98.1% @ 800mA (best)
  • 97.1% @ 1600mA
  • 95.7% at 2600mA

So the efficiency is constantly at a very high 95.5% and better over the entire current range of interest.

20160203_Projekte_008
This little dummy load is really useful

The resulting loss is less than 1.6 Watts @ 2.6A out. As a result, the shield never gets hot, even when running at this power level for a while.

Note that this is quite a bit more power than the converter was designed for. 37W as opposed to the 30W I designed it for. The FETs could even handle much more. The limiting factor would likely be the coil reaching saturation. Unfortunately my lab supply doesn’t supply any more than 2.2A so I can’t push it any further.

20160203_Projekte_006
Shield performs well even beyond 30W spec

 

One thing to note is that these efficiency figures don’t take into account the power consumed by the arduino, the display, the fet driver, current monitoring ICs and so on. This brings us to the last topic for now: The current consumed by the various components. I did these measurements mainly in order to understand how to limit power consumption in a later version. To me, this shield is only a proof of concept and so reducing power consumption was never an issue.

20160203_Projekte_002
Basic test setup

Here are the results:

  • Arduino: 48.7mA
  • LCD backlight: 8.9mA
  • LCD excluding backlight: 1.148mA
  • FET driver (standby): 106.56uA
  • FET driver (62.5kHz, Iout=0): 2847uA
  • FET driver (62.5kHz, Iout=2.5A): 2937uA
  • Current sensors (each): 48.6uA

So the arduino itself is using up the lion’s share of current. Next comes the LCD backlight. Nothing unexpected so far. The LCD without backlight still consumes a considerable 1.15mA, no matter if it’s on or off. The FET driver uses around 2.9mA when on and only about 0.1mA when off. Output current only has a minor impact. The current sensors don’t use up much – less than 0.1mA for both.

Check out my next post for a closer look at the software or here for an overview over this project.

Arduino MPPT Solar Charger Shield

20160119_Projekte_028

A friend has approached me regarding his solar project. He wants to install a solar panel together with a battery and an inverter in order to have power at his allotment garden. He had looked at a hobbyist project where an arduino was used to build a MPPT (maximum point of power tracking) charge controller. I took a look at the design, liked a lot of what I saw and decided to build something similar.

20160119_Projekte_032

The basic idea behind an MPPT solar charger is simple. A solar panel has a certain voltage (in the region of 17 to 18 volts for a 12 volts pannel, somwhat dependent on temperature) at which it provides most power. So as long as the battery needs charging, you want to pull just as much current to reach this voltage. But once the battery is full you need to avoid overcharging the battery. So you want to maintain a maximum voltage for your battery (somewhere around 13.8 volts for a 12 volt lead acid battery) and no longer care about the pannel’s voltage.

20160119_Projekte_029

So the charger needs to convert an input voltage of 17-18V to an output voltage of 12-14V as efficiently as possible. Obviously, a step-down (aka buck) switching converter is ideally suited for the job. However, a typical DC-DC converter is designed to maintain a stable voltage at it’s output, independent of it’s input voltage. As described above, our requirements here are different.

20160119_Projekte_038

Switching converters are controlled by the duty cycle of a (typically) fixed-frequency PWM signal. So a microcontroller could be used to do the job. In most applications, this wouldn’t work that well because a microcontroller would be too slow to react to sudden changes in load or input voltage. But this is not much of a concern in our solar application: Sun intensity changes within seconds at best and the battery will absorb any sudden changes in load. So if we adjust our duty cycle a few times per second we’ll be more than fine. And that’s easy to do with a microcontroller.

20160119_Projekte_030

The next step was to figure out at which frequency to run our converter. An arduino runns at 16MHz. At a 8-bit resolution, this gives us a maximum PWM frequency of 62.5kHz. That’s a pretty slow speed for a switching DC-DC converter nowadays. Most modern designs run in the hundreds of kHz to a few MHz. The main reason of using higher and higher switching frequencies is size. The higher the frequency, the smaller the inductor can be. For us, using a somewhat bigger inductor is totally acceptable. And in terms of efficiency, a lower frequency is even preferable since it reduces switching losses.

20160119_Projekte_037

The project here is intended mainly as a proof on concept. I expect it to be fully functional but it will consume quite a bit of power while sitting idle. The display (including backlight) is always on, the same goes for all the other components. But the main drain on the battery will be the Arduino itself which consumes around 50mA when running at 16MHz. That might not sound like much but it will add up during the many hours the solar panel doesn’t produce any power. The system will be installed in Zürich, Switzerland so you can’t count on having 8 hours of sunshine every day. In winter, there might be snow on the panel, preventing it from producing anything for weeks in an extreme case. So a productive system should draw hardly any current (say <1mA) when not doing anything useful.

20160119_Projekte_031

At least for now, the we’ll be using a 30W 12V monocrystaline panel and a 45Ah car battery. So I’ve scaled this converter to comfortably handle 30W input power which translates to about 1.8 amps at the input and 2.5 amps at the output.

As deba168’s design, I’m using a synchronous buck topology. If you’re new to switchers, you might want to check out this wiki page. If you’re serious about designing your own you might want to read Sanjaya Maniktala’s ‘Switching Power Supplies A – Z’, it’s a great book. I’ve also read his other two books on the topic but this is the one I love the most, especially to start with. I’m also using the same half bridge driver (IR2104) even though I find the 540ns off time somewhat excessive. But I like the enable/pwm input signals as opposed to having to drive each fet individually and I found this feature to be somewhat rare.

20160119_Projekte_035

Apart from that I’ve really done my own design, mainly using parts I’ve still had from previous projects. As most stuff I build, it’s entirely SMD, except for the input and output capacitors. Not only are SMS designs smaller in size. The parts are much easier to source (and often cheaper) than conventional through-hole components nowadays. And contrary to popular belief, with a bit of practice I find them easier and faster to solder.

The FETs are IPB136N08N3, a quite large surface-mount type that I use quite frequently. They have a 11mOhms Rds-on resistance which will be great for efficiency. They are also easy to drive in terms of gate capacitance. Probably a bit oversized for the 2.5 amps we’re trying to switch here but I still have some here and they’re not expensive, around 70 cents each. The inductor is a 100uH Coilcraft MSS1583 with a resistance of 0.103 ohms and a 2.8A current rating. 100uH is a bit much at full load, 68uH would easily do. But the system will spend most time at moderate loads (remember, this is not California). I’ve ordered a 68uH as well and intend to use it for a later design or maybe to see what difference it makes. Input and output caps are quite a bit oversized as well, 680uF 35V at the input and 820uH 25V at the output. They are from the Panasonic FR series which I like using for my switchers since they work well at frequencies up to a few hundred kHz while being afordable and having very high ripple current ratings.

20160119_Projekte_034

I’m doing voltage and current sensing at both input and output. I’ve decided to use conventional high-side, shunt resistor based current sensing. The Texas INA213 are fairly precise, work up to 26 volts and have a fixed gain of 50. Also here, I still had some left over from my dummy load project. Most components are much cheaper if you buy 10 in stead of just one or two so I tend to buy 10 😉

I’ve also added a standard 2×16 characters LCD display so I can see what’s going on. And you may have noticed that I’ve put a zero ohms resistor at several places. This will enable me to easily measure current consumption of the respective sub-circuit. As mentioned before, current consumption will play a major role in the final design so I’m interested to see how much juice is used by certain components under real-life conditions.

Besided the connectors for the panel and the battery, I have added a separate connector for the power supply. This is handy for early testing and programming. Just connecting this supply will power up the entire system. The arduino, the display, the converter and all. But there is not yet any load at the converter’s output and no supply at it’s input. So I can start programming the Arduino, start measuring and displaying voltages and currents and even turn on the converter to see if everything behaves as expected. And since there is nothing at the converter’s input and output, not much can go wrong. I don’t risk blowing up the FETs due to a bug in the program or a problem with the board. Only once I’m confident that everything works as expected I will connect a panel and a battery. At that point, the 12V input can just be connected to the battery as well.

20160119_Projekte_039

I’ve written a simple sketch for the Arduino that measures voltage and current at the input and output and displays the result on the LCD. Once the input voltage exceeds a certain threshold, it will enable the half bridge driver and start switching. It starts at a duty cycle that will produce an output voltage equal to the current battery voltage. That means that no current will flow to the battery yet so the converter can start up with no load. Once the switcher is turned on, the Arduino will adjust the duty cycle about 4 times a second. If the input voltage is above its optimum and the battery has not yet reached its maximum voltage, the duty cycle will be increased by 1/255. If either the battery voltage is too high or the input voltage is below its optimum, the duty cycle is decreased by 1/255. There are also some checks for overcurrent at the input and output.

20160119_Projekte_036

The switcher is turned off when the input voltage or the output current falls below a pre-defined threshold. This is a synchronous converter so current can flow back from the battery to the panel. We can’t just wait for the input voltage to fall. As long as the switcher is on, the input will never fall because energy is pumped from the battery to the panel. A synchronous buck converter is just the same as a synchronous boost converter with its inputs and outputs inverted. So we need to make sure current is actually flowing to the battery. Luckily, a car battery will always draw a clearly non-zero current at 13.8 volts, even when fully charged. So when current stops flowing to the battery, we know the panel is no longer able to provide any power and we can or rather must turn the converter off.

20160119_Projekte_033

This post ist getting rather long so I’ll stop here and will write another post later about how the circuit has been performing and what I have learned so far. I guess this project will turn into a little series, maybe with further (and hopefully improved) versions being developped. Looking forward to that.

Before I forget: Here’s the eagle files as well as schematic and layout PDFs as a zip file: SolarCharger_Rev1.

Update: Click here to see how the shield performs or here for an overview over this project.

Update 2: Now there is an entirely new design.