Tag Archives: electronics

PWM Dimmer for LED Lighting

20160119_Projekte_046
Finished LED dimmer

I have recently moved to a new apartment and was looking for a PWM dimmer to control some 12V LED strips. I thought that should be easy enough nowadays but it proved more difficult than I thought. All I found either didn’t meet my requirements, were uggly or expensive. So I decided to build my own, tailor-made to my needs.

20160119_Projekte_044
Finished PCB mounted below a shelf

 The requirements

  • Handle 100W @ 12Volts comfortably
  • Controlled by a simple on-board pot (no remote control or the like)
  • Affordable
  • No acoustic noise
  • Fine-grained control down to very low brightness levels

I’ll go through these requirements one-by-one.

20160119_Projekte_040
Two LED strips below the shelf give a nice lighting on the desk

Handle 100W @ 12Volts comfortably

My LED strips suck up a bit more than 20 Watts per meter and there is a maximum of 4-5 meters of LED strips per dimmer so I need a power rating of around 100W. If you do the math you’ll find that there will be a maximum current of about 8.3 amps.

I don’t want this thing to get hot nor do I want to put a heat sink on it. So the total power dissipation in the dimmer should stay below, say, 1 watt. So if we use a single FET, we need a Rds-on of 14.5 milliohms. Thats not a lot but there are inexpensive MOSFETs that meet this requirement. And we can always parallel two or more of them if necessary.

And yes, there will also be some switching losses but they should be low given the modest switching frequency of an application like this.

20160119_Projekte_048
PIC microcontroller with its power supply

 Controlled by a simple on-board pot

This is most likely the simplest way of controlling a dimmer but it’s surprisingly hard to find. A lot of commercially available dimmers come with IR remote controls nowadays. And some of the higher quality models expect a 0-10V control signal which means that you have to use an external pot which you have to mechanically attach somewhere. I would like everything on a single PCB to keep things simple.

Affordable

I needed 3 of these things so cost was a factor, too. All the nicely-made dimmers I could find were priced at $50 and uppwards. Not that bad but I figured that I could make my own for a small fraction of this, perhaps $10.

No acoustic noise

We all know those dimmers that produce audible humming. Especially when dimmed somewhere half-way down. I hate it. Drives me crazy.

This proved to be more difficult to archieve than I thought. More on this later.

20160119_Projekte_054
Since the power supply has 4 output leads, my dimmer has a 8x connector at its input

 Fine-grained control down to very low brightness levels

This is where most products fail miserably. Most of those remote-controlled things only have 8 brightness levels. And just about everything I found works linearly which makes very little sense if you ask me. We humans perceive brightness logarithmically, rather than linearly. So going from 1% to 2% seems the same as going from 50% to 100%.

20160119_Projekte_050
Beefy mosfet and capacitor

Linear control will not give you fine control at the lower end. Ideally, you want to have an exponential transfer function from pot position to PWM duty cycle to compensate for the logarithmic nature of the human vision. I found the easiest way to do this was using a microcontroller. Furthermore, the ability to do all of this in software enables you to play around with it and find a transfer function that you’re happy with.

High granularity at the lower end also means that we need quite a bit of PWM resolution. The common 8-bit resolution translates to about 0.25% per step. Going from 0.5% (wich is about what I mean by very low brightness) to 0.75% is already quite a step. Many microcontrollers are capable of 10 bits which is 4 times better and probably good enough.

20160119_Projekte_045
Yet another view

The design

At the center of my design is a 8-bit PIC microcontroller, a PIC16F1936. There’s not much special about this particular model, it’s just a type I’ve used several times before and still had some on stock.

A LM2931 provides the PIC with 5 volts from the 12 volts input voltage. I use the LM2931 as my standard 5V regulator. It’s pin compatible with the legendary 7805 but survives input voltages in the range of -50 to +60 volts making it very robust against transients.

20160119_Projekte_051
A LM2931 generates 5V from 12V

The PIC controls a LM5111 dual FET driver that provides a powerful 12V gate drive to a pair of Infineon IPB136N08N3 N-channel MOSFETs. This is the same transistor that I’ve recently used for my Arduino Solar Charger Shield. Its an inexpensive (< $1), large SMD type with an exellent Rds-on of 11.5 mOhms.

There are several variants of the LM5111. It comes in inverting and non-inverting configurations as well as combinations of inverting and non-inverting. At Farnell, the the inverting ones were by far the cheapest so that’s what I’m using here. It doesn’t really matter since you can change the polarity in software as needed.

20160119_Projekte_053
Pot and one of the output drivers

Why am I using two FETs despite the fact that one could easily handle the entire current? First, I’m driving two LED strips with this dimmer and using two transistors simplifies the layout so I have two outputs exactly where I need them. Secondly, the LM5111 is a dual FET driver anyway so I get the second gate drive for free.

20160119_Projekte_049
Nice 2kOhm pot

I’ve provided each output with a generous 1.5mF capacitor in order to shield the supply from the ripple that is inevitably produced by the PWM. I’ve also taken care to use a cap with low serial resistance (ESR) and a high current rating. The Panasonic FR series fulfills both of these requirements while being good value for money. I thought this should be enough to avoid excessive ripple and therefore also acoustic noise.

20151129_Projekte_012
Top side of the long version

The input to the PIC comes from a quite nice 2 kOhms pot that I’ve recovered from some scrap. There is also a voltage divider to measure the 12V input voltage. The idea was to only enable the output once the input voltage has stabilized but I found this to be a quite unnecessary feature when programming the PIC.

20151129_Projekte_011
Bottom side of the long version

 The Layout

20151129_Projekte_008
Top side of the short version

I’ve built the two different versions of this dimmer. The schematic is exactly identical for both of them, they only differ in their physical layout and board dimensions. I’ve just tailor-made them to their specific application so the pots are located in a handy position and the outputs are exactly where I need them.

20151129_Projekte_009
Bottom side of the short verison

 Software and Testing

My first version of the software measured the voltage from the pot using the on-chip ADC and outputed an identical 2kHz PWM signal on both outputs. 2kHz should be enough to avoid visible flicker and seemed a reasonable choice. Everything worked but the power supply made quite a bit of noise over most of the brightness range. Worse than any commercial design. Even worse, there was an awful lot of flicker. Ouch.

Dimmer_2kHz_firstTry
Too much ripple producing lots of audible noise

Looking at the power supply output / dimmer input voltage on a scope if became clear that the two 1.5mF caps still allow too much ripple at this frequency.

The first thing I tried was running the two outputs out-of-phase. Since I’m using two FETs I have two independent outputs. So I can run them 180 degrees out-of-phase. Now, at  duty cycles below 50% it looks like I’m only driving a load half the size with a frequency and duty cycle twice as high. At precisely 50% duty the supply even sees a constant load at its output since exacly one LED strip is on at any point in time. At duty cycles above 50% the on-times overlap so the load only varies from 50% to 100% and with twice the frequency. As you can see from the scope screenshot below, this already helped a great deal but the problem was not yet resolved. So the natural thing to do was to increase the PWM frequency.

Dimmer_2kHz_phaseShift
Running the outputs out-of-phase helps

At 8kHz, things already looked (and sounded) much better. Ripple and acoustic noise were much reduced but the supply was still audible at least in a quiet environment.

Dimmer_8kHz
Increasing the PWM frequency to 8kHz almost solves the problem

So I moved the PWM frequency up as far as i could. Given the PIC’s 32MHz clock and a 10 bit resolution this was 31.25kHz. Now every last bit of audible noise was gone. Finally.

Dimmer_31kHz
At 31.25kHz all the noise is finally gone

I then noticed that the phase shift was 176 degrees as opposed to the intended 180 degrees.

Dimmer_PhaseShift_before
Phase shift is 4 degrees off

Not that this makes much of a difference in practice but I solved it anyway. I’ve implemented this phase shift by starting one PWM module at 128 and the other at 0 (we’re only talking about the 4 most-significant bits here, so the maximum is 255). The two instructions are on successive lines in my C code but 3 clock cycles are needed to process each of them so they are not enabled at the precisely same time. Starting the first PWM module at 131 has solved the problem as you can see below.

Dimmer_PhaseShift_after
Now the phase shift is fixed

With these changes in place the flicker mentioned previously was also much reduced but had not yet disappeared. Looking at the voltages on a scope for a while the problem became clear. I was measuring the voltage from the pot at fixed intervals that had no connection with the switching frequency. So I was effectively measuring at random points in time.

I said that the input voltage now showed much less ripple but some ripple is inivitable. Some of that ripple is likely to somehow feed through to the voltage from the pot. That introduced noise in the value measured by the ADC which lead to variations in the duty cycle which was noticable as flicker.

I did two things to resolve this. First, I’m generating an interrupt signal (from the same timer as I use for the PWM) every 64 PWM cycles. In the corresponding interrup service routine (ISR) I read (and save) the ADC value and start a new conversion. This way I’m always measuring at the same point during the PWM cycle. So the effect of the ripple should be similar every time. I’m also averaging 32 measurements which further helps to smooth the value I’m using to calculate the duty cycle. So flicker is gone as well as you can see below.

Dimmer_DutyCycle_stable
After averaging the ADC readings, the duty cycle stays rock solid

Now for the transfer function. My first try was exponential. The problem with that was that it gave away too much of the pot range for very low brightness levels. I played around with this for quite some time and finally settled for a combination of linear (at the very low end of the range) and exponential (for everything above that). Also, two of my dimmers can be fully turned off by turning the dimmer all the way to the left. Their power supply is always on and the light is only controlled by the pot so I need to be able to really turn them off (not only down). The third one has a slightly different transfer function that only allows to turn it down to 2% or so. That one has its power supply controlled by a conventional light switch so I don’t want the pot to completely turn it off.

Dimmer_DutyCycle_stable2
Same at lower duty cycles

 The result

After all, I’m very happy with the result. There is no noticable power dissipation on the board. There certainly is a bit of dissipation but the board doesn’t heat up noticably so I’d say its clearly below a watt.

The components have cost me around $10 per board. Some stuff like the connectors I have bought a flea markets, they can be surprisingly expensive through regular retail channels. The PCBs are home-made so they have cost me a considerable amount of time but not much in terms of cash.

20160119_Projekte_052
LM5111-2M is the inverting variant

They are, furthermore, controlled by a simple pot, produce no audible noise and can be finely dimmed just as planned. So I can proudly state that all the requirements have been met.

If you’re in need of a dimmer and have a soldering iron and a bit of spare time I can only encourage you to build your own. It’s not too hard, needs only few components and is very doable on a prototyping board if you don’t want to etch or mill your own board.

As always, attached is a zip file with all the eagle files, board layouts, schematic as well as the software.

Arduino MPPT Solar Charger Shield – Software

There have been two previous posts on this project: one on the concept and the hardware and one on hardware testing. You probably want to check them out first if you’re not yet familiar with this project. Or even better: Click here for an overview over this project.

20160212_Projekte_045
Maintaining an input voltage of 17 volts even if that means a lower-than-desirable voltage at the output

Now that we know that we have a functioning MPPT solar charger we are ready to talk about the software (or the sketch as the Arduino folks call it). It’s quite simple, really. So this will be a short post. And yes, you can download the sketch. There is a link at the end of this post. As always, I appreciate any feedback, comments and the like.

There is a number of basic tasks the arduino needs to perform in order for this shield to be useful. I’ll go through them one by one.

Controlling the DC-DC converter

At the heart of this project there is a synchronous step-down (or buck) DC-DC converter that is controlled by a PWM signal from the arduino. So one of the tasks is to set the frequency and duty cycle of that PWM signal.

We let the PWM signal run at the maximum frequency the arduino allows with an 8 bit resulution. Thats simply 16MHz (the Arduino’s frequency) divided by 256 (the 8 bit resolution), or 62.5 kHz. So the prescaler will be 1.

As you can see from the shields’s schematic, we need to output the PWM signal from Pin 6 (by the Arduino’s pin numbering, not Atmel’s). In order to do this kind of low-level stuff you’ll have to read the Atmega328’s data sheet. There is usually no Arduino-ish shortcut if you really need to controll what’s going on.

Luckily it’s just a few lines of code to set things up. All in the function buck_setup(). There are three more little functions to control the DC-DC controller once it’s set up:

buck_enable() and buck_disable() are very simple and just turn it on  and off, respectively. buck_duty(uint8_t duty) is only slightly more involved. It changes the duty cycle to the value you pass to it. Besides that it ensures that the duty cycle stays within certain limits.

20160212_Projekte_042
Test setup with resistor-based dummy load

You don’t want it to go to 100% since in order to keep the bootstrap capacitor C6 charged you need a little bit of off-time. In order to drive the upper FET you need a voltage higher than the panel’s voltage and that’s exactly what C6 is for. So we enforce an upper limit on the duty cycle.

Likewise, you don’t want your duty cycle to go below 50% because in that case you would be pumping energy from the battery to the pannel. A synchronous step-down converter is basically the same thing as a synchronous step-up (aka boost) converter with input and output confused. So we also want to enforce a lower limit on the duty cycle.

The upper and lower limits are set through the #defines DUTY_CYCLE_MINIMUM and DUTY_CYCLE_MAXIMUM.

Measuring voltage and current

The shield has all the hardware necessary to measure both voltage and current both at the input as well as on the output. We’ll just need to write some simple software to make good use of that hardware.

Unlike with the PWM singal where we had to do some low-level bit fiddling ourselfs we can just rely on convenient Arduino library functions to do the job. Basically, analogRead() is all we need here.

20160212_Projekte_043
Nicely regulating so that the input stays at 17 volts

I’ve written a function called read_values() that uses analogRead() to read all 4 values (input voltage, output voltage, input current and output current) 16 times each, averages the results and converts the ADC reading to proper voltages and currents.

The necessary multipliers are defined as floats in VIN_MULTIPLIER, VOUT_MULTIPLIER, IIN_MULTIPLIER and IOUT_MULTIPLIER. I’m doing all the voltage and current measurements in floating math. Yes, this is not at all efficient but we don’t need the Arduino’s computational power for anything else most of the time so this is fine here. Just keep in mind that you can save a lot of resources here if you ever need to do so.

Displaying voltage and current on the LCD

Our hardware also involves a 2 lines x 16 characters LCD so we can show the world what we are measuring. Again, we can rely on standard Arduino functionality to do the job. There is an LCD library that does everything we need.

So my function write_display() can focus entirely on formatting. The upper line shows the voltages in Volts, the lower line shows the currents in Milliamps. The input is on the left hand side of the display, the output on the right.

Deciding what to do

In the first section we’ve discussed the functions necessary to controll the DC-DC converter. But in order to use those functions, the Arduino needs to first decide what to do.

Vin21
66% duty cycle at 21V input voltage gives the desired 13.8V at the output

This is where the function buck_update() comes into play. You could consider this the heart of this sketch. This is where all the relevant decisions are made. When to turn the converter on, when to turn it off, when to increase the duty cycle, when to decrease it… You get the idea.

The behaviour of buck_update() is controlled by 8 #defines. I list them here together with the values I have used:

#define ENABLE_VOLTAGE 18.0
#define DISABLE_VOLTAGE 15.0
#define INPUT_TARGET_VOLTAGE 17.0
#define OUTPUT_TARGET_VOLTAGE_LOW 13.8
#define OUTPUT_TARGET_VOLTAGE_HIGH 13.9
#define INPUT_CURRENT_LIMIT 2000.0
#define OUTPUT_CURRENT_LIMIT 3000.0
#define INPUT_CURRENT_MINIMUM 0.0

I think they are quite self-explanatory, especially if you look at how they are used inside buck_update. It’s quite simple: If the panel’s voltage rises above 18V, turn the converter on. Once the converter is on, try to archieve a panel voltage of 17V without exceeding 13.9V at the output. If the panel’s voltage drops below 15V turn the converter off again.

Vin17
At 55% duty cycle with a 16.9V input voltage we’re getting only around 9.2V at the output

Besides that the function is also looking at the input and output current and makes sure certain limits are not exceeded. But with a 30W panel it should never be possible to reach those limits anyway.

Putting it all together

Now all we need to do in the loop() function is calling read_values(), buck_update() and write_display(). Since writing to the LCD is quite slow we are only doing it every 32nd time we read the values and update the PWM signal.

With this sketch I’ve hooked the MPPT Solar Charger up to my lab power supply. (a Keysight E3645A, my newest toy *g*) and my extremely simple but occasionally useful resistor-based dummy load.

The enable and disable voltages are simple and work as expected. Maximum output volage is also not tricky. If the voltage at the output goes too high, the duty cycle is decreased and everything is fine again.

20160212_Projekte_041
There’s not much to photograph when you’re writing and testing software

More interesting was to see how the shield would regulate when faced with a limited current budget at the input. For that the supply was set to a voltage of 21V (about a 12V solar panel’s open-circuit voltage) with a current limit of 100mA to 500mA. That’s quite a nasty supply, quite a bit trickier to handle than a real solar panel. Try to pull just a bit too much current and the voltage will drop to zero…

Also, the resistors at the output are not a realistic load for the converter. A car battery will pull no current at 12 volts or so (unless overly discharged) but will quickly start to sink large currents when the voltage goes just a bit higher and the battery is charging.

But I think the setup is good enough to test the sketch. And it handles the challenge quite well. With all resistors on (i.e a 100/6 ohms load) and a 300mA current limit, the input voltage sits at 17V (our target input voltage) while 9.25V appear at the output. At 400mA, the output voltage rises to 10.7V with the input still at 17V. At 600mA the input is still at 17V but with the output now at 13.15V. If I take the current limit even higher, the output voltage rises to 13.82V but not any higher, just as we want. The input voltage rises to 21V (since this is a lab supply and not a panel) with a corresponding drop in current to 530mA.

20160212_Projekte_044
Quite realistic: The charger is pulling as much current as it can with the current limit at 530mA and reaches an output voltage just above 12 volts

I’m honestly quite happy with the project as it is now. The idea definitely works and I’m motivated to design a new, deployable version with some fancy features that will use much less power at the same time. I’ve already done quite some work on that new version but it will take another few weeks until I get to describe that project here.

Until then I will show you some other, smaller projects that I’ve already finished but didn’t have time to document yet. So you will first see a number of smaller, simpler projects over the next few weeks.

Before I forget: There’s the Arduino sketch for download. And click here for an overview over this project.

Arduino MPPT Solar Charger Shield – Testing

20160203_Projekte_004
First tests are being performed on the Solar Charger Shield

In my last post I’ve introduced a proof-of-concept Arduino solar charger shield. I went through the hardware as well as the way it works – or at least is intended to work. It was prominently linked on dangerousprototypes.com as well as some other sites and got quite a bit of publicity as a result. Thank you all for sharing this post.

By the way: here’s an overview over all posts on this project.

20160203_Projekte_001
DUT hooked up to my Constant Current Dummy Load

This time I’ll show you some results of the testing that I’ve done. The basic test setup is shown above: The solar charger is hooked up to my home-brew constant current dummy load, together with a pair of DMMs at the output in order to precisely monitor output voltage and current. For the input I’m relying on the lab supply to provide these measurements. And yes, the shield does its own measurements of both input and output currents and voltages. Once calibrated they are even quite accurate but I won’t rely on them for things as calculating the converter’s efficiency.

no_load_overview
Vin=17V, no load

But first we need to see if our converter works at all. As the scope screenshot above demonstrates – it does. For all the tests shown in this post, the input voltage was provided by a lab supply set to 17 volts. So we’re not yet testing the software and its capability to draw just the right amount of current.

no_load_closeup
Vin=17V, no load

As you can see, since the converter can draw any (reasonable) current at the input, it provides the maximum voltage (set in software) of 13.8V at its output. In order to do that, the upper FET is on approximately 80% of the time. The signals all seem nice an clean and there is no noticable ripple at the output at 1V/div and no load. And the switching frequency is 62.5kHz (16MHz / 256) as expected.

1Amp_closeup
Vin=17V, Iout=1A

At 1 Amp output current, the software has to increase the duty cycle somewhat to 82% (above) and even further to 84% at 2A (below). Besides that, everything still looks very similar under load conditions.

2A_closeup
Vin=17V, Iout=2A

In my last post I’ve raised the question if the FET driver’s dead time of 540ns according to the datasheet is not a bit excessive. Well, let’s look at the dead time on the scope. First of all we can observe that the dead time of the IR2104 is in line with the data sheet. I don’t have it in front of me right now to check the min/max specs but the measured 522ns seem reasonably close to the theoretical 540ns.

deadtime
The IR2104 has a built-in dead time of 540ns according to the data sheet. We’re measuring 522ns here – close enough.

From looking at the screen shot above, the dead time does seem a bit long. The reason dead time is introduced is to prevent shoot-through. If both FETs are on there is a short-circuit from the input to ground. Together with the input capacity and the FETs low Rds-on, very large currents could flow, possibly destroying the FETs and at least detoriating efficiency. So introducing a bit of time when both transistors are off seems reasonable. But too much of it also costs efficiency since current has to flow through the diode instead of the lower FET. The main reason for using a synchronous topology is to prevent this in order to gain efficiency. So obviously one has to find a balance. I think here we’re a bit far on the conservative side but never mind for now.

20160203_Projekte_005
Let some current flow

So now that our converter is working, let’s take a look at efficiency. I’ve measured the efficiency at output currents ranging from 100mA to 2.6A in 100mA steps with the input voltage at 17V. I didn’t use the sense-wires connections on the lab supply so I had to compensate for the voltage drop on the input leads manually.

20160203_Projekte_007
There was a drop of up to 220mV on the input leads so the voltage reading of the lab supply is not quite accurate

The results are quite impressive:

  • 95.5% @ 100mA (worst)
  • 96.9% @ 200mA
  • 97.9% @ 400mA
  • 98.1% @ 800mA (best)
  • 97.1% @ 1600mA
  • 95.7% at 2600mA

So the efficiency is constantly at a very high 95.5% and better over the entire current range of interest.

20160203_Projekte_008
This little dummy load is really useful

The resulting loss is less than 1.6 Watts @ 2.6A out. As a result, the shield never gets hot, even when running at this power level for a while.

Note that this is quite a bit more power than the converter was designed for. 37W as opposed to the 30W I designed it for. The FETs could even handle much more. The limiting factor would likely be the coil reaching saturation. Unfortunately my lab supply doesn’t supply any more than 2.2A so I can’t push it any further.

20160203_Projekte_006
Shield performs well even beyond 30W spec

 

One thing to note is that these efficiency figures don’t take into account the power consumed by the arduino, the display, the fet driver, current monitoring ICs and so on. This brings us to the last topic for now: The current consumed by the various components. I did these measurements mainly in order to understand how to limit power consumption in a later version. To me, this shield is only a proof of concept and so reducing power consumption was never an issue.

20160203_Projekte_002
Basic test setup

Here are the results:

  • Arduino: 48.7mA
  • LCD backlight: 8.9mA
  • LCD excluding backlight: 1.148mA
  • FET driver (standby): 106.56uA
  • FET driver (62.5kHz, Iout=0): 2847uA
  • FET driver (62.5kHz, Iout=2.5A): 2937uA
  • Current sensors (each): 48.6uA

So the arduino itself is using up the lion’s share of current. Next comes the LCD backlight. Nothing unexpected so far. The LCD without backlight still consumes a considerable 1.15mA, no matter if it’s on or off. The FET driver uses around 2.9mA when on and only about 0.1mA when off. Output current only has a minor impact. The current sensors don’t use up much – less than 0.1mA for both.

Check out my next post for a closer look at the software or here for an overview over this project.

Arduino MPPT Solar Charger Shield

20160119_Projekte_028

A friend has approached me regarding his solar project. He wants to install a solar panel together with a battery and an inverter in order to have power at his allotment garden. He had looked at a hobbyist project where an arduino was used to build a MPPT (maximum point of power tracking) charge controller. I took a look at the design, liked a lot of what I saw and decided to build something similar.

20160119_Projekte_032

The basic idea behind an MPPT solar charger is simple. A solar panel has a certain voltage (in the region of 17 to 18 volts for a 12 volts pannel, somwhat dependent on temperature) at which it provides most power. So as long as the battery needs charging, you want to pull just as much current to reach this voltage. But once the battery is full you need to avoid overcharging the battery. So you want to maintain a maximum voltage for your battery (somewhere around 13.8 volts for a 12 volt lead acid battery) and no longer care about the pannel’s voltage.

20160119_Projekte_029

So the charger needs to convert an input voltage of 17-18V to an output voltage of 12-14V as efficiently as possible. Obviously, a step-down (aka buck) switching converter is ideally suited for the job. However, a typical DC-DC converter is designed to maintain a stable voltage at it’s output, independent of it’s input voltage. As described above, our requirements here are different.

20160119_Projekte_038

Switching converters are controlled by the duty cycle of a (typically) fixed-frequency PWM signal. So a microcontroller could be used to do the job. In most applications, this wouldn’t work that well because a microcontroller would be too slow to react to sudden changes in load or input voltage. But this is not much of a concern in our solar application: Sun intensity changes within seconds at best and the battery will absorb any sudden changes in load. So if we adjust our duty cycle a few times per second we’ll be more than fine. And that’s easy to do with a microcontroller.

20160119_Projekte_030

The next step was to figure out at which frequency to run our converter. An arduino runns at 16MHz. At a 8-bit resolution, this gives us a maximum PWM frequency of 62.5kHz. That’s a pretty slow speed for a switching DC-DC converter nowadays. Most modern designs run in the hundreds of kHz to a few MHz. The main reason of using higher and higher switching frequencies is size. The higher the frequency, the smaller the inductor can be. For us, using a somewhat bigger inductor is totally acceptable. And in terms of efficiency, a lower frequency is even preferable since it reduces switching losses.

20160119_Projekte_037

The project here is intended mainly as a proof on concept. I expect it to be fully functional but it will consume quite a bit of power while sitting idle. The display (including backlight) is always on, the same goes for all the other components. But the main drain on the battery will be the Arduino itself which consumes around 50mA when running at 16MHz. That might not sound like much but it will add up during the many hours the solar panel doesn’t produce any power. The system will be installed in Zürich, Switzerland so you can’t count on having 8 hours of sunshine every day. In winter, there might be snow on the panel, preventing it from producing anything for weeks in an extreme case. So a productive system should draw hardly any current (say <1mA) when not doing anything useful.

20160119_Projekte_031

At least for now, the we’ll be using a 30W 12V monocrystaline panel and a 45Ah car battery. So I’ve scaled this converter to comfortably handle 30W input power which translates to about 1.8 amps at the input and 2.5 amps at the output.

As deba168’s design, I’m using a synchronous buck topology. If you’re new to switchers, you might want to check out this wiki page. If you’re serious about designing your own you might want to read Sanjaya Maniktala’s ‘Switching Power Supplies A – Z’, it’s a great book. I’ve also read his other two books on the topic but this is the one I love the most, especially to start with. I’m also using the same half bridge driver (IR2104) even though I find the 540ns off time somewhat excessive. But I like the enable/pwm input signals as opposed to having to drive each fet individually and I found this feature to be somewhat rare.

20160119_Projekte_035

Apart from that I’ve really done my own design, mainly using parts I’ve still had from previous projects. As most stuff I build, it’s entirely SMD, except for the input and output capacitors. Not only are SMS designs smaller in size. The parts are much easier to source (and often cheaper) than conventional through-hole components nowadays. And contrary to popular belief, with a bit of practice I find them easier and faster to solder.

The FETs are IPB136N08N3, a quite large surface-mount type that I use quite frequently. They have a 11mOhms Rds-on resistance which will be great for efficiency. They are also easy to drive in terms of gate capacitance. Probably a bit oversized for the 2.5 amps we’re trying to switch here but I still have some here and they’re not expensive, around 70 cents each. The inductor is a 100uH Coilcraft MSS1583 with a resistance of 0.103 ohms and a 2.8A current rating. 100uH is a bit much at full load, 68uH would easily do. But the system will spend most time at moderate loads (remember, this is not California). I’ve ordered a 68uH as well and intend to use it for a later design or maybe to see what difference it makes. Input and output caps are quite a bit oversized as well, 680uF 35V at the input and 820uH 25V at the output. They are from the Panasonic FR series which I like using for my switchers since they work well at frequencies up to a few hundred kHz while being afordable and having very high ripple current ratings.

20160119_Projekte_034

I’m doing voltage and current sensing at both input and output. I’ve decided to use conventional high-side, shunt resistor based current sensing. The Texas INA213 are fairly precise, work up to 26 volts and have a fixed gain of 50. Also here, I still had some left over from my dummy load project. Most components are much cheaper if you buy 10 in stead of just one or two so I tend to buy 10 😉

I’ve also added a standard 2×16 characters LCD display so I can see what’s going on. And you may have noticed that I’ve put a zero ohms resistor at several places. This will enable me to easily measure current consumption of the respective sub-circuit. As mentioned before, current consumption will play a major role in the final design so I’m interested to see how much juice is used by certain components under real-life conditions.

Besided the connectors for the panel and the battery, I have added a separate connector for the power supply. This is handy for early testing and programming. Just connecting this supply will power up the entire system. The arduino, the display, the converter and all. But there is not yet any load at the converter’s output and no supply at it’s input. So I can start programming the Arduino, start measuring and displaying voltages and currents and even turn on the converter to see if everything behaves as expected. And since there is nothing at the converter’s input and output, not much can go wrong. I don’t risk blowing up the FETs due to a bug in the program or a problem with the board. Only once I’m confident that everything works as expected I will connect a panel and a battery. At that point, the 12V input can just be connected to the battery as well.

20160119_Projekte_039

I’ve written a simple sketch for the Arduino that measures voltage and current at the input and output and displays the result on the LCD. Once the input voltage exceeds a certain threshold, it will enable the half bridge driver and start switching. It starts at a duty cycle that will produce an output voltage equal to the current battery voltage. That means that no current will flow to the battery yet so the converter can start up with no load. Once the switcher is turned on, the Arduino will adjust the duty cycle about 4 times a second. If the input voltage is above its optimum and the battery has not yet reached its maximum voltage, the duty cycle will be increased by 1/255. If either the battery voltage is too high or the input voltage is below its optimum, the duty cycle is decreased by 1/255. There are also some checks for overcurrent at the input and output.

20160119_Projekte_036

The switcher is turned off when the input voltage or the output current falls below a pre-defined threshold. This is a synchronous converter so current can flow back from the battery to the panel. We can’t just wait for the input voltage to fall. As long as the switcher is on, the input will never fall because energy is pumped from the battery to the panel. A synchronous buck converter is just the same as a synchronous boost converter with its inputs and outputs inverted. So we need to make sure current is actually flowing to the battery. Luckily, a car battery will always draw a clearly non-zero current at 13.8 volts, even when fully charged. So when current stops flowing to the battery, we know the panel is no longer able to provide any power and we can or rather must turn the converter off.

20160119_Projekte_033

This post ist getting rather long so I’ll stop here and will write another post later about how the circuit has been performing and what I have learned so far. I guess this project will turn into a little series, maybe with further (and hopefully improved) versions being developped. Looking forward to that.

Before I forget: Here’s the eagle files as well as schematic and layout PDFs as a zip file: SolarCharger_Rev1.

Update: Click here to see how the shield performs or here for an overview over this project.

Stand-alone Inductance Meter

_MG_1169

Some of you may have seen my arduino-based inductance meter in this post: http://soldernerd.com/2014/12/14/arduino-based-inductance-meter/. The guys at dangerousprototypes.com picked it up (http://dangerousprototypes.com/2014/12/16/arduino-based-inductance-meter/) and this blog got more visitors than I could ever have imagined. Thanks, dangerousprototypes.

_MG_1158

The arduino-based meter works well and made a great proof-of-concept. But for everyday use you’re probabely not looking for an arduino solution but rather something that looks and feels more like a multimeter. That’s why I’m following up with this stand-alone version.

_MG_1175

So this version is battery powered and comes complete with a 3D-printed case. It uses a mid-range PIC microcontroller, a PIC16F1936. Not that there’s much special about this model, I just happened to have some left from previous projects. I also thought about using a Atmel Atmega328, the same chip that is on the Arduino UNO.

_MG_1172

Using an entirely different chip means I’ll have to write the software from scratch. But I felt that the Atmega328 was just too much of an overkill just to measure a frequency and control an LCD. They are quite a bit more expensive than the PIC, CHF 3.70 compared to CHF 1.90 @10pieces at Farnell where I get just about all my chips.

_MG_1159

Talking of the LCD: The one I’m using here comes with a I2C interface. It’s blue with a white backlight and 2×16 characters and really tiny. I bought 2 of them years ago because they were small and relatively cheap (around 15CHF) and don’t require so many precious I/O pins of your microcontroller. Somehow I never used them but here their small size makes them a good choice. I/O pins aren’t a constraint here obviously as most of the 28 pins are unused.

_MG_1170

I’m not yet familiar with the details of how they are controlled. I had a look at the data sheet and it looks like you send them just about the same commands like with the standard Hitachi compatible ones, just over I2C. But I expect to spend an evening or two figuring out the details.

_MG_1173

The case was designed using FreeCAD. As the name suggest, it’s a free (and open-source) CAD design tool. This was only the second time I was using it but I found it quite easy to learn.

_MG_1162

I printed the case at the Zürich fab lab (zurich.fablab.ch) on one of their Ultimakers. Was my first 3D-printing project, thank you very much for your support, everyone.

_MG_1178

As always, I’ll put all the files online as a zip. So you can download all the Eagles plus PDFs as well as the FreeCAD models. Here it is: InductanceMeter. I haven’t written any software yet but I’ll but that online, too, as soon as it’s finished.

_MG_1176

The software is ready now. Klick here for the next post: http://soldernerd.com/2015/01/23/stand-alone-incuctance-meter-finished/.

Arduino Ultrasonic Anemometer Part 13: Arduino library finally ready

It’s been a while since the last post of this series. As so often, the task turned out to be more demanding than I first thought. And then I was also entirely new to assembly language, got distracted by my Inductance Meter Project (http://soldernerd.com/2014/12/14/arduino-based-inductance-meter/) and went on a skiing holiday. But finally, the promised library is ready.

If you’re new to my Arduino-based ultrasonic wind meter project, you might want to click here for an overview: http://soldernerd.com/arduino-ultrasonic-anemometer/. This is also where you find all the various downloads, including the new library.

Using the new library is easy:

#include <anemometer.h>
extern volatile anemometerResults_t *anemometerCalculationSet;
extern volatile uint8_t anemometerStatus;

anemometerSetup();

You can then access the results as follows (replace NORTH_TO_SOUTH with SOUTH_TO_NORTH, EAST_TO_WEST or WEST_TO_EAST as needed):

anemometerCalculationSet[NORTH_TO_SOUTH].timeOfFlight
anemometerCalculationSet[NORTH_TO_SOUTH].sine
anemometerCalculationSet[SOUTH_TO_NORTH].cosine

I’ll go through the meaning and usage of these one by one:

anemometerSetup()

This function has to be called once before the anemometer can be used:

void setup()
{
  anemometerSetup();
}

anemometerStatus

anemometerStatus notifies your when a new set of measurements has been completed and is ready to use. Every time a new set is ready, anemometerStatus will be set to 1. You have to set it back to 0 once you’re done with your calculations.

if(anemometerStatus==1)
{
   /* use the results */
   anemometerStatus = 0;
}

A new set of results is made available exactly every 250ms or 4 times a second.

anemometerCalculationSet

anemometerCalculationSet is a pointer to the ready-to-use results.

Internally, the library uses a ping-pong buffer. Every time a new set of results becomes available, anemometerCalculationSet is updated to point to the last completed set of results.

The result set pointed to by anemometerCalculationSet is a

anemometerResults_t anemometerResults[4];

where anemometerResults_t is a struct defined as

typedef struct
{
  uint32_t timeOfFlight;
  int16_t sine;
  int16_t cosine;
} anemometerResults_t;

The following #defines may be used as array subscripts:

 #define NORTH_TO_SOUTH 0
#define EAST_TO_WEST 1
#define SOUTH_TO_NORTH 2
#define WEST_TO_EAST 3

timeOfFlight

This is easy to understand. It is the time it takes for the envelope detector to trigger. It is averaged over 32 measurements. Reference point is the rising edge of the first pulse sent. The unit is nanoseconds (ns).

timeOfFlight
Time of flight explained graphically

sine, cosine

sine and cosine indicate the phase shift between the transmitted and the received signal.

This was by far the most challenging part of library. For each of the 32 measurements, 4 rising and 4 falling edged of the zero-crossing detector are evaluated. So the phase shift indicated by sine and cosine is an average over 256 measurements. But phase shifts wrap around, casually speaking.  A phase shift of 359 degrees is almost the same as phase shift of 1 degree. The average should be zero degrees, not 180. Now you could try to solve the problem by constraining your phase shift to the range of -180 to +180 degrees. But that only moves the problem to the other side of the circle: -179 and +179 degrees are almost the same and their average should be 180 degrees, not zero.

I spent quite some time thinking about this and came up with increasingly complex alogrithms that still failed when some unlucky combination of angles was encountered. Remember, we are trying to average n (currently n=256) angles, not only 2.

But of course, many people smarter than me have encountered the problem before and have come up with a perfectly elegant solution: If phi is your phase shift, then calculate sine(phi) and cosine(phi). Sum up all the sines and all the cosines. Then use the arctangent function to convert the summed sines and cosines back to an (averaged) angle. [If wordpress had something like LATEX support, one could state this as a nice-looking formula]

So there is an elegant solution. But there’s also a tight time budget: The zero-crossing detector triggeres every 12.5 microseconds (us). In order to not miss the next zero crossing, we need to calculate both sine and cosine and add them to their respective sum in less time than that. And then there is some overhead like context switching. Plus we also have to do some  housekeeping during that time.

sine and cosine are expensive functions, even more so on a 8bit microcontroller. So the only way was using a lookup table. With this approach I managed to stay within budget (around 10.8us). Besides, missing the next edge is not the end of the world – the edge after that is almost as good.

captureInterrupts
Zero-crossing interrupts are just fast enough not to miss the next edge

So we now have summed sine and cosine values – how do we use them?

atan2(cosine, .sine) gives you the phase shift in radians. Multiply this by (180/PI) if you prefer degrees. My preferred approach is:

(12500.0/PI) * atan2(cosine, sine)

This also gives you the phase shift but with nanoseconds (ns) as unit which makes it directly comparable to the timeOfFlight which is also in ns.

temperature()

There’s also another function returning the temperature. It returns a int16_t containing the temperature in 0.01 degrees centigrade. So if the temperature is 23.45 degrees, it will return 2345.

It’s currently implemented using floating-point math and does not account for the sensor’s (slightly) non-linear nature. It’s there mainly as a placeholder. I’m planning to implement it properly using a lookup-table with interpolation which will make it much faster and will allow it to include the non-linear effects.

Arduino Sketch

The .zip file with the library also includes a very basic arduino sketch using that library. I’m still evaluating what is the best way to calculate the actual wind speed and direction taking into account issues  such as calibration and the like.

But my preliminary results look quite promising and I’m confident that most if not all the heavy lifting has been done.

As always, I highly appreciate any feedback and suggestions. Click here for the next post on this project: http://soldernerd.com/2015/02/17/arduino-ultrasionic-anemometer-part-14-wind-tunnel-testing/

Arduino-based Inductance Meter

_MG_1131
Incuctance meter in action. It displays the resonance frequency together with the inductance

I’ve just finished a little Arduino project. It’s a shield for the Arduino Uno that lets you measure inductance. This is a functionality that I found missing in just about any digital multi meter. Yes, there are specialized LCR meters that let you measure inductance but they typically won’t measure voltages or currents. So I had to build my inductance meter myself.

_MG_1146
Close-up of the circuit with the display removed

The basic design is really simple. It a colpitts oscillator (http://en.wikipedia.org/wiki/Colpitts_oscillator) with the coil missing. You use the test leads to connect it to a coil which will make it resonate. The Arduino then measures the frequency at which the oscillator is resonating and calculates the inductance. The capacitors are part of the shield so the capacity is known.

_MG_1132
With the test leads open, the oscillator can’t resonate. The current calibration/zero-offset is displayed in stead

There is 1uH of inductance included on the schield which is placed in series with the coil to be measured. This serves two purposes: The oscillator can resonate when you short-circuit the test leads. When you then press the push button on the shield, the software will use the current measurement as new calibration. It also puts an upper limit on the resonance frequency. This ensures that the software the rest of the circuit can keep up with the oscillator.

_MG_1139
Pressing this blue button zeroes the meter

As can be seen from the schematic, the oscillator uses two 1nF capacitors in series. Together with the 1uH inductance, this limits the frequency to about 7.1MHz. In practice, it oscillates at around 5.4MHz when the test leads are short-circuited.

_MG_1137
The Arduino shield from below

The oscillator output is followed by a comparator turning the sine wave of the oscillator into a square wave. I’ve used an inexpensive but fast Microchip MCP6561R. It has a maximum propagation delay of 80ns which allows it to keep up at the maximum frequency.

_MG_1142
Viewed from straight above

But of course, 5.4MHz is way too fast for the Arduino to keep up. The Arduino runs at 16MHz and will need at least a few dozend instructions to process each pulse from the shield. My solution was to add a 74HC590 8-bit binary counter dividing the frequency by 256. That gives a theoretical maximum frequency of 7.2MHz / 256 = 27.7kHz. That’s something the Arduino can deal with.

_MG_1145
The entire shield with the display removed

For obvious reasons, there is also a display included on the shield. And then there’s that pushbutton which is debounced in hardware by running it through an RC low-pass filter and a Schmitt-triggered buffer. The button is used to zero the meter, i.e. the current measurement is used as the new zero-offset.

_MG_1151
Even very small inductance values can be measured

All related files can be downloaded as a .zip file: LMeterShield. This includes the Arduino source code (aka sketch) as well as the Eagle files and PDFs of both the layout and the schematic.

Now there’s also a stand-alone version: http://soldernerd.com/2015/01/14/stand-alone-inductance-meter/