An Arduino based Solar MPPT charge controller.

Similar projects worth following
In India most of the people are living in rural areas,400 million people that are currently have no access to electricity.Despite India being the world's 5th largest energy producer,the existing electric grids are not capable of supplying the electricity need to those poor people.
So the need for clean, affordable alternatives is obvious.Solar power have the advantage of being less maintenance and pollution free.
To provide basic need of electricity and improve the socio-economic positions of rural people, I started this project from basic lighting system and a simple PWM solar charge Controller in March-2014.The feedback was incredible on Instructables. After working over one year to improve the controller, I have landed up in this stage.This project is on MPPT solar charge controller which can charge a commonly used 12V lead acid battery from a solar panel.This is more sophisticated,30 to 40 % more efficient and have several advantages over the other charge controllers.

MPPT stands for Maximum Power Point Tracking. MPPT charge controllers used for extracting maximum available power from PV module under certain conditions.The Maximum Power Point Tracker (MPPT) circuit is based around a synchronous buck converter circuit.It steps the higher solar panel voltage down to the charging voltage of the battery. The Arduino tries to maximize the watts input from the solar panel by controlling the duty cycle to keep the solar panel operating at its Maximum Power Point.

You can find more details on MPPT here

Algorithm :

The Maximum Power Tracker uses an iterative approach to finding this constantly changing MPP. This iterative method is called Perterb and Observe or hill climbing algorithm.To achieve MPPT, the controller adjusts the voltage by a small amount from the solar panel and measures power, if the power increases, further adjustments in the direction are tried until power no longer increases.

The voltage to the solar panel is increased initially, if the output power increase, the voltage is continually increased until the output power starts decreasing. Once the output power starts decreasing, the voltage to the solar panel decreased until maximum power is reached. This process is continued until the MPPT is attained. This result is an oscillation of the output power around the MPP.

Specification of version-3 charge controller :

1.Based on MPPT algorithm

2. LED indication for the state of charge

3. 20x4 character LCD display for displaying voltages,current,power etc

4. Overvoltage / Lightning protection

5. Reverse power flow protection

6. Short Circuit and Over load protection

7. Wi Fi data logging

8.USB port for Charging Smart Phone /Gadgets

Electrical specifications :

1.Rated Voltage= 12V

2.Maximum current = 5A

3.Maximum load current =10A

4. In put Voltage = Solar panel with Open circuit voltage from 12 to 25V

5.Solar panel power = 50W

  • 1 × Arduino Nano Atmega328P based Microcontroller
  • 3 × Current Sensor ACS712 hall effect Current Sensor
  • 2 × LM2596 module DC-DC Buck Converter module
  • 1 × ESP8266 WiFi SOP module
  • 1 × 20x4 char LCD display Yellow Serial 2C/TWI 2004 20X4 Character LCD Module Display
  • 2 × IR2104 Driver Half Bridge Driver, Single Input Plus Inverting Shutdown Pin
  • 1 × AMS1117 Power Management ICs / Linear Voltage Regulators and LDOs
  • 1 × 2N3904 Discrete Semiconductors / Transistors, MOSFETs, FETs, IGBTs
  • 4 × SR5100 Discrete Semiconductors / Diodes and Rectifiers
  • 6 × IN4148 Diodes

View all 49 components

  • Battery Temperature and Charging Voltage Compensation

    Debasish Dutta09/16/2015 at 09:45 0 comments

    All chemical reactions are affected by temperature. Battery charging is also an electrochemical reaction, so it too is affected by temperature. As the battery gets warmer, the gassing increases. As the battery gets colder,it becomes more resistant to charging. So battery charging voltages should be corrected based on battery temperature. This adjustment is referred to as temperature compensation, a charging feature that helps ensure that a battery is neither undercharged nor overcharged regardless of battery temperature.

    Using normal target voltages to charge a battery that is colder than approximately 25ºC (77ºF) will result in an undercharged battery, which will deliver lower performance, reduced life and a higher life cycle cost. Applying normal target voltages to a battery that is hotter than 25ºC may result in an overcharged battery. This condition could lead to the drying out of VRLA battery cells. With flooded cells, the result will be excessive outgassing, increased battery maintenance in the form of more frequent watering and reduced battery life due to thermal stress. In fact, some battery manufacturers and charger manufacturers recommend not charging a battery that is 50ºC (122ºF) or hotter.

    Temperature Sensor :

    To monitor the battery temperature a DS18B20 1-Wire digital temperature sensor from Maxim IC will be used. It can measures temperatures from -55°C to +125°C. Fahrenheit equivalent is -67°F to +257°F with ±0.5°C accuracy.

    We choose a waterproofed version of the DS18B20 Temperature sensor. It is quite handy to measure something far away, or in wet conditions.

    You can see it here

    You can see the Data Sheet

    Temperature Compensation Formula:

    minus 0.018 volts per degree Celsius

    Example :

    1. Let the battery temperature is 0 degC and float voltage is 13.8V ( STC : at 25degC )

    Compensation Required = ( 0 - 25) * ( - 0.018 ) = + 0.45V

    Compensated Float Voltage = 13.8 + 0.45 = 14.25 V

    2. Let the battery temperature is 35 degC and float voltage is 13.8V ( STC : at 25degC )

    Compensation Required = ( 35 - 25) * ( - 0.018 ) = - 0.18V

    Compensated Float Voltage = 13.8 - 0.18= 13.62 V

    So cold batteries ( example-1) require a higher charge voltage in order to push current into the battery plates and electrolyte, and warmer batteries( example-2 ) require a lower charge voltage to eliminate potential damage to valve regulated lead acid (VRLA) cells and reduce unnecessary gassing if flooded cells are used.

    Reference :

  • Software requirements for MPPT controller V3.1

    Debasish Dutta08/30/2015 at 15:06 1 comment

    Software requirements for MPPT controller V3.1

    Draft by Keith Hungerford, updated 12th September 2015

    Charging states

    The charger operates in one of several charging states, depending on the sunlight level.

    Charger OFF state

    At nil or low sunlight levels, as indicated by solar voltage below battery voltage + 0.5 Volts, the charger state is OFF.

    Transition from the OFF state occurs when

    a) if battery voltage is greater than 11.5 volts and solar voltage rises above battery voltage + 0.5 Volts

    b) if battery voltage is less than 11.5 volts and solar voltage rises above 12.5 volts.

    When either of these voltage conditions is met the charger goes into one of the following states:

    i) Float state if the battery voltage is greater than the Float voltage;

    ii) Boost state if the battery voltage is less than the Float voltage and the Boost time since the last night time is less than [1 hour];

    iii) Bulk state if the battery voltage is less than the Float voltage and the Boost time since the last night time is greater than [1 hour]

    In all 3 cases initially the controller will use the DCM charging algorithm.

    Boost DCM and Bulk DCM states

    When in the Boost DCM or Bulk DCM state, the charger can go to OFF state if the solar voltage falls below (battery voltage + 0.5 Volts).

    The charger can go to Boost CCM or Bulk CCM state if the Solar Power rises above 10% of the rated power.

    The charger can go to the Float state if Battery voltage rises above Float.

    The charger can go from Boost DCM to Bulk DCM if the Boost time since the last night is greater than Boost duration.

    Boost CCM and Bulk CCM states

    When in the Boost CCM or Bulk CCM state the charger can go to Boost DCM or Bulk DCM if the Solar Power falls below 10% of rated power.

    • The charger can go from Boost CCM to Bulk CCM if the Boost time since the last night is greater than Boost duration

    Float state

    The float state is functionally the same as Bulk state when the battery voltage reaches Float.

    When in Float state the charger keeps just sufficient current flowing to the battery to maintain the battery voltage at Float.

    Charging algorithms

    CCM algorithm

    Continuous Current Mode (CCM) applies when the available solar power is more than 10% of the rated power (strictly, when the current in the inductor always flows towards the battery, but this is difficult to measure directly in the software so we use the power level as a proxy estimate).

    In this mode, the PWM period is set at 12 microseconds. The PWM duty cycle is set either at a value that achieves maximum power, or to meet the charging voltage required by the battery (see battery management conditions below). When it is required to reduce the charging rate so as to limit the battery voltage, the PWM duty is reduced, thereby increasing the panel voltage above the maximum power point and reducing the current accordingly.

    The Fast PWM mode of the Arduino is used to generate this PWM. The PWM period of 12 microseconds is 192 clock cycles at 16 MHz. The PWM period is divided into a Panel Connect phase followed by an Earth Connect phase. The length of the Panel Connect phase is controlled by PWM Duty.

    When maximising power, the power level is measured approximately every 0.5 milliseconds and is compared to the previous power level measurement. The PWM duty cycle is changed up or down by 1 CPU clock cycle after every measurement. After the first measurement, the PWM duty cycle is increased. On subsequent measurements, if the power level is increased or is the same as the previous measurement, the PWM duty cycle is changed in the same direction as in the previous cycle. If the power level is decreased from the previous cycle, the PWM duty cycle is changed to go in the opposite direction to that in the previous cycle.

    When tracking the allowable battery voltage, the battery voltage is measured approximately every 0.5 milliseconds and is compared to the target value. If the new value is within +0.1 volts of the target value, the PWM duty is left unchanged. If the new value is...

    Read more »

  • Overview of Version-3.1

    Debasish Dutta08/30/2015 at 14:50 6 comments

    After lot testing we observed that MOSFET ( Q3 ) in ver-3.0 design is burning repeatedly.We tried to modify the existing software but not find any satisfactory result.

    The other problem was that MOSFET Q1 ( in V-3.0) conduct even when there is no solar input.

    To solve the above problems and enhance the power handling capability we are modifying both the hardware and software.This is named as Version-3.1 Charge Controller.This version have 3 options.

    1. 5 Amp version :

    T94-26 toroid, 48 turns of AWG20 wire to give 135 uH (it takes almost 1.5m of wire)

    Q1, Q2 and Q3 all pairs of IRFZ44N MOSFETs (6 in all).

    C1 will be 3 * 220 uF low ESR capacitors in parallel,

    C2 will be a single 220 uF low ESR capacitor

    Single ACS712 on the panel side as per version 3.0

    2. 8 Amp version :

    T106-26 toroid wound with 23 turns of a compound wire made from 3 strands of AWG20 wire twisted together to give 47 uH (this takes about 3.1 m of wire).

    Q2 will be a pair of FDP150N10A MOSFETs in parallel.

    C1 will be 5 * 220 uF low ESR capacitors in parallel,
    C2 will be a single 220 uF low ESR capacitor

    Two ACS712, one on the panel side as per version 3.0 and one in series with the battery.

    3 10 Amp version :

    T130-26 toroid wound with 23 turns of a compound wire made from 4 strands of AWG18 wire twisted together to give 41 uH (this takes about 4.5 m of wire).

    Q2 will be a pair of FDP150N10A MOSFETs in parallel.
    C1 will be 6 * 220 uF low ESR capacitors in parallel,
    C2 will be 2 * 220 uF low ESR capacitors in parallel.

    Three ACS712, one on the panel side as per version 3.0, one in series with the battery and one in series with the load.

    Here is a rough sketch for V-3.1

    You can download the complete schematic from here

    We are working on new PCB for V-3.1 Here is the sample of one

    The drive circuitry (common to all 3 versions) will use 3 separate IR2104 driver chips, one for each of Q1, Q2 and Q3. We drive the Q1 and Q2 drivers from pin D9 and HO1 and HO2, and drive Q3 from pin D10 and LO3.

    In driver chips 1 and 2, pins IN and SD are driven in parallel by Arduino output pin D9. In the case of driver 1 (for Q1) there is a low pass RC filter in series, with a time constant of about 1 ms. Driver 2 is driven directly (as in the current circuit, but probably with a slightly higher series resistor to allow more current for the Q1 driver and its RC filter).

    In driver chip 3, IN is driven by D9 and SD is driven by D10.

    The purpose of using separate drivers for Q2 and Q3 is to enable us to switch Q3 OFF to operate in Asynchronous mode at low current levels when the controller will be in DCM (Discontinuous Current Mode). There may be a better way to do this but in the short time we have available this is a simple option and easy and reliable to implement.

    All 3 versions should have LCD displays, WiFi, LED indicators (maybe with a more fancy coding scheme to separately indicate DCM and CCM).

    All 3 versions should be able to cope with either 18 V or 30 V panels, and use algorithms that stop them burning out if the panel can produce more current than the rating allows. This can all be done auto-detect.

    All the components exposed to panel voltage need to be rated for at least 40 V (in particular C1 and our buck converter to generate 12V for the drivers and to power the control electronics.

  • Overview of MPPT algorithm modelling

    Debasish Dutta08/26/2015 at 07:29 0 comments

    Panel model consists of a simple step-wise linear model of a solar panel.See the above figure.

    1. Constant Current : up to 18 volts

    2. Constant Power : between 18 and 19 volts

    3. Power decline linearly to zero : between 19 and 21 volts

    4. Zero Current and Power : above 21 volts

    In the spread sheet attached below there are 5 MPPT models.Here is some brief description on each.

    1. MPPT model 1 implements the logic flow chart as shown in above figure

    2. MPPT model 2 implements the same logic flow chart with a declining panel power.

    3. MPPT model 3 implements the algorithm used in the Arduino software. It is easy to adjust it for fixed or variable panel power and for various starting conditions.

    4. MPPT model 4 is the same as Model 3 except that it used “<=” rather than “<” for the power test.

    5. MPPT model 5 is the functionally the same as Model 4. It uses three branches on the power comparison to the previous iteration, which has the same result as the comparison in Model 4. The main difference is it uses the equivalent of the integer arithmetic used in the Arduino for calculation of PWM duty cycles.

    Models 1 to 3 all exhibit similar characteristics, as follows:

    They all converge satisfactorily when given a high PWM starting point (above the MPP) or a lower one with a derived voltage less than the maximum cut-off voltage of the panel (in the model, 21 V).

    None of them work at all when given a low PWM starting point with a derived voltage above the maximum cut-off voltage.

    The MPPT model 4 corrects this last problem by constantly increasing the PWM (ie decreasing the derived voltage) in the case of equal (ie zero) power. It will always find the MPP of the panel model no matter what starting point is used. It may take more steps than provided in the examples, but it always converges.

    MPPT model 4 also sweeps the total maximum power area.

    To clarify this: Models 1 to 3 when converged all oscillate at the top or bottom edge of the MPP area, depending on whether they approached it from above or below.

    It seems desirable for the tracking to sweep the whole MPP area, irrespective of which direction the approach came. This would better deal with cases where the power curve had local flat spots for some reason. Model 4 does this.

    MPPT Model 5 provides a tool for exploring the effect of integer arithmetic on the PWM calculations and the resultant voltages and currents.

    Integer arithmetic in PWM calculations :

    At the hardware level, the current software uses Timer1 to produce the PWM signal at a 20 microsecond period.20 microseconds is 320 clock cycles of the Arduino clock (which is 16 MHz, ie with a period of 62.5 ns).Because the Timer1 library uses the “Phase and Frequency correct” PWM mode of Timer1, which counts both up and down, the setting of the TOP level (which defines the 20 microsecond period) is 160. The PWM duty can be changed in units of 2 clock cycles, or 125 ns.The integer calculation of PWM runs like this (using the current software):The MPPT code uses a 16 bit integer variable “pwm” to manage the duty cycle. It runs from 0 to 100 to represent 0 to 100% duty cycle, and can be stepped up or down by 1 unit (ie 1%) in each pass through the MPPT algorithm. The Timer1 library accepts PWM duty parameter in the form of a 16 bit integer variable which runs between 0 and 1023 to represent duty cycle as a fraction of 1024.

    I will use an example to illustrate how the calculations run.

    As an example we start with a desired PWM duty cycle of 70%, that is the integer “pwm” has a value of 70. To convert this to an integer between 0 and 1023 to pass to the Timer1 library, the software multiplies pwm (70) by 1023 (giving 71610.The MPPT code then divides this number by 100 giving 716, which it passes to the Timer1 library. Note that 716 / 1024 = 0.6992188..., which is a small amount less than the 70% we started out with.

    Note that even if we had multiplied the original 70 by 1024,...

    Read more »

  • Quarter Final Video

    Debasish Dutta08/15/2015 at 19:43 0 comments

  • Keith Presentation

    Debasish Dutta08/13/2015 at 12:30 0 comments

    keith.hungerford ( team member ) from Australia, who is one of the major contributor to this project.He has experimented a lot on this project.After my request he made this nice video explaining the efficiency,losses at various load,how DCM will take care at low load condition, about the MPPT v4 controller and writing of a new Arduino TimerOne library to handle our requirement.

    These are the loss analysis curves at different load condition.

    At 100 Watt :

    At 80 Watt :

    At 1 watt :

    In the 100% ( 100W ) graph, the optimum PWM period is 14 microseconds, at which period the decrease in the core loss is balanced by the increase in the switching and capacitive drive loss. When Keith checked, he found that the capacitive drive losses are so nearly equal to the switching losses that the curves fully overlap and you cannot see the capacitive loss curve. It is more clear at 80% ( 80W ) load where both curves are visible.

    As the load decreases, the resistive losses decrease and the relative influence of these period-dependent losses increases, but the pattern remains the same. In the MOSFETS, the importance of the switching losses decreases with decreasing load, since there is less current flowing and therefore a reduced amount of charge to be absorbed, even though the voltage excursion is unchanged. The capacitive losses come to dominate. Because the switching losses are less, the optimum PWM period decreases with decreasing load. At 10% load it is down to 11 microseconds.

    However the difference between the total loss at 11 microseconds and 14 microseconds is only 5% of the loss, so a single PWM period of around 14 microseconds is quite efficient SO LONG AS THE CONTROLLER IS IN CCM.

    Somewhere below the 10 % load point, but above the 5% load point, the controller goes into DCM. That is, there is not enough current flowing out of the panel to make the current in the inductor always flow in the same direction.

    His design assumption in this spreadsheet is that the controller algorithms explicitly support DCM. That is, they switch off Q3 at the time that the current would start flowing "backwards". So now, in DCM, the controller has 3 phases within the PWM period. There is the phase when current flows from the panel via Q2 through the inductor, and increases. there is the phase when current flows from Earth via Q3 through the inductor, and decrease. Then there is the Null phase when no current flows through the inductor.

    This Null phase is a good one as far as losses in the inductor and MOSFETs are concerned - there is no current and so no loss. However C1 is receiving all of the current from the panels, and C2 is delivering all of the current to the battery or load. This creates extra voltage ripple at the panels, and at the battery/load.

    So long as the voltage ripple at the panels and battery/load is within reasonable limits, in DCM it is better to have a much longer PWM period. Hence the appearance of very long PWM periods at very low load levels. The length of the PWM period is mainly limited by the voltage ripple tolerable at the battery, and the reduction in efficiency of the panel caused by the ripple there.

  • Finished the Soldering

    Debasish Dutta08/12/2015 at 03:22 2 comments

    Purchased all the missing components and started to solder it on PCB.After few hours of work, everything is soldered.I have tested auxiliary power circuitry,everything works fine.The next task is to test the charging circuit.I will update it soon.

  • Soldering the Components on PCB

    Debasish Dutta08/12/2015 at 03:09 0 comments

    Today I soldered most of the components on the new PCB.But few components are not available in my stock.So I can't solder them.I will solder the remaining components after buying it from my local shop.

    The following components are missing

    1.Fuse Holder

    2.TVS Diodes

    3.5.1V Zener Diode

    4.USB Port

  • Improvement in LCD Display Function

    Debasish Dutta08/11/2015 at 15:57 0 comments

    The LCD display functionality is improved.The above video shows the simulation to test the modified software.

    These are the improvements

    1. Dynamic battery status in battery icon.Earlier it was always showing about half full .Now it changes according to the battery SOC, just like in cell phone.

    2. Removing the long if else statement for displaying the battery SOC. Now used a math function to do the job.

    3. Adding a spinner icon to show the charger is running.It stops when program stuck up.

    Code before Modification :

    void lcd_display()
      back_light_pin_State = digitalRead(BACK_LIGHT_PIN);
      if (back_light_pin_State == HIGH)
        time = millis();                        // If any of the buttons are pressed, save the time in millis to "time"
     lcd.setCursor(0, 0);
     lcd.setCursor(4, 0);
     lcd.setCursor(0, 1);
     lcd.setCursor(0, 2);
     lcd.setCursor(0, 3);
     lcd.print("W "); 
     lcd.setCursor(8, 0);
     lcd.setCursor(12, 0);
     lcd.setCursor(8, 1);
     if (charger_state == on) 
     else if (charger_state == off)
     else if (charger_state == bulk)
     else if (charger_state == bat_float)
     //--------------------Battery State Of Charge ---------------
     if ( bat_volts >= 12.7)
     lcd.print( "100%");
     else if (bat_volts >= 12.5 && bat_volts < 12.7)
     lcd.print( "90%");
     else if (bat_volts >= 12.42 && bat_volts < 12.5)
     lcd.print( "80%");
     else if (bat_volts >= 12.32 && bat_volts < 12.42)
     lcd.print( "70%");
     else if (bat_volts >= 12.2 && bat_volts < 12.32)
     lcd.print( "60%");
     else if (bat_volts >= 12.06 && bat_volts < 12.2)
     lcd.print( "50%");
     else if (bat_volts >= 11.90 && bat_volts < 12.06)
     lcd.print( "40%");
     else if (bat_volts >= 11.75 && bat_volts < 11.90)
     lcd.print( "30%");
     else if (bat_volts >= 11.58 && bat_volts < 11.75)
     lcd.print( "20%");
     else if (bat_volts >= 11.31 && bat_volts < 11.58)
     lcd.print( "10%");
     else if (bat_volts < 11.3)
     lcd.print( "0%");
    //------------------Duty Cycle-----------------------------------------
     //------------------------Load Status-----------------------------------
     if (load_status == 1)
     backLight_timer();                      // call the backlight timer function in every loop 
    void backLight_timer(){
      if((millis() - time) <= 15000) // if it's been less than the 15 secs, turn the backlight on
          lcd.backlight();           // finish with backlight on  
          lcd.noBacklight();         // if it's been more than 15 secs, turn the backlight off

    Code After Modification :

    void lcd_display()
      static bool current_backlight_state = -1;
      back_light_pin_State = digitalRead(BACK_LIGHT_PIN);
      if (current_backlight_state != back_light_pin_State) {
        current_backlight_state = back_light_pin_State;
        if (back_light_pin_State...
    Read more »

  • PCB Arrived

    Debasish Dutta08/11/2015 at 15:27 0 comments

    On 4th August 2015, I received the PCB from fab house.It is manufactured locally at PCB Power.The board are looking really nice.The size of the board is 12.5mm x 10mm.

    This is 3D out look of the board after soldering the components.

View all 14 project logs

View all instructions

Enjoy this project?



Shane wrote 01/10/2017 at 01:09 point

I am about to embark on a similar project but will be using an XRP7704 Buck controller.  This chip has an I2C interface to talk to an Arduino, and 4-phase conversion for reduced input and output ripple currents.  For drivers, I will use the ISL99135b which has level shift and 35A half-bridge drivers in one package.  The Arduino will not only continuously "hunt" for MPPT, but also monitor battery health for display.

  I suspect that a reasonably constant current from the PVs is necessary to maximise power.  Alternatively, a large capacitor connected to the panel, but then, inrush current control may become necessary.  If the average current is at the MPPT, the actual panel voltage will swing substantially above and below that point.

  Are you sure? yes | no

Nicolás Rodríguez T wrote 08/11/2016 at 21:54 point

 Mr. Dutta,  after many hours trying to compile the software without success I've decided to stop it, fortunately I don't spend money. Unless you show that this project works, it's a fake!. In another web site you and your project has been  hardly criticized by the same reason. Apparently, no body could be able to run it satisfactorily.  End of the story.

  Are you sure? yes | no

tom.starwalker wrote 07/23/2016 at 10:37 point

So if I want to customize this for Li-ion batteries rated at 24V/25A, I'll just change the parameters in the code made for Arduino regarding voltage rating? Do I need stronger MOSFET's too?

  Are you sure? yes | no

LJCIRCUITS.COM PCB wrote 05/07/2016 at 05:41 point

Hi Debasish, 

Do you need BARE PCB outsourced manufacturing for your project?

Thanks for sharing your time.

T. Tan


  Are you sure? yes | no

guy caluwaerts wrote 04/27/2016 at 19:46 point

meanwhile I started with a prototype board to built the controller. It's gone be the 10A version.

I have some questions about the coils.  In the description and also on the drawings 33 micro H is  indicated. When I see the component list, there are other values (135 µH for 5A, 45 µH for the 10 version.. Is this correct ? I will not make the coil myself but order it.

  Are you sure? yes | no

guy caluwaerts wrote 02/23/2016 at 10:27 point

I'm interested in your project.  I'm making a solar tracker for my camper with a  solar panel of 80 Watt. So I think I have to go for the 8A version. Where can I order the PCB or see the latest drawing of this version ?

  Are you sure? yes | no

phbo0303 wrote 12/16/2015 at 10:00 point


I am interested in your project! I want to know basic question. Why connected in parallel R2 and C8??? I am beginner of electric circuit. Can you tell me the reason??

  Are you sure? yes | no

bandi94 wrote 12/18/2015 at 08:05 point

R1 and R2 are in series and it's called voltage divider. The Arduino can't take on the input more than 5V so R1 and R2 are dividing solar panel voltage down to 0-5V for the arduino. C8 is a filtering capacitor to filter out any noise so arduino can measure the voltage without error. 

  Are you sure? yes | no

phbo0303 wrote 12/21/2015 at 01:49 point

Thank you for your reply! It was good for me!

  Are you sure? yes | no

Leon Hiemstra wrote 12/07/2015 at 03:53 point

Hi, Great project! Maybe a few things I don't understand..

While running, if someone suddenly disconnects the solarpanel, the current path will go reverse, even worse: the switching of Q3 could cause the circuit running in boost mode and causing high voltage on the drain of Q3.. perhaps even damage it. How to protect it? 

1 solution might be to detect low solar current/voltage and immediately stop switching Q3 (add a freewheeling diode in parallel). Then the buck converter is falling back to non-synchronous mode and not able to boost up the voltage from the battery.

Secondly, if Q3 is not switching, the bootstrap capacitor for the IR2104 driver does not charge up, thus a separate Vcc (24V) might be necessary??

A document of interest is:

  Are you sure? yes | no

bandi94 wrote 12/09/2015 at 13:07 point

Bootstrap capacitor is failing in every possible way, i already noticed Deba about it but i don't know if he is going to do something about it. IR2104 is a load driver and not a battery charger, When you drive a load and Q2 switches off on Source pin you will have 0V so the voltage potential of the bootstrap cap. is input voltage - 0V = input voltage so that mean's it can double the voltage on the drain pin, but if you put a battery on the load side when Q2 is off you have battery voltage on Source pin and not 0V so potential = input-battery that means  18V(solarV) - 12(batteryV) = 6V on the bootstrap cap and it's not even near the minimum 8Vgs that Q2 will generate a lot of heat.  The right way to do it is a voltage doubler aka Dickson charge pump, or galvanic isolated power supply in range of 10-15V (this can be a battery,a simple 12V screwdriver charger,a small 12V transformer that can supply 10-15mA,etc..), and a push-pull gate driver(made with transistors) or an opto-isolated gate driver (TLP250). 

  Are you sure? yes | no

Lars Sorensen wrote 10/30/2015 at 21:05 point

Hi guys. How are you and the project (v4) going?

Is it still ongoing are you taking a break?

  Are you sure? yes | no

Debasish Dutta wrote 11/04/2015 at 09:44 point

Hello Lars,

We are taking some time break due to busy on other work.Stay in touch we will start it again.

  Are you sure? yes | no

Evan Allen wrote 10/23/2015 at 14:58 point

Would spec-ing up some of the components allow for things like 60Voc panels, or is this limited to lower voltage panels by some specific design choices?

  Are you sure? yes | no

bandi94 wrote 10/25/2015 at 16:58 point

It is possible to make it work with 60Voc but there is no logic to convert 60V panels to 12V battery. You would need 4x12V battery to work at 48V battery bank. At 48V battery bank you would have some problems with IR2104 max Vcc 25V so the mosfet driver needs a voltage regulator, heavy duty Mosfet's that can handle the 60V drain-source voltage, and so on.  Now converting 60V to 12V will work with replacing the mosfets (IRFZ44N max is 55V) capacitors etc.. but you will have serious problems on the inductor, you would reduce the voltage from 60V to 12V that is 5 times the input and the inductor will work very hard so you would need a very big core with very thick wire to handle the generated heat. Anyway until they don't fix the Q3 shorting out the battery(and i am very intrested how they will fix it from the moment that sync. buck is not made for battery charging) the charger doesn't really work in this configuration, you would need to re-design it with a standard async buck replacing Q3 with a schottky diode.

  Are you sure? yes | no

Leon Hiemstra wrote 12/10/2015 at 06:07 point

Replacing Q3 with schottky diode would decrease the efficiency at higher power levels. Is it an idea to enable Q3 switching only when solar current is higher than ..Ampere? And just stay with the schottky diode at low currents. So basically switching in between synchronous and non-synchronous buck

  Are you sure? yes | no

bandi94 wrote 12/11/2015 at 08:36 point

Yes replacing it with a diode would decrease the efficiency, but the current status of the charger does not handle Q3 very well and the loss is even higher than with a diode. If Q3 stays open even few millis longer it will short the battery losing a lot of power on Q3. I asked somebody who build it and told me that he got 3 Q3's burnt out and he need a fan to cool it down even with a big heatsink. A good schottky diode drops about 0.4V, when i charged a 56Ah battery at 4A Q1 and the schottky diode had a small heatsink and no problem with heating up. So i am just curious which is better ? Q3 with a big heatsink and a fan, or a schotty which needs a very small heatsink and does not even heat-up ?   I agree that you loss power but to use Q3 you need a complex system to drive it and not just a "homemade" circuit with a poor IR2104. 

  Are you sure? yes | no

bamideleelusade wrote 10/09/2015 at 15:49 point

Good day everyone, thank you for this project Mr Debasish Dutta and thanks Mr keith.hungerford for the mod. i downloaded the code for version 3.1 as i go through it i noticed that in the code the function read_sensor_data() is missing some things like all the readings were not averaged. Division by the number of time it was sampled, please some one should please look in to that and correct my misconception.

I try compiling the code but i got this error message from the IDE  'lcd' was not declared in this scope  this code was pointed to lcd.print(spinner_chars[cspinner%sizeof(spinner_chars)]); i will need an urgent help from any body thank you.

  Are you sure? yes | no

Debasish Dutta wrote 10/09/2015 at 16:22 point

You have to download the correct liquid crystal library.

  Are you sure? yes | no

morozaw wrote 10/07/2015 at 17:46 point

Hello Debasish and everybody!

Really nice project!
I have few questions about this project!
I am also working with MPPT design, but my own - little similar to this.

Did You or anybody have problems with charging the bootstrap capacitor?
Did You or anybody used blocking diode at output of dc converter?
is it possible that, the bootstrap works pretty well with output
voltage at VS of mosfet driver? There should be problem if Vin < 24V
in my opinion!
Did You have or anybody problems with reverse current from battery, through main inductor, via low side mosfet to GND?

Waiting for Yours reply!
Greetings from Poland!

  Are you sure? yes | no

Debasish Dutta wrote 10/09/2015 at 16:26 point

Hi morozaw,

Thank you for your appreciation.

We are facing the reverse current from battery through inductor,via the low side MOSFET to GND. Still now the problem is not solved.If you have a solution please help us.

  Are you sure? yes | no

smiley8088 wrote 08/24/2015 at 14:21 point

Congratulations for making it into the semifinals! Good luck for the next stage.

  Are you sure? yes | no

Debasish Dutta wrote 08/24/2015 at 17:49 point

Thank you so much.

  Are you sure? yes | no

bandi94 wrote 08/20/2015 at 09:57 point

I asked some opinions on a forum from my country about the circuit and i got some feedback maybe your intrested to improve the circuit. The pump cap from the IR2104 should be increased from 100nF to something around 470nF ( considering that he need to drive two Mosfets insead of one). The Q3 will short when the IR2104 is not powered and gived the shutdown function. I was advised to use a simple async buck because the low voltage difference ( PV 17V battery 14V the power loss is significantly low about 2.5W difference at 10Amp, and will not cause headache of shorting out the battery) , anyway if you are looking for maximum efficiency / you want to be able to run 24V PV would not be your case. No mater what you will do Q3 will be under stress,simple sync buck converters are not made to drive a capacitive load ( when you don't drive capacitive load like a battery there is no current than can flow back to short Q3) but if you hook up a battery no-mater how less that Q3 is opened the battery is simply shorted ( for a smaller time or longer achieving a small time that doesn't burn Q3 out doesn't mean the batter is not shorted, i can guess that Q3 is building up some heat. How high end MPPT charger use sync buck well they must have some fancy way doing it hardware or software driven by a special designed uC. Driving an N-Mosfet on high side would require his Gate to be atleast 8-10V more positive that the PV voltage, driving the IR2104 from the 12V battery ( lets say 12.3V if we take a discharged battery) the bootstrap pump will double that so we will have 12.3*2 = 24.6 lets make it 25V if the PV voltage is 17V thats 25-17 = 8V only the very low end of the requirement, it works but if the battery is less than 12.3 or the PV voltage is bigger than 17V those Mosfets may not be able to fully turn on , at least Q1 with D1 dropping 0.7V that Mosfet will get only about +7.2V below the 8V limit. IR2104 should be powered at aprx. 15V like Tim Nolan did ( powered from the PV maybe there should be added a 20V zener to protect it if the battery would be disconnected and the PV voltage rise above 20V, in the datasheet dosen't realy says that the 20V limit is the uC's max power or is duet most mosfets Vgs is 20V, if the uC could handle more than 20V the software could fast stop the uC when it detects that the PV voltage is more than 19.5V si the mosfets are protected) but if you power it from the Solar Panel you will get Q3 shorted duet when IR2104 is not powered to hold Q3 closed Q3 may start conduct and short out . As i see the things i think i will attempt to build it with an async buck and IR2104 powered from the Solar Panel input ( in async mode you can't short the battery even if the IR2104 is not operation, R5 will discharge Q1 the battery is sealed). Maybe the IR2104 should be powered in the middle of two diodes one from the Solar Panel one from the battery somthing like this , daytime Solar Panel will have more potential so it will power IR2104 at 15V+ for an optimal Mosfet drive, night time the battery will have bigger potential so it will power the IR2104 this way it will be always powered hopefully the switch is fast enough to don't short Q3 ( the downtime of IR2104 durring the power supply switch should be low enough to IR2104 power up again and hold Q3 switched off).

D3 UF4007 reaction time is greater than the mosfets internal diode so it should be removed.

  Are you sure? yes | no

case06 wrote 08/13/2015 at 05:12 point

wetherall i like much your prototype-board designs, this new pcb looks great. Do you plan to sell it ?

  Are you sure? yes | no

Debasish Dutta wrote 08/13/2015 at 05:18 point


Till now not planned as some issues are present. After solving everything, I will think for it.

  Are you sure? yes | no

Lars Sorensen wrote 08/03/2015 at 19:28 point

So... How is it going with the project?

I found these really cool power supplys for USB, that might be cool for the project:

  Are you sure? yes | no

Debasish Dutta wrote 07/13/2015 at 10:04 point

Thank you to all of you for your valuable support and feedbacks.

I  won a DSlogic analyzer  for using Atmel parts in my 2015 Hackaday Prize entry.

  Are you sure? yes | no

K.C. Lee wrote 07/13/2015 at 12:35 point

Congrats!  You've earned it!

  Are you sure? yes | no

Debasish Dutta wrote 07/13/2015 at 12:38 point

Thanks and Congrats to you too :)

  Are you sure? yes | no

Petar wrote 07/13/2015 at 12:57 point


  Are you sure? yes | no

Debasish Dutta wrote 07/15/2015 at 09:32 point

Thank You 

  Are you sure? yes | no

antscran wrote 07/10/2015 at 14:58 point

Just joined the site and was reading some of the posts on here, I have built an MPPT tracker on the Texas Instruments C2000 platform back in January 2014.  It used a synchronous buck converter and also in a interleaved design to reduce the peak current, although it was only used on a 10W panel it could be easily scaled.

I am working on a new design which can be used with any microcontroller and currently have code for MSP430, working on Tiva C and will also bring over to the Arduino when I have time.  No battery charger circuit yet but will add this functionality as well.

The 4 part tutorial can be found here as well as some videos demonstrating the P&O algorithm working:

Shamlessly advertising my site :-)

  Are you sure? yes | no

Debasish Dutta wrote 07/11/2015 at 02:53 point

Hi friend ,

No problem.I have already seen your tutorial.Its really nice.

If you have any suggestions please comments on my project.

  Are you sure? yes | no

aplavins wrote 07/02/2015 at 01:05 point

There are a few things about the code that I found issue with, I'm trying to fix them without messing up the rest. Please let me know if these issues make sense.

The variable pwm is a number between 0-100 whichis then divided by 100 and multiplied with 1024. This means that every % step we jump about 10 intergers. We could use all 1024 steps and have better duty cycle accuracy and therefore better voltage regulation.

When the sol watts is low, the charger goes into full on, which is the opposite of what it should do. We would want to use MPPT in this instance to get as much out of the panel as possible.

The decision of which state to be in relies on sol watts, I think it should be dependent on voltage only. We can use sol watts in the tracking algorithm and for display and data collection purposes but not here.

  Are you sure? yes | no

keith.hungerford wrote 07/02/2015 at 13:38 point

Hi Adam, a few comments on your suggestions. I don't have answers, but thoughts on some lines of inquiry to get the best system. 

I agree the use of 0 - 100 in units of 1 for PWM, then converting to an integer between 0 and 1024 is clumsy. It would be more logical just to set the number to its final binary value. However what is the best step size, ie 10 or 1 or whatever, is not so clear. I think there are several issues to think about here. Smaller step size will lead to slower convergence on the "best" value, and perhaps a more accurate setting. On the other hand, the quantisation of current and voltage measurements may have a role as well. Further, the environment may be unstable - that is, there may be variable illumination on the panels. Sometimes there will be steady, slowly changing illumination (eg on a clear day when the sun is at an angle which changes hour by hour). At other times there may be patchy clouds which come and go between the sun and the panels. Or the panels may be affected by shadowing from trees which are moving because of wind. Just how complicated we should be, can be, I don't know. There may be some good references out there (someone may have done their PhD on MPPT algorithms?) 

So maybe there is a PWM quantisation "sweet spot" that gives us good performance across the whole range of conditions. Some analysis and modelling might help.

Another thing has become clear to me working on sizing the inductor and capacitors, is that there is a substantial ripple current in capacitor C1, some of which is seen at the panel as voltage and/or current excursion. Is there some way of getting value out of that ripple to direct the MPPT algorithm?

I agree it seems logical that the decision to start MPP tracking should depend on solar panel voltage. But it also should depend on battery state of charge and the load current - if the output requirement is much less than what the panel can produce, we don't need MPPT at that time, we need to control the output current so that the voltage at the battery is the appropriate value for Float or Boost charging. I have not checked back over the code but I think this is already in there. I THINK  the right behaviour is to reduce the PWM so that the panel current falls, panel power falls, until the current into the Battery + Load just matches the demand, to give us the desired Float or Boost charging voltage. This is a sort of tracking, but it is not maximum power point tracking.

I think it would be good to have a clear description of all the states, and the conditions that lead to transitions to and from each one.


  Are you sure? yes | no

aplavins wrote 07/02/2015 at 14:55 point

Thanks for the reply Keith,

I uploaded a new version of the code to my github. I need someone with the standard hardware to test it. See if it does it's job and maybe some info on how long it takes to find MPP. link is here:

The charger has 5 states:

no_battery: If the voltage is below 10V, the battery is either too dead to charge or not connected. Charger is off, displays "noBat".

sleep: If the panel voltage drops below 15V, it's probably night. Turn the charger off to prevent current leaking back into the panel. (I think we are all still using Q1 right?)

bulk: If the panel voltage is above 15V and battery voltage is above 10 but below 13.5, go into bulk charging. begin MPPT algorithm. duty cycle starts at 50% (512) and changes by 1 each time through the loop. First direction is positive (more loading of the panel). MOSFET driver is enabled. sol watts begins at 0, on the second loop, it will have a value and on the third loop that value will be stored in old_sol_watts. Then begins the tracking, if the new value of sol_watts is less than the previous one, change direction of travel. In case of my panels MPP is at around 44% so we began at 50% and went up so in my case we would switch direction here. At this point it loops until it finds (and just passes) the MPP and then switches direction again, forever.

float: if the battery voltage rises above 13.5, we stop MPPT and begin PWM on the ShutDown pin. At 13.5 the charger is on 99.9% and is enabled. At 13.6 charger is still at 99.9% but is disabled. voltage will hover at the threshold of 13.5-13.6.

error: If the battery voltage goes above 15V, something is wrong. The battery will be over-charged. Turn off charger. display "error"

The % of pwm is now derived from pulseWdith(0-1024) instead of the other way around. 

The switch case happens in a seperate "if" statement and uses only voltage to decide which state to be in

Unless the battery is full, we are always using MPPT now. This applies to adding additional loads as well.

My CC has been working unsupervised for about 2 weeks now on a similar version of this code. Only difference is the way PWM is sent to the driver and the MPPT algorithm.

If you find any issues with the code, put them in "issues" on github and I'll try to correct them. Unfortunately it's tough to test when you don't have the same hardware. Anyone in Ontario, Canada that has it?

  Are you sure? yes | no

keith.hungerford wrote 07/03/2015 at 06:17 point

Hi Adam, this is all clear to me except  for: "float: if the battery voltage rises above 13.5, we stop MPPT and begin
PWM on the ShutDown pin. At 13.5 the charger is on 99.9% and is enabled. At 13.6 charger is still at 99.9% but is disabled. voltage will hover at the threshold of 13.5-13.6."

Can you please explain a bit more. Is it correct that when you "begin PWM on the ShutDown pin" that you hold the IN pin at 1 (High) and that the duty cycle on the SD pin is reversed? - it it has a short period of 0 (when HO will go high) and a long period of 1 (when HO will go low). Maybe the "enabled" and "disabled" relates to the IN pin? 

I guess that if the 0.1% PWM is not sufficient to hold the battey at 13.5 volts, then it will go down a bit and the charger will revert to MPPT briefly, so there will be an alternation between around 13.4 and 13.5 to 13.6. Is that correct?

Thanks, Keith

  Are you sure? yes | no

Petar wrote 07/03/2015 at 08:42 point

Hi guys! I found something interesting. It's for Microchip but is useful:

  Are you sure? yes | no

aplavins wrote 07/03/2015 at 16:13 point

Hi Keith,

The pwm of 99.9% is always on the IN pin while in float. The SD pin is set high (on) when the voltage is at 13.5 and low (off) when at 13.6. If the voltage drops below 13.5, the charger will go back into bulk and MPPT will resume. It's like having a PWM charge controller switching from full on to open circuit, except that full on is 99.9% for the charge pump.

This is in contrast to the previous method which was to reduce the pwm on the IN pin lower and lower to prevent the voltage going too high without changing the SD pin state. The problem was that at very low pwm values, the inductor would saturate and Q3 would be shorting the battery and fail.

Now we are just setting the whole system to open circuit when voltage reaches 13.6. In the future I want to add a diversion load feature with it's own control MOSFET similar to the LOAD MOSFET. When the charger goes into float, it would turn on the diversion load to continue to utilize the power coming from the panel(s) even when the battery has been charged. The load would be best matched to ~90% of the output of the panel(s). It could be used to pump water from a well or heat/cool a space. I think this would be a useful feature in V4.

  Are you sure? yes | no

keith.hungerford wrote 07/04/2015 at 05:10 point

Hi Adam, thank you for the clarification. I believe that now a) I understand what your software is doing and b) I have corrected my misinterpretation of the IR2104 datasheet (for some reason I had the logic of the SD_bar pin upside down). 

I think that even with the new version of software you have written, there is still an opportunity to  have Q3 burnout. This will happen if the battery voltage sits and stays at 13.5 V for an extended time. At that voltage, the IN pin will be running at 1 on, 1023 off which means that Q3 will be 99.9% ON and the short OFF periods will not be sufficient to stop the reverse current flow. Therefore the reverse current flow will steadily increase, cycle after cycle, until something breaks.

You previously said "begin PWM on the ShutDown pin" and I think that is exactly what you need to do. If you hold the IN pin at a steady 1, and do PWM on the SD_bar pin, then when SD_bar is 1, HO is high making Q1 and Q2 ON, and LO is low making Q3 OFF, In the other part of the PWM cycle, SD_bar is 1, so both HO and LO are low, so Q1, Q2 and Q3 are all OFF (Q1 a little bit delayed by the RC circuit controlling its gate).

With this configuration, the converter is operating Asynchronously and in Discontinuous Current Mode (DCM). This mode is appropriate for all current levels below the threshold where if Q3 is left ON the current flows backwards through the inductor. I have been studying this mode in relation to the V4 efficiency modelling, and will show the results in the not too distant future.

I will respond to your suggestion about a "diversion load" a bit later and probably in the V4 development log which is where I think it will be most easily found. by others.

I think it is really good to have found an explicit reason for the Q3 burnout problem, so this is really important progress.

Thanks again, Keith

  Are you sure? yes | no

keith.hungerford wrote 07/07/2015 at 13:48 point

Hmm. Several things. I have made a local copy of your code and made a number of suggested adjustments to it. Most of them are just to do with editing comments. However there are a couple of "real" suggestions as well. I am not sure what is the best way of putting this into "the system". Currently it is in Word format with the changes highlighted with Track Changes. 

In addition I have a few issues I have been unable to resolve. 

a) polarity of PWM. My understanding is that if you set pulseWidth to (say) 102 (being about 10% of 1024) then you will get a signal out which spends 10% of its time as a 1 and 90% of its time as a 0. This seems to be the reverse of what you do in the code for case Float in the switch (charger_state) routine, where you set pulseWidth to 1022 which gives you close to 100% 1 (ie direct connection of solar panels to battery). 

b) granularity of PWM. Even though the pulseWidth parameter taken by the Timer1.pwm function is a 10-bit value, it does not give a 1024 step granularity to the actual PWM, because it cannot (as I understand it). This is because a 20 microsecond period requires just 320 cycles at 16 MHz, which is the frequency of the Arduino clock. There is a function that translates the pulseWidth parameter (10 bit) into the counter value that causes the PWM transitions. I think it is in TimerOne.cpp in the function setPeriod; however I find it a bit opaque. But anyway I reckon that changing the pulseWidth parameter in units of 1 will result in no change in actual PWM ratio for 2 steps and then a change on the 3rd step (or in some cases the 4th step), because the 1024 values of pulseWidth have to map onto 320 values of the counter that determines the PWM transitions. 

c) Minimum PWM to keep the IR2104 charge pump going: To keep the charge pump capacitor C7 giving around 10 V to the IR2104 VB pin, we need no less than a certain amount of time with HO at 1 and 0. I have not tried to work it out, but it must be at least a few 10s of nanoseconds. Now HO goes High about 700 ns after IN goes High, and goes Low about 200 ns after IN goes Low. So the pulse width on HO is about 500 ns shorter than on IN. There is a bit of variability in this, but I think we need a minimum pulse of about 800 nanoseconds on the IN pin, which would generate a pulse of 300 ns on the HO pin, with a further variable from the IRFZ44N which has a nominal rise time of 60 ns and a fall time of 45 ns, reducing our 300 ns by another 15. To get a minimum pulse of 800 ns we need to set pulseWidth no higher than 983 and no lower than 41. These should mean PWM counter settings of 307 and 13 and thus actual pulse widths of  812.5 ns on IR2104 pin IN. The next step down would be 750 ns. If this produces too high a charge rate in "Float" state, it will be looked after by the cycling between enable_charger and disable_charger. A further option, if we need to reduce the actual duty cycle further, is to increase the PWM period, as Debasish did in his original code.

d) DCM mode is a challenge. With the current hardware connections, it is not possible to do what I suggested in my previous post, that is to perform PWM on the SD pin. Reasons for this include the fact that currently the SD pin is connected to Arduino pin D8, which is not equipped to do PWM. However Arduino pin D10 is currently unused, and is equipped for PWM from Timer1, the same timer that runs the PWM on pin D9 connected to IN. Now this is where I get a bit unsure since there is a lot of complexity, some of it hidden and hard to find and understand. Timer1 has 2 counters, one of which is used to set the PWM period (ie the 20 microseconds that takes 320 clock cycles). The other one is used for performing PWM, currently only on pin D9 (IN). I think that if we want to do PWM on the SD pin (so as to implement Discontinuous Current Mode and reduce losses in the inductor, FETs and capacitors) then we just need to issue a new command similar to "Timer1.pwm(PWM_PIN, pulseWidth, 20), but for the SD pin. With some suitable logic to use this at the right time, of course.
Requests please:

Suggestion of how to provide my comments/suggestions on the code

Comments on the above 4 issues a) to d).

Thanks, Keith

  Are you sure? yes | no

Debasish Dutta wrote 06/22/2015 at 15:14 point

Hi all,

Hackaday starts their second round of community voting for 2015 Hackaday Prize , and it’s time to select the community choice for the project Most Likely to "Save The Planet".

I made this project to harvest green energy and  help people to use clean energy.If we can use solar energy we can reduce the environmental pollution to a great extent.

I request you to vote for me,if you think it is useful.Your vote is valuable for me.


You can vote  by click on the link

here’s a video tutorial on how to vote: 

  Are you sure? yes | no

keith.hungerford wrote 06/23/2015 at 12:39 point

Well I voted, went through all my 50 votes, but this Arduino MPPT project did not come up, so I could not vote for it. 

But I discovered a couple of other interesting projects along the way! Keith

  Are you sure? yes | no

Debasish Dutta wrote 06/23/2015 at 15:01 point

No problem :)

Anyway you discovered few interesting project is good news.Thanks

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates