First scale test results

I took some time to analyze the results from my scale test.  If you like graphs, then keep reading.  If you don't like graphs then skip to my conclusion at the bottom.  I happen to like graphs...

To summarize the previous post, I wanted to see if there were two effects happening to my fancy new RS232 scale: 1) temperature and 2) sensor drift (or creep).  The easiest way to track this was to measure the weight of an object with a constant mass over time, while also measuring temperature over the same time span.  I did that and now have a week's worth of measurement data to sift through.

Figure 1: Temperature and Weight vs. Time

First I graphed weight and temperature each versus time.  Figure 1 shows this graph.  You can immediately see that the measured weight correlates closely with the temperature, so clearly I was right that there is a temperature effect.  The second thing to note is that the weight line shows clear quantization, but this is to be expected as the scale only specifies to have a 0.1 lb resolution (but it's still nice to see it clearly in the graph).  Another thing to note is that the temperature is pretty noisy.

Figure 2: Average Temperature and Weight vs. Time

Figure 2 is the same graph but with a moving averaged temperature.  Perhaps a "moving average" is not the correct term for this; I never did much with formal statistics.  I basically just calculated each reading by taking the mean of the previous 6 readings.  You can see the temperature line looks much less noisy now and the correlation between temperature and weight still remains.

Figure 3

My next task was to try and figure out the mathematical relationship between weight and temperature, so that I can then (hopefully) correct for temperature and get a more accurate weight reading.  The graph for weight versus temperature is shown in Figure 3.  There are several interesting things here.  The first is that you can see that both the weight and the temperature are quantized since all the blue points in the graph come out on grid lines.  The next thing to note is that the point cloud is pretty widely distributed (which isn't good).  I had Excel generate a best fit linear trend line.

Figure 4

Next up I repeated that graph (Figure 4) but with the the averaged temperature data from Figure 2.  Now you can see that the quantization in the temperature data has disappeared but remains for the weight, which is what we'd expect.  The trend line has changed a little based on this adjustment.  I also threw a 6th order polynomial fit trend line on the data to see if that would fit the data better, but as you can see that is nearly a straight line, so we'll stick with the linear fit line for future calculations since it seems to be a pretty good approximation (at least compared with a polynomial fit).

Figure 5

Now from this we can use the calculated trend line to create a mathematical attempt at canceling out the temperature effect of the scale readings.  Figure 5 is a graph of the temperature-adjusted weight plotted over time.  The ideal line would be a line that is constant at 55 lb.  The adjusted weight line is clearly not a straight line but if you compare it to Figure 2 we have certainly made an improvement over the raw weight readings.

As it stands this temperature correction is probably useful enough that I could start using the scale for continuous weight measurements, however I'd like to make it better if I can.  I think one improvement I can make (which I mentioned in my previous post) was that my temperature sensor has pretty low resolution (about 1 degree Fahrenheit). I suspect that having a sensor with 0.1 degree resolution would help, and might bring the point cloud in Figure 3 into a tighter cloud which would make the generated trend line more accurate.  So now I'm going to start looking around for a more suitable temperature sensor (I might already have one on hand in my parts library) and re-run the test to gather fresh data.

Zeo sleep monitor

My wife got me a new toy for Christmas this year, a Zeo Sleep Monitor. It's a device that fits on your forehead while you sleep and measures your brain waves while you sleep. Based on your brain waves it logs what phase of sleep you're in (light, REM, deep, or awake). I got some time to try it out a few nights ago and I was pretty impressed!

Above, you can see a screenshot from the app on my phone. You can see for yourself what each of the colors means on the graph above.  The fun thing to note for me is that it lines up perfectly with what happened that night.  At around 1AM (the second set of red lines) my dog woke me up to be let outside.  Then around 2AM my wife woke up which woke me up for a little while.  Then at around 6:30AM my wife woke up to get ready for work which again woke me up.  So that correlates the data with reality nicely.

The interesting things in the graph are what I wouldn't ordinarily be able to determine for myself, namely differentiating between light sleep, deep sleep, and REM sleep.  I find this pretty fascinating.  I think this also means that I don't have sleep apnea (or at least not this night), since I would assume there would be many more red lines throughout the night.

I'm going to keep using this as much as possible for the next few weeks to get an idea of what my sleep habits look like over time.  The Zeo Android app also has another feature whereby you can set an alarm and the app will try to wake you when you're in an optimal sleep state.  This works on the theory that you feel better and more alert if you're awakened when you're in a light sleep state.  I haven't tried that feature yet, but I will soon.

When I find some time I'd like to find a way to use the Zeo sensor to monitor my sleep cycles and when I'm in a REM sleep cycle trigger subtle lights or sounds that might allow me to experience lucid dreaming.  I found this Android API which may aid me in doing that.

Update: I tried the alarm feature last night and it is amazing!  It delayed my wakeup time by about 15 minutes to wait for the REM cycle I was in to end.  I woke up feeling fantastic!  I may have to start using it every night.

Testing an RS232 scale

To further the experiments I've been doing with measuring specific gravity, I needed to take long-term continuous weight measurements (5-10 days total). I started searching for a scale or load cell that would be appropriate.

My specific use case involves monitoring the weight of an object in the range of 50-70 lbs for 2 weeks.  Since we have a heavy weight on the scale for a long time a problem that could come up is sensor drift (also sometimes called creep).  This effect is similar to what happens if you hang an object from a suspended spring.  Over time the spring will slowly deform.  The rate of the deformation depends on many factors like the weight of the object and the physical properties of the spring.  The same thing happens with a scale.  Although mechanically different from a suspended spring, in many other ways it's very much like a spring.

Another factor that can throw off the readings from a scale is temperature.  As the temperature changes the properties of the components in the scale also change.  If these changes aren't compensated for in some fashion then they will affect the scale's readings.

I initially tried to measure a 55 lb test weight using a 75 lb maximum capacity digital scale.  Within minutes the scale's readings started drifting.  I assumed that this was probably due to creep and was probably so prominent because I was weighing something close to the rated capacity of the scale.  This scale also had the additional failing that it did not have a way to communicate externally (which as you'll see soon was an important requirement) so I decided to look for a different scale.

I reasoned that if I found a scale that had a maximum capacity that was significantly larger than object I was weighing, then it might not display significant effect from creep (or at least for the 2 week period that I needed continuous readings).

Luckily I found a 300 lb capacity shipping scale (MyWeigh HD-300), and a well-written tutorial from Adafruit.  This scale was a little more expensive than what I had in mind, but it's worth the price considering all of its features:

• 300 lb capacity
• RS232 communication
• ability to disable auto-off (most scales turn off automatically which sucks for continuous measurements)

I quickly started an "eyeball" test by again placing my 55 lb weight on the new scale.  I kept a log book near the scale and roughly every 60 minutes I would write down the time and the displayed weight.  I left this experiment running for about 4 days.  I should note that I didn't stick to the 60 minute test interval that closely.  Sometimes I would leave several hours between readings, sometimes it was more like 30 minutes, and I didn't wake up to take readings in the middle of the night; I like science but I like sleep more.

The results of this test told me that something was causing the displayed weight to vary by about 1 lb over the course of 4 days.  I had a suspicion that temperature was causing much of the variation (the weight would be lower when it was cooler in my house and higher when the temperature was higher).  I couldn't really tell if there was any effect from sensor creep.

Next I decided to repeat the above experiment but make it a little more scientific.  For this run I wanted to run for at least 10 days and gather temperature and weight readings every 10 minutes.  Of course, this is exactly what computers are made for.

The test set up consists of a python script running on an old laptop.  The script communicates with the scale via its RS232 interface to gather weight readings.  To get the temperature I decided to use an Analog Devices TMP36 sensor that I already had on hand.  Coincidentally, Adafruit had another tutorial on using this sensor with an Arduino.  I used some of the ideas from the tutorial but wrote my own Arduino firmware to make it act as a serial thermometer.

The test script on the laptop was modified to also query the Arduino for the temperature and log the returned value along with the measured weight value to a file every ten minutes.  

The test setup from left to right: laptop power supply, USB wifi dongle, scale control box, laptop, plywood to act as stable platform for scale, Arduino with TMP36 sensor, MyWeigh HD-300 scale with 55 lb test weights

I put the source code for the python test script and the Arduino firmware on github.  Keep in mind that the script was written to run on Windows and would need to be ported to run on another operating system.  Also, since I implemented the script very quickly I didn't spend much time or effort on error checking so it's not very robust in that respect.  You have been warned.

At this point you may be wondering why I didn't just use the Arduino by itself to do the data logging.  I have a few reason for that:

• I needed a circuit to convert the RS232 voltage levels of the scale to TTL voltages that the Arduino can understand.  I already had the hardware to do that but I didn't want to waste time assembling it when I had a laptop with a perfectly good RS232 port available.
• I didn't have an Real-Time clock to keep track of time or anything to use for large data storage (SD card socket).  The Adafruit data logging shield would have been ideal for this but I didn't want to wait to run the test.

After I was half way through implementing the test I realized that the TMP36 sensor used in combination with the Arduino's 10-bit resolution ADC only gives a resolution of about 1 degree Fahrenheit.  I would have preferred to have 0.1 degree of resolution but decided to run the experiment anyway and see how the numbers looked.

I'll create an additional post with the results from the first test run.

Improved Security Node

I've spent some time recently polishing the Security Node demo I made a while back to the point where it is no longer a demo.  It's now installed and functioning in my house.

Here are some of the changes:

• Integrated catisith2's keypad interface code
• Added logic so alarm system is run completely by the JeeNode
• Replicated original functionality of the DSC alarm control board
• Added circuit to control the (very loud) siren
• Send radio packets when events occur (alarm, arm, disarm, doors open/close)
• Handle remote commands via radio (mainly arm/disarm commands)
• Made a small "cheatsheet" with all the commands to attach inside the keypad panel

I've update the source code in my github repo.

I'm pretty satisfied with how the Security Node turned out but I have some things I'd like to change:

1. The alarm system runs fine locally but my ultimate goal is to have an external interface so I can receive texts when events occur and remotely arm/disarm the system.  I'm still trying to figure out how I want to do that.  JC Wippler is doing some interesting research along these lines.
2. There isn't much security with the arm/disarm radio messages, though I could encrypt the radio traffic pretty easily.
3. The final board works well but it looks ugly.  I'd like to redraw everything in EagleCAD and have a proper PCB made.
4. Adding a battery backup so the alarm will still work when there is a power outage.

Here are some pictures:

Security Node without JeeNode installed

Security Node installed

Keypad communicating with JeeNode

Beer Crate

Over the holidays, I set out to build some more permanent storage cases for my homebrew beer.  I had just been using whatever cardboard beer boxes I could get my hands on.  Now that I'm getting more into homebrewing I thought it would be nice to put my woodworking skills to good use.

The finished beer crate

Design
Design decisions:

• Be easily stackable (up to 3 or 4 high)
• Some sort of locking/registration mechanism so when they're stacked they stay stacked
• Separators between bottles so the bottles don't knock together when moved
• Sturdy!
• Some method of identifying what beer is in a given case
• Hold at least 12 bottles (24 seems like too much)
• Tall enough to hold any normal 12 ounce beer bottle
• Handles for ease of carrying

I started by measuring a cardboard beer box to get some general size guidelines.  I also measured the tallest 12 ounce beer bottle I could find to see what the height needed to be.

Based on the measurements I designed the beer crate in Sketchup (as usual).  I decided to use 3/4 inch pine boards for the sides and end pieces and 1/8 inch hardboard for the bottom and the separator pieces.  There are two interesting features: The first is that I plan on applying chalkboard paint to the sides of the crate so I can write info on the batch in chalk.  The second interesting feature is a trick I learned from woodgears.ca.  The idea is to use marbles to "lock two flat surfaces together in a removable fashion.  The idea is to drill two hols on the two surfaces just wide enough and deep enough to fit a marble.  The marble then sits above the surface of the top edge end piece and fits into a matching hole on the bottom of the end piece.  In this way the crates can be stacked without worrying about them slipping.  Since the marble is spherical it's easier to line up than a cylindrical peg.

The beer crate design in Sketchup

Construction

The construction details are not that interesting since they are just standard woodworking techniques.  The sides, ends, bottom, and separator pieces were cut to size from pine boards and hardboard sheets.  A slot was cut into the sides and end pieces to fit the bottom piece similar to the way drawer bottoms are traditionally made.  

The hand holds were cut in the end pieces with a forstner bit and a jigsaw, and sanded smooth using an oscillating spindle sander.  The recesses for the marbles were drilled using a drill press and a template I made  to make sure the holes line up properly.

Slots were cut halfway through the separator pieces so that they would fit together.  To make these cuts I used my table saw and just stacked up several separators at a time and pushed them into the saw blade until the blade hit a pencil mark half way through the separator.  There are cleaner ways to make this cut but since the cut is not visible after the seperators are assembled, I wasn't too concerned with cosmetics.  If you'd like to see how these separators work just take a look at a carboard 12 pack box and they go together the same way; they're just made of hardboard instead of cardboard.

I just used a butt joint to connect the side and end pieces.  I put 1.25" wood screws into countersunk pilot holes to hold it.

Finish

I first sanded all the pine pieces mainly to get rid of machine marks.

I used two coats of clear gloss wipe-on polyurethane to seal the side and end pieces.  I didn't put any stain on the wood because I like the look of unstained pine.  I left the outside face of the side pieces unsealed since I wanted to apply the chalkboard paint there.

For the chalkboard surfaces, I first primed with some white latex paint that I had lying around.  After that had dried I sanded lightly and applied one thick coat of black Rustoleum chalkboard paint using a foam brush.  After it had dried it didn't seem to need a second coat so I left it at that.

Future Improvements
This was the first project that didn't require me to make some adjustments to the design during construction.  I credit using Sketchup and doing careful measurements before I started.

Now that I've finished the prototype I need to make 8 or 9 more to hold all of my homebrew beer.  I'm really looking forward to doing some "assembly line" style woodworking.  It seems like 90% of the time in woodworking is spent setting up for each cut, so making 10 of something doesn't take 10x more time than making 1.  I usually only make 1 of a project so it will be fun to make many more.

Even though this project went well I have some concerns and improvements for the future:

1. I might want to use some nicer wood like oak in the future.  Then again the pine looks pretty good and has the additional advantage of being cheap.
2. The butt joint isn't that pretty; using dovetails or finger joints would look better.
3. I'm a little worried that the placement of the marbles may be a little too precise and I might have trouble getting things to line up when I have multiple beer crates.  I can probably get around this by only using two marbles placed above each handle instead of the current 4 marble design.  Also I could make a jig to align the pieces when I drill the pilot holes for the screws.  The jig would ensure that I get the distance between the end pieces exactly the same every time.