Close

Troubleshooting of Ver-3

A project log for ARDUINO MPPT SOLAR CHARGE CONTROLLER

An Arduino based Solar MPPT charge controller.

open-green-energyOpen Green Energy 06/08/2015 at 14:067 Comments

Problem :

1. During my prototyping, I have faced a critical issue.The issue was that when I connect the battery to the controller,the connection between the battery and the switching ( buck converter ) become very hot and then MOSFET Q3 burn out. It was due to shorting of MOSFET-Q3. So Current flows from Battery -MOSFET Q3- GND which is unexpected.

To solve this problem I have put it on comments section.After taking suggestions from all, keith.hungerford suggestions really works for me. So I have modified few things and tested it .


Rectifications / Changes :


As per Keith suggestions

Modification in MOSFET Driver Circuit :

1. With the existing circuit, if the panel voltage is zero then the IR2104 has no VCC input. This may make its behaviour unpredictable. As per data sheet, the driver VCC should be in between 10 and 20 Volts for "proper operation".

2. It means the driver will always be working, and so there is a positive control over the switching MOSFETs at all times.

3. The voltage from the solar panels has been specified as up to 25 volts, which is a bit more than needed to connect a standard 36 cell solar panel. The voltage doubler circuit that generates the Vb voltage for the driver will turn that into 50 volts, which in turn will put 25 volts onto the Source-Gate interface of both Q1 and Q2. The maximum rating of this interface is 20 volts, so either of these FETs may become unreliable with a high solar panel voltage of more than 20 volts.

4. Using the battery for Vcc of the driver means that Q1 and Q2 both only have Source-Gate voltages equal to the battery, which is comfortably within the 10 - 20 Volt range of these MOSFETs.

Changes :

Powering the MOSFET driver IR2104 from battery terminal ( 12V ) instead of solar panel ( earlier ).


Removing the MOSFET Q1 from the circuit for improving the efficiency

The MOSFET Q1 in the circuit is used for blocking the reverse power flow from battery to solar panel during night. It is noticed that in all the cases when Q1 is OFF, then Q2 is OFF as well. So Q1 is not actually doing anything useful. So we decide to remove it.Removing it would slightly improve the efficiency of the converter, and simplify the construction also.

Changes : Removing Q1 , D1 and R5 from the original circuit.

After few more test it is observed that without MOSFET Q1 current flow from battery to solar panel during night, due to conduction of body diode in mosfet (MOSFET is OFF ) .I am really sorry for modifying things repeatedly,but its a learning process for our version-4 design.I apologize for my mistakes.

Changes on 16/06/15 : Put back Q1 , D1 and R5 as in the original circuit.

The updated schematic is attached below.If anyone making this controller, make this changes and test it. If you have any suggestions, comments it.

MPPT Controller v-3 Schematic updated

2. Problem on LCD back light control :

In the software ,I implemented LCD back light control.When the user press a button,LCD back light should on for 15secs and then goes off. To do so I am monitoring the button status ,if it is pressed then lcd.backlight() is called and delay(15000) pauses for 15sec in other condition lcd.noBacklight() is called to implement no back light.

Though it works perfectly,but problem is that when the back light switch is pressed the program( charging algorithm ) pause for 15 seconds. During this time delay, the charging will continue without the program knowing that the voltage is rising because of waiting to complete the 15 seconds delay.

Problem rectified :

I modify my existing code with aplavins suggested code. It works for me.

Thank You aplavins for solving the problem.

Download the updated code.


Discussions

keith.hungerford wrote 09/03/2015 at 00:53 point

I think the key to the Q3 burnout problem may be in the start-up sequence.

First look at the original schematic. With battery only and no PWM, Vs is sitting at Vbb
(battery voltage, via the inductor). Vb is sitting at Vbb minus one
diode forward drop (probably 0 because there is no current).

My updated circuit is the same except there are 2 diodes in the path to Vb. Still OK I think.

When panel voltage exceeds battery voltage by some margin (we need to define
that more clearly, there is no margin in the current software) the  Arduino will raise SD and start PWM on IN.

The first part of the first PWM cycle, with 1 on IN, makes HO equal to Vb which is the
same as Vs which does nothing - does not turn on Q2 or Q1 because their
source voltages are Vbb (for Q2) and Vpp (for Q1) and higher than HO.

The second part of the first PWM cycle, with 0 on IN, makes LO equal to Vcc = Vbb and turns on Q3.
Current flows through the inductor from the battery to ground. The rate of current increase depends on Vbb and the
inductance; at 12 volts and 33 microHenries the rate is 12/33 = 0.36 Amps per microsecond.
At this time, Vs is close to ground and current  flows through D1 to charge capacitor C7 to about 11 volts.

At the end of the second part of the PWM cycle, LO goes to 0 and Q3 turns
off. For the dead band time of the IR2104, HO is still at Vs. Once the
dead band time finishes, then it will go to Vb.

In the  original circuit, the current from the inductor will now raise the
voltage at Vs, and (via C7) Vb, so HO will rise, When HO reaches Vpp
plus the threshold voltage of Q1 plus the forward drop of D1, Q1 will
turn on and the inductor current will flow into C1, and also into the
connected solar panel. This will limit the voltage rise at Vs of the
IR2104 to around 4 to 5 volts. I think all this happens during the dead
band time of the IR2104, which is about 0.5 microseconds, before HO
rises to Vb, There may be a voltage spike at Vs, Vb, Q2 gate, Q1 gate
due to slow turn-on of Q1. Subsequent PWM cycles may increase the charge
on C1, but eventually the PWM duty cycle should settle down and the
reverse current through the inductor will finish. If the original PWM
duty cycle is too low (ie Q3 is on too much of the time) the reverse
current through the inductor could build up to a level that destroys Q3,
before the MPPT logic for the PWM duty cycle has time to increase it
sufficiently.

With a staring duty cycle of 90%, Q3 will be on for 2 microseconds and Q2 will be on for 18 microseconds.
If the panel voltage is only marginally higher than the battery voltage, and if
the solar panel can absorb the reverse current, then the reverse
inductor current will rise by 0.7 amps every cycle of 20 microsecond, So
in 50 cycles (1 millisecond) the reverse current will be 50 * 0.7 = 35
amps - enough to destroy Q3.

Turning to the new circuit I have proposed to prevent back-flow from the battery to the
panel during night time, this problem is different.
With battery only and no PWM, Vs is sitting at Vbb (battery
voltage, via the inductor). Vb is sitting at Vbb minus two diode forward
drops (probably 0 because there is no current).
When  panel voltage exceeds battery voltage by some margin the sequence for
Q3 proceeds as above for the first part of the first PWM cycle. We end
up with a reverse current through the inductor, and C7 charged to about
11 volts. However the IR2104 driving Q1 now has 1 on its IN and SD pins,
so its HO will be sitting at Vb, ie at Vbb (battery voltage) minus 3
diode forward voltage drops. Since the Source of Q1 is at panel voltage
Vpp, which is marginally higher than Vbb, Q1 is turned OFF.

When Q3 turns off as a result of IN going to 0, voltage at the low end of C7
rises. The top end of C7 rises the same amount, lifting Vb of both
IR2104 drivers and turning on Q1. Thus the inductor current has a path
through Q2 body diode, Q1 turned on, to C1 and the panel, similar to the
original circuit.

The "solution" to this that I can see right now is to have the initial Q3 ON time as short as possible, so
as to get the charge pump capacitor C7 charged so it can raise Vb on
both drivers. I think we can do it with a defined margin of Vpp above
Vbb before PWM is started, and the shortest ON time for Q3 that we can
achieve - perhaps around 0.5 microseconds. We can make sure that the
reverse current only lasts a small number of PWM cycles, hopefully only 1.

There may be other options to consider.

  Are you sure? yes | no

Open Green Energy wrote 07/06/2015 at 15:58 point

Hi all,

By taking help from Ron Kuris ( https://github.com/rkuris) the software is improved a lot.These are some changes in the code.

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

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

2. Load Control : Changed the code to support having a different load control .The first algorithm (the default) will turn on the load when the battery is not fully discharged and there is no solar power( for street light ) . The second algorithm turns on the load when the battery is fully charged and there is solar power. You'd use that as a dump circuit (if you have something to do with excess power).

3.Removing all the delay functions used in the code.

4.Improved the LED indication function

5.Few changes in wifi data log function but still needs some improvement.We are working on it.

Attaching both earlier and modified code below.Please look in to it.

Earlier : http://www.instructables.com/files/orig/FE2/W4IU/IB4ADUH0/FE2W4IUIB4ADUH0.rar

Now: https://github.com/deba168/MPPT_Master/blob/master/MPPT_Code_ESP8266/MPPT_Code_ESP8266.ino

Ron also tested the code by using his bench power supply.Here is the video during his test.

Thanks 

Debasish

  Are you sure? yes | no

keith.hungerford wrote 06/12/2015 at 05:30 point

Can I ask a dumb question please? Where can I find the definition of the function delay() please?

  Are you sure? yes | no

Open Green Energy wrote 06/12/2015 at 07:48 point

Hope this link will helpful, where the arduino functions are elaborated.

http://urbanhonking.com/ideasfordozens/2009/05/18/an_tour_of_the_arduino_interna/

  Are you sure? yes | no

aplavins wrote 06/11/2015 at 19:16 point

Here's a sample code for backlight control

#define backLight 13          // pin-5 is used to control the LCD back light (set to 13 for testing)
#define buttonPin 2           // the pin number of the pushbutton pin




const long check = 15000;     // 15 seconds in milliseconds
long time = 0;                // variable to store time the button was pressed in millis
int buttonState = 0;          // variable for storing the button state
int loops = 0;                // variable to count the number of loops




void setup() {
  pinMode(backLight, OUTPUT);
  pinMode(buttonPin, INPUT);
  Serial.begin(9600);
}




void loop() {
  buttonState = digitalRead(buttonPin);                          // See if the button has been pressed
  if (buttonState == HIGH) time = millis();                      // If any of the buttons are pressed, save the time in millis to "time"
  backLight_timer();                                             // call the backlight timer function in every loop
  loops++;                                                       // increment "loops"
  Serial.print("# of loops:");
  Serial.println(loops);
  delay(1000);                                                   // wait
}




void backLight_timer(){
  if((millis() - time) <= check)digitalWrite(backLight, HIGH);  // if it's been less than the check time, turn the backlight on
  else digitalWrite(backLight, LOW);                             // if it's been more than the check time, turn the backlight off
}

sorry about the word wrap

  Are you sure? yes | no

Open Green Energy wrote 06/12/2015 at 00:15 point

Thank You aplavins.

  Are you sure? yes | no

keith.hungerford wrote 06/08/2015 at 14:25 point

Looks good. 

Keith

  Are you sure? yes | no