Posts Tagged profiling

Laser water cooling, part 1: Peltier element theory

I just ordered a laser engraver/cutter from China.  While I wait for the slow boat to come into port, I thought it would be a good idea to start preparing the infrastructure.  These products don’t include any hardware for the required water-cooling, other than a submersible pump.  Most people just say “just have a few gallons of water circulating, and you’ll be fine.”  I say “if it’s worth doing, it’s worth overdoing.”

In the spirit of overdoing it, I remembered that I had a peltier element-cooled fridge in my lab for a while, and that the parts were still kicking around somewhere.  Peltier coolers are really neat.  They can use an electrical current to drive a difference in temperatures on the opposite plates.  I found an interesting page with a simplified model for calculating their performance across a range of conditions.  It’s interesting to note that you can’t just drive it harder to move more heat.  Because the modules are consuming energy themselves, self-heating can (and often does) overwhelm the coolers ability to move heat.  After spending a couple days understanding the models, I discovered an error in the page, so I’m going to re-post corrected equations.

Computation of T1

This equation computes the temperature of the “cold side” of the cooler.  The model depends on several variables:

I = Drive current (Amps)

Rp = Cooler resistance from the data sheet (Ohms)

Q1 = Thermal load that we’re trying to cool (Watts)

C1 = Thermal conductivity from load to ambient (Watts/°C)

Cp = Thermal conductivity through the peltier (Qmax/ΔTmax) from the data sheet

Ch = Thermal conductivity of the heatsink on the hot side (Watts/°C)

T1 = Temperature of the object being cooled (°C)

T3 = Temperature of the ambient environment (°C)

I’m going to ignore P.  For now, it suffices to say that it’s a constant that models the peltier junction’s performance.  (Watts/Amp)

The article that I got this model from doesn’t really explain the terms at all, so I’m going to try to interpret the pieces of it.  First of all, the T3 term references the entire model to ambient.  If you used something else as a counterpoise, I’ll call it, to the peltier you could remove this term and model it.

The middle term models the heat flow out of the hot-side heatsink.  The numerators of this term are the thermal load (Q1) and the self-heating from the peltier cooler’s current (see Ohm’s law for the inspiration of this).  The entire term is divided by the thermal conductivity of the heatsink, Ch.  Thermal conductivity is a very useful specification, as it tells us the °C across the device per Watt.  In the case of a heatsink, that is referenced to ambient.

The first term models the heat flow from the load through the peltier.  Again, there is the Q1 term, as we have to get the thermal load through the device.  Second, we have half of the peltier’s self-heating.  My assumption is that only half of the peltier’s self-heating has to travel all the way through the device.  Finally, the -P*I term models the active cooling (the point of this whole thing).  These are all divided by the combination of the thermal conductivity of the load-peltier junction and the peltier’s internal thermal conductivity.

The upshot of this, is that we can model the performance of our system built around a given peltier junction given load, heatsink performance, and ambient temperature.


Now, let’s talk about P.  We can derive P entirely from information commonly found in peltier junction datasheets.  There really isn’t much more to say about this, just plug in the values…

The module I'm working with

The module I’m working with

Now, let’s make all of this a little less abstract…  The image above is the module that I’ve salvaged.  It’s easy enough to lookup the model number and get the data sheet.

Specification table

Specification table

Using the specification table, directly from the data sheet, we can calculate P to be 14.47 (for 25°C).  For now, let’s also choose some values for the other parameters.  Let’s say we want to cool a load that is producing 10 Watts, with a rather poor heat sink that has .2 Watt per °C of conductivity (would be listed as 5 °C per Watt as resistance).

T1 heat versus amps, with simple heatsink (blue) and ambient (green).

If we graph T1 versus drive current, I, we can see that the optimal current from the cooler is 0.8 Amps (red line).  Unfortunately, if we compare it to Q1/Ch (which would happen if we just put a heatsink on the load) it’s almost 6 °C hotter than without the peltier cooler…  boo.   The laser is estimated to produce about 200 Watts (20 times more than the 10 Watt example) of heat.  The problem, ultimately, is that the hot-side heatsink matters.  A lot.

T1 heat versus amps, with simple heatsink (blue) and ambient (green). With a better heatsink

T1 heat versus amps, with simple heatsink (blue) and ambient (green). With a better heatsink

Now, what happens if we find a much better heatsink?  They’re expensive, but you can find .1 °C per Watt heatsinks on Digi-key.  This would be 10 Watts per °C in terms of conductivity.  With the better heatsink, the cold side is down to -17 °C!  The heat sink is more than able to shunt the heat from the load and the cooler.

All that is obviously super-awesome, but what if we want to calculate what the ideal drive current is for a peltier cooler?  The Itec equation, above, will give us this information.  We still need the P and Rp terms from the data sheet, and the thermal conductivity of the peltier and the heatsink.  But, you’ll notice that thermal load and the ambient temperature are not factors in the equation.  Therefore, the ideal drive current (and, therefore maximum temperature drop) are not affected by those factors.

I hope this has been at least somewhat interesting.  Stay tuned for part two, where I investigate whether it’s really feasible (practically and economically) to move over 200 Watts with peltier elements.  Also, I’m planning some research into how to characterize the efficiency of radiators in liquid cooling setups.  If you have any insight, please leave it in the comments.  Also, I started to write a mac application to model peltier cooler systems.  I probably won’t finish it unless it seems like something people would want.  Leave messages in the comments if you would pay a few dollars for something like that.

, , , , , , , , ,


Homebrew bubble counter

Counting bubbles during secondary fermentation

For a while now, my friends and I have been brewing beer at my house.  I was inspired by an old Sparkfun tutorial about a bubble logger for Nate’s terrible wine.  I figured that while logging bubbles is interesting and all, wouldn’t it be more useful to have real-time information on the fermentation process?  I basically copied the optical gate method of counting bubbles, added a sensitive pressure sensor, and an AVR development board (Yes, Arwen, that’s your old TekBots board! 🙂 ).

Just like the Sparkfun tutorial, I used an IR photogate sensor on an S-shaped airlock.  One thing that I thought was really interesting is that the water in the airlock doesn’t block the IR path, it actually improves it.  I ended up needing a potentiometer to adjust the LED brightness on the photogate, this is because it has to be just the right brightness to detect bubble transitions.

Counter closeup

The programming on the microcontroller was really simple.  All it does is keep a clock, and when there is a rising edge of photogate signal (bubble passed) it prints the time and a bubble count to the serial port:


I chose to use whole seconds as the time step.  That was certainly an oversight.  When I designed the software, the brew was in second fermentation.  There was a bubble once every 20 seconds or so.  I thought “It couldn’t be that much more during primary fermentation, right?”  Wrong.  During the beginning of primary fermentation, there can be 3 or 4 bubbles a second.  I made up for this oversight in the Ruby script I wrote on the server:

# Get an interval from the last to this bubble in seconds
interval = seconds - last_record_seconds
last_record_seconds = seconds

if interval == 0
	bubbles_per_second += 1
# if, in the last second, we counted more than one bubble
# find the frequency by multiplying the bubbles per second
# to bubbles per hour
	if bubbles_per_second > 0
		frequency = bubbles_per_second * 3600
		bubbles_per_second = 0
	# Convert the interval into fractions of an hour
		interval = interval / 3600.0
		# Convert the interval to bubbles per hour
		frequency = 1.0 / interval
		printf("%f bubbles per hour\n", frequency)
		RRD.update(rrd_name, "N:#{frequency.to_s}")

I’ve left out the parts where I initialize the serial port and the RRD database and parse the messages.  I’ve attached the whole script, including the script that generates the graph, at the end of the post.

Chocolate porter brewing record (primary fermentation)

Here is the bubble record from one of our beers.  I was very surprised by the 14,000 bubbles/hour rate achieved a half-day after pitching the yeast.  I adjusted the graph many times to make everything visible.  I absolutely had to use a logarithmic scale on the value access, there is just no other way to be able to see a 14k+ value while still being able to see where 60 bubbles/hour is (this is about when the brewing is finished).  These graphs are always updated, and are available online.  Of course that is only meaningful when there’s a brew going at the moment!

Sensitive pressure sensor

I had grand plans of adding a pressure sensor to try and measure the volume of co2 escaping out of the airlock.  I figured that if I subtracted the pressure after the bubble from the pressure before I could use the ideal gas law and measure the moles of co2 that escaped.  This was all fine and good during secondary fermentation (when I first tried it).

Pressure delta during slow fermentation

During slow fermentation, when bubbles happen less than once per 15 seconds or so, it’s easy to see and measure the pressure difference before and after the bubble.  In the image above, there is about 40 mV of swing before and after.  The time represented in this image is a full minute, so you can see the slow buildup of pressure.

Pressure measurement during fast fermentation

During very fast fermentation, on the other hand, individual bubbles don’t contribute to much difference in pressure.  In the image above, you can see general trends of pressure.  Sometimes, i assume, due to surface tension there aren’t bubbles for a while.  When pressure builds up to a sufficient level bubbles begin.  The pressure drops again and the cycle repeats.  I’m not really sure how much I can do with this data.  The time represented in this graph is 12 seconds, and the bubbles per hour is about 18,000 bubbles per hour (5 * 3600).

Close up of a bubble during fast fermentation

This is just a close up of a single bubble.  There isn’t really any measurable difference in pressure before and after the bubble.  Ultimately, the pressure measurement stuff is on hold for the moment.  If someone reads this that’s really good with the ideal gas law has ideas let me know!

The next step for me is to figure out an elegant way to support many brews.  We’ve got a wine, apple cider, and a beer going at the moment, so I would like to have 3 channels.  Oh well, another project for another day.

Supporting files:


ruby script

Development board schematic

, , , , , , , ,


Toaster Oven Temperature Profile

Reflow Oven temperature profile

Reflow Oven temperature profile

I’ve decided to spend some time profiling the toaster oven.  In addition, I’ve made a simple controller board that may get the brains to manage a reflow operation on it’s own one day.  For now, I’m satisfied learning more about the oven’s capabilities.  An interesting thing to notice is that it (appears) incapable of satisfying the recommended profile from Kester.
I wanted to start with a very simple controller that gets most of it’s brains from an attached computer.  This is a somewhat central tennant of the way I build most projects.  The reason for this is that computers have really huge screens, and nice keyboards so it’s easy and cheap to have a cool UI.  For this project I’m still working on the OpenGL for the realtime graphing of the temperature profile, but you can see what I have designed so far:

Oven Controller UI

Oven Controller UI

The left side of the window is where the realtime graph window goes, the oven system status is in the upper right, with the reflow profile defined by the user in the bottom right.  Anyway, back to the controller hardware.

The controller is built around a PIC microcontroller and the MAXIM 6675.   The 6675 is a thermocouple conversion chip that handles all the analog complication of dealing with thermocouples (including cold-junction temperature).  The microcontroller interfaces with it through a simple synchronous serial protocol.  One thing that you have to keep in mind with this chip is that if you request a sample more than 4 times a second then it doesn’t finish the conversion.  I decided to let the microcontroller handle waiting for the appropriate amount of time, taking a sample, and sending the data over the serial port.

Because computers don’t have serial ports anymore, I have to include serial to USB converters on everything.  In this case I used the FT232RL schematic block that I copy and paste whenever I need it.  Here is an image of the completed schematic (Full size PDF):

Reflow Oven Controller Schematic

Reflow Oven Controller Schematic

Like almost all my projects, I got a board made at BatchPCB.  It turned out great:

Oven Controller Board

Oven Controller Board

Unfortunately, I wasn’t able to find a nice socket for the somewhat standard plug they put on the end of thermocouples.  In this case, I just used a screw terminal.  The posts on the left go to the thermocouple wires.  I’ve included another pair for adding a relay that could be used to switch power to the oven.  Also, I’ve included a port that could control a R/C servo that could open the front door to facilitate rapid cooling of the oven.  Eventually, I’d like to allow this controller to begin a reflow cycle when the button in front is pressed, runs until the target temperature is reached, shuts off power, and opens the door at the perfect time.  For now, I still have to watch and stop when I feel it’s right.

The thermocouple is installed just by using the friction of threading it through the oven rack that is installed above the board.

Oven thermocuple installation

Oven thermocouple installation

To keep everything relatively tidy, I double-stick taped my controller to the side of the oven:

Oven Controller Installation

Oven Controller Installation

Finally, I’ll analyze the graph from the beginning of the post.  For you’re convenience, here it is again:

Reflow Oven temperature profile

Reflow Oven temperature profile

The blue graph is the recorded profile used while soldering an actual board based on my observations.  I stopped the oven cycle based on the advice I gave in my other post about the Toaster Oven Reflow Soldering post.  For the Green trace I ran the oven until the thermocouple read 210°C.  I decided to run it without a board in it because I didn’t want to smell burning FR-4 ;).  I’m not saying that it would have actually burned it, but I realize now that I really need to calibrate my thermocouple against a trusted reference thermometer.

To compare the actual results against the specifications in the Kester datasheet, I’ve included a line for the maximum and minimum profiles.  For the preheat phase of the profile all that is required is that the temperature increases less than 2.5°C/second, up to 150°C so I didn’t include it.  Once it reaches 150°C the temperature needs to increase between .5 and .6°C/second up to 180°C.  From 180°C to 210°C temperature needs to increase at a rate between 1.3 to 1.6°C/second.  As you can see the toaster oven almost keeps track with the 150-180° rate, but can’t achieve the 1.3-1.6°C/second ramp rate.  I’m not sure what the exact effect of this is, but I’ve had good results so far.

Anyway, it was an interesting exploration.  I do kinda wish I was able to match the correct profile, but I’m glad in a way that it doesn’t because I don’t have to implement a PID temperatue controller :).

, , , ,