Posts with «pwm» label

Roll Your Own Arduino PWM

Most projects are built on abstractions. After all, few of us can create our own wire, our own transistors, or our own integrated circuits. A few months ago, [Julian Ilett] found a problem using the Arduino library for PWM. Recently, he revisited the issue and used his own PWM code to fix the problem. You can watch the video below.

Of course, neither the Arduino library nor [Julian’s] code is actually producing PWM. The Atmel CPU’s hardware is doing the work. The Arduino library gives you a wrapper called analogWrite — especially handy if you are not using an Atmel CPU where the same abstraction will do the same work. The issue arose when [Julian] broke the abstraction to invert the PWM output.

The video does a good job of framing the issue. Setting the PWM hardware to zero still causes a one tick output to occur. That is, the actual count is the count you supply plus one. That’s great on the high end where 255 is treated as 256 out of 256. But at the low end, a zero counterintuitively gives you 1/256. The Arduino library authors elected to detect that edge case and just force the output pin to go low in that case. When inverted, however, the pin still goes low when it ought to go high. You can see the source code responsible, below.

pinMode(pin, OUTPUT);
if (val == 0)
  {
  digitalWrite(pin, LOW);
  }
else if (val == 255)
  {
  digitalWrite(pin, HIGH);
  }
else
{ ...

Oddly, the 255 case appears to be superfluous in the normal case but is also backward if you invert the output. In all fairness, the Arduino library doesn’t provide you a way to invert the output, so you’ve already broken the abstraction and that’s why this isn’t technically a bug in the library.

[Julian’s] code is quite simple. There’s initial set up of the TCCR1A and TCCR1B registers along with ICR1. The DDRB register sets the pin as an output. After that, writing to OCR1A and OCR1B set the PWM value. The video explains it all in great detail.

We’ve looked at PWM on FPGAs at least once, and that post gives some background on PWM in any application. We also have our own video from way back in 2011 about PWM.


Filed under: Arduino Hacks
Hack a Day 12 Nov 12:00

Scrap Bin Mods Move Science Forward

A first-time visitor to any bio or chem lab will have many wonders to behold, but few as captivating as the magnetic stirrer. A motor turns a magnet which in turn spins a Teflon-coated stir bar inside the beaker that sits on top. It’s brilliantly simple and so incredibly useful that it leaves one wondering why they’re not included as standard equipment in every kitchen range.

But as ubiquitous as magnetic stirrers are in the lab, they generally come in largish packages. [BantamBasher135] needed a much smaller stir plate to fit inside a spectrophotometer. With zero budget, he retrofitted the instrument with an e-waste, Arduino-controlled magnetic stirrer.

The footprint available for the modification was exceedingly small — a 1 cm square cuvette with a flea-sized micro stir bar. His first stab at the micro-stirrer used a tiny 5-volt laptop fan with the blades cut off and a magnet glued to the hub, but that proved problematic. Later improvements included beefing up the voltage feeding the fan and coming up with a non-standard PWM scheme to turn the motor slow enough to prevent decoupling the stir bar from the magnets.

[BantamBasher135] admits that it’s an ugly solution, but one does what one can to get the science done. While this is a bit specialized, we’ve featured plenty of DIY lab instruments here before. You can make your own peristaltic pump or even a spectrophotometer — with or without the stirrer.

[via r/Arduino]


Filed under: chemistry hacks, tool hacks

Primer on Servos Hits All the Basics

Servos are pretty basic fare for the seasoned hacker. But everyone has to start somewhere, and there’s sure to be someone who’ll benefit from this primer on servo internals. Who knows – maybe even the old hands will pick up something from a fresh perspective.

[GreatScott!] has been building a comprehensive library of basic electronics videos over the last few years that covers everything from using a multimeter to programming an Arduino. The last two installments delve into the electromechanical realm with a treatment of stepper motors along with the servo video below. He covers the essentials of the modern RC-type servo in a clear and engaging style that makes it easy for the newbie to understand how a PWM signal can translate into positional changes over a 180° sweep. He shows how to control a servo directly with an Arduino, with bonus points for including a simple 555-based controller circuit too. A quick look at the mods needed to convert any servo to continuous rotation wraps up the video.

If [GreatScott!]’s video whets your appetite for more, be sure to check out [Richard Baguley]’s deeper dive into servos. And when you’re ready to put your new-found knowledge into practice, maybe a nice project would be to convert a hobby servo into a linear actuator.


Filed under: classic hacks, misc hacks

Smart street light using arduino

Introduction:

This project is about smart street light using arduino. This project consists of 3 analog IR (infrared) sensors. By default, the intensity of street light is set to 50 percent. We are using high intensity led as they have extra brightness. This project also features harnessing the solar and wind energy.
We are using a solar panel of  9 Volt, 2.5 watts and for wind mill, we are simply using a 12 volt dc motor.

Components required:
  1. Atmega 8a (based on arduino ng board)
  2. 8 high-intensity led
  3. Relay
  4. Perfboard
  5. 7805
  6. connecting wires
  7. solar panel (9 volt, 2.5 watt)
  8. Relay
  9. 12 volt DC motor.
How it works:

By default, the intensity of high intensity light (aka street light) is set to 50% pwm. We are using three channel of PWM. The first channel of pwm is controlling three leds, second channel is used for controlling two led's whereas the third channel is used for controlling three led at once. There are eight high intensity led. There are three, analog IR sensor, which can detect the vehicle. Upon detection of vehicle by the first sensor, it will increase the duty cycle of first three led's to 100% and by this the intensity of first three led will increase. Now, when vehicle reaches near second IR sensor first three led will again set to 50% duty cycle whereas the next two led will set to 100% duty cycle. 


IR sensor:

IR sensor is made up of simply IR led and photodiode. The connection is as follows:

DIY IR sensor

Check out the video:



Stay tuned for more updates !!






FunWithElectronics 14 Oct 05:08

8-bit volume control for Arduino tone()

Connor Nishijima has devised a neat trick to give the standard Arduino Tone() function 256 smooth volume levels using PWM at an ultrasonic frequency, without any extra components. This allows for programmatic control of square waves with nothing other than a speaker connected to an Arduino Uno.

Normally to simulate an analog voltage with a digital-only pin of a microcontroller you’d use Pulse Width Modulation. This works great for LEDs because your eyes can’t the 490 / 976Hz flicker of the standard analogWrite() function. But for audio things are a bit more difficult. Because your ears can easily detect frequencies between 20 – 20,000Hz, any PWM with a frequency in this range is out.

Luckily, the ATmega328P allows you to change the clock prescalers for ultrasonic PWM! We need to use Timer0, because it can drive PWM at a max frequency of 62,500Hz, which even if you cut that in half would still be above your hearing range. Now that we have ultrasonic PWM on Pins 5 & 6, we configure Timer1 to fire an Interrupt Service Routine at a rate of “desired frequency” * 2.

Finally, inside the Timer1 ISR routine, we incorporate our volume trick. Instead of digitalWrite()’ing the pin HIGH and LOW like the normal Tone() function does, we analogWrite() “HIGH” with our volume value (0 – 255) and analogWrite(0) for “LOW”. Because of how fast the PWM is running, the user doesn’t hear the 62.5KHz PWM frequency, and instead perceives a 50% percent duty cycle as a speaker driven with only 2.5 volts! While a few volume levels do produce subtle artifacts to the sound, it mostly delivers quality 8-bit volume control to replace the standard Tone() function.

When all is said and done, you’ll be able to customize your project with unique loudness as you play anything from the iconic Nintendo sound to R2-D2’s beeps and bops. In Nishijima’s case, he developed this Arduino volume-control scheme to make an incessant, inconsistent artificial cricket to hide in a friend’s vent for the next few months… You can read more on its Hackaday.io page, as well as find documentation and ready-to-use example sketches GitHub.

Arduino Blog 13 Jun 13:48

Temperature controlled dc fan

In this post, we will control the speed of dc fan based on the temperature.

List of components:

1. Arduino Uno
2. LM 35 temperature sensor
3. LCD 16*2
4. 10k potentiometer
5. ULN 2003
6. DC motor
7. Breadboard/ perfboard

First of all, we will monitor the temperature by using lm35 i.e. temperature sensor. It's scale factor is +10mV/°C which means with increment in temperature by 1° Celsius, the voltage is rise by 10 mV.
We can read adc count by analogRead(A0); // we are using channel A0

This will give us a digital count of adc which varies from 0 to 1023, we have to convert these count into voltage and then into temperature. First of all, we will convert into voltage:
In arduino uno, adc is of 10-bit.
Resolution = Vref/(2^n-1), where n is bit (in our case it's 10)
Resolution = 5000 / 1023, ( Verf = 5000 mV and 2^10 is 1024 minus 1 is 1023)

Resolution = 4.887 mV
Now, we have to convert voltage into temperature:
Temperature (in °C) = Voltage (in mV) / 10.0
With this temperature monitoring is over.

LCD interfacing is simple since we have library for the same with proper documentation.

Now coming to pwm part. In arduino, we can control output voltage by pulse width modulation (pwm).
Duty Cycle = Ton / (Ton + Toff)
Duty Cycle = Ton / T

Duty Cycle (in %age) = (Ton / T)*100

In arduino, for pwm we have analogWrite function :

In arduino uno, we have six pwm channels viz, pin no. 3, 5, 6, 9, 10 and 11.

analogWrite(pin no, value)

Pin no may be 3, 5, 6, 9, 10 and 11
Value varies from 0 to 255 since pwm resolution is of 8-bit (2^8-1)

0 for 0% duty cycle                  0 volts
64 for 25% duty cycle              1.25 volts            if(val<=40.0)
127 for 50% duty cycle            2.50 volts            if(val>40.0 && val<=50.0)
192 for 75% duty cycle            3.75 volts            if(val>50.0 && val<=60.0)
255 for 100% duty cycle          5.00 volts            if(val>60.0)

where val is temperature in °C

Vavg = Duty Cycle  * 5.0 volts
 
Schematic of temperature controlled fan
Download the source code from the link below:


Stay tuned for more updates !!





Send HEX values to Arduino

FIVE MINUTE TUTORIAL

Project Description: Sending Hex values to an Arduino UNO


This simple tutorial will show you how to send Hexadecimal values from a computer to an Arduino Uno. The "Processing" programming language will be used to send the HEX values from the computer when a mouse button is pressed. The Arduino will use these values to adjust the brightness of an LED.



 

Learning Objectives


  • To Send Hexadecimal (Hex) values from a computer to the Arduino
  • Trigger an action based on the press of a mouse button
  • Learn to create a simple Computer to Arduino interface
  • Use Arduino's PWM capabilities to adjust brightness of an LED
  • Learn to use Arduino's analogWrite() function
  • Create a simple LED circuit


 

Parts Required:


Fritzing Sketch


The diagram below will show you how to connect an LED to Digital Pin 10 on the Arduino.
Don't forget the 330 ohm resistor !
 


 
 

Arduino Sketch


The latest version of Arduino IDE can be downloaded here.
 
  1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
/* ==================================================================================================================================================
         Project: 5 min tutorial: Send Hex from computer to Arduino
          Author: Scott C
         Created: 21th June 2015
     Arduino IDE: 1.6.4
         Website: http://arduinobasics.blogspot.com/p/arduino-basics-projects-page.html
     Description: Arduino Sketch used to adjust the brightness of an LED based on the values received
                  on the serial port. The LED needs to be connected to a PWM pin. In this sketch
                  Pin 10 is used, however you could use Pin 3, 5, 6, 9, or 11 - if you are using an Arduino Uno.
===================================================================================================================================================== */

byte byteRead; //Variable used to store the byte received on the Serial Port
int ledPin = 10; //LED is connected to Arduino Pin 10. This pin must be PWM capable.

void setup() {
 Serial.begin(9600); //Initialise Serial communication with the computer
 pinMode(ledPin, OUTPUT); //Set Pin 10 as an Output pin
 byteRead = 0;                   //Initialise the byteRead variable to zero.
}

void loop() {
  if(Serial.available()) {
    byteRead = Serial.read(); //Update the byteRead variable with the Hex value received on the Serial COM port.
  }
  
  analogWrite(ledPin, byteRead); //Use PWM to adjust the brightness of the LED. Brightness is determined by the "byteRead" variable.
}


 


 
 

Processing Sketch


The latest version of the Processing IDE can be downloaded here.
 
  1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
/* ==================================================================================================================================================
         Project: 5 min tutorial: Send Hex from computer to Arduino
          Author: Scott C
         Created: 21th June 2015
  Processing IDE: 2.2.1
         Website: http://arduinobasics.blogspot.com/p/arduino-basics-projects-page.html
     Description: Processing Sketch used to send HEX values from computer to Arduino when the mouse is pressed.
                  The alternating values 0xFF and 0x00 are sent to the Arduino Uno to turn an LED on and off.
                  You can send any HEX value from 0x00 to 0xFF. This sketch also shows how to convert Hex strings
                  to Hex numbers.
===================================================================================================================================================== */

import processing.serial.*; //This import statement is required for Serial communication

Serial comPort;                       //comPort is used to write Hex values to the Arduino
boolean toggle = false; //toggle variable is used to control which hex variable to send
String zeroHex = "00"; //This "00" string will be converted to 0x00 and sent to Arduino to turn LED off.
String FFHex = "FF"; //This "FF" string will be converted to 0xFF and sent to Arduino to turn LED on.

void setup(){
    comPort = new Serial(this, Serial.list()[0], 9600); //initialise the COM port for serial communication at a baud rate of 9600.
    delay(2000);                      //this delay allows the com port to initialise properly before initiating any communication.
    background(0); //Start with a black background.
    
}


void draw(){ //the draw() function is necessary for the sketch to compile
    //do nothing here //even though it does nothing.
}


void mousePressed(){ //This function is called when the mouse is pressed within the Processing window.
  toggle = ! toggle;                   //The toggle variable will change back and forth between "true" and "false"
  if(toggle){ //If the toggle variable is TRUE, then send 0xFF to the Arduino
     comPort.write(unhex(FFHex)); //The unhex() function converts the "FF" string to 0xFF
     background(0,0,255); //Change the background colour to blue as a visual indication of a button press.
  } else {
    comPort.write(unhex(zeroHex)); //If the toggle variable is FALSE, then send 0x00 to the Arduino
    background(0); //Change the background colour to black as a visual indication of a button press.
  }
}


 

The Video


 

The tutorial above is a quick demonstration of how to convert Hex strings on your computer and send them to an Arduino. The Arduino can use the values to change the brightness of an LED as shown in this tutorial, however you could use it to modify the speed of a motor, or to pass on commands to another module. Hopefully this short tutorial will help you with your project. Please let me know how it helped you in the comments below.

 
 



If you like this page, please do me a favour and show your appreciation :

 
Visit my ArduinoBasics Google + page.
Follow me on Twitter by looking for ScottC @ArduinoBasics.
I can also be found on Pinterest and Instagram.
Have a look at my videos on my YouTube channel.


 
 
             


 
 



However, if you do not have a google profile...
Feel free to share this page with your friends in any way you see fit.

Thermal control loop working (sort of)

Classes start tomorrow, so I spent yesterday making sure that the incubator control project was feasible. I had gotten the fan feedback control working well back in September, but I’d put the project aside for Fall quarter and only got back to it this week.  As a reminder, here are the previous posts on the project:

Here is the interior of the styrofoam box, with the lid open. The 6″×12″ aluminum plate covers the bottom. The thermistor is on the left, propped up by a rubber foot, the resistor in is the center, and the fan is sitting on a foam pad on the right. (The foam is to reduce noise until I can get the fan proper mounted in a baffle.)

I left the foam out this time, which made for a somewhat noisy fan, and I still haven’t built a baffle—I’m still using the bent-wire-and-paper deflector shown in the photo. What I worked on yesterday was the software—since the temperature changes are fairly slow, it takes a long time to tune the control loops.

One thing I did was to try to reduce measurement noise further on the thermistor measurements. I now add 60  analog-to-digital readings. They’re 10 bits on the Arduino-compatible board (a Sparkfun redboard), so adding 60 still fits in an unsigned 16-bit word. I now get noise of about ±0.05°C, which is half the least-significant-bit of the converter.  I doubt that I can do better in precision without switching to a processor with a better analog-to-digital converter, though I could do digital filtering with a 1Hz low-pass filter to smooth out the remaining noise.

I copied the fan feedback control loop (with the anti-windup provisions) described in Improving feedback for fan for temperature control, but made two changes:

  • I changed the integration time and K_p for the thermal control loop, since the temperature response is much slower than the fan response.
  • Because of the huge asymmetry in the temperature response (the resistor and metal plate can heat up much more quickly than they cool down), I turn off the heater the moment it gets over temperature, no matter with the PI loop suggests, but I only switch to full-on when the air temperature is 3°C too cold. For the fan, I used a symmetric window around the set point for using the PI loop rather than full-on/full-off.

Here are some results from tuning experiments:

The blue curve switched to PI control at 23.5°C, the other two at 22°C. The green curve has pretty tight control over the temperature, but does overshoot a bit.

The initial temperatures were not all identical, because I wasn’t always willing to let everything cool down all the way to room temperature after each tuning run. I could only do about 1 tuning run an hour, which could pose problems for the freshman design seminar, as we don’t have long lab times—only the 70-minute lecture-schedule meeting times.

I continued the best of those runs with another step, up to 35°C, then let it cool down.

The step to 35°C has more ringing than the step to 25°C. I terminated the run before it had finished cooling, because the 32-bit µs timer wrapped around.

The cool-down at the end fits a 0.0069 °C/s line better than it fits an exponential decay to the ambient temperature.  If I do fit an exponential decay curve, I get a time constant of around 1975 seconds.

A simple thermal-resistance, thermal-capacity model is not a very good one for predicting how the system will behave, particularly since we’re not measuring the temperature of the large thermal mass (the aluminum plate and power resistor), but of the air, which has a large thermal resistance from the plate.  The time constant for the aluminum-air transfer is larger than the time constant for the electricity-aluminum transfer, which is why we get so much overshoot when we turn off the power to the resistor—the aluminum plate has gotten much hotter than the air, and continues to transfer heat to it, even though no more heat is being added to the aluminum.

Still, it is worth seeing what we get if we model the box a simple thermal mass and thermal resistor. The steady-state 35°C seems to need about 9W (PWM of 51/256) and the 25°C 3W (PWM of 17/256) with an ambient temperature of about 19°C, implying that the styrofoam box has a thermal resistance of about 1.9°C/W.

To see what is really going on, I’ll have to heat the box to 35°C, then start the cool down with a reset 32-bit timer.

Single-step warming from 16.9°C to 35°C. The steady state at 35°C is about 9.32W, for a thermal resistance of 1.8°C/W. The rise of 0.0451°C/s at 45W implies a thermal capacity of 998 J/°C.

Heating at 45W (9V, 1.8Ω) results in a temperature rise of about 0.0451 °C/s. This warm-up rate at 45W implies a thermal capacity of about 998 J/°C. We may want to adjust our thermal capacity estimate, since some of the 45W put in escapes through the box—maybe about 3–4W at the temperatures where the rise was measured. This reduces the thermal capacity estimate to about 910 J/°C.

The cool down from 35°C starts out as a straight line (about -0.0074°C/s or -26.5°C/hour), but gradually starts behaving more like the exponential we would expect from a thermal-resistance and thermal-capacity model.

The time constant for the cooling is about 1380s, but the initial cooling is too slow for a simple exponential.

The time constant of 1380 s, combined with a thermal capacity of 910 J/°C gives a thermal resistance of 1.5 °C/W, a bit lower than the 1.8°C/W I estimated from the steady-state power.

I continued the cooling (with the timer wrapped around) to see if I got a clean exponential at low temperature differences:

The exponential seems to fit well here, with a time constant of 2300s. Combined with the 910 J/°C, this gives a thermal resistance of 2.5°C/W, which seems a little high compared to the other estimates.

So I’ve made some progress on the thermal control loop (though I’d like to reduce the overshoot and ringing) and I have a crude model for the box: a thermal mass with capacity about 910 J/°C and thermal resistance 2±0.5 °C/W.

Still on my to-do list for this project:

  • Consider using a PID controller for the temperature to get faster response without overshoot.  (If I can reduce the noise problem.) I should be able to reduce the noise with a digital filter, but I’m already pushing well beyond what I’m comfortable covering in a freshman class. Tuning a PID controller is even trickier than tuning a PI controller, which is already going to take most of the quarter to teach.
  • Design and build baffling for the fan to get better airflow in the box. This might be a good thing to get students to do, particularly if we can get them to learn how to use the laser cutter. But even handsaws would suffice, given some thin plywood or masonite, some angle irons, and nuts and screws.
  • Figure out how to get students to come up with workable designs, when they are starting from knowing nothing. I don’t want to give them my designs, but I want to help them find doable subproblems. Some of the subproblems they come up with may be well beyond the skills that they can pick up in the time frame of the course. The more I work on this project, the more I realize that I and the students will have to be happy with them having explored the options, without getting all the problems solved.
  • Add changes to the cumulative error term whenever KP or TI are changed, to keep the PWM output the same after the changes—currently changing any of the control loop parameters adds a huge disturbance to the system. I don’t know how important this is—I’ve been doing my tuning of the thermal loop by recompiling, rather than by changing parameters on the fly. The quick changes were handy for the fan loop, where I could see things happening quickly, but for the thermal loop each experiment took about an hour, so there was no need for a fast parameter change.
  • Research control algorithms other than PI and PID, particularly for asymmetric systems like the temperature control, where I can get fairly quick response to the inputs when heating, but very slow response when cooling. The asymmetric window for switching between on/off and PI control seems to have helped here, but there is probably a more principled way to handle asymmetric control inputs. Maybe I should ask some of the control-theory faculty for some pointers.
  • Develop a more detailed thermal model with separate components for the aluminum plate and the air in the box. It may be worth adding another thermistor, taped to the aluminum plate, to monitor that temperature. The extra thermistor would also allow much tighter temperature control, avoiding overshoot on air temperature.

 


Filed under: freshman design seminar Tagged: Arduino, control loop, fan, incubator, integrator windup, PID controller, power resistor, PWM, tachometer, thermal resistance, thermistor

Improving feedback for fan

I wanted to look at the step response of the fan and of the heater, so that I could see if I could derive somewhat reasonable control parameters by theory, rather than by cut-and-try parameter fiddling.  Most of the tutorials I’ve looked at give empirical ways of tuning PID controllers, rather than theoretical ones, even ones that use Laplace transforms to explain how PID controllers work and how to determine whether or not the control loop is stable if you are controlling a linear time-invariant system with a known transfer function.

When I first looked at the fan response, I noticed a problem with my tachometer code:

The tachometer gives two pulses per revolution, but the markers used are not perfectly spaced, so I get different estimates of the speed depending which falling-edge-to-falling-edge pulse width I measure. The difference between the two speeds is about 1.6%.

I rewrote the tachometer code to trigger on all four edges of a revolution, and to record the time at each edge in a circular buffer. This way I can use a full revolution of the fan for determining the speed, but get updated estimates every quarter revolution, available in micros_per_revolution:

volatile uint32_t old_tach_micros[4];  // time of last pulses of tachometer
	// used as a circular buffer
volatile uint8_t prev_tach_index=0;    // pointer into circular buffer
volatile uint32_t micros_per_revolution; // most recent pulse period of tachometer

#define MIN_TACH_PULSE  (100)   // ignore transitions sooner than this many
				// microseconds after previous transition

void  tachometer_interrupt(void)
{   uint32_t tach_micros = micros();

    if (tach_micros-old_tach_micros[prev_tach_index] < MIN_TACH_PULSE) return;
    prev_tach_index = (prev_tach_index+1)%4;  // increment circular buffer pointer
    micros_per_revolution= tach_micros-old_tach_micros[prev_tach_index];
    old_tach_micros[prev_tach_index] = tach_micros;
}

In setup(), I need to set up the interrupt with attachInterrupt(FAN_FEEDBACK_INT,tachometer_interrupt, CHANGE);

I think that this improved tachometer code may be a bit too much for first-time programmers to come up with. Circular buffers use a bunch of concepts (arrays, modular arithmetic) and are likely to cause a lot of off-by-one errors. Interrupts alone were a complicated enough concept for students to deal with. I don’t know whether the improvement in speed measurement would be justifiable in the freshman design course.

The new tachometer code did smooth out the measurements a lot, though, as expected—it reduces the fluctuation in measured speed to about 0.3%, which is limited by the resolution of the micros() timer I’m using on the Arduino board. I then tried recording some step responses, both for upward steps and downward steps. The upward steps are reasonably approximated by an exponential decay (like a charging curve):

The low speed with PWM=0 (always off) is 724.7 rpm, and the high speed with PWM=255 (always on) is 6766.3rpm. The exponential fit is not perfect, but it is certainly a good enough approximation for designing a closed-loop system.

The response to a downward step, however, is not well modeled by a simple exponential decay:

The fan spins down gradually at first (with a time constant about 1.6s), but at low speed the speed changes faster (as if the time constant dropped to about 0.6s).

Note that the fan slows down much more gradually than it speeds up, which means that it is not a linear, time-invariant system. In a linear system, superimposing a step-up and a step-down would cancel, so the responses to the step up and step down should add to a constant value—the fan most definitely does not have that property.

I was curious whether the difference was just apparent for large steps, or also for small ones, so I tried steps between PWM duty cycles of 100/256 and 160/256:

A small upward step is again quick, with almost the same time constant as before.

The small downward step is faster than before, though still substantially slower than the upward step of the same size, and with an initially slower response than the final convergence.

I’m going to try writing a couple of ad hoc controllers for the fan, to see if they behave better than the PID controller I’ve been using: open-loop control using just  PWM=(setpoint-740)/25; a simple on/off control with a single threshold; hysteresis, using two thresholds instead of 1; PI control with no anti-windup; and a controller that goes to full on or full off when the error is large, to make a quick transition,  switching to approximately the right PWM value,  when the error is small, with PI control thereafter.

I think that the open-loop controller will have a steady, but wrong speed; the  crude on/off controllers will make an audible pulsing of the fan motor; the PI controller will suffer from overshoot when making big steps, and the on/off/PI controller should make nice steps, if I can tune it right.

I implemented all the controllers and ran a test switching between setpoints of 1000RPM and 5000RPM every 30 seconds.  Here are plots of the behavior with different control algorithms:

The PWM values computed by the various control algorithms show the integrator windup problem for PI clearly after the downward transitions—PI takes a long time to recover from the errors during the downward edge.

The mixed algorithm does a very good job of control, with little overshoot. The simple PI algorithm has substantial overshoot, particularly when the control loop wants a PWM value outside the range [0,255]. Open loop has significant offset and wanders a bit. On/off control oscillates at about 10hz, and adding hysteresis makes the oscillation larger but slower (about 5Hz).

The errors for the mixed controller are only about ±0.3% and overshoot or ringing at the transitions <40RPM.  The simple PI controller overshoots by 340RPM and takes 20 seconds to recover from the integrator windup on the downward transition.  The open-loop controller has offset errors of about 1% and a fluctuation of about ±0.7% at the high speed, and an offset of 1% and fluctuations of about ±0.5% at the low speed.  The on/off controller has an offset of  about 0.5% at high speed with fluctuations of ±2%, and an offset of 28% with fluctuations of ±28%.  Adding hysteresis slows down the oscillations, but makes them larger (0.2% offset, fluctuations ±3% at high speed, and 44% offset with fluctuations of ±70% at low speed).The mixed algorithm which uses on/off control for large errors and PI for small errors, with back-calculation of the integral error when switching to the PI controller seems to work very well.  But would I be able to get freshmen to the point of being able to develop that themselves within a 2-unit course?  Probably not, but I might be able guide them through the development in a series of exercises that started with on/off control, then went to modeling and open-loop control, then the PI control, and finally the mixed control.  It would take most of the quarter.


Filed under: freshman design seminar Tagged: Arduino, control loop, fan, incubator, PID controller, PWM, tachometer

Improving feedback for fan

I wanted to look at the step response of the fan and of the heater, so that I could see if I could derive somewhat reasonable control parameters by theory, rather than by cut-and-try parameter fiddling.  Most of the tutorials I’ve looked at give empirical ways of tuning PID controllers, rather than theoretical ones, even ones that use Laplace transforms to explain how PID controllers work and how to determine whether or not the control loop is stable if you are controlling a linear time-invariant system with a known transfer function.

When I first looked at the fan response, I noticed a problem with my tachometer code:

The tachometer gives two pulses per revolution, but the markers used are not perfectly spaced, so I get different estimates of the speed depending which falling-edge-to-falling-edge pulse width I measure. The difference between the two speeds is about 1.6%.

I rewrote the tachometer code to trigger on all four edges of a revolution, and to record the time at each edge in a circular buffer. This way I can use a full revolution of the fan for determining the speed, but get updated estimates every quarter revolution, available in micros_per_revolution:

volatile uint32_t old_tach_micros[4];  // time of last pulses of tachometer
	// used as a circular buffer
volatile uint8_t prev_tach_index=0;    // pointer into circular buffer
volatile uint32_t micros_per_revolution; // most recent pulse period of tachometer

#define MIN_TACH_PULSE  (100)   // ignore transitions sooner than this many
				// microseconds after previous transition

void  tachometer_interrupt(void)
{   uint32_t tach_micros = micros();

    if (tach_micros-old_tach_micros[prev_tach_index] < MIN_TACH_PULSE) return;
    prev_tach_index = (prev_tach_index+1)%4;  // increment circular buffer pointer
    micros_per_revolution= tach_micros-old_tach_micros[prev_tach_index];
    old_tach_micros[prev_tach_index] = tach_micros;
}

In setup(), I need to set up the interrupt with attachInterrupt(FAN_FEEDBACK_INT,tachometer_interrupt, CHANGE);

I think that this improved tachometer code may be a bit too much for first-time programmers to come up with. Circular buffers use a bunch of concepts (arrays, modular arithmetic) and are likely to cause a lot of off-by-one errors. Interrupts alone were a complicated enough concept for students to deal with. I don’t know whether the improvement in speed measurement would be justifiable in the freshman design course.

The new tachometer code did smooth out the measurements a lot, though, as expected—it reduces the fluctuation in measured speed to about 0.3%, which is limited by the resolution of the micros() timer I’m using on the Arduino board. I then tried recording some step responses, both for upward steps and downward steps. The upward steps are reasonably approximated by an exponential decay (like a charging curve):

The low speed with PWM=0 (always off) is 724.7 rpm, and the high speed with PWM=255 (always on) is 6766.3rpm. The exponential fit is not perfect, but it is certainly a good enough approximation for designing a closed-loop system.

The response to a downward step, however, is not well modeled by a simple exponential decay:

The fan spins down gradually at first (with a time constant about 1.6s), but at low speed the speed changes faster (as if the time constant dropped to about 0.6s).

Note that the fan slows down much more gradually than it speeds up, which means that it is not a linear, time-invariant system. In a linear system, superimposing a step-up and a step-down would cancel, so the responses to the step up and step down should add to a constant value—the fan most definitely does not have that property.

I was curious whether the difference was just apparent for large steps, or also for small ones, so I tried steps between PWM duty cycles of 100/256 and 160/256:

A small upward step is again quick, with almost the same time constant as before.

The small downward step is faster than before, though still substantially slower than the upward step of the same size, and with an initially slower response than the final convergence.

I’m going to try writing a couple of ad hoc controllers for the fan, to see if they behave better than the PID controller I’ve been using: open-loop control using just  PWM=(setpoint-740)/25; a simple on/off control with a single threshold; hysteresis, using two thresholds instead of 1; PI control with no anti-windup; and a controller that goes to full on or full off when the error is large, to make a quick transition,  switching to approximately the right PWM value,  when the error is small, with PI control thereafter.

I think that the open-loop controller will have a steady, but wrong speed; the  crude on/off controllers will make an audible pulsing of the fan motor; the PI controller will suffer from overshoot when making big steps, and the on/off/PI controller should make nice steps, if I can tune it right.

I implemented all the controllers and ran a test switching between setpoints of 1000RPM and 5000RPM every 30 seconds.  Here are plots of the behavior with different control algorithms:

The PWM values computed by the various control algorithms show the integrator windup problem for PI clearly after the downward transitions—PI takes a long time to recover from the errors during the downward edge.

The mixed algorithm does a very good job of control, with little overshoot. The simple PI algorithm has substantial overshoot, particularly when the control loop wants a PWM value outside the range [0,255]. Open loop has significant offset and wanders a bit. On/off control oscillates at about 10hz, and adding hysteresis makes the oscillation larger but slower (about 5Hz).

The errors for the mixed controller are only about ±0.3% and overshoot or ringing at the transitions <40RPM.  The simple PI controller overshoots by 340RPM and takes 20 seconds to recover from the integrator windup on the downward transition.  The open-loop controller has offset errors of about 1% and a fluctuation of about ±0.7% at the high speed, and an offset of 1% and fluctuations of about ±0.5% at the low speed.  The on/off controller has an offset of  about 0.5% at high speed with fluctuations of ±2%, and an offset of 28% with fluctuations of ±28%.  Adding hysteresis slows down the oscillations, but makes them larger (0.2% offset, fluctuations ±3% at high speed, and 44% offset with fluctuations of ±70% at low speed).The mixed algorithm which uses on/off control for large errors and PI for small errors, with back-calculation of the integral error when switching to the PI controller seems to work very well.  But would I be able to get freshmen to the point of being able to develop that themselves within a 2-unit course?  Probably not, but I might be able guide them through the development in a series of exercises that started with on/off control, then went to modeling and open-loop control, then the PI control, and finally the mixed control.  It would take most of the quarter.


Filed under: freshman design seminar Tagged: Arduino, control loop, fan, incubator, PID controller, PWM, tachometer