Knock-together schematic. . .

I have been pulling together a potential hardware design for the MPPT - CAN controller, and here is a 1st cut.  Some key features:

• Support for Vpp up to 80v
• Support for Ibat (output) up to 25a
• CAN (Stuffable optional)
• Dual bank, one can be depopulated to save for $ and cut current out in half.

I have been playing with efficiency modeling some more, and the current components represent the best mix I have come up with yet.   While calculating the input capacity losses I had to bring the operating frequency from 50K to 100K in order to get the Iripple down to  manageable level.  At 50Khz I was getting over a 1W loss in the input caps.  At 100K, and limiting configurations to realistic ones I can keep Iripple under 4A, and the input cap losses under 180mW.  Here are the 4 configurations I expect folks to run at:

1. 1x panel (Vp ~ 32v)  -->  12v battery
2. 1x panel (Vp ~ 32v)  -->  24v battery
3. 2x panel (Vp ~ 64v)  -->  24v battery
4. 2x panel (Vp ~ 64v)  -->  48v battery

The worst case combination is actually #1, 1 panel and a 12v battery.  With the core switching efficiency of 97.8% at max load.  Adding in the cap losses of  75mW, and an estimated uC + CAN loss of 150mW = 225mW total additional loss.  This will bring the total system efficiency down to an estimated  97.4%

For a .pdf copy of this, click here:
 https://drive.google.com/file/d/0B5GiaoeXCQ3vM3ItbWZFV2thUjA/view?usp=sharing



A few notes:

• Need to scrub all components, recalculating again things.
• Current Best FETs are: Vashrey - SiS468DN.  Low cost!, but also PQFN - SMT packaging...
• Need to verify idea of taking controller power from solar panels as opposed to battery and/or both..
• I used a LDO regulator to get g om10v to 5v as opposed to another switcher.  Reason is during deep-sleep the uC power is in the uA range, and switchers are very inefficient there.  Plus, the LDO will help make a quieter voltage source for the uC's A/Ds
• Want to look at adding simple l/c for the uC's A/D voltage source, to twy and quiet things down.
• There is still no input filtering on the solar panel side....
• Still want to look at FETs, worried about PQFN parts. . . .

More in-depth look at Buck modeling - and some component selections

I have been playing more with the .xls buck modeling tool from MicroChip, plugging in various inductors and FETs to see what might be possible, along with varying the switching frequency to see its impact.  In short - FETs have made progress in the past few years.  Several of the ones I am looking at were released withing the year, and a few just this past summer.  Very low Rd-on's, and modest Qc's all help to reduce losses.  And as far as losses go, there really are three sources:

• Series Resistance of the Inductor
• Series Resistance of the FETs (Rd-on)
• Switching losses of the FETs.

Like many things in life, choices are not simple - often balancing one side against another.  Take the Inductor:  Once sized for the max current (25A goal), inductance requirements actually increase as loads are reduced - less one lives wiht increased output ripple, or need to fall out of the common CCM mode into a less efficient DCM (Continuous Conduction Mode and Discontinuous Conduction Mode).  But with increase inductance comes increased resistance, opposing goals.  Sourcing a more expensive inductor can help solve this dilemma, as can increasing the switching frequency, but then we get more switching losses in the FETs.

And the FETs also have conflicts themselves - low Rd-on often comes with increased capacitance (ala, gate capacitance - Qg) that slows down switching times - increasing switching losses.

How to address this all?   Here is my current thinking:

• Minimize conductive losses by using right sized inductor
• Consider using variable frequency at lighter loads to remain in CCM mode
• Accept larger Vout ripply for the battery charger then one would desire for a power supply
• (Need to watch out for heating / losses on output caps though as they handle more ripple)
• Minimize FET losses by:
• Selecting low Rd-on devices
• Balancing this with capacitance
• use powerful driver chips to shorten switching times (ala, 4A drivers)
• Design around 50Khz  primary operating frequency to lower accumulated switching losses even more.

Using the above approach, here is one example modeling results.  Design support  using the following components - with the resulting efficiency graph:

• SER2915H-153KL  Inductor - Widely used Coilcraft 22uH inductor
• LM25101C              Driver chip (Limits panels to 85 Voc max)
• IRFH7185PbF         FETs - High and Low

 For some details, here is the data behind this graph:

(Click for larger view)

Hey, not bad!  Lots of 99%, and only drops to the high 98% under high load.  Do remember, this modeler only considers losses from the FETs, Inductor, and Driver chip.  Not included is the controller, Amp shunts, nor any reverse polarity losses.  Remember, this modeler predicted 98.8% against the measured(whole system) 96.9% of the TI reference design. 

 And by playing with different FETs, even looking at asymmetrical ones for the Top and Bottom FETs I was able to get another 0.5% out of this.  Bottom line:  A buck converter using modern FETs and coils can give very good efficiencies. A few concerns with the above components though:

1. The Coilcraft inductor saturates at 11.5A.  Changing to a CWS HF467-260M-45AV solves this issue, but we loose about 0.5% efficiency and costs increase from $3.33ea to $23.50ea.
2. FET driver limits panels to Voc of 85v, would like to see a bit higher voltage to match the FETs (100v) - just to get some more headroom on two large panels in series.
3. FETs as shown use a very hard to hand-solder PQFN package. 

Moving to TO-220 parts (ala, an asymmetrical paring of: CSD19532Q5B & CSD19535Q5B) still delivers efficiency in the 98.7% range, but increases the pair cost from say $7.50 to $10 + the cost of a small heatsink.

1st look at Buck modeling

One of the 1st steps I want to do is some efficiency modeling; there are a few alternatives for hardware configurations - and some work up front can help select, or solidify, a direction.

I am using one of the .xls spreadsheets out there to model the standard CCM buck switching power supply architecture, as that architecture is rather simple and very mature in its development.  The one tool I was able to easily download (for some reason the .xls files are kind of hidden by many venders - even though the .pdf instructions are simple to find).   But I was able to locate the one from MicroChip.  Look under the Reference tab above for "AN01471A", both the .pdf and a .zip file with the spread sheet to save yourself a bit of googling :-)

The 1st thing I did was enter the devices used in this TI 20A-MPPT reference design:
    http://www.ti.com/tool/tida-00120?keyMatch=mppt&tisearch=Search-EN
It uses two paralleled buck sections which can have some issues of balancing between the two sections.  For the modeling I ran things up to 15A, just to cover the potential for uneven distribution of currents between the two.  

FYI:  I am using the TI reference design as they have well characterized the results, but am really only interested in the power (driver) side.  The CPU side seems a mess, including using RCs to delay digital signals to set the dead-time between the upper and lower FET.  Will not be doing that...


OK, so TI claims a measured 97% efficiency in a 12v deployment.  Putting in the power side components used, the MicroChip tool comes up with this graph:

I ran two curves.  One at 200K as the reference design was designed around, and one at 50Khz - which often result sin greater efficiency due to lower FET switching loss (esp the upper FET).  In this case, it did - esp at lighter loads.  But do keep in mind the design was not optimized for 50Khz, (Notably the FET), and there may be some problems with this - as well as additional opportunities.

And here is the table behind the graph:

Efficiency Graph
Series	1	2
Input Voltage (V)	17.33	17.33
Output Voltage (V)	12.32	12.32
Switching Frequency (Hz)	200000.00	50000.00
Driver VDD (V)	10.00	10.00
HS FET	CSD18532Q5B	CSD18532Q5B
LS FET	CSD18532Q5B	CSD18532Q5B
Driver	SM72295MA	SM72295MA
Inductor	SER2915L-103KL	SER2915L-103KL
Iout	Efficiency
.000	00.00%	00.00%
.500	91.06%	97.37%
1.000	95.20%	98.61%
1.500	96.65%	99.02%
2.000	97.38%	99.21%
2.500	97.81%	99.32%
3.000	98.10%	99.39%
3.500	98.29%	99.43%
4.000	98.44%	99.46%
4.500	98.54%	99.47%
5.000	98.62%	99.48%
5.500	98.69%	99.48%
6.000	98.73%	99.48%
6.500	98.77%	99.47%
7.000	98.80%	99.46%
7.500	98.82%	99.45%
8.000	98.83%	99.44%
8.500	98.84%	99.43%
9.000	98.85%	99.41%
9.500	98.85%	99.40%
10.000	98.85%	99.38%
10.500	98.84%	99.36%
11.000	98.83%	99.34%
11.500	98.83%	99.32%
12.000	98.81%	99.30%
12.500	98.80%	99.28%
13.000	98.78%	99.26%
13.500	98.76%	99.23%
14.000	98.74%	99.21%
14.500	98.72%	99.18%
15.000	98.70%	99.15%

At 1st blush I would say there is an OK correlation between the calculations and the measurements, though the tool seems to be a bit more optimistic:   98.8% efficient at 7.5A (shared, 15A total)  vs. a 96.9% measured with the sample system.  But there is one key differeance here, the .xls modeling tool does not take into account the additional losses associated with the TI's platforms additional FETs on the input and outputs.  I iwll modify the tool some and see how much changes..


But overall it is perhaps a bit encouraging.  Tools seems somewhat close, at least with a couple of % not taking into account the additional losses in the actual hardware.  It also confirms the gains associated with lower frequencies.   Over the next week or so I want to play with different FET / Inductor combinations and see what can be produced.   As well as modifying the tool to include the ability to consider losses associated with Amp shunts, protection Diodes, and perhaps on/off FETs.

Outlining the goals.

There are already in existence low cost solar MPPT controllers - some under $100 that were not available even two years ago.  So why do this project?

Like most of the other battery oriented projects I have done - because I want to.   But perhaps a bit more, this will be part of a larger system of battery oriented charging management projects - ones that communicate with each other to improve battery safety and performance, as well as simplify installation.  Some of the high level goals for this project can be outlined as:

• Sized to match one common large solar panel (240-300w) to a 12v or 24v battery system
• Current carrying speced at 25A
• Optionally support 2 panels in series in 24v systems.
• 48v support by ???  (current design does support 48v battery systems)
• Modular systems approach:  
• Multiple panel/controller pairs can be placed in parallel
• Controllers will intelligently communicate with each other to coordinate charging
• Simple to use DIP switches for out of the box installs.
• Available ASCII commands to enable advanced options 
• Integrate into CAN based battery charging / management system.

As with the other projects, this one will be open sourced for non-commercial use.  All CAD files and source code will be posted under the links above.  And as before the Arduino IDE will be used to make things a bit simpler to use and modify as people with.  (Update November 2014:  Am needing to review the Arduino IDE some - integrating the ATmegaxxM1 uC into it is not that simple..)

======================================================

A bit more:   Am looking to make a Buck based solar MPPT controller.  This matches up well with common solar panel outputs, as illustrated here:

Example 240W solar panel

The optimal panel voltage in all light levels is around 30v.  This matches up well with a Buck type switching power supply for 12v systems, but could be a bit on the edge for 24v systems - care will be needed at the point where Vpanel and close to Vbat.  And some consideration should be made for a pass-though mode if appropriate.


For simple deployments, a single controller might be sufficient.  But I intend to include a CAN bus to allow communication with other controllers, as well as the SmartBMS project to gain more precise battery voltage and other needs.  This should not only improve battery safety and life, but also reduce wiring by just using CAT-5 cables to connect up all the devices.  (Plus power cables!)

Am just starting on this project, and working in parallel with the BMS project: http://smartBMS.blogspot.com/


More come, as am just getting started....

Licensing

Hardware and Software designs copyright : William A. Thomason.



SOFTWARE
With releases starting in 2015 software is released in the GNU GPL3 (General Public License version 3) as published by the Free Software Foundation.  See http://www.gnu.org/licenses/ for additional details.

HARDWARE
And Hardware will be released under the  Creative Commons "Attribution  - ShareAlike" 4.0 license.
Full details may be found here:  http://creativecommons.org/licenses/by-sa/4.0/

===============================================================

Works (hardware and software) released prior to 2015 used the Creative Commons "Attribution  - NonCommercial  - ShareAlike" licence.
Full details are here:  http://creativecommons.org/licenses/by-nc-sa/3.0/

Hardware Design Overview

Last updated Nov 21, 2014

(Just a quick overview for now)


The Smart MPPT controller is based on a dual phase Buck switching power supply.  With careful component selection, and attention to details, efficiencies should approach the 98-99% range.

Core of the hardware is a dual phase - 180^o out of sync - buck converter.  By utilizing a dual-phase approach, smaller inductors could be used, allowing off-the-shelf ones.  And with the 180^o out of phase, smaller filter capacitors are allowed.

The ATmegaxxM1 uC was selected to drive the FETs, taking advantage of its advanced PWM capabilities, as well as integrated CAN controller.  Driving FETs hard and fast allow for very short dead-times, and when combined with a moderate 100Khz switching frequency, allow high efficiency of the conversion.


v0.0.1 of the PCB includes some components to enable debugging, also DC blocking capacities in the FET drivers (Protects the FET drivers in case of a burned out FET), as well as the ability to add ferrite beads in the FET gate drivers if needed to resolve spurious oscillations.  It is expected the final version of the design will be able to remove these.

Software Design Overview