Tag Archives: MPPT solar charger

USB Mass Storage Device Bootloader

Let’s start with a video. It will tell you most of what I’m going to write about today.

That Hackaday Prize final has passed and unfortunately for me, the solar charger didn’t make it into the top 5. The good news is that there are plenty of projects and stuff that I would like to share. Things that I did over the last one or two years but never had time to write about. I’m trying to catch up with all that now.

First of all, I have completed the USB bootloader for the solar charger. This part of the project will enable the non-technical end user to easily and reliably update the firmware in the field.

Unlike a USB HID (Human Interface Device) bootloader that requires some application to run on the host computer, this USB MSD (Mass Storage Device) bootloader requires absolutely nothing in terms of host software. It’s entirely independent of the OS used. Windows, Linux, Mac, it all doesn’t matter. As long as they can deal with a USB drive, they’re good to go. Just copy the new software (in the form of an .hex file) to the Solar Charger drive and follow the instructions on the display.

It might even be that this bootloader is the world’s first of its kind for the PIC18 platform. To be sure, this kind of bootloader has been around for years for more powerful 32-bit microcontrollers like ARM Cortex and the like. But in my online research I have been unable to find any other such project for the PIC18 family (or any other 8-bit microcontroller). So I had no choice than to write my own. If you know of any other implementation, please let me know.

Once the file has been found and the user has pressed the button, the file is checked. If all those checks pass, we can be confident that we have a valid hex file. Of course, it doesn’t tell us anything about the quality of that code, that’s an other issue. But technically we should be fine.

Once the checks have passed, the user is once again requested to press the push button to confirm that this file should be programmed onto the chip. While it’s programming, it keeps displaying the current hex file entry it is processing to give the user an idea of the progress. It also keeps track of the number of flash pages it has written. One page corresponds to 1024 bytes on this architecture.

Once all the new code is flashed onto the chip, a message is displayed and the user is asked to once again press a key to re-boot the device into normal operating mode.

There are two different ways to enter bootloader mode. One is to press the push button at power-up. The other one consists in writing the value 0x94 (an arbitrarily chosen value) to the EEPROM address 0x100. In this case, the device will start up in bootloader mode no matter the state of the push button. The bootloader then overwrites this value (to 0x00) in order to start up normally next time.

After the reboot, you should be greeted by the startup screen of the solar charger firmware as shown above.

While I wrote this bootloader specifically for the solar charger, the code is rather universal. It can be ported to other PIC18 projects with relatively little effort. As always, the code’s on github: https://github.com/soldernerd/PIC18_USB_Bootloader.

Solar Charger in Hackaday Prize Finals

I’m delighted to tell you that my MPPT Solar Charger has been nominated for this year’s Hackaday Prize Finals taking place on October 22nd.  I’ve submitted it in the Power Harvesting Challenge category a while ago and was just informed that it was picked as one out of twenty projects submitted to the finals. Check out the original article here. Of course, any support is highly appreciated.

If you check out the project description on hackaday.io you will notice that my blog is somewhat lagging the latest developments. But don’t worry, I hope to post more updates as well as a few videos soon.

MPPT Solar Charger – Revision F

While the solar charger was originally intended to be used as a standalone device, it can just as well be integrated into other projects. In such applications, the user interface can be left away without sacrificing functionality other than the display and rotary encoder.

One project doing just that is MeshPoint, a rugged wifi hotspot for disaster and outdoor areas. But in most cases, the main application needs to be able to communicate with the solar charger. It wants to know if power is harvested, how full the battery is and so on. It needs to be able to enable and disable the various power outputs and maybe to control the fan. Or maybe it wants to make use of the charger’s real time clock and calendar. Or store some configuration data on the charger’s EEPROM. Possibilities are endless.

And when it comes to external communication interfaces, all the chargers up to revision D had little to offer other than the USB interface. Depending on your project, adding USB host functionality may be inconvenient or even totally out of the question. There was always the possibility to somehow tap the display’s I2C port but there was no extra header on the board for that.

Revision E has finally changed that. The charger now comes with two extra headers, one for I2C and one for SPI. As of now, the PIC acts as a master on both of those buses but slave functionality can be (and is planned to be) added in software. Hardware-wise it is even possible to update the charger’s firmware through those interfaces. I must admit that this is not the number one priority to be implemented but its nice to know that the possibility is there.

With the implementation of the USB bootloader next on the agenda I also upgraded the microcontroller to the newly introduced PIC18F47J53. It is extremely similar to the previously used PIC1846J50 and entirely pin compatible so it didn’t require any changes to the board. But it has twice as much flash memory (now 128kB) which allows for a feature-rich USB bootloader without runing into any issues memory-wise.

Another nice thing about it is that it has many more PWM modules which means that all four power outputs can now be PWM controlled. Think of LED lighting which is probably one of the main uses of those outputs. As a bonus, it also comes with an 12bit ADC which means four times the resolution on the temperature sensors.

When modifying the software to fit the new board and microcontroller, I noticed that my pin choice for the external SPI slave select signal was somewhat unlucky. I happend to pick one of the few pins without PPS (peripheral pin select) functionality which can be a problem if you try to use that interface with the charger configured as slave. The fix was easy, just swapped two pins but required a slightly modified board. That’s why the current version is now revision F.

Click here for the previous post in this series.

Free Solar Charger PCBs

A reader of this blog was so kind to send me a number of surplus boards of two of my solar charger designs. Thank you, Joachim.

Solar Charger Hall of Fame

[November 10, 2017]

After just a few days, all of the boards were sent out to all over the world. Today, the first photo of an assembled board has arrived. I’ll post this and all following photos here:

By Orkhan from Germany

Arduino Solar Charger

The first variety is my Arduino solar charger shield. Being my first attempt it is maybe not the most advanced design but it’s by far the simplest. So it’s well suited if you want to get your hands dirty while keeping the level of complexity reasonably low and do all your programming via the Arduino IDE. And despite its simplicity it operates very efficiently – apart from the power-hungry Arduino.

Solar Charger Rev C

This is a relatively recent and far more advanced design. It is very low power, highly efficient, comes with USB and lots of bells and whistles. So if your ambitions are somewhat higher this board is for you.

The Rules

Now here are the rules. As the title of this post suggests, I give these away for free. I ship them world wide absolutely free of charge. All I ask for in return is a photo of the assembled board within 6 weeks after you get the board. A maximum of 2 boards per person (one of each design).  First come first served. Just send an email to [admin at soldernerd dot com].

MPPT Solar Charger Rev C – First Test Results

Over the last few weeks I have been quite busy with my MPPT Solar Charger project. I’ve built up a first board and started writing firmware for it. Since the last version was not too different in terms of hardware I was able to re-use most of that code. But I hadn’t even touched on the whole USB stuff back then so there was still a lot of work to do. While the project is still far from being complete I am happy to say that I’ve made quite some progress. Most importantly, the new design seems to work well and so far I haven’t found any mistakes in the board layout. But let’s go through this step by step.

USB

I regularly find USB communication to be the most complex and obscure part of the firmware. That’s why I like to get that working first and then add all the other functionality later. I’ve started with some sample code that Microchip provides for their PIC1846J50 family of chips. That way I was able to get the my board act as a composite HID (Human Interface Device) / MSD (Mass Storage Device) quite quickly. Of course, that demo application doesn’t do anything particularly useful but it provides a solid basis for adding the functionality you need.

At least for the HID I’ve implemented most of that functionality. I can read all the relevant data such as settings, currents, temperatures, voltages and so on over USB. I can also control all the outputs as well as the actual solar charger remotely. More on that later.

On the MSD side there is still lots to be done. The solar charger successfully enumerates as a USB flash drive and you can read and write data from and to it. But that’s really it. The charger doesn’t care about the files you save there and also doesn’t put any data there.

Flash and EEPROM

This brings us to the next topic: Non-volatile memory. There is both a I2C EEPROM as well as a SPI flash on the board. Communication with the EEPROM is fully implemented but currently its only used to save the time and date. The idea is to save all the settings and calibrations on the EEPROM. That shouldn’t be difficult but I haven’t had time for that yet.

The flash also works just as it is supposed to but the chip I chose turned out to be a bad design choice. It can’t do page erase, only entire 16k sectors can be ereased. That makes it difficult to use since you have to temporarily save the sector’s data somewhere when you want to change only part of a sector. We don’t have that much RAM so we have to save that data to flash itself. That can all be done but it’s just a hassle. Apart from that a sector erease takes time. A loooot of time. So I’ll just juse a different chip when I do the next iteration of the board. For now I’ll just use the first 512bytes of each sector. That’s extremely wasteful but will do for now I guess.

Solar Charger

The actual charger circuit hasn’t changed much since the last version so I expected little trouble in getting it to work. However, I managed to confuse the low and high gate pins in firmware and only found that bug days later when I had already done plenty of damage to the board. By the time I found and fixed the problem I had already killed the input current sensor, the ADC, as well as some of the PIC’s output drivers.

So I built up a second board but only with the components required to test the buck. And much to my relief it works. And it works well. I haven’t done any precise measurements yet but it seems at least as efficient as the last version. I had it running at its rated power of 75 without it getting overly hot. As expected, most power dissipation takes place in the coil so the coil did get quite warm but not hot. The FETs heat up a bit due to their proximity to the coil but otherwise don’t care much. My main problem with these tests was to somehow sink the power at the output without overcharging the battery. My home-made dummy load can sink up to 4.5 amps but not for very long before it regulates down to avoid overheating. I had the charger running at around 40 watts for several hours and it only got modestly warm.

Also, the wave forms on the scope look nice and clean. There’s considerably less ringing and overshoot than with the last version. So the improved layout seems to work well. During the tests so far I have turned the charger on and off at least a hundred times, switched from asynchronous to synchronous mode and vice versa and had it running for about 10 hours. I also pushed it all the way up to about 85 watts where the coil starts saturating and the caps have to handle more ripple than they are rated for. I’m happy to report that during all these tests I haven’t killed a single fet nor any other component (once the firmware was ok). I am confident that it will stay this way.

Synchronous bucks are somewhat dangerous in the sense that it is easy to short the input or output to ground when you’re not careful. My solution to this is having rigorously tested functions for turn-on, turn-off, switching mode and changing duty cycle and then rely only on these functions when implementing different MPPT strategies. If these few functions do what they should you can get away with quite a bit of abuse without damaging anything.

What I also noticed during my tests is that the break-even between synchronous and asynchronous mode is somewhere in the region of 1 amp. That’s about twice what it was with the last version and is thanks to the extremely efficient diode that makes asynchronous mode much more efficient.

USB Charger and power outputs

This is something that has changed quite a bit since so I was eager to see how it performs. I haven’t done any detailed tests but I’m very pleased with it so far. It definitely performs better than the last version. In theory, you should be able to simultaneously pull 2 amps from each of the two USB charging ports. I haven’t done that yet but when fast-charging two cell phones (approximately 2 amps judging from the power it pulls from the battery) it stayed surprisingly cool – unlike the last version.

Also no surprise with the 4 power outputs. I had changed the mosfet drivers and mosfets in order to save board area. Apart from that everything works like before. I can still turn off the drivers when none of the outputs is in use in order to preserve power. All works as it should.

Solar Charger App

Of course, all the USB HID functionality is of little use without some software on the other side, i.e. running on a PC. I’ve spent a lot of  time writing my Solar Charger App over the past few weeks and I can say it’s getting pretty good. I has already proved very useful in testing the buck. Since I can monitor and control everything via USB there is no need to have a user interface sitting on top of the board during testing. That means unrestricted access for scope and multimeter probes. And since there’s so much more space on a PC screen than on the little LCD I can display all parameters simultaneously.

The program is written in C#, using my recently published HID utility and WPF .  I’ve tested it on Win7 and Win10 and runs absolutely stable. It also copes well with ultra high resolution displays where everything gets scaled-up in order to still be visible/readable. The screen shot above gives you some idea of its current functionality. Take the efficiency measurement with a grain of salt, though. The measurements are yet to be calibrated.

The code is available on github: github.com/soldernerd/SolarchargerApp. To compile it you need VisualStudio 2015 Community which is available free of charge.

Measurements

Measurements is another important topic. The newly chosen 16-bit ADC works well. Actually, I don’t feel much of a difference to the 18-bit version used previously. Anyway, the measurements are done with 14-bit precision only in order to speed them up.

 

The readings I get from the two current sensors are surprisingly accurate even without having done any calibration so far. So for now, all measurements have been done with their theoretical (i.e. calculated) multipliers and offsets.

The temperature measurements are done by the PIC directly, using a 2.5V external voltage reference. Both the temperature sensors (one on-board, up to two externally) as well as the voltage reference perform just like they should but I get a lot of noise in my otherwise reasonable measurements. This is quite certainly a software issue. I might not give the PIC’s internal ADC enough time to settle after switching channels or something like that. I’m sure it can and will be solved but I haven’t given this very high priority so far.

Next steps

A lot of work remains to be done. One of the next things I will do is to implement proper calibration for the voltage and current measurements. At the moment, all the relevant constants are hard-coded so I first need to change them being variables, store them in EEPROM and retrieve them from there at startup. In a second step I need to make them accessible over USB. Once that’s done it should be possible to calibrate them in a fully automated fashion. I’ve never done that so far but my multimeter as well as my power supplies can be controlled via USB (or GPIB, respectively).  So I want to write a calibration routine that sweeps the device under test, calculates the proper calibration values and sends them to the solar charger.

Getting the Mass Storage Device working from FLASH is another big thing to do. As reported, the currently 7kb of memory on the flash drive are mapped into the PIC’s internal flash memory. I’ll have to dive quite deep into the Microchip USB code in order to figure out how to change that. I expect to spend a significant amount of time until that works but there’s no way around it in the long run.

Once mass storage works properly I can also start implementing settings as a configuration file on the flash drive. So as an alternative to doing things via HID which requires dedicated software to run on the PC you can also check and change settings by editing a text file residing on the flash drive. The next step will then be to also write measured data to that storage.

Then most of the low-power features are still to be implemented. The most basic stuff is there: The 5V buck for USB charging is turned off when not in use and so are the mosfet drivers for the power outputs and the solar charger. The user interface is also turned off after a certain time of inactivity. But the PIC constantly runs at 48MHz, the USB module is never turned off even when not in use, it never goes into any of the several low-power modes and so on. So at the moment it consumes around 10mA with the display off and 16mA with the display on.

And yes, there’s also more testing to be done on a lot of aspects. The code could definitely use a clean-up once I’m done with it, I also have plans of adding a boot-loader so users can update the firmware via USB… I won’t run out of work any time soon.

The firmware is on github, too: github.com/soldernerd/SolarChargerRevC_Software. It is updated much more frequently than I do posts here so if you’re interested I suggest you track the most recent development there.

The next post on this topic is here.

MPPT Solar Charger Rev C Design

Over the last year or so I’ve designed, built and tested a standalone solar charger. It performed quite well but as with any complex design there were a number of things that needed to be improved.  So I eventually reached the point where I decided to design a revised version. And this is what this post is all about.

Things to improve

Here’s a list of things that I wanted to improve besides fixing the design errors of the old design:

  • Downsize the board and give some thought to how to put the whole thing into a case. Consider carefully where to put screw holes, connectors and the like.
  • Reduce complexity wherever possible. Reduce the number of distinct components.
  • Reduce total component cost without sacrificing performance.
  • Reduce height of the assembled board so that it can ship in a padded envelope.
  • Turn user interface on by means of a logic signal as opposed to turning its power supply on and off. Ability to control the display entirely via I2C, including backlight brightness and reset.

Let’s look at these points one by one.

Downsize the board

I looked around for a suitable case for my solar charger and finally decided on a 90x115mm cast aluminium case. The specific model chosen is available from Farnell at around 10 bucks which I found very reasonable. With the case chosen the size of the board was pretty much given. The inside shape of the case is rather special since there are also mounting holes for the case itself that take away space for the board. However, I decided to keep the board rectangular so it stays universal and is not just made to fit that particular case. That left me with a board of 85x78mm as opposed to 90x140mm of the last version. That’s about half the size in terms of board area so fitting everything on the new board was really a challenge.

The main space saving came from using much smaller mosfets. The model previously used was rather huge in physical size. I’m now using NXP PSMN6R0-30YL in a LFPAK package that is much smaller while delivering similar if not better performance.

The main inductor is also somewhat smaller. I found that the Coilcraft MSS1210 series delivers pretty much the same performance as the MSS1583 while saving some space.

Apart from that I didn’t downsize any of the components in order to keep everything hand-solderable  and hobbyist-friendly. Particularly, all the resistors and ceramic capacitors are at least 0805 in size.

Getting the board made from dirtypcbs.com also allowed me to do a denser layout, mainly by using smaller vias. But I didn’t push it to the limit, all traces are still at least 12 mils (0.3mm) wide with 0.4mm vias and 6 mils clearance.

Now all the power connectors are located at the top of the board with a single 12-pin 200-mil connector. USB is still located at the front and the programming header is at the right edge of the board. External temperature sensors and fan output are now on the left side. The header for the user interface is now located so that the user interface can just be stacked on top of the charger and sits precisely in the middle. There are also mounting holes for the user interface on the charger board.

Reduce complexity

The obvious place to start was the combination of PIC18F26J50 microcontroller with a I2C multiplexer and a port extender. The same PIC family also includes a 44-pin version that allows replacing all 3 chips with a single chip.  I’m now using the top-of-the-line PIC18F46J50. That not only simplifies the board but also the software since we no longer need to care about the mux and which pins are on the PIC and which are on the port extender.

The 4 mosfet drivers for the power outputs have been replaced by 2 MCP14A0153 dual mosfet drivers that also don’t require a reference voltage signal which further reduces complexity somewhat.

The 5V switching converter for USB charging on the last version needed quite a few external components to function. Besides that it got rather hot at 2 amps. I’ve replaced it with a Texas TPS54428 synchronous switcher that is more efficient, uses less external components, delivers up to 4 amps and has a thermal pad at the bottom which helps keeping it cool. The new Coilcraft MSS1048 coil is slightly higher but otherwise the same size and helps keeping power dissipation low.

I’ve tried quite hard to keep the number of distinct capacitor and resistor values to a minimum. You can easily see that the same values such as 10k, 300k and 680k appear over and over again. The only point where there are still a lot of distinct resistor values are the USB charging ports where I’ve tried to emulate an Apple and Samsung charger, respectively. I’m not sure to what extent one can cut corners here without risking that certain devices don’t charge properly.

Overall, the number of distinct components has been reduced from 60 to 47 despite some added features.

Reduce cost

Getting rid of the I2C mux and the port extender already saves some cost. The same goes for the dual mosfet drivers and the downsized inductor. There were some unnecessarily expensive components on the last version. There was an 18-bit ADC that we didn’t really need. The Microchip MCP3428 is a very similar model that only has a maximum resolution of 16 bits and is quite a bit cheaper without making any difference to our application. Another component that was somewhat of an overkill was the voltage reference. Note that the voltage reference is only needed for the temperature measurements. The voltage and current measurements are done by the external ADC that comes with a precise on-board voltage reference. I found the Silicon Labs TS6001 which provides a sufficiently precise 2.5V reference.
I’ve also replaced the large and relatively expensive EEPROM with a much smaller 16kbit Microchip 24AA16 EEPROM in combination with a cost-effective serial Flash (Spansion S25FL208K) with 8Mbit of capacity. This way we get much more storage at a similar total cost while still keeping some easy-to-use EEPROM for configurations and the like.

Reducing height

Since the only overly high components on the last version were the input and output capacitors this was an easy task. I decided that I want to use the same model for both input and output which meant that I needed a 25 volt rating. Maintaining the 10mm diameter and limiting the height to 12.5mm left me with a maximum available capacity of 470uF. The ripple current rating of the new caps is also lower so I now have to use 2 caps in parallel at the input to not exceed this rating at 75 watts.
The caps are still the highest components on the board but only slightly higher than the USB connector, the main inductor and the 200-mil connector. The resulting total height of about 15mm is low enough to comfortably ship the assembled board in a padded envelope which is much cheaper than a small parcel.

User interface

I’ve already presented a user interface that fulfills most requirements listed. However, I still needed to again revise the user interface for two reasons. First, the previous version would not physically fit inside the cast aluminium case. So I had to somewhat taper off the board towards the side so it would fit. I also had to re-locate the mounting holes inward so that they lay on the charger board. Secondly, I need to be able to shut down the user interface without blocking the I2C interface. This was not an issue with the last version where I had a I2C mux in between. So the new  interface now includes a 2-channel bi-directional switch that is controlled via the same signal that turns the interface on and off.

Next steps

I’m looking forward to my ReflowR hopefullly arriving soon so I can build up the board in an efficient way.  As you can see below I have already prepared a setup to apply the solder paste to the board. I have glued three faulty user interface boards to a piece of coated plywood to repeatedly align the board. I have limited experience with reflow soldering but I will hopefully learn quickly and report my progress and lessons learned here.

As you can see from all the photos here the boards have already arrived and I’m excited to try them out. All the eagle files as well as the Gerbers and everything are on github: github.com/soldernerd/SolarChargerHardware.

MPPT Solar Charger Testing II

It’s time to follow up on the MPPT Solar Charger project. Progress has been slow since I’m currently working full time and doing a master’s degree at the same time. Given that this blog has previously been something close to a 50% job at times things will necessarily slow down a bit. But all the projects, including this one and the ultrasonic anemometer are alive and well and I’m working on them whenever I find some time.

20161012_userinterfacereva_014

User Interface

So what’s new with the MPPT solar charger? First of all, it got this nice user interface. Unfortunately there were still some issues with the first version so there is an identically looking but much-improved and bug-free Rev B.  I’ll do a separate post on that documenting all the things I’ve changed.

I re-used the white-on-blue display from the initial version for the Rev B. as opposed to the black-on-white used with the Rev A. They are pin compatible so you can use whichever you prefer. I more and more start liking that black-on-white look. It’s about 10 bucks cheaper as well. What’s your opinion on this?

img_4334

Solar Panel drains Battery

My intention with this design was to just leave the solar panel connected to the input of the buck converter. There’s a problem with that, however. The input of a buck is always at least at the output voltage minus a diode drop. With a 12V lead-acid battery at the output the input (i.e. where the solar panel is connected) the voltage never drops much below 12 volts.

That’s a serious problem since even a small solar panel like the monocrystalline 30W panel I have here sinks around 10mA at that voltage. So whenever the panel is not providing any power it considerably drains the battery.

Try a Diode

Obviously we need a way to avoid that. The first solution that comes to mind is a diode. But there’s a problem with that, too. To keep the power loss in the diode acceptable, the diode needs to have a low forward voltage. However, any diode with a low forward voltage also comes with a high reverse leakage.  Physics seems to dictate that.

Leakage can easily be in the range of milliamps for a diode that can handle, say, 4A like needed here. And that reverse leakage is also highly temperature dependent. It may be ok-ish at room temperature and then detoriate by an order of magnitude at 50 degrees centigrade.

To get an acceptable reverse leakage one needs to tolerate at least half a volt of forward drop which is something like 3% in efficiency. Since our converter operates at around 97% efficiency that would mean doubling the energy dissipated.

P-Channel or N-Channel Mosfet

So the next obvious thing to try is a mosfet acting as a switch.  Yes, a mosfet also has a body diode that also has a reverse leakage. But the body diode is a bad diode in terms of forward drop and has a correspondingly low reverse leakage.

A nice way of solving our problem would be to use a p-channel high-side switch disconnecting the battery from the converter whenever the panel is not producing. That not only disconnects the panel but powers off the entire buck including the input and output caps and everything. Where there is no voltage no power can get wasted. Perfect.

img_4342

Unfortunately, powerful (i.e. low Rds-on) p-fets are relatively large,  rare and expensive. As a rule of thumb a p-fet needs twice as much silicon area for the same performance compared to a n-fet. Besides that, that would be another type of component and I’m trying to not use too many distinct components.

So the other solution is to use an n-fet as low-side switch just disconnecting the panel. We already have 6 powerful n-fets in our design and they are cheap, too. So this is what I’ll do in the next version.

For now I’ve used one of the power outputs to connect the panel. I’ve cut some traces and soldered in some wires so that the fet is on whenever the buck is powered on.

Buck Software

During early testing of the buck converter I managed to kill the bottom fet several times. Since I was able to run the buck at relatively high power levels for prolonged periods of time without any issues (and without getting hot) I suspected that this was caused by carelessly written software. This seems to have been the case indeed. Whenever I killed a fet it happened at startup or shutdown, usually the latter. In the mean time I’ve written well-defined startup and shutdown routines and never had any issue since.

bootstrapcapacitorcharging

Synchronous converters are dangerous in this respect. It is very easy to short the battery to ground via the bottom fet. All it takes is a duty cycle that’s too low or a timer is running too slow or not at all. Or you stop the PWM module at a time when the bottom fet is on and it will stay on forever.  Or at least a few milliseconds until it’s dead.

Asynchronous topologies are much more forgiving in this respect since you can’t short anything. So an easy solution would be to start up and shut down in asynchronous mode. We can easily make this an asynchronous converter in software by just not utilizing the bottom fet. The diode in parallel with it will then automatically take over.

Unfortunately we cannot start up in asynchronous mode. Why? To enable the upper fet we need a bootstrap voltage above the input voltage. And we don’t have that unless the converter is running. It’s a chicken and egg problem, really. So we need to start up in synchronous mode at least for a few switching cycles for the bootstrap diode to charge up.

That’s exactly what the startup routine does. It completes 16 cycles in synchronous mode at a neutral duty cycle. What do I mean by neutral? Simple: Duty Cycle = Output Voltage / Input Voltage. That means no current actually flows on average. So this is a nice, soft way to start up. After those 16 duty cycles the buck enters asynchronous mode. As the screenshot above shows, the bootstrap capacitor is fully charged after just one full duty cycle so that number is more than sufficient.

This routine is critical. If it doesn’t do precisely what it should chances are high that the buck is destroyed. So I’ve checked it carefully by both looking at the code and the scope. I’ve run it many times and observed closely what it does just to be sure it starts up nicely very time.

Why run in asynchronous mode? Because it’s more efficient at low power levels. Once the current rises above a software-defined threshold the converter will change to synchronous mode. If the current later falls below a second (lower) threshold, the buck changes back into async mode.

The optimal values for the two threshold will have to be determined experimentally but will likely be in the range of a few hundred milliamps.

buckturnoff

The shutdown sequence is simple. The buck is shut down if the current falls below a very low threshold (say, 10mA) below which it cannot run profitably. If the current falls even lower we are better off shutting down the buck and entering a low-power mode. Since the current is low when we shut it off, the converter is already in async mode. So shutting it down is now easy and uncritical. We just turn off the top fet and can then also turn off the timer and supply voltage to the buck. The screenshot above shows an example of that.

Conserving power

A main feature of this solar charger is it’s ability to (hopefully…) run at a very low (<100microamps) current when not in use. So we obviously need to turn off everything we don’t need and run the PIC at a much lower frequency as well.

The PIC’s maximum operating frequency is 48MHz. This is the frequency it runs at when the buck and/or USB (not yet implemented) is on. These two features need that clock frequency to perform their task.

If both the buck and USB are off we can clock the PIC down to 8MHz which already saves a great deal of power. At 8MHz we can still do everything else, including running the user interface. Updating the display and particularly calculating the display content consumes quite some computation time and so we need a few MHz to do this.

If the user interface is not used for a certain time (say, 10 seconds), it is turned off. We can then lower the board voltage to 2.3 volts and lower the CPU frequency even further to 32.768kHz.  This is the frequency of the real-time clock that is running anyway. At such a low frequency the PIC’s computational power is low but still sufficient to do some housekeeping tasks.

One can wake up the user interface at any time by pressing the push button. Turning the encoder won’t help because that, too, has been powered off.

While in this low power mode every 6 seconds the board voltage is raised to 3.3 volts and all temperatures as well as the input and output voltages are measured. That all happens at 32.768kHz. After the measurement is complete the PIC decides if the panel voltage is high enough to start harvesting energy or not. If this is not the case the board voltage is lowered again and a new set of measurements is captured 6 seconds later.

img_4336

Despite all those efforts the board consumes something like 530 microamps which is much more than it should. About 100 microamps comes from the voltage divider used to measure the panel voltge. That’s an easy to solve design problem that I’ve described earlier already. But that still means that something is drawing 400 microamps. Not much at all but still way too much.

I’ve spent an evening trying to find the problem but I still don’t know. I’ve suspected the capacitors but when I measured some spare caps of the same type they hardly drew any current at 12 volts. I also un-soldered the buck’s mosfet driver but that made hardly any difference so that’s also not the problem. It may even just be some near-short on my board homemade board. So I leave that for now and check again once I have a revised design with a proper PCB.

Buck testing

I’ve saved the most interesting part for last 😉 I’ve established before that this converter has a similarly high efficiency than the Arduino version published some time ago. But at that time I was only able to test up to 35 or so watts.

This solar charger is capable of handling much more power than that. Testing how much was a bit more difficult than expected. Unless the battery is very empty it won’t draw as much as this charger is able to provide. And you don’t want to discharge a lead acid battery too much, they don’t appreciate it at all. So once again my constant current dummy load came to the rescue.

img_4339

With the dummy load at one of the power outputs I was able to draw some serious current. I set the dummy load to 4 amps and the battery absorbed (or provided) whatever was left. Obviously, I can only do that for a limited amount of time until the dummy load gets too hot. It automatically shuts down once the heat sink reaches 70 degrees centigrade which is soon the case at 4 amps.

I let the charger draw 4.5 amps at a bit more than 17 volts for as long as I could. The coil got quite warm, slightly hot even, maybe something like 60 degrees. The mosfet only got lukewarm and I’m not sure if this was because of their own power dissipation or due to their proximity to the coil.

img_4341

So from this test I’d conclude that this was about the power which the charger can handle for a prolonged period of time. So I think something like 75 watts is a realistic power rating.

I’ve also had another look at the datasheet of the coil and it pretty much confirmed my findings. 75 watts at (say) 13 volts output corresponds to 5.8 amps through the coil. The datasheet states that the coil starts saturating at 8.2 amps which means we’re still safe with 5.8 amps plus the ripple current. The datasheet also states a 40 degree temperature rise at 5.3 amps. So thermally the coil is pretty much at its limit at 75 watts. That, too, seems realistic to me having touched it after some time at that power.

The road ahead

So how to continue? As we have seen, there is a number of design issues but the general concept works. During testing and debugging I’ve cut and re-soldered many traces and also made some modifications like the one with the n-fet described above. I’ve unsoldered and changed many components as well. All of that doesn’t improve the reliability of the board. At some point it makes sense to design a new version, build it and take it from there. A clean slate kind of.

I think this point has been reached here. So I will work on a new revision from now on. The concept won’t change at all but I’ll try to apply what I’ve learned so far. I also hope to reduce the number of different components, reduce the size and total cost while not sacrificing performance. In other words move a step towards a design that may one day be built as a small series. Let’s see.

Low Power User Interface

20161007_userinterfacereva_001

As you may have noticed I’m quite busy working on the MPPT Solar Charger project. The latest version uses a 4 lines x 20 characters LCD that connects via I2C as well as a rotary encoder with a push button.

20160904_solarcharger_006

While the display got its own little board, the encoder connected directly with the solar charger where its signals aredebounced in hardware and then routed to the PIC.

20160905_solarcharger_015

After a few little fixes (see my last post) that worked but I had to use the signal intended for controlling the  backlight brightness for the display’s reset signal. I don’t want to run any more wires to the display and there are no spare pins on the PIC anyway so I had to come up with another solution.

20160905_solarcharger_017

And it was not very elegant that the display was powered off by just cutting the entire power supply. Having a digital enable/disable signal would be preferable

20161012_userinterfacereva_014

Design a universal User Interface

I then decided to design an new board that also includes the rotary encoder with all the necessary debouncing. That way I get a quite universal, easy to use user interface that I can use for other projects as well. That eliminates the need to design the same functionality (think debouncing) again and again. The size of the board is mainly given by the size of the display so there is plenty of board space.

20161012_userinterfacereva_011

So far so good but that doesn’t solve the actual problems yet. I still need a way to control both the backight as well as the reset signal without needing any more singnals. Since the display connects via I2C it was quite straight forward to use I2C communication for those purposes as well. My first thought was to add a I2C port expander just like I’ve done on the solar charger board. Those chips aren’t expensive but they typically provide 8 or 16 extra GPIO pins which seemed a bit wasteful. And PWM control of the backlight would require a great deal of I2C communication which puts a burdon on the microcontroller.

20161007_userinterfacereva_002

I also considered adding a sub-dollar PIC16 which could be programmed as an I2C slave and control both the backlight and the reset signal (as well as giving the option of getting the encoder input via I2C). But I wasn’t eager to write any software for this thing.

20161007_userinterfacereva_003

Requirement: Ultra Low Power State

Another design requirement was to keep this a very low-power design. To be sure: when the display and especially the backlight are on it will consume several milliamps to several dozen milliamps. Illumination doesn’t work without power, such is life. But when the user interface is not in use, we need a way to put it in a very low power state where the display as well as the rotary encoder is off but the push button still works in order to wake up the microcontroller. In that state the user interface must not use more than a few microamps. Furthermore the encoder signals must assume a high impedance state when the user interface is disabled.

20161012_userinterfacereva_012

My final solution was as follows:

  • Use the previous (backlight) PWM signal as an enable signal. Power can now always stay on. When the enable signal is high, the display is on, when enable is low, the user interface goes into its low-power state.
  • Add a dual I2C digipot to control both the reset signal as well as the backlight.

The reset signal is connected directly to the wiper of one of the two digipots. Of course any intermediate digipot values don’t make sense. The digipot should always be either at its minimum or its maximum.

The backlight brightness is controlled by the other digipot via an op-amp and a n-channel mosfet.

The debouncing is basically unchanged. Like in the solar charger design, a 74HC126 quad tri-state buffer is used together with some resistors and capacitors.

Since there are 4 gates on the 74HC126 and I only need to debounce 3 signals, there is still one gate left. I used that gate to power the display as well as the encoder and the encoder’s gates(without the push button which is always powered on). So the enable signal only controls the input of that gate. I thought that’s a nice and elegant solution. Well, if you think so too, think again. More on that later.

Testing

20161007_userinterfacereva_010

First of all nothing worked at all. I asserted the enable signal and nothing happened. Nothing was powered on. The error was soon found. I made a design error with the result that the respective gate was permanently in a high-impedance state. Somehow I had tied the gate’s enable input to ground instead of VCC. The mistake was corrected by cutting the ground connection and conecting the respective pin to the enable singal itself which was available from the pin right next to it. Not pretty (see below) but problem solved.

20161007_userinterfacereva_006

Then ok, power was there but when I tried to turn off the reset singal (i.e. pulling the reset signal high) nothing happened – again. Again, the reason was simple. The digipot’s upper terminal was floating instead of being connected to VCC. On the schematic the wire touched the respective pin but there was no connection. While that was really hard to notice on the schematic I should have noticed the problem when I laid out the board. There was obviously no connection to that pin.

20161007_userinterfacereva_007

This was a bit harder to fix than the previous error. There were no signals to cut but the digipot’s pins are much more closely spaced and the right signal was not to be found nearby. I ended up soldering a thin wire accross the digipot to a resistor that is connected to VCC on the upper end.

20161007_userinterfacereva_005

Even less pretty but problem solved anyway. Turning on the backlight basically worked as intended but the load was a bit much for the 74HC126. While it can supply up to 35mA according to the data sheet, its output voltage is nowhere near its positive supply rail when it supplies that much current. Even with a more modest 5mA load the gate’s output voltage was about half a volt below the input voltage. As a result, the display as well as all the other components only get to see about 2.8 volts instead of 3.3. This didn’t pose any problems so far but it’s not nice.

Another issue I noticed was that the LM321 op amp I had chosen is not a rail-to-rail op amp. The LM321 is inexpensive and I had quite a few left from another project so I used it without giving it much thought. I measured that the output voltage doesn’t get closer than about 1.4 volts of the positive supply rail. Since the n-mosfet used to control the backlight has a very low threshold voltage that didn’t pose a problem but the LM321 is not really a good choice here. While it does work from as little as 3 volts it’s made for split supply and higher voltages, say plus/minus 12 volts. I’ll use a low-voltage rail-to-rail type next time.

Software

Getting any MIDAS I2C display to work is a nightmare. They make nice, pretty and affordable displays. That’s why I buy them. And once you’ve managed to properly initialize them they are easy to work with. But getting them initialized with the right settings is always a lengthy trial-and-error process. I’ve ranted about that before but I feel the need to do it once again.

The entire initialization sequence needs to be written in one single I2C transmission. At least for me it didn’t work otherwise. The data sheet says absolutely nothing about that.

userinterfacestartupsequence

The data sheet doesn’t even mention the initialization sequence. Nor the timing of the reset singnal. The reset signal needs to be pulled low for 10ms. One then needs to wait for 5ms before the initialization sequence is sent. There is not one word about that it in the current datasheet. There is an older version in the net somewhere that mentions those timing issues and at least gives a sample initialization sequence.

userinterfacestartupsequence2

There are various contrast settings that must be set properly via I2C commands but there is very little information on those commands in the data sheet. I wrote an email to their customer support asking if there is a list of commands the display supports. That was more than a month ago and I still didn’t get any answer. As so often, google was my friend and others have faced similar problems before so I managed to find some commands that make the display work properly. I’m sending 10 or so bytes to the display but for most of them I have not a clue what they actually mean or what they are supposed to do. And the commands for this black-on-white display are different to the (otherwise identical) white-on-blue display. Have fun…

Debouncing

I’ve devoted one of my very first posts to the much-neglected issue of debouncing. The logic is pretty much the same here except that I use different (non-inverting) gates here. The reason for that is the need for 3-state outputs as mentioned before.

debouncing_pushbutton_press

Unfortunately the 74HC126 doesn’t have schmitt-triggered inputs so I need to implement the necessary feedback myself via the 680k resistors.

Debouncing something like a pushbutton is quite easy. Just use a relatively long time constant (i.e. large resistors and capacitors) and all will be fine. That will introduce some delay in the output signal but as a rule of thumb anything below 50ms is not noticable. And a time constant of a few milliseconds is totally sufficient so you might end up with something like 10ms of delay. No human user will ever notice it and it’s more than enough to perfectly debounce any switch that I’ve seen.

debouncing_pushbutton_release

With rotary encoders things get much trickier. The basic circuit is exactly the same but choosing the right component values is more difficult. You can’t press a button more than a few times a second but a rotary encoder might produce pulses just milliseconds or even less apart.

debouncing_ccw

So you face the challenge of debouncing the signal while still letting relatively fast transitions pass. If you use a time constant of a few milliseconds like with the push button you will not be able to detect when the encoder is turned quickly.

debouncing_cw2

The data sheet of the Burns encoder I’m using here recommends using two 10k resistors together with a 10nF cap. I’ve increased the value of one resistor to 22k but have otherwise followed that recommendation.  So the time constant is now a few hunderd microseconds.

debouncing_ccw2

Toghether with the positive feedback via the 680k resistors that works very well. I expected to tweak those values a bit but found that they work so well that I just leave them as they are.

debouncing_clean

I’ve inserted plenty of scope screenshots here to give you an idea of what the undebounced and debounced signals look like. Even with the same encoder there’s plenty of variation as you can see. But with the hardware debouncing applied here we get a clean, digital output singal nevertheless.

debouncing_typical

Power consumption

Very low standby power consumption was one of the key design goals. When in low-power mode only the push button pull-up and the 74HC126 is supplied with power. Everything else, the display, the op-amp, the digipot and the pull-up for the rotary encoder are all completely powered off.

As long as the push button is not pressed, no power flows there so the only power consuming device is the 74HC126. Its datasheet specifies a maximum static current consumption of 8 microamps (worst) at room temperature.  There’s no typical figure so that’s all the information I had. When I measured it, this is what I got.

20161012_userinterfacereva_018

That’s 4 nanoamps  at 3.3 volts which is nothing really. Actually the measurement fluctuated between about 0 and 15 nanoamps. I thought something is not hooked up correctly but when I pushed the button the current jumped to 326 microamps which is just what I expected since there is a 10k pull-up resistor conected to that button.

20161012_userinterfacereva_019

So the measurement works and it seems that the 8 microamps given in the data sheet are just a very conservative worst case. I mean CMOS is close to zero-power when static and only a single tri-state gate is active so essentially no current flows. Cool.

Next steps

After the two hardware fixes this user interface works quite as intended. Using the spare gate to supply the rest of the circuit with power was not as good an idea than I thought. On the positive side the debouncing works just perfect with the chosen component values. And as mentioned, the op-amp was not a great choice for the job at hand.

But I like the look and feel of this universal user interface and think the overall concept is good. So there will be a Rev B of this board with those issues solved.

Here you find the eagle files as well as PDFs of the schematic and board. The two errors are already corrected but I haven’t actually built them so check carefully yourself. I’ve also re-exported the gerbers so they, too, already include the fix.

MPPT Solar Charger Testing

20160927_solarcharger_036

In a previous post I have presented a design for an MPPT Solar Charger. In the mean time I have built a prototype and also wrote some software for it. So today I’ll go through my findings of what works well and what needs to be improved. And yes, there are some flaws in the design…

The software is far from final but with the notable exception of USB all the basic functionality has been implemented.

Power Supply

20160904_solarcharger_002

One of my main goals with this design is to archieve very low standby current, somewhere in the tens of microamps. The basis for this is a low-power buck on the basis of a Texas TPS62120 where the microcontroller can switch the output voltage between 2.2 and 3.3 volts nominally. This works as intended. With no load and the output voltage low, the supply consumes 12.9 microamps at 12V input voltage. With the high output voltage the idle current goes up to 14.3uA. Quite a bit of that current is due to the voltage divider that sets the output voltage. The regulator itself consumes about 9uA in both cases.

Microcontroller

20160928_solarcharger_045

The PIC18F26J50 starts up using the primary oscillator’s 8MHz crystal with the internal PLL disabled. It can then switch to 48MHz operation by enabling the PLL or to the secondary oscillator running at 32.768kHz. The latter is always running since it also serves as the clock source to the real-time clock and calender (RTCC). Switching between clock sources as well as the RTCC have been implemented in software and work fine.

I2C Multiplexer and Port Expander

20160928_solarcharger_046

The microcontroller doesn’t have enough GPIO pins so a I2C port expander (Microchip MCP23008) is used to give us another 8 pins. The display is connected via I2C as well but since the display is entirely powered off when not in use, the display cannot be on the same bus. Otherwise it will pull the SCL and SDA lines low and block the bus. The NXP PCA9546 multiplexer takes care of that. Both devices, the mux as well as the port expander work as they should.

Voltage Reference, Temperature Sensors and Fan

20160904_solarcharger_004

There is a total of 3 temperature sensors, one on the board and 2 external ones. The temperature is measured by the PIC directly so it has a 2.5V voltage reference in order to get meaningful results. At room temperature all three temperature sensors deliver very similar results, typically within a few tenth of a degree. Better than expected. The fan output can also be enabled if the on-board temperature gets too high.

Voltage and Current Measurements

20160928_solarcharger_047

The more important measuements, namely the input and output voltages and currents are performed by a MCP3424 4-channel 18-bit ADC. I was already familiar with that type so I quickly got it to work. In this application I don’t use its internal PGA (programmable gain amplifier) or rather I leave the gain at 1. All the measurements are done with 14bit accuracy which is reasonably fast (23ms worst case) and sufficient here.

User Interface

20160904_solarcharger_006

The debouncing of the rotary encoder works ok but I’ll tweak the resistor and capacitor values a bit when I get time. The push button is uncritical but there is a bit too much debouncing for the rotary encoder itself making it miss some very fast turns. But it already performs reasonably well as it is.

The display module is the first real flaw in my design. It has 5 wire connections: GND, VCC, SDA, SCL and Backlight. The idea was to turn the display off by simply cutting off VCC when the display is not needed. When in use, the brightness of the backlight is then controlled by the Backlight PWM signal.

20160905_solarcharger_015

Since the display needs quite a few supporting components (mainly 1uF capacitors) and has no mounting holes I made a little one-sided PCB for it. When I first tried it nothing worked. A ground connection was missing and I didn’t notice that in Eagle because in Eagle it was a double-sided board. That was easily fixed by a short piece of blank wire soldered in place. So far so good.

Unfortunately the display (a Midas MCCOG42005A6W-BNMLWI) still didn’t work. Besides the data sheet being a nightmare it needs to be reset after having powered up. So you need to power it up, wait for a while and then do a reset by pulling its reset pin low. So just pulling the reset pin high with a resistor like I have done won’t work. My solution for now was to connect the backlight signal to the reset pin. So I can now use the display but the backlight brightness is permanently  at it’s maximum.

20160905_solarcharger_017

I already have a new and hopefully better version of this display unit in the making and there will be a separate post on that. My idea is to have a rather universal module that I can use in other projects as well.

USB Charging

20160928_solarcharger_049

The USB charging module works reasonably well. When pulling the full rated current of 2A it gets rather warm but doesn’t overheat. I was able to pull 2.5 amps for a prolonged period of time without any issues. I only had a Samsung A5 to try but at least that phone charged perfectly fast pulling around 1A of current. With that load the module only gets slightly warm.

20160927_solarcharger_038

Turning the USB charger on and off in software also works as planned. This can now even be done via the user interface – see above.

Power Outputs

20160928_solarcharger_053

The 4 power outputs can be controlled in software. In order to save power, the mosfet drivers can be powered off if none of the outputs is on . All that is already implemented in software and the outputs can be turned on and off individually via the user interface.

20160927_solarcharger_037

I plan to implement a low-frequency (say, 100Hz) PWM functionality for these outputs in order to e.g. control some LED lighting but that has not been done yet.

EEPROM

20160927_solarcharger_042

I haven’t implemented any data logging functionality yet but I have written a few library functions for the EEPROM. When the date and time is set via the user interface those values are saved to EEPROM and restored after a reset. Reading from and writing to the EEPROM therefore works.

20160927_solarcharger_041

Solar Charger

Yes, I’ve left the main thing for last. Don’t know why.

20160928_solarcharger_051

When I first assembled the board I noticed that I had ordered the wrong mosfet driver – a MIC4605-2 instead of a MIC4605-1. They are near-identical except the fact that the -1 has two independant inputs while the -2only has one PWM input plus an enable signal. That also works but doesn’t give us the option to run the converter in asynchronous mode. So I’ve unsoldered the chip again and replaced it with the MIC4605-1 that I had in mind when I designed this thing.

20160928_solarcharger_050

As you can see on the photos above, I’m now using a 22uH coil, not a 68uH coil as shown in the schematic. The reason for that is that I’m using a relatively high switching frequency of 48MHz / 256 or 187.5kHz. That high switching frequency enables me to use a lower value inductor which massively increases its current rating while pyhsically being the same size. Since the inductor was the limiting element in this design before this significantly increases the power rating of this solar charger. The previous version was (very conservatively) rated at 30 watts only. With the new 22uH inductor this very similar design can handle something like 75 watts. I need a more powerful power supply to do some serious testing but at 35 watts it’s getting slightly warm at the most. I’ve only done some quick and dirty testing but efficiency at 35 watts is around 97%. That means we are only losing about 1 watt which is the reason the charger barely gets warm.

20160912_solarcharger_026

There will likely be another post focussing only on the charger itself so I won’t go into more details here. The code regarding the buck is extremely basic and potentially dangerous at this point. I’ve killed the bottom mosfet twice due to the not very graceful way the buck turns off. If it turns off while the bottom fet is on, that fet will stay on, effectively shorting the battery to ground. At least that’s my explanation at the moment.

20160927_solarcharger_033

Oh yes, there’s another issue with the buck as well. With the battery at its output there will always be the battery voltage minus a diode drop at its input where the panel is connected. So when there is no sun, the battery is powering the panel. I’ve tried that with a small 30W panel and the panel draws 8mA at 12 volts which several magnitudes more than we are willing to use when the charger is sitting idle. So the next version will have to disconnect the panel when the charger is off. And we will also need to disconnect the voltage divider at the charger’s input when we’re not measuring the voltage, just like we’re doing at the battery.

Summary

There are a lot of features on this board and getting them all to work properly requires quite a bit of work. But most of the heavy lifting has been done so I can now focus on improving the software.

20160912_solarcharger_030

First and foremost I need to work on the way the buck is controlled. First there needs to be a strict and safe procedure how this thing is turned on and off. I’m confident that there won’t be any blown-up mosfets once that’s done. Then I also need to improve the algorithm of how the maximum point of power is tracked. And I also want to implement asynchronous operation at low loads in order to improve efficiency. I’ll spend some time on all these issues next, looking at the signals on a scope and trying to improve things.

But all-in-all I’m quite happy with how how this design has performed so far. Yes, there are some issues but nothing that can’t be fixed with relative ease.

For those of you interested, the code can be found under downloads on the overview page. In my next post we will take a closer look at the display unit / user interface.

MPPT Solar Charger Design

I’m currently waiting for the boards for my Ultrasonic Anemometer Rev B to arrive from Hong Kong and this gives me some time to write about the MPPT Solar Charger design that I did quite some time ago. I published a series of posts on a Arduino MPPT Solar Charger Shield and got a lot of encouraging feedback. But that shield was more of a proof-of-concept than a finished product.  While it generally performed well it drew way too much current when idle to actually be deployed unless you can count on plenty of sunshine every day.

SolarChargerEagleTop

Aiming for very low power consumption

While I like the Arduino platform I had to admit that it’s probably not ideal for a low-power design. Yes there are some things you can do to reduce the 50mA or the Arduino draws but it will never be truely low power. So I designed a stand alone version with plenty of extra features that I hope to draw only a small fraction of the current. I particularly care about the idle current, i.e. the current it pulls when the solar panel is not producing any energy. In winter, the panel might be covered by snow for weeks and you don’t want your charger to drain the battery during that time. With this new design I’m aiming for an idle current in the tens of microamps. Even if it ends up being 100 microamps that is still 500 times less than an Arduino uses just by itself. And that means it draws less than 1Ah (ampere-hour) per year so you will never drain the battery no matter how little sunshine there is.

SolarChargerSchematic1

PIC18 series microcontroller

At the core of the design is a PIC18F26J50 in a 28 pin SOIC package. It’s capable of running at down to 2.15 volts and consumes extremely little power when running at lower clock speeds. And apart from that it features USB so we can have all the benefits of USB without any external components except, of course, a USB socket.

The PIC has two crystals at its disposal. A 8MHz crystal which will be boosted up to 32MHz by its internal PLL. That’s what the PIC will run on when there is work to do. And then there is a 32.768kHz crystal that will be used to run its real-time clock (RTC). When there is little to no work to do this low-frequency clock will also be used to run the CPU which will greatly reduce power consumption. Power consumption is approximately linear in frequency so this should cut power consumption by a factor of about 1000 compared to full-speed operation.

SolarChargerSchematic2

Switch mode power supply

Now we can run the microcontroller at only a few volts but our power supply is a 12 volt battery. So one of the most straight forward things to do in order to save power was to use a switch mode step-down regulator aka buck.

I looked around and found the Texas TPS62120. It’s only capable of providing 75mA but that’s more than enough for us in this case. It works at a switching frequency of 800kHz and only consumes a bit more than 10 microamps with no load at its output.

It needs a 18uH inductor as well as some ceramic capacitors to work. The output voltage is set via a pair of resistors acting as a voltage divider. I’ve added a n-channel mosfet that allows the PIC to increase the output voltage from 2.2 volts to 3.3 volts when needed. Because while the PIC can run on down to 2.15 volts the display can’t. And even the PIC needs 3.0 to 3.6 volts for USB operation.

Synchronous / asynchronous operation

The actual MPPT converter has changed only little. I’ve changed the mosfet driver to a MIC4605.  Unlike the IR2104 used last time, this model has adaptive dead-time (as opposed to the longish 540ns fixed) and separate inputs for each mosfet. This will allow us to either operate in synchronous (using both mosfets) or asynchronous (only using the upper fet and relying on the diode) mode. Asynchronous operation has a certain efficiency advantage at low power levels so this might come in handy.

The MIC4605 consumes quite little quiescent current for a mosfet driver, only 100uA typical. But that’s still too much for our purpose. So the PIC can power the whole thing off via a NPN transistor and a p-channel mosfet. That BUCK_ON signal also serves as the supply voltage for the INA213 current sensors already used in the last version. So the entire converter can be powered off and should consume precisely zero current when not in use.

What about the voltage divider necessary to measure the battery voltage? That’s been taken care of, too. That divider is interrupted by a (low threshold voltage) n-channel mosfet unless a signal from the PIC turns on the mosfet and closes the circuit.

SolarChargerSchematic3

Port expansion

I soon ran out of GPIO pins with that PIC so I had to add an I2C port expander (MCP23008) to gain another 8 I/O pins. I’ve also added a PCA9546 I2C switch in order to translate between different voltage levels.

It’s probably not the most elegant solution and a future version might trade these 3 chips for a higher pin-count PIC. But I had all components here already so that’s what I’ll use for now.

Precise measurements

In order to precisely measure input and output voltages and currents there is now a MCP3424 4-channel 18-bit ADC. To be sure, we don’t need 18 bits of precision here but we’ll trade some of that precision for speed and work with 14 or 16 bits.

The ADC has its on-board voltage reference and PGA with gains up to 8.  Since it only consumes a maximum of 1uA in standby mode it is always powered on.

There are also a total of 3  LMT86 temperature sensors, one on the board and 2 external ones. The external ones are intended to measure the temperature of the panel and battery, respectively. The maximum voltage for a battery is quite dependent on temperature so that’s a useful information to have. The inputs from the temperature sensors are measured directly by the PIC.  For that purpose there’s also a ADR361 2.5V voltage reference.

Measuring temperatures requires the board voltage to be high, 3.3 volts nominally. So both the voltage reference and the temperature sensors are only powered on when then VCC_HIGH signal is set.

User interface

To communicate with a human user there is a 4×20 LCD display that is controlled via I2C in order to save some I/O pins. There are quite a few external components needed to run it at 3.3 volts so it has its own PCB and connects via a 5-pole wire. There is 3.3 volts and ground for power, SCL and SCD for I2C communication and a PWM singal in order to control the display brightness. Because that’s a rather universal board I will document that as a separate post.

As an input device there’s a rotary encoder with push button. Together with the display (and some decent software) that should allow for a pleasant user experience.

The inputs from the encoder are debounced in hardware via a 74HC126 that serves a double purpose. With its 3-state outputs it allows us to use the pins that are otherwise used for in-circuit programming of the PIC.

Both the rotary encoder (except the push button) and the entire display unit can be powered off when not in use. The push button is always powered on so the user can wake up the user interface at any time by pressing the button. When the user interface is not actively powered on the 74HC126’s outputs are in high-impedance mode and the PIC can be programmed without being affected by the rotary encoder.

SolarChargerSchematic4

Data logging

One might be interested how much energy has been harvested by the solar charger over the last hours, days, weeks or months. So there’s some non-volatile storage as well. The 24FC256 connects via I2C and offers 256kBit of memory. It consumes only 100nA in standby so it can stay powered on at all times.

Fan control

As mentioned, there’s a temperature sensor on the board. If it gets too hot, a fan can be powered on via the FAN_ON signal controlling an n-channel mosfet.

Outputs

There are 4 power outputs, each controlled by a separate signal from the PIC. There should be some PWM modules left on the PIC so some (two I think) can be PWM controlled. A typical application would be LED lighting which can be controlled and dimmed directly from the solar charger via the rotary encoder. Each output channel has a beefy  mosfet of the same type as the MPPT switcher (IPB136N08N3).

Each has its own FAN3111E mosfet driver. They have a separate input for the reference voltage so the PIC can easily control them when running at only 2.2 volts. The FAN3111 should only draw 5uA (10uA max) when idle but there are 4 of them so they can be powered off (all togeher, not individually) when not in use.

SolarChargerSchematic5

USB charging ports

One of the first thing one wants to do when there is power is to charge one’s cell phone or similar device. So there are two USB charging ports capable of delivering some 2 amps of current at 5 volts in total.

They are powered from the 12V batter via a TPS54231 buck converter. So there are a total of 3 buck converters on this board… It is always connected to the 12V rail but the PIC can turn it off when not in use. The regulator’s shutdown current consumption is only 1uA typical (4uA max) so that should be adequate.

Manufacturers of mobile devices have all come up with nasty ways of making their devices incompatible with other manufacturer’s chargers. They basically abuse the otherwise unused (for charging purposes) data lines to recognize their own chargers and discriminate against any others. That might mean they won’t charge at all or only at a slow rate.  So there are two charging ports on this board, one emulating an iPad charger and the other one a popular Samsung scheme. So pretty much any device should be able to charge on at least one of these ports at a reasonable speed.

Summary

As you can see, there’s a lot of functionality in this new design just waiting to be unlocked by some clever software.  I’ve already milled a board and I’m looking forward to populating it and bringing it to life. I guess that will be quite a bit of work but I think its well worth it. Thanks to all of you who have kept asking about this project – I very much appreciate all your feedback.

There are only Eagle files (including PDFs of the layout and schematics) at this point. They can be downloaded on the overview page. There’s now also a prototype. First test results are presented here.