Solar MPPT controller

Last updated:  Nov 21, 2014

The SmartMPPT controller is a solar panel charge controller utilizing the Arduino IDE to allow for simple updating and modification. It is sized to support one or two 'large' solar panels (charge current up to 25A, and solar panel input up to 85v) supporting 12v, 24v, 32/36v, or 48v battery systems.  In its final form a wide range of charge profiles will be included, and when combined with the remote smartBMS module ( http://smartBMS.blogspot.com/ ) will allow advanced battery charge management capabilites (such as measuring battery acceptance rate) to assure not only a fully charge battery, but also protect it from overcharging (as well as chronic undercharging).

By using a module approach, multiple SmartMPPT controllers may be installed into a system to allow near unlimited solar capacity scaling.  In addition, each solar panel / mppt controller module will optimize power output independently - allowing optomial power production when say a port of your solar systems panels are shaded (highly important in movable structures, ala boats or RVs).  Simple CAT-5 cables connect the  SmartMPPT controller (s) allowing coordination of solar charging, as well as intelligent integration into other charging sources for the canBAT network ( https://groups.yahoo.com/neo/groups/canBAT/info  )

Currently the 1st hardware design has been completed.  After fabrication the MPPT algorithm from Tim Nolan's efforts will be ported to proof the hardware.  From there will develop more advanced firmware to include concepts from the Smart Alternator Regulator (http://ArduinoAlternatorRegulator.blogspot.com/) such as configurable battery charge profiles, ASCII commands to allow customization w/o recompiling, as well as CAN protocols for communicaiton.  I am interested in experimenting with advanced MPPT algrosums, as well as other optomizaiton algrosiums (ala, self optomizing dead-time for the FETs)

Continued refinement of the ATmega32M1 / ATmega64M1 support under Arduino IDE

Though slow, there has been progress in enabling the ATmega32M1 / ATmega64M1 uC inside the Arduino.  Today new Arduino IDE support files are available under the "Arduino Libs" resource tab above.  They corrects a few errors, and a new 'version' is available that is compatible with the latest Arduino IDE 1.6.7 without producing warning messages.

At this point we have demonstrated the basic of the porting effort, SPI has been demonstrated to functions - as well as I2C using one of the SoftI2C libs.  The advanced PCS (Power Stage Controller - think really smart PWM) is working, as is the amplified differential ADC inputs.  And a 1st step at utilizing the built in CAN subsystem was accomplished, via a rather ugly rough-n-ready porting of the Atmel AT90CAN lib.
IDE. 

Over the coming months I am looking to create a more 'Arduino like' library for the  CAN subsystem, and may also look at a like one for the PCS subsystem.  If anyone is interested in helping out, feel free to contact me!

Still here - how is YOUR summer?

Just a quick note:  am still here - and have not abandoned this project.    But have been kind of distracted with maintenance needed on our boat after it sat unattended for a full year.  Have also been working a bit on refinements to the Alternator Regulator project.

I do have the new v0.0.3 PCBs on hand, and parts for it all ready to solder up.  But with all that we have 'planned' for the summer there is a good chance I will not have much time to work on this for another month, or even more, but I am still interested in completing this MPPT platform.   So hand in there.

And if by chance there is anyone wanting to pitch in, I do have a couple of extra blank PCBs!

-al-

v0.0.3 posted

Today I posted v0.0.3 of the Arduino enabled solar MPPT controller.  Key changes include:

1. Continued simplification of power supply - now primary switcher followed by LDO
2. Inclusion of night-time 'dark' blocking FET
3. Slight adjustments to FET driving traces, adding back in debug components.

I moved to a 13v switcher followed by a 5v LDO vs. the dual switcher in the last design.  Primary this gives a more stable voltage source into the ATmegaxxM1 for its ADCs - as well as providing a stronger VDD for the fet boost source.     In looking at the extra loss associated with the LDO, when fully active I calculate 175mW loss vs. perhaps 10 for a switching PS.  However this reduces down to the 5mW range when the uC is 'idle' or asleep - likely the in the same area as switcher (or even a little lower).  Given the uC can likely be placed into sleep for a large portion of time (most the peripherals work independently), am looking for low final loss.

Debugging has progresses enough that I thought it was time to add in a night-time blocking diode (using a FET for less loss).  The drive for this is pulled off of the boost ckt for bank-A, anytime that is working the blocking diode FET will get enabled.  It uses the intrinsic capacitance of the FET to keep enabled between pulses, while the 1M resistor provides a turn off after a period of inactivity.

I increased the trace widths of the FET drivers, and added in DC blocking capacitors, as well as 10K resistors between the drivers and the uC.  Idea hear is to provide SOME level of protection to the driver and uC while debugging code.  The final version of the PCB will have these removed.  And I likely will go to a 4-layer PCB for any final PCB as well.

Updated ATmega32M1 / ATmega64M1 support files for Arduino IDE

During debugging of the MPPT controller, I found a problem with the serial port code I adopted - resulting in random hangs while using Serial.Print() or Serial.Write() functions.  Today I posted corrected files (there was a logic error between the ::write object, and the interrupt handler).

I think the code can be cleaned up even more, and may do that later - perhaps using the current 1.6.1 files as a starting point.  But for now, do know there was a  bug which has been corrected.

ATmega32M1 and ATmega64M1 support with the new Arduino IDE 1.6.0

Update 2-14-2016:  There has been some fixes around ports usage - see readme.txt for details.  SPI is now demonstrated to work, and have been making progress in a CAN library. 

There are now 3 different 'versions' of the support files to use with different generations of the Arduino IDE, including the latest 1.6.7 w/o warning.

=====================================================================
 March 4, 2015:
This morning I posted up new portings of the ATmega64M1 uC in several variations, as well as support for the ATmega32M1 uC - all enabled at the same time in the new Arduino IDE release 1.6.0

Look under the Arduino Libs resource tab above, and follow the links and readme for the Arduino 1.6.0 IDE.  In short, you will need to copy a subdirectory in its entirety to your local 'arduino' users folder, and you will still need to make some edits with the avrdude.cong file.  But once done, you will find new 'board types' available for the ATmega64M1 and ATmega32M1 uCs.   A couple of details on the optiboot  ports:

1. The optiboot included has disabled any startup blinking of the LED - in case you happen to have Port 13 assigned to something other than an LED.
2. Some details on the fuses I selected:
• Brown-out is set at 2.7v (same as the Arduino UNO), so you should be able to operate at 3.3v (take care of max clock frequency allowed when operating at lower Vcc - hence the 8Mhz versions).
• The fuses are also set to FORCE  both the A and B outputs of the PSC controllers to a known LOW state upon startup / reset.  (6 output ports:  PSCOUT0, 1 & 2 - both A & B).
• The clock selected is one of:  16Mhz, or 8Mhz external xtal, or internal 8Mhz osc.

 For the 'core' support libraries, at this time I simply copied over the libs I modified in the v1.0.6 IDE port.  I noted there had been a bit of cleanup with some of the 1.6.0 libs, esp around the hardware serial functions - but it does appear that the existing libs still function w/o problems.  Going forward I will update the core lib functions as errors are found.

Refer to the graph at the end of this post for a mapping of the CPU pins to Arduino PORT names/numbers.  Do make sure to check the Arduino Libs resource tab above for any updates.

Versions enabled include:

• ATmega32M1 - 16Mhz external xtal
• ATmega32M1 -   8Mhz external xtal
• ATmega32M1 -   8Mhz internal osc.

• ATmega64M1 - 16Mhz external xtal
• ATmega64M1 -   8Mhz external xtal
• ATmega64M1 -   8Mhz internal osc.

Enhancements to pinMode() and analgoReag() - Differential inputs.

The ATmegaxxM1 line of CPUs have an extra feature to their analog inputs:  3 sets of adjustable gain differential inputs.  The core libraries have extended to recognize three new 'virtual' ports AD0, AD1, and AD2.  To use one simply uses the analogRead() as normal, but passing one of the virtual port names.  pinMode() has been extend to recognize the three virtual ports - with a slight change; when a differential port is passed to pinMode(), it is always assumed the mode will be INPUT - and the 2nd parameter then becomes the gain factor to be used.  Gain factors may be one of these:  GAIN5, GAIN10, GAIN20, GAIN40.   Here is a sample sketch showing their use:

   void setup() {
     pinMode(AD1, GAIN10);              // Differential input channel #1
                                        // With gain of 10x
     Serial.begin(9600); 
   }




   void loop() {
     int i;
 
     i = analogRead(AD1);            // Read differential channel#1
     Serial.println(i);              // Print its value out
     delay(1000);                    // Delay 1 second between reads
   }




New 'Virtual' ports:

•   AD0  = Differential input of   D9 - D8
•   AD1  = Differential input of   A4 - A3
•   AD2  = Differential input of D10 - A6 

New gain parameters passed as 2nd value in pinMode():

• GAIN5
• GAIN10
• GAIN20
• GAIN40

A few notes on the 1.6.0 release of the Arduino IDE.  Overall I am very happy to see them include a newer version of the GCC compiler - with its direct support of both the ATmega32M1 and ATmega64M1 uC as well as a better optimizer resulting in perhaps a 5% code size reduction.  It does appear they have also optimized the workflow of the overall tool some - I noted a bit better response / less delays when doing various tasks.

However I am rather disappointing they did not upgrade some of the other tools - e.g. AVRDUDE and the OptiBoot code.  You will still need to manually edit avrdude.cong adding in the ATmega32M1 and ATmega64M1 IDes, but at least now you can have both at the same time.  And for Optiboot - they not only did not upgrade to the latest release, but they totally broke the toolsets needed to recompile optiboot under 1.6.0;  it is a mess, with the only option to use a down rev 1.0.x release for the toolset and add in the latest source of optiboot source.

This is what I did for the boot files needed in this porting.

A final note:  I have only TESTED this port using the ATmega64M1-16Mhz xtl, and 8Mhz Osc options; as that is the boards / CPUs I have at had.  As folks use this if you find any issues with the porting I did, please let me know.

Click for larger view.
(Be sure to retrieve latest version from Arduino Libs resource tab above.)

Time to checkout the Magic Smoke!

I have finished assembling a solar MPPT controller - here are a couple photos:

I really should not have the camera THAT close.
Those Caps look like towers!

Have also been working to clean up the Arduino IDE and the port of the ATmega64M1 CPU.  I think I have most things fixed and will post corrections as I continue the debugging effort.  A bit on that: the porting is to the IDE version 1.0.5 / 1.0.6.   Arduino just released their 'updated' IDE v 1.6.0, and it will be much better - mostly because it uses an updated version of AVRDUDE and the GCC compiler - providing native support for the ATmegaxxM1 series of CPUs.   However, there has been some large changes in the support files - specifically around the hardware serial port, and it will take me some time to work though that all.  So for now, I am continuing my efforts under the 1.0.x line of the IDE.

Just last night I moved to start some live testing using the Solar Panels on Viking Star.  It is perhaps a good time to do this as the weather has changed, and our overcast winter sky's limit the panels output.  So far results tell me there is still a bit of work to do.  Am not happy with the +12v boost power source, and have worked though a fuse or two already...

But will carry on, and see what all I can get working.

More on ATmega32M1 and ATmega64M1 support with Arduino IDE

This morning I have posted up a refreshed set of 'files' to enable the ATmega64M1 uC in the Arduino IDE.  See 'Arduino Libs' resource tab above.  Specifically I have made edits to pins.h, and the wiring.c files scrubbing port names and how they are handled.  I also desk-confirmed the macro's needed to support software serial.  At this time I have touched a good portion of the Arduino IDE stack, and think most is 'ported' in support of the Arduino IDE - the two areas I have not touched, but perhaps will work fine due to how things are written, is the basic PWM and timing functions.

If you have downloaded the porting files before, you should do it again as there has been some significant corrections made in the area of how port names and numbers are defined.

I have also expanded the supported variants to include:  8Mhz, and 16Mhz external crystals, and an 8Mhz internal oscillator variant.  

All these changes are in support of the Arduino IDE version 1.0.x.  Going forward, I am working to bring up the SmartMPPT controller and as I find issues I will continue to update these files.  I also want to make a set of files targeting the new 1.6.x series of Arduino IDE's  as that will simplify things given their usage of more current compilers and ARVDUDE and as a result better native support of the ATmegaxxM1 uC's.  However, there are some major changes which have been done and porting to the new environment will take some time.

Expanding Arduino analogRead() and pinMode() to support the differential inputs on the ATmega32M1 / ATmega64M1

A nice feature of the Atmega32M1 / ATmega64M1 line of uC's is the addition of a differential input amplifier as one of the options for the ADC.  No longer must one take two measurements and subtract them in software, the 'op-amp' can do it for us.  Plus these differential inputs have a selectable gain from 5x to 40x.

On the Solar MPPT controller I use this capability to measure the battery and solar panel currents via a simple low ohm resistor.  Add in a small RC low-pass filter, and that is all that is needed...  (Using the ATmega32M1 uC allowed me to remove several other components typically used in other approaches, current measurement being one of those areas).

There are three differential channels: 0, 1, and 2.  I have extended the Arduino IDE's wiring_analog.c to recognize three new 'virtual ports'**:  AD0, AD1, and AD2.   Reading the value of these differential analog ports one simply uses the oh so familiar analogRead() function, example:

    solarAmpsRaw = analogRead(AD2);       // Read raw value of Solar Amp Shunt.


pinMode() has also been modified to recognize AD0, AD1, and AD2, with a slight change:  the 2nd parameter no longer specifies a 'mode' - as differential reads are always input.  Now the 2nd parameter is used to specific the amplifier gain to be used:  GAIN5, GAIN10, GAIN20, GAIN40

  pinMode(AD2, GAIN40);                 // Enable diff-amp #2, with gain of 40x


** Do take note that when enabling the 'virtual' differential analog inputs, two actual hardware ports are repurposed:

• AD0 returned results of:  (  D9 - D8)   * gain
• AD1 returned results of:  (  A3 - A4)   * gain
• AD2 returned results of:  (D10 - A6)   * gain

Summary of changes:

1. analogRead() expanded to recognize differential virtual ports AD0, AD1, and AD2
2. pinMode() expanded to enable AD0, AD1, AD2 and set the gain with: GAIN5, GAIN10, GAIN20 or GAIN40.

An example sketch:

#define SOL_AMPS_CHAN AD2               // ADC channel to read solar amps
                                        //  (Differential channel #2)
#define SOL_AMPS_SCALE (1/(40 * 0.002)) // Channel gain of 40x, 2mOhm shunt


void setup() {
   Serial.begin(9600);                  // open the serial port at 9600 bps:
   pinMode (SOL_AMPS_CHAN, GAIN40);     // Set up the differential channels.
}





void loop() {
  Serial.print(" Solar Amps are now: ");
  Serial.println(analogRead(SOL_AMPS_CHAN)*(int)(SOL_AMPS_SCALE  * 5/1024));
                                       //read and convert Solar Amps
  delay(1000);
}

Turning the PCB - and Arduino internal ADC accuracy

I have found enough errata to want to do a turn of the PCB.  v0.0.2 was send to OSHPark Thursday, as with a Mouser order.  Should have them in in a couple of week.  I will work on porting Tom Nolan's simple MPPT software (https://web.archive.org/web/20140324221651/http://www.timnolan.com/index.php?page=arduino-ppt-solar-charger)  to the SmartMPPT controller in preparation.  v0.0.2 has several changes, including:

• Corrected SMT footprints
• Cost reduced power supply, USB designs.
• Removal of SERVICE port (functions could be accessed via ICSP port)
• Improved voltage sampling buffering ckt - removal of offset errors in op-amps

Overall cleanup of board, and improvement in tight Hi/Low FET layout.

One area I struggled with a little was the voltage sensing design - based around using the Arduino's built in A/D.   In short - how much $ vs. desired accuracy?   One might noticed I backed off from the 0.1% resistors in the voltage divider, and now just use 1% devices.  This saved about $1 in BOM cost.  And here was my thinking:   The ATmega32M1 is able to selected one of two sources for its A/D converter reference:  External (Vaa, or +5 in this design), or an internal 2.56 source.   And there is the basic issue.  The internal source is known to be rather stable over time and temperature, but not all that accurate (2.5-5% or so).  Using Vaa tied to +5, even with the filtering, can present a significant error its self (And is dependent on the accuracy fo the +5 supply to boot).

All told, using high precision components in the op-amp ckt seemed kind of like putting silk on a pig's ear.  Additional cost could have been added by adding an external voltage reference (i.e. LM4040) - but I think even then we would not know the BATTERIES voltage, only what we see at the output of the MPPT controller.

So, I have  backed off - and accept a few % error in absolute accuracy for voltage readings, but still look for stability.  As far as the MPPT logic is concerned, it is trying to maximize a value - and it really does not care too much how accurate that value is, just that it is repeatable.


For accurate battery voltage information, to say decide charging states and accommodate voltage drops over the battery cables, will look to the CAN BMS device attached via a simple CAT-5 cable.
http://smartbms.blogspot.com/

atmega32M1 / atmega64M1 and the Arduino IDE

This series of blog entries will document the enhancements of the arduino IDE to support the ATmega32M1 and ATmega64m1 uC.   Make sure to follow this link to see all the changes and enhancements:
http://smartmppt.blogspot.com/search/label/xxM1-IDE



I selected the atmegaxxM1 uC for this solar MPPT controller for three reasons:

1. An very nice PSC (Power Stage Controller) module that can do tightly locked driving for the H-bridges - much more advanced then the standard PWM modules in say the atmega328p
2. Built in CAN controller
3. High degree of robustness as it was designed primary for automotive applications.
4. Being part of the atmega line of uC's, it is a close cousin to the atmega328p as used on the Arduino UNO

This last point is attractive as it could allow one to use the Arduino IDE to program the smartMPPT controller.  Only problem is - the atmega32/64M1 uC is not currently supported by Arduino.  Compounding this is that the serial port is a bit different - rather then a 'standard' UART it has a serial controller which can assist with UART functions, but also provide support for another type of bus used in automobile applications, the LIN bus.

All of this means  - one can not just plug things in and it will work.  Google turned up a few folks who looked into this, the one making perhaps the most progress was: http://spaces.atmel.com/gf/project/arduinoallegro/

Over the past few days I have been successful in porting the optiboot bootloader to the atmega32/64M1 uC, integrated the start of the environment from Stuart (specifically his work around Serial.print() functions.) and successfully have been able to use the Ardino IDE to flash in a bootloader, and then download sketches via the serial port!

Look under the resource tab above 'Arduino Libs', and select the  directory called 'atmegaxxM1 Arduino IDE'.  In there you will find an optiboot bootloader, modifications to the avrdude configuration file, as well as the Arduino IDE (boards.txt, etc..) and instructions on what to do with each.  I suspect there is a bit more work to do with the Arduino libs - beyond Serial.print(), and as I find and update those will post revised files to the resource tabs above.

I also have modes needed to support the atmega32M1, and once things are a bit more proofed out I will post a set of files needed to support that uC in the Arduino IDE.

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

Additional Info Feb 2015:  I have tracked down a bit more details re: the atmega64M1 uC support by the tools selected by Arduino for their IDE.   Bottom line:  In the 'main' release of Arduino uses gcc version 4.3.2, which does not have in its known list of uCs the atmega64m1 - but does have the atmega32m1.   My current 'work around' was to configure the above files for the atmega64m1 and 'spoof' to the compiler think it was a atmega32m1.  This works OK, but prevents me from defining both the 32M1 and 64M1 at the same time.

In the beta version of Arduino (1.5.8, etc) is an updated the GCC compiler (version 4.8.1?)  which has been updated to include many more uCs, including the atmega64M1.  For now I will continue to work with the  the 1.0.x releases, but in the future (and depending on what the Arduino team ends up doing) will perhaps switch to the 1.5.x versions for more complete support.

More additional info March 2015:  I have completed a porting over to the 1.6.0 release of the Arduino IDE - and was able to enable BOTH the ATmega32M1 & ATmega64M1 uC at the same time.   See here:
http://smartmppt.blogspot.com/2015/03/atmega32m1-and-atmega64m1-support-with.html

Status of prototype build.

We are now in the Portland OR area and could fetch mail (and boxes) from our mail drop.   Most all the components have arrived, and the PCB should be here soon.   But there is one delay:  the inductors from CoilCraft are on back-order until the end of January... 

Oh Well, will give me time to play with other parts of the bringup.

v0.0.1a of hardware design released

Today I edited this BLOG to put in the resource links above, and also posted the final release hardware design for the initial build v0.0.1a:

See 'Schematic' link above for larger image .pdf file

And here are some 3D renderings:

Top view

 

Bottom view

The module is approx 3x4" (actually, 80mm x 100mm), utilized 100v FETs and caps (I am suggesting keeping solar panel voltage below 85v), and can support up to 25A battery current.  These give it the following range of charging support per module:

• 12v battery:         345W capacity
• 24v battery:         690W
• 32/36v battery: 1,000W
• 48v battery:      1,380W

 To each the above capacities one or more solar panel can be used.  Example, for a 12v system one could use a single large 280W panel per controller.  For a 48v system, 4 such panels could be deployed in a combination of serial/parallel connection.

The costed BOM come to $73.30 + price of PCBs, which could be found for under $10 using overseas supplier.  I expect parts to arrive some time in December and will start assembling one unit then, and when I return to Viking Star will be able to start playing with trial runs on our solar panels as well as start developing the more advanced firmware.


For those interested there is a LTSPICE model of the buck converter using in this design under the CAD resource tab above - kind of fun to play with.

Final 'Rough-Cut' schematics #3

Tonight I posted what I am calling the last of the 'Rough Cut' schematics; last as I have completed my initial review of the switchers - and am well underway in PCB layout.  Next step will be to release v0.1 of the design, along with the CAD files.

Over the past weeks or so I have been focusing on the FETs and doing a bit of SPICE modeling, paying attention to the transitions.  As a result I swapped out the FET driver ICs for ones that are able to drive the FETs harder, removed any imposed gate resistance, and also removed the bypass diodes around the lower FETs.  This last step might seem odd, but in refining things I have been able to greatly shorten the dead-time, currently looking at using 35nS as a very safe starting point.  This short time seems contrary to some folks thinking for such large FETs, but actually is in line with start-of-the-art designs - Drive the FETs Fast-n-hard, and with the right drivers (ala the LT's I am now specifying) am able to get real tight switching w/o any adverse effects.

A higher resolution PDF file:

https://drive.google.com/file/d/0B5GiaoeXCQ3vclRRaFFEUXhQQXc/view?usp=sharing

 
Some other small changes include:

• Finalization of 5V and 13V power supplies. (though may need to change out 10Ohm R3, am just trying to reduce the number of different parts used)
• Addition of 'Service Port' which can be used instead of populating USB
• Upgrading all FETs to 100v parts, allows use of two common panels in series for 24v/48v batteries.
• Reduced some of the large switching  CAPs, still have plenty for the design.
• Changed Amp Shunt resisters from 1mOhm to 2mOhm for better use of ADC ranges

With these changes, the .xls sheet is indicating 98.6% - 98.7% conversion in the core.  SPICE modeling seems to confirm this, will see with actual hardware.


I have also been revising the layout of the core switching elements to minimize current paths.  I still have some work to do, and may end up modifying the schematic some, but largely I think this is close to what the finial design will be.

Note how some parts are still not places, I need to work on the drivers a bit more - but overall am happy with how this layout is shaping up.

We are about to begin our move from Minnesota back to Washington (and Viking Star) - with a stop in Portland for the Holidays.  It is likely I will not have too much time to put into this over the next few weeks, hence I wanted to get what I had posted.   But I do intend to finish this in time to order up some PCBs and parts so I can start playing with hardware after the new year, and when I am back at the boat with the solar panels!

Rought Draft #2 of schematic, and a draft PCB layout

I have posted into the Schematic link above a .pdf of the latest schematic.  Not a whole bunch has changed from the 1st rough-cut, Refining the FETs - settled on an asymmetrical pair:  Faster switching top FET, and lower Rdon lower FET.  Also have gone with DPAK devices for this 1st PCB FAB, may upgrade to the better PQFP ones later, but the DPAK ones will be simpler to replace if need be :-)    Replaced the LDO with a 2nd switcher in the power supply sub-system, saving that 125mW overhead.  And did a little SPICE modeling on the FETs and drivers and hence added a spot for some additional gate drive options (specifically the fast pull-down diodes on the High FETs) that might help with some of the cross-over losses.

Click for larger view <BR/> Also see the .pdf under the Schematics link above.

And here are a couple of views of the PCB layout Top and bottom:

Top view

The PCB comes in at 10x7cm, and a rough BOM cost of around $75-80, including an off-shore PCB fab.  I tried to select higher temperature 125c rated parts; that did increased BOM cost perhaps 10%.  If one wanted to back off and use an external USB <--> TTL adapter, and drop the CAN ports, might save $15-20???  Dropping one bank might save another $10??  (The PCBs come in around $2-3 using off-shore fab, so not sure it is worth doing more than one PCB design - just do stuffing options)

In the top 3D rendering above you can see some odd parts, notably the USB connector.  This is the result of stuffing options in the PCB design - I have in there the ability to use horizontal or vertical components for the USB, DIP switch, and the RJ-45 ports.  Or, one can populate headers and use external cables (e.g., to place this into a waterproof box and use waterproof external connectors vs. wiring glands).  Because all the stuffing options are in the schematic, they are rendered in the 3D view - each on top of the others.


Still to do:  I need to go through and confirm all the switching power supply calculations, inductors, caps, etc. (and there are three of them on the board!)  The caps used on the solar buck are rather costly (around $2-3 each), and want to make sure I have in what is both needed, but not more than what is.  I also need to finish the PCB layout, just a couple more routs to do, and confirm some thermal dissipation around the FETs - as I am relying on the PCBs as the heat-sinks.  Look for a physical interference between the caps and the large solar and battery connectors - the 3D rendering shows an overlap, but the connector 3D modes are mocked up and may not be accurate.  And I want to put some time into the xxM1 uCs and Arduino IDE - there are a few postings out there about using the uC with the Arduino IDE, want to make sure it will actually work before getting much further along.

There is a lot going on family wise these days, the above may take me a bit of time to complete.  My intention is once I complete some of the tasks above to order a set of 3x OSH-PARK PCBs and a set of components to build one up.  If someone is interested in building up one of the other PCBs, drop me a line.  At that time will also post up the CAD files to the links above.   I figure once things are proven a bit, will revise the PCB and get a set of them made - perhaps look into have some of the SMT parts machine assembled.  Might also revise the FETs to the 'better', but harder to hand assemble, QPFP packages.

Fine tuning the FETs

Have done some more modeling and think I am about at the end of incremental improvements using this tool.  I posted the .xls sheet with the additional drivers, FETs, and inductors I have been using in the reference tab above.

Below as the detailed results for three potential FETs.  All SMT, one the new PQFP package and two DPAK ones.  Costs are 1x qty from Mouser.com  Parameters use for each run was:

                Vpanel = 32.0v

                Vbat      = 13.8v

                22uF inductor

                100Khz PWM frequency

Early on I had to look to increase the operating frequency from 50Khz to 100Khz else the output capacity ESR losses became very large.  Unfortunately, increasing the frequency also increased switching losses in the FETs…  And at this point the switching losses for the high side FET are in the 350mW range.   Here are the detailed tables:

1)  IRFH7185 – PQFP - $3.92

IOUT (A)	HS Conduction Losses	LS Conduction Losses	HS Switching Losses	Diode Conduction Losses	Reverse Recovery Losses	MOSFET Output Capacitance Losses	High Side Gate Drive Losses	Low Side Gate Drive Losses	Inductor Winding Losses	Output Power (W)	Input Power (W)	Efficiency	HS Die Temperature (˚C)	LS Die Temperature (˚C)
.00	.0021	.0025	.0000	.0000	.3520	.1096	.0360	.0360	.0000	.00	.5382	0.00%	41.23	25.09
1.00	.0042	.0049	.0386	.0032	.3520	.1096	.0360	.0360	.0029	13.80	14.3873	95.92%	42.65	25.28
2.00	.0104	.0121	.0771	.0064	.3520	.1096	.0360	.0360	.0114	27.60	28.2511	97.70%	44.22	25.65
3.00	.0209	.0242	.1157	.0096	.3520	.1096	.0360	.0360	.0257	41.40	42.1297	98.27%	45.94	26.18
4.00	.0358	.0413	.1543	.0128	.3520	.1096	.0360	.0360	.0458	55.20	56.0235	98.53%	47.81	26.89
5.00	.0554	.0635	.1929	.0160	.3520	.1096	.0360	.0360	.0715	69.00	69.9328	98.67%	49.84	27.78
6.00	.0798	.0909	.2314	.0192	.3520	.1096	.0360	.0360	.1030	82.80	83.8579	98.74%	52.05	28.85
7.00	.1093	.1239	.2700	.0224	.3520	.1096	.0360	.0360	.1401	96.60	97.7993	98.77%	54.43	30.12
8.00	.1442	.1626	.3086	.0256	.3520	.1096	.0360	.0360	.1830	110.40	111.7576	98.79%	57.00	31.59
9.00	.1848	.2073	.3471	.0288	.3520	.1096	.0360	.0360	.2317	124.20	125.7333	98.78%	59.77	33.26
10.00	.2314	.2585	.3857	.0320	.3520	.1096	.0360	.0360	.2860	138.00	139.7272	98.76%	62.75	35.17
11.00	.2845	.3167	.4243	.0352	.3520	.1096	.0360	.0360	.3461	151.80	153.7403	98.74%	65.96	37.32
12.00	.3444	.3822	.4629	.0384	.3520	.1096	.0360	.0360	.4118	165.60	167.7733	98.70%	69.41	39.72
13.00	.4117	.4557	.5014	.0416	.3520	.1096	.0360	.0360	.4833	179.40	181.8273	98.67%	73.12	42.40

2)  IPD096N08N3 – DPAK - $1.78

IOUT (A)	HS Conduction Losses	LS Conduction Losses	HS Switching Losses	Diode Conduction Losses	Reverse Recovery Losses	MOSFET Output Capacitance Losses	High Side Gate Drive Losses	Low Side Gate Drive Losses	Inductor Winding Losses	Output Power (W)	Input Power (W)	Efficiency	HS Die Temperature (˚C)	LS Die Temperature (˚C)
.00	.0054	.0063	.0000	.0000	.2912	.0502	.0260	.0260	.0000	.00	.4051	0.00%	42.34	25.32
1.00	.0106	.0124	.0321	.0040	.2912	.0502	.0260	.0260	.0029	13.80	14.2553	96.81%	44.20	25.82
2.00	.0264	.0306	.0641	.0080	.2912	.0502	.0260	.0260	.0114	27.60	28.1339	98.10%	46.59	26.93
3.00	.0533	.0616	.0962	.0120	.2912	.0502	.0260	.0260	.0257	41.40	42.0423	98.47%	49.55	28.68
4.00	.0923	.1062	.1283	.0160	.2912	.0502	.0260	.0260	.0458	55.20	55.9820	98.60%	53.10	31.11
5.00	.1445	.1656	.1604	.0200	.2912	.0502	.0260	.0260	.0715	69.00	69.9553	98.63%	57.31	34.28
6.00	.2113	.2418	.1924	.0240	.2912	.0502	.0260	.0260	.1030	82.80	83.9658	98.61%	62.25	38.29
7.00	.2944	.3368	.2245	.0280	.2912	.0502	.0260	.0260	.1401	96.60	98.0173	98.55%	68.02	43.24
8.00	.3963	.4542	.2566	.0320	.2912	.0502	.0260	.0260	.1830	110.40	112.1155	98.47%	74.71	49.31
9.00	.5201	.5980	.2886	.0360	.2912	.0502	.0260	.0260	.2317	124.20	126.2678	98.36%	82.51	56.70
10.00	.6693	.7740	.3207	.0400	.2912	.0502	.0260	.0260	.2860	138.00	140.4834	98.23%	91.57	65.70
11.00	.8488	.9910	.3528	.0440	.2912	.0502	.0260	.0260	.3461	151.80	154.7760	98.08%	102.15	76.75
12.00	1.0658	1.2600	.3848	.0480	.2912	.0502	.0260	.0260	.4118	165.60	169.1639	97.89%	114.60	90.40
13.00	1.3280	1.5970	.4169	.0520	.2912	.0502	.0260	.0260	.4833	179.40	183.6706	97.67%	129.31	107.45

3) IPB090N06N3 – DPAK - $1.73,  60V max part

IOUT (A)	HS Conduction Losses	LS Conduction Losses	HS Switching Losses	Diode Conduction Losses	Reverse Recovery Losses	MOSFET Output Capacitance Losses	High Side Gate Drive Losses	Low Side Gate Drive Losses	Inductor Winding Losses	Output Power (W)	Input Power (W)	Efficiency	HS Die Temperature (˚C)	LS Die Temperature (˚C)
.00	.0037	.0046	.0000	.0000	.1280	.0655	.0360	.0360	.0000	.00	.2739	0.00%	32.89	25.19
1.00	.0072	.0091	.0302	.0040	.1280	.0655	.0360	.0360	.0029	13.80	14.1188	97.74%	34.24	25.52
2.00	.0178	.0223	.0603	.0080	.1280	.0655	.0360	.0360	.0114	27.60	27.9855	98.62%	35.87	26.21
3.00	.0358	.0446	.0905	.0120	.1280	.0655	.0360	.0360	.0257	41.40	41.8742	98.87%	37.79	27.26
4.00	.0614	.0763	.1207	.0160	.1280	.0655	.0360	.0360	.0458	55.20	55.7856	98.95%	40.03	28.69
5.00	.0950	.1176	.1509	.0200	.1280	.0655	.0360	.0360	.0715	69.00	69.7206	98.97%	42.58	30.51
6.00	.1371	.1693	.1810	.0240	.1280	.0655	.0360	.0360	.1030	82.80	83.6799	98.95%	45.47	32.73
7.00	.1882	.2319	.2112	.0280	.1280	.0655	.0360	.0360	.1401	96.60	97.6650	98.91%	48.72	35.40
8.00	.2490	.3065	.2414	.0320	.1280	.0655	.0360	.0360	.1830	110.40	111.6775	98.86%	52.36	38.54
9.00	.3203	.3939	.2715	.0360	.1280	.0655	.0360	.0360	.2317	124.20	125.7189	98.79%	56.41	42.19
10.00	.4029	.4955	.3017	.0400	.1280	.0655	.0360	.0360	.2860	138.00	139.7916	98.72%	60.93	46.42
11.00	.4979	.6129	.3319	.0440	.1280	.0655	.0360	.0360	.3461	151.80	153.8983	98.64%	65.93	51.27
12.00	.6066	.7482	.3621	.0480	.1280	.0655	.0360	.0360	.4118	165.60	168.0423	98.55%	71.49	56.85
13.00	.7307	.9036	.3922	.0520	.1280	.0655	.0360	.0360	.4833	179.40	182.2275	98.45%	77.66	63.23

System overhead:

         o    Output capacitor losses – est:   26mW (using 3.57A inductor ripple current)
         o    Input capacitor losses    - est:  162mW using 9A load.

·                O       +5v rail:  25mA -->   125mW

o   uC consumption:       14mA @5v (per datasheet typical)

o   OpAmps:                     100uA @ 5v (per datasheet typical)

o   CAN consumption:     6mA @ 5v (assuming a 1% dominate/recessive ratio)

o   Various pull-ups:         5mA @ 5v (WAG)

·    ·           O       uC power supply loss:  134mW

o   Switcher loss:                    9mW (Per datasheet, 25mA load, 36v Vin)

o   Linear Loss:                   125mW  (10v à 5v = 5v drop at 25mA)  -- Clearly need to look at this closer…

·    ·           O       Vbat & Vpan resistor network:  1.2mW

o   Vbat:                     190uW

o   Vpanel:                1mW

Total estimated overhead:  26mW + 162 + 125mW + 134mW + 1.2mW =   449mW  --> 450mW

Based on 250w input this would be a 0.18% reduction in the above efficiency numbers.  So, the IRFH7185 selection, instead of being 98.78% efficiency would come in at 98.60% overall.

If one did a depopulated (one bank only) configuration, and eliminated the CAN subsystem – that would save 60mW in losses between the CAN transceiver and uC power supplies.

The straw-man has a liner LDO regulator taking the 10v from the LTC3639 SPW down to 5v.  I had selected this as a cost trade-off in support of very low +5 current consumption if the uC is placed into sleep.  Most low cost small switching power supplies need a min of 5-10mA to remain stable, and in sleep the uC will be in the low uA range.  Perhaps need to consider another switching power supply, but a more costly one as the 125mW loss associated with the LDO is very significant.

How does this look, does it seem like I have missed something?

-al-