"Bad Things Happen"
That was the brilliant, crystal clear thought that flashed in my mind. As in, a real, actual, obviously very bad thing was happening right there, literally in my hands.
A few moments before I was thinking the opposite: good things were happening. I had discovered that the layer of grease on my Revere Ware kettle turned to liquid when the water boiled. I grabbed a paper towel and started mopping the layer off the kettle, restoring it's beautiful mirror finish. Cleaning it was so much easier than trying to scrub the grease off with a sponge.
I was nearly finished when the paper towel, now coated with hot oil, touched the heating element and burst in to flames.
Oops.
Bad Things weren't quite happening yet (but would soon). I reflexively gave the flaming wad a little shake to put it out. It responded by doubling in size. Amused, I tried to blow it out. That totally didn't work and clearly pushed the fire deeper into the towel. A flame licked my finger and I dropped it on the stove top.
Things weren't going to plan, and thus Bad Things were happening. What to do?
Save the house and the stove top! Keep the fire alarm from going off! Don't make a mess of it!
I pinched the unburning edge of the flaming grease-sprite and dropped it in the sink, and turned on the water. (It wasn't greasy enough to flare...) Contained on 3 sides, with water to keep it from charing the sink pan, it looked contained. I poured two cups of tea while I waited for it to burn out.
A small reminder that disasters can strike when you least expect them... right before tea!
Mountains
Tuesday, February 12, 2013
Monday, February 4, 2013
New Life to Old Things
Rusted, then brushed, oiled, and ground back to usefulness.
Rusted, then bolted, oiled, and ground back to usefulness.
Rusted, then bolted, oiled, and ground back to usefulness.
Monday, January 28, 2013
Raspberry Pi Fiddling
Raspberry Pi
I'm sure you've heard of it.
700mhz ARM CPU, 512 megs of ram, OpenGL ES GPU, HDMI, 2 USB ports, I2C, SPI, UART, and GPIO pins. All in a single board computer that costs $35? Sounds like fun! So fun, I got one for christmas.
(that you santa)
It took some experimentation to get mine to boot. (That's mostly because I didn't read the manual. ) Unlike a traditional x86 PC, it doesn't have a complicated firmware that preconfigures hardware and allows boot device selection. It just recusively drills the SD card for a bootloader and runs from there. No card? No Bootloader? No magic. Just a bright red activity LED and a dimly glowing SD card read light.
It's also very picky about where the bootloader is. The first time I downloaded the raspian disk image, I ran (on my mac)
%dd if="~/Desktop/2012-12-16-wheezy-raspbian.img" of=/dev/disk3s1 bs=10k
That process took forever and didn't work. After checking the cables and reading the manual, I learned that I need to overwrite the whole disk, not just the first partition, and that BSD uses a different syntax in that scenario: disk3s1 becomes rdisk3.
%dd if="~/Desktop/2012-12-16-wheezy-raspbian.img" of=/dev/rdisk3 bs=1m
Took just a few moments (read up on tuning dd's bs=* in your spare time. It will, one day, spare you time) and, when I plugged in and powered up the rbpi, i was greated with a massive screen load of linux booting goodness...
... and ultimately a desktop!
I'm sure you've heard of it.
700mhz ARM CPU, 512 megs of ram, OpenGL ES GPU, HDMI, 2 USB ports, I2C, SPI, UART, and GPIO pins. All in a single board computer that costs $35? Sounds like fun! So fun, I got one for christmas.
(that you santa)
Getting the Rasperry Pi Working
I should note that it really takes some other investment to get rolling with a Raspberry pi. You're going to have to put out for an HDMI cable, a powersupply, an ethernet cable, and USB cable, and a decently sized SD card. Also, I discovered that hot plugging my one USB keyboard between several computers and the Pi to be pretty tedious. If you plan on adding a lot of USB stuff, a powered hub to supply 500mA is going to be needed (my keyboard fades every now and then). A protective case might also be worth considering. Plan and additional $30-$80 worth of investment if you don't have any of that equipment It took some experimentation to get mine to boot. (That's mostly because I didn't read the manual. ) Unlike a traditional x86 PC, it doesn't have a complicated firmware that preconfigures hardware and allows boot device selection. It just recusively drills the SD card for a bootloader and runs from there. No card? No Bootloader? No magic. Just a bright red activity LED and a dimly glowing SD card read light.
It's also very picky about where the bootloader is. The first time I downloaded the raspian disk image, I ran (on my mac)
%dd if="~/Desktop/2012-12-16-wheezy-raspbian.img" of=/dev/disk3s1 bs=10k
That process took forever and didn't work. After checking the cables and reading the manual, I learned that I need to overwrite the whole disk, not just the first partition, and that BSD uses a different syntax in that scenario: disk3s1 becomes rdisk3.
%dd if="~/Desktop/2012-12-16-wheezy-raspbian.img" of=/dev/rdisk3 bs=1m
Took just a few moments (read up on tuning dd's bs=* in your spare time. It will, one day, spare you time) and, when I plugged in and powered up the rbpi, i was greated with a massive screen load of linux booting goodness...
... and ultimately a desktop!
Raspberry Pi First Impressions
Fast computer, slow XWindows.
Watching the boot speed, I was genuinely impressed. For how small and cold (temperature wise, it only needs 700 mA to start), it can really move. It's an amazing demonstration of how much power has been packed into chip packages through miniaturization. My enthusiasm was damped once I started X. The pi does not yet (at the time of writing) have an accelerated XWindows driver, so the GUI feels very sluggish at times. With some tuning, the fbdev driver can be made to feel somewhat snappy (using lightweight window managers and turning every single graphical flourish off), but for users not familiar with X and *nix, that's not going to be an easy option. The LXDE distributed with the Pi is a pretty good balance of usability and speed, but is not outright snappy. I think that puts user focused nettop duty out of the picture until X acceleration arrives. After being spoiled by compositing window systems for 8 years, and accelerated graphics for nearly 20, it's a little hard to go back. For programming and fiddling, It's definitely usable.
The raspian distribution comes with a heavy lean on python development, though there is a smattering of other compilers/interpreters present (C(++), perl, lua, bash), and if you're that kind of person, you probably know how to get what you want running. I was able to use apt to get emacs. As far as going from just a cute board to a cute board that does stuff heavy computational stuff, the barriers are quite low.
Now to figure out what to do with it...
The raspian distribution comes with a heavy lean on python development, though there is a smattering of other compilers/interpreters present (C(++), perl, lua, bash), and if you're that kind of person, you probably know how to get what you want running. I was able to use apt to get emacs. As far as going from just a cute board to a cute board that does stuff heavy computational stuff, the barriers are quite low.
Now to figure out what to do with it...
Thursday, January 24, 2013
Programming Shoot and Ladders
In college and highschool, we (really, the ubiquitous We, since i'd have this conversation with anyone who cared), spent a lot of time discussing the merits of different programming languages, about which model worked best and which was fastest for a given application. I spent a lot of time at work and home tinkering with different languages. Fortran, C, shell script (tcsh & pdksh), javascript/html, VB, perl, Igor, and labview.
However, I'm a career chemist, not a computer scientist. My goals are very much focused on cranking publications and not fine tuning code. I've come to realize the best tool for a lot of problem is the one you have to effectively solve the problem. One example: at work, one of our visualization products is written in Delphi. I doubt that would be the tool of choice for many people, but the scientist who is the PI knew pascal really well (back in the 1980s!) and it has stuck over time.
Of course, the tool you have works great, until you reach its limits. I use Labview for instrument automation. It has a easy to use GUI toolkit, and knows a lot about hardware and signals, right out of the box. Yesterday, I found something it doesn't know much about: drawing arbitrary graphics on screen.
I'm building a control package for a vacuum manifold that preconcentrates gases before injecting them into a gas chromatograph. I thought it would be nice to give a visual representation of the flow paths that were open by drawing the manifold on screen. It turns out, labview doesn't give you many tools to do easily do that:
What this image is showing is that Labview's 2D drawing stack is entirely procedural, with no facilities for storing, moving, or transforming images after they've been created. Anytime your program wants to update an image screen, the code you write needs to explicitly redraw the entire image. It's not possible to algorithmically create a sprite library, then scoot the sprites around, or rotate or otherwise transform them. You have to build a bunch of routines that describe objects and then push those around.
Pain.
This means that it's going require writing quite a bit of code to make a panel that easily represent the open flowpaths to the user. Achieving that kind of functionality is not a high priority for the project, so for the time being, it will fall back on using more generic, less descriptive indicators.
If you're standing in front of the hardware, it's possible to guess what this means, but I think that's going to be beyond the grasp of inexperienced users, so I consider the solution to be suboptimal. Experience has shown that analytical error rates scale with the steps the analyst must complete and the clarity of state and hardware protection that software can provide. This panel doesn't clearly show linked flow paths, or if the instrument really knows if gases are moving or pressure tolerances are being exceeded.
Things could be a lot better.
However, I'm a career chemist, not a computer scientist. My goals are very much focused on cranking publications and not fine tuning code. I've come to realize the best tool for a lot of problem is the one you have to effectively solve the problem. One example: at work, one of our visualization products is written in Delphi. I doubt that would be the tool of choice for many people, but the scientist who is the PI knew pascal really well (back in the 1980s!) and it has stuck over time.
Of course, the tool you have works great, until you reach its limits. I use Labview for instrument automation. It has a easy to use GUI toolkit, and knows a lot about hardware and signals, right out of the box. Yesterday, I found something it doesn't know much about: drawing arbitrary graphics on screen.
I'm building a control package for a vacuum manifold that preconcentrates gases before injecting them into a gas chromatograph. I thought it would be nice to give a visual representation of the flow paths that were open by drawing the manifold on screen. It turns out, labview doesn't give you many tools to do easily do that:
What this image is showing is that Labview's 2D drawing stack is entirely procedural, with no facilities for storing, moving, or transforming images after they've been created. Anytime your program wants to update an image screen, the code you write needs to explicitly redraw the entire image. It's not possible to algorithmically create a sprite library, then scoot the sprites around, or rotate or otherwise transform them. You have to build a bunch of routines that describe objects and then push those around.
Pain.
This means that it's going require writing quite a bit of code to make a panel that easily represent the open flowpaths to the user. Achieving that kind of functionality is not a high priority for the project, so for the time being, it will fall back on using more generic, less descriptive indicators.
If you're standing in front of the hardware, it's possible to guess what this means, but I think that's going to be beyond the grasp of inexperienced users, so I consider the solution to be suboptimal. Experience has shown that analytical error rates scale with the steps the analyst must complete and the clarity of state and hardware protection that software can provide. This panel doesn't clearly show linked flow paths, or if the instrument really knows if gases are moving or pressure tolerances are being exceeded.
Things could be a lot better.
Monday, January 21, 2013
Obey Posted Speed Limits
We took the Pike Peak Cog Railway to the top of Pikes Peak on Christmas Eve.
I think this is the first time in 10 years I've seen the trains up close (actually, it might be more, I don't remember if I drove up last time or took the Cog). This time I paid a lot more attention to the details of the engines.
The biggest gauge was the speedometer. It was about 8 inches in diameter and ranged from 0 to 15 mph. While slow compared to most commuter trains, I would note that most people can't climb the mountain that fast, and it can keep a decent speed up a grade at high altitude. My ponderings of higher velocities were curtailed when I looked out the window and saw this:
The rails are so warped that it would seem to be a mistake to attempt high speed travel. Besides, your sinuses might explode from the pressure change.
I think this is the first time in 10 years I've seen the trains up close (actually, it might be more, I don't remember if I drove up last time or took the Cog). This time I paid a lot more attention to the details of the engines.
The biggest gauge was the speedometer. It was about 8 inches in diameter and ranged from 0 to 15 mph. While slow compared to most commuter trains, I would note that most people can't climb the mountain that fast, and it can keep a decent speed up a grade at high altitude. My ponderings of higher velocities were curtailed when I looked out the window and saw this:
The rails are so warped that it would seem to be a mistake to attempt high speed travel. Besides, your sinuses might explode from the pressure change.
BlikenLichten
We bought timers for our Christmas lights this year. It let us have them on while we were away, and probably saved some money since we didn't forget and leave them on all night.
The timers we got are digital (I wanted grounded outlets, and digital was the only way we could find a time with grounded outlets.
Of course, we got it home and I had to take it apart; I had to know how it worked.
Do you recognize anything thing? Here, I'll give you a hint:
DC From AC Without a Transformer
The timer is made up of two boards, a power/switch board (left) and a clock board (right). The timer is powered by the rectifier/capacitor circuit in the lower left through the Yellow-Red wires, running to the clock. The clock has a battery (green, upper right), a photo sensor (middle far right, "dusk") and a quartz crystal (middle right). The clock signals a relay (black box, middle left) through a trigger circuit to turn the outlets on and off. I'm not precisely sure how that circuit works (didn't try to lift out that board). Plausibly, the clock opens the transistor (middle left, beside the relay), which applies partial rectified power using the diode and capacitor to the relay's coil. (The relay doesn't work when the timer is unplugged).
I'm surprised at how much of this timer is air and hand assembled discrete components.
The timers we got are digital (I wanted grounded outlets, and digital was the only way we could find a time with grounded outlets.
Of course, we got it home and I had to take it apart; I had to know how it worked.
Do you recognize anything thing? Here, I'll give you a hint:
DC From AC Without a Transformer
The timer is made up of two boards, a power/switch board (left) and a clock board (right). The timer is powered by the rectifier/capacitor circuit in the lower left through the Yellow-Red wires, running to the clock. The clock has a battery (green, upper right), a photo sensor (middle far right, "dusk") and a quartz crystal (middle right). The clock signals a relay (black box, middle left) through a trigger circuit to turn the outlets on and off. I'm not precisely sure how that circuit works (didn't try to lift out that board). Plausibly, the clock opens the transistor (middle left, beside the relay), which applies partial rectified power using the diode and capacitor to the relay's coil. (The relay doesn't work when the timer is unplugged).
I'm surprised at how much of this timer is air and hand assembled discrete components.
Film Developing
Subscribe to:
Posts (Atom)
