Project Logs

Collapse

• Still Alive

  Jonathan Bruneau • 08/21/2018 at 05:46 • 0 comments

  Despite it being over a year since my last project post, I'm still alive.

  Quite a few things have changed since my last post. I’ve had a major job change, a house change, and a +1 to the family. Needless to say, I haven't’ been able to do much on this project.

  This doesn’t mean that I’ve stopped working on it: au contraire! My pace might have slowed significantly, but I haven’t stalled.

  I’ve completely revamped the power supply. Primarily in function of the larger 9W solar panels you can now find on Adafruit, Sparkfun, and other sites. I’ve also changed ECAD tools, opting for CircuitStudio. I’ve always liked the schematic+layout integration Altium tools provide, and now I can have my cake without breaking the bank.

  In designing this latest supply, I’ve made a few notable changes which made the board significantly larger and more expensive.
  

  These include:

  • 5A input and output support for larger solar panels.
  • 24V input and output support for larger solar panels and battery banks.
  • FTDI header output for UART debugging.
  • Firmware controllable output voltage and output current limits.
  • Fun LEDs and much more!

  This seems counter to all my previous logs, and you’d be right in thinking so. The rational here is three fold:

  1. I don’t have nearly as much time to optimize the design.

  2. The basic set of components required to provide MPPT support is a fixed cost that is hard to further optimize (proof, the rest of this project’s logs).

  3. Addressing some of the shortcomings of the previous design requires additional costs, which are best amortized by pushing more power.

  The design worked out fairly well. Powering this entire endeavor is a PIC16F1773, with 6 comparators, 6 DACs, and 3 OpAmps (no typos). As configured, this SEPIC power supply offers cycle-by-cycle input under-voltage protection (UVLO), intput and output over-current protection (OCP), and output over-voltage protection (OVP).  The PIC is also setup to directly drive the FET with it's two beefy 100mA output drivers.  Not bad for $1.80/PIC.

  The design worked well enough that I even bothered making a GUI to help me debug the bringup issues (I connected a UART to the PIC) (note that the input and output current readings (and thus power readings) are completely trash, that needs to be addressed in a future spin of the power supply).
  

  
  At it’s peak, I was able to push out over 2A from the 9W/1.5A panel sold by Sparkfun. The output current was so high that I measured over 0.5V of drop in the cable between the supply and the supercap bank alone!

  I also managed over 85% efficiency, which is pretty decent (but not great yet).
  

  All said in done, my bill-of-materials amounts to $8.17 @ 1000 QTY, not including the 4-layer PCB. For a 9W panel, this comes out to be slightly more than $1/W, which isn’t bad. But for a 3W panel, this is completely overkill.

  
  The design turned out to be rather expensive in an attempt to remedy three major issues: Precision, Efficiency, Flexibility.

  
  

  Precision
  

  The internal reference of the PIC16F1773 has a +/- 4% tolerance across the entire temperature range.

  
  While this large tolerance doesn't matter much when measuring small analog signals, when measuring a large 24V through a voltage-divider, it can mean the difference between measuring 23.59V or 25.56V, which is a huge error margin.

  Worst yet, the resistors used on the voltage-divider are all 1%!  In itself, this tolerance will provide a measured voltage range of 23.66V to 24.70V. These two sources of error, combined, make a cheap voltage measurement solution unacceptable.

  So I add a MCP1501 high precision external reference, and upgrade the output voltage sense resistors to 0.1%. This, naturally, adds cost.

  
  

  Efficiency
  

  Previous MPPT designs operate fairly well at light load, but as the output amperage increases, their efficiency drops. The losses come in many forms, but the most obvious paths include.

  • Losses in the forward...

  Read more »

• OpAmp Be Gone

  Jonathan Bruneau • 05/10/2017 at 23:42 • 0 comments

  Wait a second...

  I just finished uploading my latest project log, and it got me thinking. Maybe I can get rid of the OpAmp altogether and still successfully implement over-current protection.

  Here's the thought. The way the latest SEPIC design implements over-current protection is by amplifying a small voltage drop across a sense resistor, right after the MOSFET.

  The truth is, the PIC16F1764 has a DAC that can be wired as one of the inputs to the internal comparators.

  So instead of amplifying the signal using a OpAmp, I can use a DAC to decrease the comparator's input voltage, essentially doing the same thing.

  This is just a firmware change away, so I tried it. It works like a charm! Below is a graph of the net result. The yellow line is the PWM going into the gate of the MOSFET, the magenta is the voltage across the sense resistor, (the blue is the OpAmp voltage, set as unity gain (hack needed to make this work with current PCB)).

  Notice the smooth ramp-up in voltage on the magenta line. That's the voltage increasing across the sense resistor. By changing the output of the DAC connected to the comparator, I can change the over-current set point. Neat, don't you think?

  Ok, so now to find a MCU with a high-speed PWM, two comparators and a DAC that can connect to a comparator inputs. Should be easy to find.

  HA, check this out: brand new chip: PIC16F15323, $0.53 @ 1k! If the PWM lives up to the datasheet, we might have a winner. This MCU doesn't have the 100mA GPIO drivers, but at 50mA I can double down on the number of pins used to drive the MOSFET. This just might work.

  Needless to say, I've ordered some of these PICs. I'll keep you posted with more details.
  

• Return of the SEPIC

  Jonathan Bruneau • 05/10/2017 at 23:11 • 1 comment

  A long time ago (man, almost 1.5 years ago) I tried my hand at a SEPIC, with mixed results. While the topology indeed works as a MPPT, the two inductors required by the topology made the cost quickly go out of budget (switching at 31kHz). So, I canned the idea.

  But after reflecting on the findings of my latest MPPT hack, I started thinking about the SEPIC once more. This latest hack works quite well, but suffers from a fatal flaw: the maximum output voltage can only go up to 6V. There are a lot of applications out there that require a 12V output, so 6V just wouldn't cut it.

  I needed something that could output 12V, and in the spirit of this project, could output 12V irrespective of the input solar voltage (lower or higher than 12V). This naturally brought me back to buck-boost topologies.

  So I started looking for boost or buck-boost regulators that could be hacked into MPPT controllers. The results were not encouraging. I found that in my price range, the regulators were one of more of the following:

  • Unable to output enough current.
  • Too expensive.
  • Switching too slowly, requiring large inductors.
  • Too inefficient

  And on top of using hacking a regulator, I would still need a MCU to start/stop the regulator for Voc (Open-Circuit voltage) sampling, crucial in finding the MPP.

  This is when I started turning my brain on.

  Hey, if I need to have a MCU anyways, it would be a hell of a lot cheaper to replace a hacked-up regulator with a MOSFET (cheaper by an order of magnitude) and use a SEPIC as long as it was switched fast enough to keep the inductor sizes small (a.k.a. within budget).

  How fast? Well, pretty fast actually. Anywhere in the 300kHz to 1MHz range. I made a spreadsheet to calculate exactly how fast I needed to go, using equations given from three reputable vendors. You can see it here (or just look at the pretty picture below).

  333kHz seemed to be as slow as I was willing to go, which gave me a 1.6uH inductor size. To my surprise, the amount of output decoupling is enormous, 105uF @ 333kHz! At 500kHz, that value thankfully went down to 70uF.

  The key at this point was finding a MCU that could generate a >= 300kHz PWM signal with sufficient resolution at a price point lower than using an external boost regulator + MCU. I say sufficient resolution because with most (if not all) PWM peripherals, as the period decreases (i.e. increasing frequency), the number that can be used to represent the duty cycle also decreases. The fewer bits available, the coarser the MPPT becomes. If too coarse, the MPPT cannot successfully settle on the actual MPP. I ran into this issue in the past and talked about it in this blog post.
  

  Turns out finding a sub $0.60 MCU that can switch at such high frequencies while retaining sufficient duty cycle precision is quite hard. I only found a handful:

  • PIC12F1571
  • PIC16F1764 (over budget)
  • ATtiny25
  • XMC1100
  • XCM1301
  • EFM8BB
  • <insert your suggestion here>

  Factor in other variables such as:

  • The design needs to have at least 1 comparator, preferably 2.
  • The design needs an OpAmp for over-current sensing.
  • The design costs can be reduced if the external MOSFET driver can be replaced with MCU GPIO pins.
  • The MCU needs to have a ADC for Voc sampling and tracking.
  • I just want to prototype the damn thing at this point.

  And I ended up using the PIC16F1764. The integrated OpAmp + 2 comparators + 16bit PWM operating at 32MHz + 100mA (not a typo) high current drive MCU pins + the fact that I already have some lying around tipped me over. For a 333kHz oscillation, I would end up with a period value of 96, meaning I would have 96 discrete steps for duty cycle. With a max of 24V input, this would give me a resolution of:

  I found this acceptable enough to bother making a PCB for it. Here it is, in all it's glory.

  I ended up using a slightly larger inductor than calculated in my spreadsheet to give me a margin of error. I used SRF0703-3R3M, a 3.3uH coupled inductor. (The astute observer will also notice that I actually used a PIC16F1768, but that's a complicated...

  Read more »

• Being Hard with the Soft-Start

  Jonathan Bruneau • 02/03/2017 at 07:36 • 0 comments

  As part of my weekly routine, I run a Digikey search in the "Voltage Regulator" and "Voltage Controller" sections in hopes of finding a better, cheaper alternative to the RT8299. I even have the searches saved: try them out if you're interested:

  • Voltage Regulator Search
  • Voltage Controller Search

  Why looks for a new regulator? Why hate on the RT8299? Because it tempts me.

  Here's why. Take a look at the pinout of the RT8299.

  See the VCC pin? Well, dig deeper in the datasheet and you'll find that this pin is actually the output of an LDO.

  For the astute (and long term memory) observer, my latest and greatest hack of this RT8299 requires an external LDO regulator to power the PIC MCU used to override the default behavior of the RT8299 (see this post if your memory fails you).

  Given that the RT8299 has a LDO built in, and it's exposed to a pin... well damn, I "should" be able to use it and rid myself of this unholy external LDO! Yoohoo!

  "Should" is the correct answer. The RT8299 fails us in two ways.

  1. The RT8299's internal regulator only powers on when the EN pin is high.
  2. The voltage coming out of the regulator is said to be 5V, but goes all the way to 9V as VIN rises.

  I like how the datasheet discretely fails to mention point 2.

  Having VCC go above 5V is actually a good thing, as this voltage is used to drive the FETs. Higher drive voltages result in higher efficiencies. That being said, it's terrible for powering a MCU. There are a handful of higher voltage MCUs (mostly from Microchip), but the cost prohibits their usefulness (with one notable exception, sort of).

  To make things worst, with the enable pin always high, there's no way for me to properly stop the RT8299. Stopping the regulator is crucial to sample the open-circuit voltage (Voc) and to prevent an over-voltage condition on the output.

  This is where those weekly Digikey searches come in.

  As part of my weekly ritual, I peruse the datasheet of new parts that crop up to see if anything juicy strikes my fancy. About a month ago I landed on this guy: the AP65452.
  

  The specs aren't perfect, but the pinout certainly is: a stable 5V VCC, and a soft-start pin, exposed!

  For the uninitiated, the soft-start pin usually connects to a capacitor and is charged with an internal constant current source. This voltage is then used to limit the rise time of the output of the regulator. All in all, it eliminate large inrushes of current, and that's a good thing.

  It's especially a good thing since the 5V regulated output is, like its RT8299 cousin, only enabled when the EN pin is high. This means I cannot use the EN pin to start/stop the regulator. But thanks to the soft-start pin, I have an alternative way to keep the AP65452 disabled. With the help of a single N-channel MOSFET, I can keep the soft-start voltage close to GND (i.e. prevent the capacitor from charging) to prevent the AP65452 from turning on.

  Now we're cooking with oil! The regulator can power up, enable the internal LDO, and stay off until the MCU wakes up and is ready to go.

  This had enough legs to run, so I made a board and tried it out.

  The same OpAmp feedback pin override technique was used to adjust the maximum power point, and it worked as expected. Horray!

  Is the AP65452 the final solution? It depends. It's Vin range is smaller than the RT8299 (4.5V-18V vs 3V-24V) and the maximum output voltage is 6V, hardly enough to charge 12V batteries.

  Do I need to care about 12V output? Maybe this is something you can tell me.
  

• Timing Isn't the Answer

  Jonathan Bruneau • 02/03/2017 at 06:01 • 9 comments

  It's been far too long since I've posted an update.

  I am still, in fact, working on this project. In my last project log I was trying to find a way to enable/disable the hacked RT8299 buck regulator to give me a open-circuit voltage (Voc) reading, which is then used as the maximum power point target until the next sample is taken.

  I've played with a variety of different oscillators, and eventually landed on a single Op-Amp multivibrator. It's an attractive solution thanks to the low parts count: offering a potential for significant cost reductions. The basic circuits looks like this (image courtesy of this site):

  The principle is quite simple. The OpAmp acts as a comparator, comparing the voltage on a capacitor to a reference voltage. The reference is generated right off the OpAmp's output (R1 & R2), and resistor R is used to limit the charge/discharge rate of the capacitor.

  This basic multivibrator circuit generates 50% duty cycle square waves, but for this MPPT application, I need something closer to 99% duty cycle (sample VOC briefly, turn on RT8299 and track MPPT the rest of the time). This can be easily done by adding a diode in parallel with resistor R to provide a fast discharge path. To control the discharge rate, another resistor is used in series with the diode.

  The modified circuit ends up looking like the image below (found from this site, which contains enough interesting material to keep folks such as myself busy for entirely too long):

  The only difference between this image and the actual circuit I build was that the values of R1 and R2 are flipped, effectively inverting the output duty cycle.
  

  This circuit works well and integrates nicely with my current MPPT implementation, with a caveat. In order to get long periods (over 10sec), I need a large RC time constant. To keep cost down, I chose the largest R in my arsenal in an attempt to make the C reasonable.

  Bad idea!

  With a sufficiently large R, not enough current enters the input of the OpAmp (they have a required minimum, usually referred to as the "Input Offset Current"). When not enough current enters the OpAmp, the circuit no longer oscillates.

  This left me with the uncomfortable position of having to chose a large C, which is more expensive.

  Right off the bat, this doesn't sound like a deal breaker, until you add up the costs. After adding the cost of the OpAmp multivibrator, the large timing capacitor, the reference voltage used to regulate the output, the output comparator (an OpAmp "can" be used with sub-par results), the feedback override OpAmp (see this post for an explanation) and the Voc sampling circuit (see this post), it ends up being cheaper to use a PIC.

  Somehow the universe decreed PICs to be amazingly cheap.

  All this to say, I'm no better-off than I was prior to this nonsense science.
  

  This is just part of the news. I'll post another entry with my other experiments.
  

  
  
  

• Timing is the Answer

  Jonathan Bruneau • 08/03/2016 at 04:21 • 4 comments

  It's a great song by the way.

  As discussed in my previous project log, I was able to remove the ADC and DAC otherwise needed to perform the MPPT algorithm, vastly simplifying, if not outright eliminating the need for a microcontroller. The motivation is simple: save cost.

  But there's a caveat to this plan of mine; I still need a timing circuit to briefly turn the RT8299 buck regulator off to sample the open current solar panel voltage (Voc). This is where things get interesting.

  As shown by my latest breadboard, I've tried a variety of options. I'll discuss the two most interesting below.

  My first inclination was to replace the MCU with the good 'ole trusty 555 timer. These ICs have been around since the dawn of semiconductor (mild exaggeration on my part), and today sells well over a billion units a year (not an exaggeration on my part). If you'd like to read more on it's fascinating history, I'd recommend this great oral interview with the inventor.

  Anyways, with the 555 timer, it's relatively easy to generate a duty cycle greater than 90%. High duty cycles allows the RT8299 stay enabled and regulating the input solar voltage for as long as possible while briefly turning off to have our peak detector circuit sample for Voc voltage.

  I won't go into too much details, but it turns out you can easily generate high duty cycles by using a diode to bypass the resistor between the discharge and trigger pins of the timer (circuit borrowed from this site).

  Not too surprisingly, this worked, and after hooking it up to the RT8299, the latter successfully regulated the solar panel voltage.

  Mission accomplished. Well, sort of.

  Yes, 555 timers are cheap, but the cheap ones ain't so great. At $0.10 each for the NA555DRG4, we have a 555 timer that has:

  • VCC range: 4.5V-16V
  • Quiescent current: 10mA @ 16V

  The voltage range isn't very wide, and the quiescent current is fairly large. Not ideal.

  First, let's fix the voltage range issue. The best range I can find is 2V to 18V. It's doesn't completely encompass the 24V max supported by the RT8299, but at 18V I'm willing to compromise. For that range, we're looking at the ICM7555IBAZ-T. The quiescent of 60uA is *far* superior, but the part cost $0.27 alone, and after adding all the surrounding passive components, we're looking at $0.38, more expensive than microchip's cheapest $0.31 microcontroller (PIC10F200), which could do the same job as the 555 timer.

  This is where I try to be clever (clever-er?). I remembered many moons ago learning about the 4000 series and their magical ability to operate at high voltages. Enter the CD14538: a dual mono-stable multivibrator. With a VCC range of 3V-20V (not a typo, look at the datasheet), a quiescent current of 0.08uA, and a price tag of $0.14, this deserved some attention.

  Being that they are mono-stable multivibrators, I had to devise a way to retrigger each multivibrator one after the other. The first multivibrator had a long period to simulate the long duty cycle, and the second had the short period to turn the RT8299 off.

  After some tweaking, and realizing that the maximum allowable period supported by the IC is 10seconds, I got it to work. Rough schematic looks like this:

  The astute observer will notice just how similar this is in implementation to the internals of a 555 timer.

  As you could imagine, while a fun exercise in playing with 1970's technology, the large number of external passive add up to an impressive cost: about $0.17. Add this to the $0.14 for the IC itself, and you find that the total cost of this solution is $0.31, the same-ish price as the 555 timer or the PIC10F200. Hardly making progress here.

  I'm very close to eliminating the need for a microcontroller, but this timing circuit requirement sure is getting in my way. More to come.
  

• We don't need no stinkin' DAC

  Jonathan Bruneau • 07/07/2016 at 01:53 • 0 comments

  Nor do we need ADCs either none.

  I want a cool hat like that!

  Turns out, with some clever wizardly, I figured out a way to get rid of the DAC and the ADC to make this MPPT power supply. "How and why" you may ask? Let me start with the why.

  My current implementation uses the PIC16LF1704, and I'm paying a whole $0.75 for it (really, it's $0.88 because of the mandatory LDO used to power the PIC's VDD rail). And for what? A OpAmp, comparator, a ADC, and a 8bit DAC, and a really dead simple algorithm that maps a solar panel open voltage ADC reading into a DAC setting, followed by a long waiting period before turning off the RT8299 and sampling again.
  

  Yeah, I put some fancy code to have the DAC output vary to have the MPPT output exactly track the exact MPP voltage, but that's otherwise a lot of money for something so simple. And since I'm trying to cut cost close to $1, I'm trying to find ways to take out the PIC16.

  It then dawned on me that the DAC+ADC+Algorithm are not needed in order to calculate the proper Vref needed on the negative input of the OpAmp (see this log for more explanation of Vref). Instead, I could build a peak detector, and properly condition the output to act as the Vref input to the OpAmp.

  In other words, instead of this (current method using internal PIC16LF1704 OpAmp):

  Do this:

  With the right combination of RT and RB, a open-circuit VSOLAR can be transformed into the same form that the DAC would normally output.

  There's a nice bonus of using this MCU-less solution: I don't need to pay the cost for a LDO. There's plenty of OpAmps that can go up-to 24V for plenty cheap.

  The trick, as it turns out, is timing. In order to get the open-circuit voltage of the solar panel, I need to turn the RT8299 off (i.e. set the enable pin low), and to do that, I need a timing circuit. The timer requirements are somewhat unique: it has to be a square wave with a pulse width must greater than 99%, with a period much greater than 10 seconds.

  But before I got too excited, I first wired up a breadboard with the new OpAmp hookup, using me (a human) as a timer to energize the sampling capacitor C3 with the open-circuit voltage. And boy does it work.

  So now I have to find a proper timing solution. I've already experimented with some timing circuits (namely the famed 555 timer), but I haven't gathered all my thoughts on it yet, so that's a story for another day.
  

• If it ain't broke, don't fix it.

  Jonathan Bruneau • 05/07/2016 at 20:40 • 3 comments

  Good news, and bad news.

  But, first and foremost, I've returned from my long travels in Europe and started working on this project again. The nice thing about vacation is that, if you time it right, the PCBs fab themselves while you're gone lounging on a beach chair enjoying Pina Coladas (my vacation was similar, just without the Pina Coladas, nor the beach chairs).

  So, for the good news, I got the improved PCBs, stuffed a board, it runs great. This is the top.

  And the bottom. Do note that the programming header (that right angle 0.1" 6pin header) doesn't need to be stuffed if the board gets programmed just once. A harness + pogo pins could program it just the same while keeping the back free of components.

  Better yet, you can get the PICs preprogrammed from Microchip, and so the boards wouldn't even need to be programmed in the first place. Neato.
  

  This is all good news, so what's the bad news?

  Well, in my infinite wisdom, I "retrofited" the pinout of the PIC16LF1704 to make the board easier to layout, and in doing so, messed up one of the pin assignments. The astute observer will have noticed a blue-wire between a pad and a pin on the PIC16 in the first picture on this post. In case you don't believe me, here it is, in all it's glory.

  The shame.

  So there. Now I have 13 boards (3 from OSHPark and 10 from DirtyPCB) with this defect. Good news is the fix was incredibly simple to make, so I should be getting me some newer better PCBs in the near future.

  So, let's recap the total BOM cost.

  Component	$/unit (1000)	# Units	Total Cost
  PIC16LF1704	$0.7500	1	$0.7500
  RT8299	$0.3775	1	$0.3775
  AP2204K-3.3TRG1	$0.1386	1	$0.1386
  TYS60456R8M-10	$0.1570	1	$0.1570
  SBRT3U45SAF-13	$0.1133	1	$0.1133
  Resistors	$0.0045	10	$0.045
  22uF 6.3V	$0.0523	2	$0.1046
  10uF 25V	$0.0357	2	$0.0714
  Other Capacitors	$0.0165	6	$0.099
  PCB (DirtyPCB)	$0.56	1	$0.56
  		Grand Total	$2.4164

  This is respectable. Attach this power supply to a 2.5W solar panel and the $/W goal is achieved.

  I think there's more room to reduce cost/watt, but I might have to do so by making a new board that accepts multiple solar inputs on a single board. More on that later.
  

• More GNDs are Happy GNDs

  Jonathan Bruneau • 02/07/2016 at 05:44 • 0 comments

  Small update.
  

  I've been playing with the PCB layout for the PIC16LF1704+RT8299 solution. I wanted to accomplished three things:

  1. Provide a better GND plane for the high-current path.
  2. Make the board smaller.
  3. Keep it to two layers (for cost reasons).

  It took some doing, but I got it. Here's L1.

  And here's L2 (notice the nice GND across the middle of the board).

  Satisfied, I ordered it through OSHPark and DirtyPCB. The latter fab house was picked because of the $0.56 I can get in volume, compared to the $1.60 from OSHPark. Plus, the boards come in red (that's got to count for something). We'll see how they compare to one another.

  Hell, if this board works out, we might have ourselves a winner.
  

• The Venerable PIC12F1571

  Jonathan Bruneau • 02/03/2016 at 06:45 • 0 comments

  In a previous project log I mentioned the possibility of using the PIC12F1571 with an external OpAmp as a lower cost replacement for the PIC16F1704. It's not a huge cost savings, 20cents-ish, but it's enough to make my ears perk up.

  So, I tried it.

  Exact same circuit as the one prototyped in this project log, except the OpAmp is external.

  It works, it runs. So mission accomplished, right?

  Well no. There's an important difference between the PIC12F1571 and the PIC16F1704 that's causing the PIC12 to under perform: the Digital to Analog converter (DAC).

  The DAC is used to set the MPP voltage, which the RT8299 then regulates to (see this project log with an explanation of how this works). On the PIC16, we are graced with an 8bit DAC. This gives us 256 different solar operation voltage points. That is to say, for a maximum input of 24V, we have a resolution of:

  In other words, once we measure the open current voltage (Voc) of the solar panel, we can set the DAC setting to be within 0.09V of the MPP. Thats' really good.

  The PIC12, on the other hand, only has a 5bit DAC, so 32 different values. For a 24V input range, this gives us:

  This is sad, and for 5V panels, it's a deal breaker.

  Think about it, if the Voc of the panel is 5V, the MPPT is 4V (80% of 5V). With a resolution of 0.75V, we'd either get the panel to operate at 4.75V or 3.25V. The former is barely exercising the solar panel, the later runs the board really close to the under-voltage lockout of the RT8299. Neither scenario are good. We want 4V.
  

  This oscilloscope plot illustrates the problem quite well. It was captured while connected to a 9V solar panel, which at the time, was generating a Voc of about 8.4V. The Magenta line is the voltage of the solar panel, the yellow line should be ignored (it's the enable pin of the RT8299, which doesn't illustrated much in this case).

  Let me explain the plot above.

  The MPPT algorithm works by first trying to guess the correct DAC value to set in order to achieve the desired MPP voltage, subsequently sets it, and then adjusts the DAC until the correct final MPP voltage is obtained (since I have an MCU I can do neat things like that). In the plot above, the MPP voltage is between two voltage points that can be set by the DAC, and so the algorithm constantly oscillates between the two voltages, never reaching the desired MPP voltage.

  This longer capture shows this whole process. Again, the magenta line is the solar voltage, and the yellow line is the RT8299 enable pin.

  The poor PIC12: never able to reach it's goal...
  

  So, where does this leave me? Two options:

  1. Try to use the PIC12F1571 awesome 16bit PWM and a LPF to generate a pseudo 8bit DAC.
  2. Stick with the PIC16F1704.

  I can tell you that I already tried option 1, and there's quite a few problems in making it work. Two noteworthy issues: settling time and linearity, but I won't go in much more details about that. The truth is, at this point, I'm trying to do a hack of a hack, and hacks^2 never make me feel comfortable.

  I might wake-up with another way to properly use the PIC12F1571, but most likely I'll just come up with more bad ideas. So I'm sticking with the PIC16F1704 for now. The next step is to redo the layout of the last board. I'll post my progress as it happens.

  Until then.
  

View all 21 project logs