Poor control

So I've been collecting data from the temperature monitors for a while now and one thing is abundantly clear.

The air-conditioning controller sucks.

(That would be HVAC for the crazy people that still haven't gone metric yet)

Graph is of room temperature for 4 rooms over the last 24 hours, with the air-conditioner turned on at ~ 1930. Note that it starts cycling almost immediately.

To put it in context, this is an AC that has a variable-speed-drive on the compressor, so there's no reason whatsoever that it should be oscillating. The PID loop driving it (and I do hope there is a PID loop...) should hold it all at a steady state.

(Note that the green line aka Living Room zone was turned off until ~ 2330 which is why it didn't start cycling until then. And the reason that the study isn't cycling more is that the balancing is awful and there's not enough air going to the study. Something I need to climb into the roof space to adjust the dampers for I think.

The AC is a Daikin FDYQ200MR. Which is a 22.2KW system I think. (Note that that's not the power draw: That's the peak heat-pumping capability).

Added to the to-do list: See if I can find datasheets for the AC VFD + compressor + evaporator, and scrap the existing controller in favour of talking to the VFD directly. Task #5412345 I think that is...

Echo

The main living room in our house has always been a little harsh to my ear; I've been complaining to the wife that there's just too many hard surfaces in the room (lots of windows) which make it very 'bright' acoustically. This has the big down sides of making it difficult to understand what people are saying on the other side of the room, and annoying the hell out of me which the kids start making a racket.

So when D poked me on the subject this evening, it motivated me to go measure the problem. Mostly in a half-arsed sort of way to start with.

I used a crappy USB webcam which happened to have an in-built microphone to record audio, and then a tiny bit of perl to play a 1 KHz pulse out of the TV speakers at reasonably high volume. (Just a single cycle of a 1 Khz sine wave).

There are so many things wrong with this as a measurement setup it's difficult to count them all (not a pure tone, speaker distortion, awful directional microphone, no calibration to speak of, etc, etc, etc) but it was to at least give me an indication that it was worth putting more effort into it.

The graph above is the result. X axis is in seconds. It's rather entertaining that there's still significant energy in echos at 250 ms past the impulse. So it's not just all in my head: The room really is very echoy. Which I already knew, but now I has some numbers! Which is surely most of the way to fixing the problem, right?

Unfortunately, reducing echo is probably going to be non-trivial. At least, it will be given that D's hard requirement is that I don't cover the windows in felt...

We'll start with simple things like throw rugs over the couches, a tablecloth over the dining table, felting the undersize of the table and the bench. And if all else fails, the dreaded curtains discussion will probably enter the stage.

But first I need to get a better microphone. And some sort of software that's able to effectively measure and display how much the echo has changed. And maybe a good psychoaccoustic model. And a pony!

It's nice to be home...

Being away with family in entertaining, but there's something very nice about being home.

Today I have:

• Kicked off PicardTagger to fix up all the tags on my various MP3 files. Free hint: If you have 26,000 mp3 files, don't try and feed them all at once into Picard. Looks like there's at least some O(n log n) algorithms in there, if not O(n^2).
• Much hacking with Eye-Fi. It nows properly with the main linux server.
  
• Rebuild an N800 device as a video-player for Katie. This is notable hindsight: It would have been better to do this before the 4 hour plane flight... Firmware is upgraded, video transcoder tools are installed and running. I ordered a new 8G flash micro sd-card to hold the videos.
  
• Start more actively hunting down a dehumidifier for the garage. I'm tired of fighting the rust battle on the milling machine and lathe; I'll cheat by just dropping the humidity. Right now, it's often in the 80% range which is deadly to precision iron. EBay sniper is fired up and ready!
• Fixed the bluetooth download for D's phone. The script that auto-detected D's phone as being in range and then grabbing all the pictures on it via bluetooth was broken by the semi-recent OS upgrade (forgot to cover up a config file). Each fix, but I still need to add some monitoring for it.
• Had a long chat with Andrew B about planes,rockets and software. He kindly brought over the paint needed for my glider, so that's a repair I'll kick off on friday.
• Polished off PID software for SMD oven. I left the hill-climbing running while we were away, so now I have the PID constants tuned to better than 6 significant figures. (NOTE: This is a total waste of time! This was running against the simulator, not the real hardware. But it's still entertaining). I had intended to use it in anger today, but ran out of time. The boards for the 200W audio amplifier are on the bench, I just need to heat them.
  
• Gone for a swim with the kids. The long days make it very pleasant to go swimming at circa 7pm at night. I'm still waiting for the relay PCB boards to arrive from batchpcb.com but I have patience. Maybe. I hear Olimex calling my name.
• Ordered the timing belts and pulleys for the mill CNC conversion. I'd decided that I'm just going to do it and the cost isn't that outragous. At least, not in comparison to some of the other things I've wasted money on over the years.

It's nice to be home. :)

Eye-Fi

Update: Perl standalone server that runs under linux for Eye-Fi card is linked here.

I bought an Eye-Fi sd-card a few weeks ago in a fit of laziness. The idea being I could put it in the SLR camera, and it would auto-upload images to the fileserver instead of me having to do the (very onerous..) walk to the server and plug it in.

I bought it in ignorance of the hugely proprietary nature of the card; Not sure I would have bought it knowing what I know now.

Part of the problem is that Eye-Fi's business model apparently includes charging large sums of money for trivial features. Thus, they go through all sorts of contortions to avoid you implementing said trivial features yourself rather than paying them.

Luckily, the protocol that the card uses on the WiFi side has been reverse engineered by others that have gone before me.

Chris helpfully wrote a little perl server that looked like it worked once apon a time. It appears that Eye-Fi have changed a few things since then so it took a little bashing to get it to work seamlessly with my card.

The two major changes are the certification calculation and the transfer mode.

It turns out that a different forumula is used to authenticate the client to the server. It's md5(mac addr, upload key, snonce) rather than the md5(mac address, cnonce, upload key) used in the other direction. Seems strange to me; Not sure this isn't a bug in the Eye-Fi code.

The other one is reflecting back the transfermode and transfermodetimestamp used in the session setup. Without this, the Eye-Fi refused to transfer more than one picture in a session.

Some minor changes include the server doing a fork for each client connect, and an unsuccessful attempt to verify that file checksum. The eye-fi card passes an MD5 sum along with the file on each upload, but it isn't a straight md5 of the tar file, nor of the embedded JPG file. I had a very quick poke, but the calculation wasn't immediately obvious to me so I wrote it off as a 'nice to have'.

Changed file can be found here. The upload key that's required in the file is stored in Settings.xml if you've used the windows app manager to configure the card. (Which I did: I failed to get it to do anything useful when run under wine).

So now I have it all working on my linux fileserver; When the camera comes into range and it's turned on, photos are automagically dropped into a spool directory, and a little daemon renames them into timestamped directories. So now I'm happy. Yay. :)

Ps: I would really have liked to get working the eyefi-config tools that Dave Hansen wrote but I simply couldn't get them to do anything beyond detect that there was a card in the USB adaptor. It appears that the protocol between the manager and the card has changed enough that the tools no longer work.

I had a quick bash trying to get the manager to run under wine so I could spy on the protocol, but after more than an hour of fighting wine the end wasn't in sight, so I moved onto other things.

IP Camera.

In my ongoing frustration to find a relatively cheap, IP based camera, I started looking at the Sparkfun 1300x1040 CMOS Camera. This is a $USD10 device, that connects via an 8-bit bus to ... something. In my case, that would be an ATNGW100.

I'll probably have to make up a board for it, to be able to handle the full bit rate, but the end result would be an IP camera for about $AUD160 - $AUD200 that handles a full mega-pixel, and does on-board motion detection. Assuming that I can get it efficient enough on the CPU. :)

It pretty much requires DMA to get the data into memory, but the camera does on-board JPEG compression so it should be too bad to ship the resulting data out over the network. And trivial jpeg decode just enough to do motion detect will hopefully be light enough on the CPU..

Anyway, something to play with. I ordered a couple so first step will be to see if I can actually get a picture off them.

CNC for Milling machine.

Making intermittent progress on converting my knee milling machine to CNC. This is random notes on my researches to date

Those that have gone before: Hafco HM-52 CNC Conversion

Torque goals:

1. Maximum handle pressure in normal operation is probably under 5 kilograms.
2. Handle radius is ~ 3 inches.
3. This is ~ 3.3 newton-meters of torque.

Speed goals:

1. Table is ~ 1200mm
2. Would like to be able to go one of the table to the other in substantially less than a minute.
3. Say 12 seconds?
4. Speed circa 6000mm/minute.
5. Leadscrew is ~ 3mm/turn from memory (8 tpi)
6. So need around 2000 rpm at the leadscrew for this speed.

Which gives around 600 rpm/Nm required from motor. So something around 5000 rpm @ 1.5 Nm peak torque would be ideal. (Using timing belt to gear it down to 2k rpm @ 3.3Nm).

Would like to use brushless DC motors for efficiency, heat, ease of sealing et al.

Can use of-the-shelf brushless controllers but they're expensive, and require hall-effect sensors on motors.

Can use Takao Shimizu effort, and modify slightly for sensor'ed operation. This would require doing boards, a fair bit of testing and mucking around, but probably substantially cheaper, particularly if I do a bunch of such boards.

Looking to use EMC2 for motion control, so the Mesa boards seem popular and vestitile. Particularly the 7I43-U which is USB or parallel port @ $USD90. Mesa also sell the 7I39-LV which will drive 2 BLDC motors at up to 250 Watts. ( ~ $USD300 for 4 axis). This is currently ~$AUD600 plus shipping. Hmmm.

On the other hand, running brushed motors enabled using the 7I30 which does 100W/channel over 4 channels for ~$USD90. This would effectively drop the top speed to ~2500mm/minute for the X and Y axis, and something much less for the Z-axis (which will need to be geared way down anyway).

Still need to find a suitable source for servo motors (i.e. cheap!).

GCAM is looking for more useful for simple CAM tasks.

Need to change over to anti-backlash nuts for X and Y axis (can probably rely on weight to handle Z-axis). Simplest thing is probably to use delrin split nut? May need to make/buy an suitable ACME tap for nuts (or find an already made one on ebay?)

APT looks like an interesting thing to play with for CAD/CAM.


Cheap rotary encoders are available for $USD25 ea. Example of one being fitted is here.

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.