Sustainable Design: Smart Water Bottle

Part II: Sensor Choice

Because I’m the solo designer, engineer, builder, sourcerer, yada yada, I need to begin defining my design parameters. So we’re going to start with a super simple block diagram (NTS!!!!)

Enlarge

waterbottle-bd-1
Crude Block Diagram of Smart Water Bottle

You can see in this very simple block diagram that green stands for the mechanical components, the blue is the electrical/software components and the pink are the attachments/add-ons that may or may not happen–we’ll revisit the customer requirements if necessary. Another thing to note is that there are two water level indicators, the blue being the LED which flashes a reminder to the user to drink water and the green being the recommended time the user should drink certain quantities of water as depicted in Siera’s customer requirements drawing.  It’s pretty evident from this block diagram that we’ll be incorporating the sensor and indicator circuit within the cap and I’ll go into why I assumed this later. This will limit the dishwasher friendliness of the bottle, in fact it may need to be a hand-washed item. Furthermore I have not specified my interfaces between the water bottle components, this will occur during the conceptual design stage. From here on out it may become a bit disorganized because throughout the project I will move between the different divisions of the design process.

Trade Off Study I: Sensor Choice

Warning, I am nowhere near being a professional electrical engineer/electrical designer so this is designed to be a learning process. Take everything I say and do with a grain of salt! Also fact check me please and let me know nicely. 🙂

I agreed to do this challenge because I lack proper sensor and circuitry design. This project gives me the ability to source, test, calibrate, integrate and assemble the electronics in a system. This means I get to move beyond arduinos and enter the world of designing and making my own PCBs! It should be fun and frustrating. But before I even enter the PCB design world, I need to settle on a sensor to measure water in the container. The original sensors I had in mind were a load cell, an IR distance sensor and an ultrasound sensor. Here is my unweighted pugh chart:

Enlarge

1
Unweighted Pugh Chart

A pugh chart can be pretty subjective, especially when you add weights to it, but it can help in eliminating certain choices thereby making the design decision easier. For instance, the load cell was eliminated. Now practically speaking if we used the load cell, the circuitry would have to move from the cap to the bottom of the bottle. This means more custom parts and potential modifications to the bottle for means of attachment. But having the circuit at the bottom isn’t that bad, this means we have a clear barrier between our electronics and water container and that we have a bit of weight at the bottom of the bottle to give it stability from tipping over (that’s a stretch). Interesting….but alas no, the main reason it was booted was attributed to our customer requirements, there will be moments where we have ice/fruit in the bottle. This is not only adding extra mass, but now we have different densities in the same container meaning that a load cell will prove unreliable and inaccurate because it will not be able to distinguish between different mediums in the container thus providing inconsistent water level readings.

So this brings me to the IR distance sensor and ultrasound sensor. Here are a few of the specs on the sensors I had on hand. Essentially I would like to do a very easy and simple test to see how well these sensors can sense the water level in a 1 ft., clear, hollow cylinder that can potentially hold around 72 oz of water. I don’t plan on using these exact sensors in the final build, but this gives me the opportunity to see how well they can sense the liquid’s height in the bottle as well as how much data processing/circuitry refinement is needed. Here are each questions I would like to answer from these tests:

  1. Are my sensors able to pick up a water level height between 0-10 inches?
  2. Could I easily interface my sensors with my cap?
  3. Are each of my sensors able to pick up the clear liquid?
  4. What is my water bottle’s water level resolution (hourly increment of water intake)? Or better yet, my resolution for my intended operating scenario…if that makes sense.

Hopefully we can answer each of these or figure out the next steps to answering these questions. Here are my current sensors’ stats:

IR distance sensor: GP2Y0A41SK0F

Enlarge

2-2
IR Sensor
  1. https://www.sparkfun.com/products/12728
  2. Range: 1.57 in – 11.81 in
  3. Sample rate: N/A
  4. Accuracy: N/A
  5. Operating voltage: 4.5-5.5 VDC
  6. Analog Output Voltage: 3.1 V @ 1.57 in to 0.3V at 11.81 in
  7. Operating current: 5 mA
  8. Dimensions: 0.78 in x 2 in x 0.4 in
  9. Price: $13.95
  10. Data sheet: http://www.sharp-world.com/products/device/lineup/data/pdf/datasheet/gp2y0a41sk_e.pdf

Ultrasound sensor: HC-SR04

Enlarge

3
Ultrasound Sensor
  1. https://www.sparkfun.com/products/15569
  2. Range: 0.78 in-157 in
  3. Accuracy: up to 3 mm
  4. Operating voltage: 5V DC
  5. Operating current: 15 mA
  6. Dimensions: 1.75 in x 0.80 in x 0.60 in
  7. Price: $3.95
  8. Data sheet: https://cdn.sparkfun.com/datasheets/Sensors/Proximity/HCSR04.pdf

I began my sensor test by marking out the length of the water bottle in ratio increments. Afterwards I built a very simple circuit using the ultrasound sensor first. The mount was made from cardboard (unfortunately no pictures). I would then remove the sensor whenever I needed to fill up or pour out the water from the container. This was all controlled with an arduino uno.

Enlarge

Ultrasonic-Sensor-Cirucit-Schematics-04
Ultrasonic Sensor Diagram from Tutorial

How to Mechatronics

There wasn’t much to the circuit, it was simply connecting the ultrasound’s VCC and the GND into the 5V and GND pins of the arduino as well as the ultrasound’s Trig and Echo pins into arduino’s Digital I/O pins. Essentially what is going to happen is that sensor will transmit a frequency of 40,000 Hz (which can be detected by dogs, cats and bats), once it hits an obstacle in its path, the sound wave will bounce back to receiver and then we can calculate the object’s distance using the travel time of the wave (divided by 2) and the speed of sound. HowtoMechatronics has an extremely good tutorial that explains how to generate the ultrasound and calculate the distance traveled by the wave from transmission to received.  Ultimately the script of the arduino sets into motion a loop where the Trig pin turns on (high state), emits the frequency for a period of time defined by the arduino’s time delay function (on the order of microseconds), then the Trig pin turns off (low state), the travel time is then read from the Echo pin, the distance calculation is done using Distance = Input Time * (Velocity of Sound/2), then the Trig pin is turned off again for a period of time as a check and the cycle repeats. Fairly simple, not much to it, everything is read from the Serial Monitor.

During the tests I collected about 100 samples in 1 second increments from the serial monitor after I poured in/poured out more water. I did this a few times and then averaged my sensor’s distance outputs and plotted accordingly. Below are the results of measuring water during the pouring out stage:

Enlarge

ultrasound-vs-actual
Ultrasound vs Actual Measurements of water

It’s important to note that the water level shown in this plot is based on the distance the water level is from the sensor, so our sensor is essentially the origin of the height axis. Because the ultrasound sensor outputted distance in inches, I compared this estimated water level with the bottle’s height distribution. If the sensor were perfect, the results would be completely linear as demonstrated by the actual height data in the plot.

Now while the ultrasound sensor seemed to be pretty good in estimating the water level between 6-12 inches, it was not that great when it came to estimating the water level at 6 inches and under. The trend began to curve and looked like it was bottoming out. Some calibration and curve fitting may need to be done and our water bottle’s water level resolution isn’t defined yet, so essentially this sensor could still be used in the final product. Now I did have problems with hysteresis when I would fill the bottle to known heights and then empty it to known heights. (not shown in plot). Granted my setup could largely affect the accuracy of my sensor and thus this could be attributed mainly to human error.

So besides this test, it’s important to note that ultrasound sensors are affected by temperature? By how much? Well, we’ll need to check the data sheet. On the plus side, ultrasound sensors are relatively cheap (at least the ones that I’m looking at) and I am trying to be cost-effective in this design process. But before I really refined anything I decided to test the IR distance sensor because why not?

The tests repeated for the analog IR distance sensor. I threw in a capacitor to do some power conditioning and there really wasn’t much to the arduino script, in fact the datasheet already provides a nice chart where they tested white and gray paper in varying distances from the sensor. Cool, so this is what my data should maybe look like? But my medium is clear…how will this affect my readings?

Enlarge

laser
Example of output distance characteristics using white and gray paper.

Sharp

This is the electrical schematic I used to set up the circuit for the IR Sensor:

Enlarge

SHARP-GP2Y0A21YK0F_bb
IR electrical schematic

https://www.makerguides.com/sharp-gp2y0a21yk0f-ir-distance-sensor-arduino-tutorial/

Below you can find the pictures of my Frankenstein-esque setup.

Enlarge

73011843_511333666113417_1618072054811066368_n
IR sensor set up

Again, I’m not a professional electrical engineer, this is just some quick prototyping I’d figure I do. Here’s a close up of the sensor that will make you wonder if I’m actually a mechanical engineer.

Enlarge

72368689_1224050207796303_2902197762269380608_n
Close up of IR sensor mounting

The IR sensor outputs voltage as determined by the datasheet. I will be comparing the voltage against the estimated water level of my container, which I converted to cm. I just want to see if the sensor’s data sheet will match the curve displayed by the IR sensor. This is what I got:

Enlarge

irsensorgraph-1
IR sensor Plot Results

Now this plot wasn’t exactly beautiful either, but it did have relatively the same curvature as the data sheet’s curve. My data seems like its been shifted along the vertical axis by almost a volt, but this could be attributed to sensing a clear fluid. This means that I can’t really compare my data to the data sheet because I’m using a clear medium and not an opaque material, but at least I can compare the general trend. Overall, I did get different voltages (evident in the hundredths place) as I moved my water level up and down. Again there needs to be more refinement and calibration done, but the sensor seemed to work with a clear medium and that was positive news. Now I just need to convert my analog voltage outputs to a water level height, which shouldn’t be too difficult as long as I set up my curve equation correctly after a few more tests and a bit more data analysis.

Now I am biased towards the laser sensor. It’s not going to have a problem if I have fruit/ice in the container–in fact that might make the measurements readings more reliable because now I have a solid object floating in the clear water. My major problem is that external light sources might throw the measurements off, not to mention IR distance sensors are more expensive than ultrasound sensors.

A friend of mine recommended that I use a flow meter as my sensor. The idea is that every time the user drinks the water, the water would run through a tube (like a thick straw or spout) and the sensor would measure the amount of water that flowed out. This was an interesting concept. Flow meters aren’t as accurate as a laser sensor, but it would be interesting to experiment with this concept. Because of my application I may need to make a custom flow meter (probably one with a Hall sensor) that could be integrated into my cap. This may be a bit problematic in terms of washing the cap and the drinking tube, but now I won’t need to worry about blocking the IR or ultrasound sensor if I am using a filter/fruit diffuser. Interesting, more pondering to do and maybe another pugh chart.

Enlarge

72947971_415786365796716_1345804074938793984_n
STM32 Nucleo board

I’ve also gotten my hands on a STM32 nucleo prototyping board and can begin programming my actual microcontroller and interfacing my sensors so I can run another batch of testing (this time with better mounts). This will bring me closer to designing the pcb I’ll need for the smart water bottle. So you may be wondering, “Is that it? Other than eliminating the load cell you didn’t really make concrete decisions.” And to that you’re absolutely right, but now I can answer my previous questions:

1. Are my sensors able to pick up a water level height between 0-10 inches?

Each of my sensors I tested were able to pick up the water level height somewhat–the ultrasound sensor kind of failed to do this between 0-6 inches initially. So this seemed like a win for the IR sensor.

2. Could I easily interface my sensors with my cap?

The sensors I have are mechanically small enough and have solid mounting points to interface with the custom cap I’m designing. The next questions are how well I can create an IP67 enclosure and how will the enclosure affect the sensor’s reading?

3. Are each of my sensors able to pick up the clear liquid?

It seems like it.

4. What is my water bottle’s water level resolution (hourly increment of water intake)?

Still needs to be defined.

And now I have even more questions. Are the sensors going to pick up the water level when the user is on the beach (operating scenario)? Or in a cold, fluorescent-lit room? Will the computer’s light affect the laser’s measurements? Will a hot car affect the ultrasound’s measurements? These are more operating scenarios and characteristics that need to be defined. So stick around any maybe we’ll see some developments in the next stages of sensor choice.

Author

smundon@bu.edu

Leave a Reply

Your email address will not be published. Required fields are marked *