I like the tools...

Tiny garden project for D involved running some 13mm pipe for irrigation from the right side to the left side.

Keeping it vaguely neat meant running it under the seat thingo. Small problem: Seat thingo has no place to bring pipe out.

Solution: Using 16mm 3-way wod drill bit I just happened to have lying around.. Oh, and the new cordless drill.

Drill bit is very neat: The pitch means that it seriously bites into wood: No pressure at all involved, it pulls itself forward. And the 3-way thing means that it doesn't get clogged doing it. (Just as well, it's pretty much impossible to reduce the rate at which it drills using a hand drill!)

End result is a nice neat hole through a 60mm chunk of pine, with pipe run and water flowing into pots on demand.

Yay tools!

Math fail

After posting the previous, I was going over the Kalman filter again, and realized that I had completely borked the math.

I had laboriously moved all the temperature calculation into log space because I couldn't see a way to write the matrix for the temperature decay as a function of temperature.

Silly me. I didn't need to write it as a function of time, but as a function of dt (the time interval). Which makes exponential decay all nice and linear. Doh!

So stripping all the log conversion out make it much simpler to understand and debug.

And then because I was getting bored tweaking PID constants, I wrote a trivial hill-climber in perl to search for good values. After running a few minutes that had reached the solution above.

Looks pretty to good to me! I still think I can get tighter fit to the measured temp (Red line) if I wrote a LQR but I currently fail as finding a good resource that explains how it works. ('explains' means "without going into Laplace transforms which are totally gone from my brain").

(Hmm. How can I attach text files et al to blogger posts?)

PID , Kalman filters, fun!

I started writing the software to the drive my temperature controlled oven thinking it was going to be a fairly easy process: Just whack in a PID controller, tune the constants a little, Voila!

Not so much.

Some of this is undoubtedly my inexperience, some of it is the extreme time lag between action and result, and some of it is the fairly exacting requirements I placed.

The model is something like: The heating element heats up ~ 0.6 Celsius per second that the power is applied. It cools at around r= ~0.007 (ie. It cools at roughly 0.7% of the difference between it's temperature and ambient temperature per second)

The heat transfer rate between the element and the board has r = ~0.085

This means the temperature as measured at the thermocouple is heavily lagged behind the applied power. Something like 12 - 15 seconds lagged.

This means that it's very difficult to get good performance out of the PID controller. The huge lag means that overshoot is difficult to control without high Kd constants. This would be ok, but for the relatively large noise in the temperature measurement. Quantization noise alone is ~ 1% and there's another 2% in measurement noise.

This could be reduced by low-pass filtering the thermocouple measurements but the sample rate is only about 5Hz. This means that to get the noise down to ~0.5% by straight averaging would need to average over ~ 15 data points which means 1.5 seconds of measurement lag into a system that already has extreme lag. :(

The first graph above shows my attempts at straight PID control. Keeping Kd low enough to avoid crazy noise in the PWM output means pushing Kp fairly low as low. The result is nice and stable about 50 degrees, and horribly over-damped at 120 degress.

I spent far too long fighting this, tweaking constants back and forth, generally wasting time.

Eventually, I gave up on the straight PID approach, took a deep breath and implemented a Kalman filter to be able to accurately estimate the current element temperature from the lagged thermocouple measurements and the known inputs.

This proved to be more than a little hairy: My maths is extremely rusty, the kalman filter has lots of matrix math, and I'm writing it all in C (it's running on an embedded board). It took me a couple of hours just to understand what was going on with the state update equations! (I may do a later post with some more detail on the maths).

Oh, and the modelled process is non-linear so I had to move it all to log space to linearize it so the kalman filter can operate.

The result is the second graph. The red line is what I care about, and you can see it's doing much better. It quickly gets to the setpoint (orange line), and then follows it fairly accurately (albeit lagged). The green line is the heating element. It deliberately overshoots the setpoint to improve the speed at which the measured temperature gets to the setpoint.

I'm pretty happy with this; I could just leave it like this.

But I probably won't. :) In the spirit that nothing suceeds quite like overkill, I'll probably attempt to write a LQR (essentially, it inverts the kalman filter to be able to predict which needs to be done). This would remove most of the lag between the measured temperature and the setpoint.

SMD Oven

I started looking some time ago at a temperature controlled oven to do surface-mount device soldering.

An oven has a couple of advantages: It's much easier to get even temperature distribution, and it's easier to follow the temperature soak profile listed in the datasheet (Important for some of the more complex sensor devices).

The first point has been a serious pain to me: Devices with sharp edges are likely to see those edges heat up very quickly so when using a hot-air gun it's easy to burn the edge of the part before the solder is close to melting. (Very easy. Really, really easy. Especially with expensive sensors that have wierd things poking out. Or expensive ZIF ribbon connects. For example. I'm just saying).

So I put together a simple board to interface to a K-type thermocouple. It's just a MAX6675 which does a K-type thermocouple on one side and an SPI interface on the other. This connects to an NGW100 board, and the SPI drivers in the linux kernel take care of all the hardware interfacing.

A tiny userspace program handles reading temperature. The end result is ~ 0 - 1000 celsius with 0.25 degree precision and ~ 2 degree accuracy.

This is coupled with a computer-driven relay switching 240VAC that drives an SMD reflow oven (aka, an electric frypan I picked up at K-mart). I just drilled a hole in the side of the lid to insert the thermocouple into.

The frypan is turned up to maximum, and the element is pulse-width modulated. (Actually, it's sigma-delta modulated with minimum on and off times, but let's not split hairs).

From here, it's a trivial matter of writing some software to run closed-loop control of the heating element to walk the temperature through a profile.

Plans...

While I was at Bunnings today, I had a thought about paints. My 3.7 meter wingspan glider is looking a little the worse for wear from a hasty and poorly executed repair, so I'd like to sand it back, re-glass the damaged sections, and paint it.

Sand and re-glass is easy, but the paint isn't something I've done before.



Thus, when I noticed 'epoxy gloss enamel' at Bunnings, it seems like something I should definitely try! The plane has an epoxy gel-coat, so "Epoxy Gloss" seems like it would be very compatible, right?

This afternoon I took 5 mins to sand a previously damaged nose cone and sprayed it up. It's still not quite dry yet, and it's only the first coat, but it's looking very decent indeed. When it full dry I'll cut it back to see how well the new paint is adhering.

The only issue is that my mind immediately wanders to grander plans. To wit: Rather than just re-glass, if I'm going to sand it back anyway, why not run some carbon tow under kevlar (aka aramid) sock and give it some decent strength in that area.

This is an attractive idea, but there's some practical difficulties: The fuselage is about 1200mm long, so putting it in a vacuum bag is going to be very non-trivial. And protecting the wing bolt nuts from epoxy is going to be similarly interesting. Lets not forget the tow hook underneath which is not built for large compression (750 newtons of tension yes, compression no).

So I'm still pondering what to do here. The repair certainly is ugly, and I'm concerned about the strength given the cruftiness. But the sanded back fuselage is probably not going to be up to carrying a full atmosphere of pressure in a vac bag.

Which means I need to finish off the pressure-to-I2C board I have lying around, so I can have one of the NGW100s run closed loop pressure control of the vacuum pump. But the MPX5010 pressure sensors I have only run 0 - 10 kpa, so they're only good for 1/10th of an atmosphere. So I need to get some larger range sensors. Or make a microswitch based one....

Yak Shaving again! I just start looking at repainting a plane, and now I'm off buying new solid state pressure sensors!

It's a terrible life :)

A Cautionary tale.

Some time ago I built a trivial irrigation controller. Based on a Atmel NGW100 (AVR32 CPU) it just controlled 2 x AC solenoids. Taking the easy way out, I used a couple of solid state relays to do the buffering between the CPU and the solenoids.

In keeping with keeping things mildly simple, I also derived the board power supply from the 28VAC that drove the solenoids. 28VAC, into a bridge rectifier, across a capacitor, and into an LM7815 supply a nice 15VDC that the NGW100 was very happy with.

The thing that wasn't happy was the LM7815. It was sinking the best part of 150ma across a ~15 volt drop. AKA a 2 watt dissipation. The LM7815 is something like 65 Celsius per watt to air, so that wasn't going to fly. I add a tiny heat sink I had lying around, but it got a bit hotter than I'd estimated (and than I was really happy with), so I just bolted it to a whacking big hunk of aluminium and called it a day. That's been working nicely for a couple of months now.

In the interim, I'd ordered some DC/DC converters. Little drop-in replacements for LM78xx devices, they promised to make all the heat issues go away.

So today I pulled the box out, and happily removed the LM7815 and added in a dimension engineering device. Adjusted it for 15 volt output and all looked good.

In an abundance of caution, I checked the voltages across everything between taking it all live.

This was fateful. Much to my surprise, the DC voltage from the bridge rectifier was over 40 volts! No wonder the poor little LM7815 was unhappy. I guess nameplate rating don't mean much on AC devices. It's putting out considerably more AC than it's rating. (Too light a load probably?)

A thought tickling the back of my mind had me looking up the datasheet: The absolute maximum rating for the DC/DC converter was 35 volts.

Yuck.

At this point, I should have put anything back and called it a day. But no, I was much to pig headed for that.

The next thought that occurred was "Well, 40V is too much for the DC/DC and too much for the LM7815, so why don't I just run the DC/DC with a floating ground to make it happy?". I.e. connect the ground for the DC/DC convertor to the output of the LM7815, so it only sees a ~25 volt differential. The connect the input of the LM7815 to the output of the DC/DC so it only sees a ~2 volt drop it has to manage, and every one's happy.

Oh, sorry day.

So I stupidly wired this all up, blightly ignored concerns about "what does this look like when it's powering up?" and "Is it stable!?" and promptly managed to stuff a 40volt power-on spike into the NGW100. Which has it's own DC/DC convertor with a 22V absolute max rating. Which blew up. :(

In hindsight, this was bleeding obvious. The DC/DC is going to look like a short circuit to ground on power-up (charging caps), so it's going to drop the full 40V to the line after the LM7815 == Boom! No shortage of haste and stupidly around here! No siree!

Very unhappy. To make it better, on my TODO list for later in the day was to write the software to backup all these boards I have running around the place. :( And all the mucking around, testing and poking, and then trying to coax the NGW100 back into life had chewed up most of a day. Very, very unhappy.

But the time I'd put a new board in, put the old power supply back in, and re-writing the software it was a 14 hours exercise in utter pointlessness. Not that I'm bitter or anything!


The only bright spot was: I got a new toy. I've been meaning to get a Li-ion cordless drill for some time, but last I looked (umm, about 2 years ago) they were pretty expensive.

Today I picked one up at bunnings for ~$AUD200 including spare battery. Wow. Prices really had dropped! It seems to work well: I was putting 7mm holes into timber this afternoon and it was doing just as well as the corded beast.

(The corded beast really is a beast: I bought it when I was driving 150mm bugle screws after the 600W drill I was using leaked all it's magic smoke. The beast has enough torque that I'm in fear of my wrist bones on occasion).

Oops!

Ooops! Stuffed it up. Shortly after I send the board off, I realized that I had the 12V and GND the wrong way around on the jumper!!

This is just my sillyness in not checking it: I normally put power pins above ground pins, but the NGW100 doesn't follow my standard.

Being extra careful before sending it off again, I noticed that I had also managed to get the distance between the two 36-pin header wrong. Argh! Really not my day. And they were 34 pin headers instead of the correct 36 pin.

Ahh well. Board is now very carefully checked, send it off to batchpcb.com

Relay board (plus a bit)

Following on from my successful 240V project, I designed a board to attach to the NGW100 and drive up to 8 relays.

The form factor for the board was dictated by the placement of the J5 and J6 jumpers on the NGW100, so there was a lot of spare board area.

So the logical thing to do was stuff in just about everything thing else I could think of that I ever interfaced to the NGW100. Which is why there's also 8-channel 1-wire interfaces, an SPI interface, and an RS-485 half-duplex driver.

The silk screen lists the RS-485 driver as the MAX-487, but it's really the equivilant 3.3V part. (I got lazy and skipped making a custom part in the library for it).

This board will plug straight into the NGW100, picking up all the signals from J5 and J6, and picking up supply power for the relays from J15, being the pre-DC/DC voltage.

This means that I can supply the NGW100 with 12VDC, which the onboard dc-dc convertor will drop down to 3.3V for the ARM32, and the daughterboard will take directly as 12VDC for the relay driving, but 3.3V for the SPI, 1-wire, and RS485.

First 240V project!

Created my first 240V project over the weekend.

I now have a NGW100 emebedded ARM board driving a relay that switches 240V on or off.

This is wired to a K-type thermocouple that measures temperature up to around 1000 degrees celcius.

The final result is that I can now do controlled temperature profile for SMD soldering. The board monitoring temperature in an electric fry pan, and turns it on or off according to time and temperature to do a nicely controlled profile per the component datasheets!