Home made cold slab ice cream

Executive summary: With an 11 pound slab of aluminum chilled in my freezer overnight, I can make one small 30g serving of ice cream.  Other promising avenues include brine instead of aluminum, and dry ice + alcohol (which gets waaaay colder than your freezer).

----

I was daydreaming about 3D ice printers, and it occurred to me that I might be able to make Cold Stone style ice cream if I put a big chunk of metal in the freezer.

My first thought was to use steel, but aluminum turns out to have almost twice the specific heat of steel and about 4 times the thermal conductivity.  So for a given weight it can absorb more heat, and do it faster.

I had an 11 pound hunk of 4"x4"x12" aluminum left over from the rotary mill, so I cleaned it up and put it in the freezer for a few hours.

The tape was to help me more accurately measure the temperature with an infrared temperature gun, but I think a contact thermometer would be better.

I used a 1:1:1 mixture of cream, sweetened condensed milk and fresh strawberries.  I'm not sure how much the cream adds to the experience, so I think it'd be worth trying just sweetened condensed milk + strawberries.

But even after lots of waiting and pushing it around on the plate, it never quite froze (but read on!).

Doing the math: should we expect it to work?

Later it occurred to me to work out the heat of fusion of the ice cream and see how that compares to the heat required to take the plate from my freezer's ~0F to 32F.  Wolfram Alpha tells me that "specific heat of aluminum * 11 pounds * 15 K difference" takes 67,700J, whereas 100g of water (~5.5 moles) needs to lose about 30kJ to freeze.  So that says my big chunk of aluminum should be able to absorb 2x as much energy as I need to freeze a small serving of ice cream, but that's assuming it starts at 0F and doesn't count any other losses (like ingredients that need to be cooled down to 32F, and absorbing ambient heat from my kitchen).

So I'll give it another go with the plate freezing overnight, but I suspect I'd need to start out colder than 0F to really make it work.  

And that makes me think this guy's clever solution of dry ice (-109F) cooling a griddle through an interface of liquid alcohol is probably a better solution.

Take 2:

On second thought, I think my IR thermometer may have been telling me something useful.  On my first attempt, it claimed the plate was only down to about 20F.  Leaving it in the freezer overnight and turning down the thermostat a bit, the plate got down to under 10F, and I made my first successful batch:

One spoonful of cream, one spoonful of sweetened condensed milk, and one spoonful of strawberries came out to about 30g.

Still marginal:

I tried a second serving right after the first, but it wouldn't freeze.  So 30g seems to be about the limit for this plate at this temperature.  I'm not sure how much of that is due to the ingredients warming up, the plate warming up as a whole, or the first batch putting too much heat into the surface of the plate (and it not being able to dissipate quickly enough into the core).

I pulled out the Flir One to see if I could sense one face of the plate being warmer than the others.  Aluminum tends to reflect thermal IR, and in the video below you can see it acting like a mirror:

Mostly it's reflecting heat from the rest of the room and the cold towel it's sitting on.  You can see some fingerprints after I touched it, and I'm not sure if that's something to do with condensation or with giving it more heat to emit, such that it's noticeable over the reflection.

To combat emissivity issues, I put a strip of tape around the four sides, since the tape won't reflect LWIR like the aluminum does.  Unfortunately, I only did this test after rinsing off the plate in the sink, which seems to have warmed it up (or at least the outer region of the plate) quite a lot and overwhelmed any evidence left from the ice cream session.

But based on earlier photos like this one, I'd guess that the heat gain is more uniform than localized.  (And I think this photo shows less reflection than the video because there was icy condensation on the plate at that time).  Maybe somebody with a better background in thermals could comment with a back-of-envelope calculation on how fast we'd expect the heat to dissipate into the core of the plate.

Saltwater instead of aluminum?

Also note Damien's suggestion below about using brine as a cold source.  Looks like a salt water solution above 33% freezes to -6F, so it gets cold enough for us.  And looks like its heat capacity is about 3300 J/(kg * K) compared to Aluminum's 910 J/(kg * K).  So it holds over 3x as much cold by weight (and since it's lighter, it has a smaller advantage by volume as Damien cites).

Weirdly though, for thermal conductivity, aluminum is reported as 205 W/(m*K) and brine says it's around 0.4 -- that's a 500x difference!  I expected completely the opposite, since liquids have natural convection and good thermal interfaces to neighboring materials.  So maybe the way they test thermal conductivity somehow controls for those factors, because I'd certainly expect putting my hand in freezing brine to be at least as chilling as putting it on a slab of aluminum.

Of course salt water is also way cheaper than aluminum.  So a thin hollow vessel, say, a box made out of thin stainless steel plate, ought to be cheaper and more effective by weight, assuming my intuition is right about brine's conductivity.  The most annoying part might be keeping the box sealed and avoiding bubbles, since we want to freeze our cream on the top surface of the box, and air bubbles won't conduct heat very well at all.

While we're on the topic, normal water ice also has better heat capacity than aluminum by weight, and like brine is listed as having less than 1% of aluminum's conductivity.  But it's easier for me to believe that solid ice could be a much worse heat conductor than solid aluminum.  So I wouldn't expect a block of ice at 0F to work as well as an aluminum slab or liquid brine.

One more thought on brine: rather than chilling it in a freezer overnight, you could also apply salt to ice traditional ice cream makers do.

Anyone got an answer to the mystery of low brine conductivity?

California Air Tools sucks

I bought this California Air Tools CAT-4620AC air compressor over a more respected brand like Makita because it's supposed to be so quiet. They claim it's only 70dB, about the level of a spoken conversation.

Well, it's not.  It's as loud as my existing compressor that's rated over 90dB.  Being 20dB louder than claimed isn't an accident.  I actually like that it has an aluminum tank, and I might have even bought it for that reason alone, but lying about noise level really ticks me off.

Compile NVidia Jetson TX1 kernel on device

There are lots of threads about problems compiling new kernels for their Jetson TX1 boards.  A lot of the issues seem to be related to the cross compilation environment.

The TX1 is pretty beefy, so I figure it can compile its own kernel.  I installed an SSD to give me enough disk space, then copied the source_sync.sh script from the Jetpack installation to the device.  I had it download the 'tegra-l4t-r24.2.1' tag which is currently the latest version.

I copied over the .config file from /usr/src/linux-headers-3.10.96-tegra/ to my kernel/ directory to start with the stock kernel config.  Then I ran make menuconfig to set the additional modules I wanted.

Alas, when I tried to compile with make -j6 zImage, I got errors like this:

  VDSO32C arch/arm64/kernel/vdso32/vgettimeofday.o
/bin/sh: 1: -Wp,-MD,arch/arm64/kernel/vdso32/.vgettimeofday.o.d: not found
/mnt/ocz_ssd/leopard/kernel/arch/arm64/kernel/vdso32/Makefile:40: recipe for target 'arch/arm64/kernel/vdso32/vgettimeofday.o' failed
make[2]: *** [arch/arm64/kernel/vdso32/vgettimeofday.o] Error 127
scripts/Makefile.build:455: recipe for target 'arch/arm64/kernel/vdso32' failed

Apparently it has something to do with backward compatibility to 32-bit ARM, which I don't even care about.   To get around that, I installed the 32-bit toolchain with 'sudo apt-get install gcc-arm-linux-gnueabihf', then export CROSS32CC=arm-linux-gnueabihf-gcc

The next issue was this:

drivers/platform/tegra/tegra21_clocks.c: In function ‘tegra21_cpu_clk_init’:
drivers/platform/tegra/tegra21_clocks.c:1064:31: error: logical not is only applied to the left hand side of comparison [-Werror=logical-not-parentheses]
  c->state = (!is_lp_cluster() == (c->u.cpu.mode == MODE_G)) ? ON : OFF;

That was fixed with an extra set of parentheses:

  c->state = ((!is_lp_cluster()) == (c->u.cpu.mode == MODE_G)) ? ON : OFF;

That seems to do it.  I could then make -j6 zImage as well as Image, modules and (sudo) modules_install, then copy the zImage and Image to /boot.

Brass hammer from hex bar stock

My friend likes to make wooden mallets:

So I thought he might get a kick out of making one with a brass head.  Here's the head so far.  (he's still thinking about what to do for a handle).

This much 1.5 inch hex bar stock cost me about $50 on ebay, enough to make two heads:

The bar was too big to fit through the headstock on the lathe, so on the mill I clamped it sideways and faced the ends, indicated it vertical (overkill), used the edge finder to find the center, then center drilled both ends:

I tapered a piece of scrap steel rod in the chuck to make a dead center.  That let me turn the piece "between centers", which is a lot more accurate than clamping the bar in the 3-jaw chuck.

I was inspired by this brass hammer, but I wasn't sure if I wanted to use the same shape for the head.  I decided on a taper, and tried several different variants.  Because of the center hole, I had to discard the first half inch or so of stock, so it was a great place to experiment.  Here's a 20 degree taper:

Collar grooves look nice but ultimately I kept it really simple:

This profile was really tempting as well: flat / taper / flat leaves a sort of brickish look that's very hammer-like:

In the end, a 10 degree taper at each end was all I wanted.  It produces a beautiful parabola shape and emphasizes the intrinsic beauty of brass.

I did a pass all the way across to cut off the corners (which were a little banged up), and should have gone a little deeper since there were still a few blemishes.  I didn't notice them until I had already cut off the piece, so I couldn't put it back between centers, and I don't trust the 3-jaw chuck to hold it true, so I didn't have an easy way to clean up the corners later.

Here you can see the dimple I put in the very center of the head to make it easy to put whatever kind of hole my friend decides to use for attaching the handle.

I also rounded off the round edge of each face of the hammer so that it doesn't immediately mushroom when used on a flat surface.  But really, this hammer is more decorative than useful; it's several pounds, so it's not great for delicate work, and the whole point of a brass hammer is to get dinged up instead of the steel part you're trying to nudge.

NVidia Jetson TX1 raw bayer frames via v4l2 via /dev/video0

The NVidia Jetson TX1 dev kit comes with a 5MP camera and a bewildering array of different libraries for accessing it.  One of the routes is using v4l2 through the /dev/video0 device.  This route only offers raw bayer data, rather than the more usual YUV-style formats.  Also it only supports V4L2_MEMORY_MMAP, not V4L2_MEMORY_USERPTR or read()ing from /dev/video0.

If you 'sudo apt-get install v4l-utils' you can use this to capture a frame from the camera:

v4l2-ctl --stream-mmap --stream-to=foo.raw --stream-count=1

foo.raw is 10077696 bytes, 2 bytes for each of the 2592x1944 pixels.  If you want to write your own code to grab frames like this, this capture example gets you most of the way there, but you need to request the V4L2_PIX_FMT_SRGGB10 (raw bayer) format instead of the default.  So change init_device to be like this:

 static void init_device(void)  
 {  
  struct v4l2_format format = {0};  
  format.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;  
  format.fmt.pix.width = 2592;  
  format.fmt.pix.height = 1944;  
  format.fmt.pix.pixelformat = V4L2_PIX_FMT_SRGGB10;  
  format.fmt.pix.field = V4L2_FIELD_NONE;  
  int retval = xioctl(fd, VIDIOC_S_FMT, &format);  
  if (retval == -1) { perror("Setting format\n"); exit(3); }  
   
  if (io != IO_METHOD_MMAP) {  
   printf("Sorry, Jetson TX1 v4l2 only supports mmap\n");  
   exit(4);  
  }  
   
  init_mmap();  
 }  

Measuring spirit level accuracy

I have a cheap Stanley 24-inch level like this one:


The other day I noticed it didn't seem to be very accurate.  I checked by flipping it end for end on my workpiece, and sure enough the bubble settled in a different spot.

To measure how far off it is, I propped up the two ends with stacks of about 15 sheets of printer paper on my kitchen counter.  (It was important to support both ends because my counter isn't perfectly flat).  I added paper to one side until the bubble was dead center, then flipped the level end for end and had 9 sheets of paper (0.036") to one side before it was dead center again.

atan(0.036 / 24) = 0.086 degrees.  Since the vial is crooked and I'm flipping end for end, 0.086 degrees represents the angle between it being crooked to one side and being crooked to the other side, which is double the crookedness.  So the vial in my level is crooked by 0.043 degrees, +- 1/64" over 2 feet, or +-0.00075 inches per inch.

That doesn't sound like much, but it means that if I set two 8 foot beams indicated as "level", but flip the level around in between, they'll vary by 1/32 every 2 feet, for a total of 1/8" over the whole length.

Stanley doesn't make any accuracy claims for my level, but their fancier "professional I-beam level" claims accuracy of only 0.0015 inches per inch, twice as bad as mine!  But then their 24-inch aluminum box-beam level claims 0.0005 inches per inch, somewhat better than my 0.00075.

A fancier brand, Stabila, claims 1/32" over 72", which is also 0.0005 inches per inch.  The manual for their fancy digital level (which doesn't exactly inspire confidence with its poor formatting) claims 0.05 degrees within 0.1 degrees of level, and 0.2 degrees elsewhere.  So that's worse than my crappy level's 0.043 degrees even in the best case.  But then just below it they have a heading of "measuring accuracy of level" and claim 0.029 degrees, which is pretty confusing but just works out to the familiar 0.005 inches per inch.  Bottom line: the level could be off by 3x the allowed 0.0005 inches per inch, and the digital readout could still read it as dead level.

So the bottom line seems to be that for best results, I want a spirit level that'll allow me to adjust it, and even fancy digital levels aren't guaranteed to be any better than perhaps 3/16" over 8 feet.

(Just for my future reference, I also measured how much angle change there is between level and when the bubble just touches the first line.  That came out to 0.120" (about 1/8"), so a rise of about 1/16" per foot.)