Scale results, round 2

I made a second run on my scale tester.  This time I used a 10KOhm thermistor as my temperature sensor.  This gave me around 0.15 degrees (F) of resolution, compared with the 1 degree resolution of the previous temperature sensor I used for the last test run.

Figure 1: Weight and Temperature vs. Time

The first graph this time is the usual weight and temperature over time.  You can see that the weight and temperature appear to be highly correlated just like the first test run. The other thing is that the temperature appears much less noisy then in the previous run.

Figure 2: Nominal weight minus weight vs. Average temperature

In Figure 2, I graphed the delta in weight vs nominal against a moving average of temperature.  I also threw down a best-fit linear trend line.  I can immediately see that the point cloud is much tighter than in the previous test run, which seems good.

Figure 3: Adjusted weight

The last graph is a plot of the weight reading adjusted by the trend line equation from Figure 2.  The ideal line is a straight line at 55 lb. Clearly the line is not straight but it certainly improves the data.  The weight reading varies by +/- 0.2 lb instead of +/- 0.75 lb for the unadjusted weight readings.

Conclusions

The adjusted weight did not seem much different from the previous test run, but it still seems useful.  I think I can now go on to implement the data logger for this project which will convert weight and temperature sensor readings to specific gravity.

There are still some unknowns here.  One is that the test runs have only been run on a constant 55 lb test weight.  It's certainly possible that the numbers will change if a different weight is used.  It might be worth re-testing with weights of 45, 65, and 75 lb weights.

Additionally, there seems to sometimes be a lag between temperature changes and weight changes.  This could be attributable to the temperature sensor and scale having different thermal mass, which is almost certainly true.  I could account for this by attaching the temperature sensor to the scale with thermal paste to ensure that they are at relatively the same temperature.

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.

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.

I did some more work on pressure sensor testing, this time with a MP3V5004 sensor which has higher accuracy than the MPX5010. This sensor definitely did work better than the MPX5010, but it still was not accurate enough for my purposes. I also leanred that my test rig was very sensitive to two things: 1) The position of the tubes (even if one of them moved 1/64th of an inch it would affect the readings significantly), and 2) if there was liquid already in the tube from a previous reading. To correct this I secured the rig's test tubes so they couldn't move at all and I made sure to clear any liquid out of the tubes between readings. With these changes I got much higher accuracy, but the sensors I tested were still not accurate enough.

I found another pressure sensor made by Honeywell (HSCSAAN001PDAA5) that has significantly higher accuracy, but it is also MUCH more expensive ($40-50 per sensor). So I'm going to try some other specific gravity measurement ideas before I invest money in the pricey new pressure sensor.

Lately I've been experimenting with counting CO2 bubbles produced by a fermentation as an indirect way of measuring specific gravity. Currently I'm using a method which shines an infrared beam through an air lock. When a certain amount of CO2 has been produced in the reaction chamber a CO2 bubble goes through the liquid contained in the air lock (which really just acts as a one-way valve). When this bubble escapes it breaks the infrared beam momentarily which I can then detect electronically.

So far I've proven that I can detect bubbles with this apparatus; now I need to make sure that I can detect close to 100% of the escaping bubbles. Here are some pictures of my current test setup:

I was able to find some sufficiently small hose clamps that fixed my air leakage problems, but now I'm having trouble with the accuracy of the pressure sensor. Here is some of the data I got during my last test session:

SG test solution -> ADC counts (0-1023)
1.000 -> 220
1.100 -> 240
1.062 -> 237
1.028 -> 233
1.000 -> 227
1.100 -> 244
1.062 -> 237
1.100 -> 242
1.000 -> 223
1.000 -> 226

So as you can see the trend is generally correct but there is too much hysteresis in the values. After perusing the datasheet for the sensor it seems that the overall accuracy is +/- 5% worst-case, so the sensor is performing much better than its spec. But it's still not very useful for my purposes.

I've been working with the pressure sensor again. I finally got a very ugly prototype of a hand-held meter built. The basic idea is that I have the pressure sensor wired to one of the analog inputs of an arduino, and then the arduino sends sample data out via serial to my PC.

I got some pretty good readings that look like I'll have a resolution of around 0.005 SG (which is usable, I think). The only major problem I ran into was that air was slowly leaking out the tubes that were in the water, which means the seal I have between the tubes and the pressure sensor ports isn't good enough. So the next thing on my list is to come up with a way to seal the tubes better.

Here are some pictures of the prototype:

I've been continuing to experiment with the pressure sensor from the previous post. I had a problem for a while where the pressure sensor results were varying by +/- 50mV which basically made the pressure sensor unusable for my purposes as I was looking for better than 5mV accuracy. I did some more troubleshooting and discovered that my power supply was causing the variance. I put an additional voltage regulator before the circuit and that brought the accuracy down to 1-2mV, which is much more usable.

I've also found another Freescale pressure sensor (MP3V5004G) that has about double the accuracy of the sensor I'm currently using (MPX5010). I'm going to try out that sensor in the near future to see if it improves my results.

Now that I'm getting decent results I'm going to build a prototype meter using an arduino and start experimenting with a bit of software filtering and averaging to see if I can get a more accurate result. Eventually I'll also attach an LCD display to the arduino and make a hand-held meter for measuring specific gravity.

Here are some of my latest experimental results with the MPX5010 and solutions of varying density:

hydrometer reading of solution -> sensor reading
(with h = 6 inches)
1.000 -> 882mV
1.028 -> 896 mV
1.062 -> 933mV
1.100 -> 961 mV

(with h = 8 inches)
1.000 -> 1.105V
1.028 -> 1.130V
1.062 -> 1.148V
1.100 -> 1.177V

I had a little time to experiment with a new project. I'm working on using a Freescale pressure sensor to measure the specific gravity of a liquid. This is a piece of a larger project that I'm working on, but I need to research this before I work on the rest of it. More on that later.

Pressure in a liquid follows this formula:
p = ghd
where p = pressure, h = height of liquid above sensor, g = acceleration of gravity, d = density of liquid

So using a differential pressure sensor (MPVX5010DP) from Freescale, I can get all of the values in the formula and solve for d. The physical test setup is show in the picture below. Basically I have lengths of plastic tubing of two different lengths attached to the sensor's pressure ports (make sure to get the right tube to the right pressure port; pressure port 1 always have to have a higher pressure on it than pressure port 2; check the datasheet). The tubes are then tied to a steel ruler with the tube ends a fixed distance apart (in this case 4" apart).

It seems like the pressure reading does indeed change with the density of the liquid the probe is placed in. However the difference in the readings is fairly small. This tells me a couple of things:
1) I should increase the distance between the end of the tubes (essentially increasing "h" from the formula before). This should increase the magnitude of the voltage read from the sensor, thereby amplifying the sensor voltage. Eight inches between the tube ends should be good. 2) Since I'm eventually going to be reading the sensor voltage using a microprocessor's ADC, I can decrease the voltage range of the ADC to increase the resolution of the ADC readings. Based on my final application, I'm going to set the voltage range to 0-1.1 V.

Here is then data I got with several different sugar solutions:

Hydrometer Reading -> Sensor Reading
1.000 -> 707mV
1.036 -> 723mV
1.068 -> 734mV