The next iteration of the turbidity sensor requires more thorough waterproofing from the beginning. Prototype I started as a simple proof-of-concept of the component combination ( LED, LDR in a garden hose enclosure) and had no consideration of waterproofing. After that, the focus of Prototype II lay on improving the initial design’s lack of water-proofing and adding long cables so it can be eventually tested out in the field.
Part I: Components, cables and heat shrinking tube
For this turbidity sensor design, I used an approximately two-meter-long stranded core CAT-5 cable to connect my white LED and my LDR to my Wemos D1 board.
After assembly, I immediately sealed the components that eventually get submerged into the water with heat shrink tubing (yellow for the LED, green for the LDR).
My first attempt at running the test code with the components through the two-meter-long wire went well. I tested the incoming values roughly by concealing the LDR with my finger.
Part II: Housing the components in the “test tube.”
Similar to the previous prototype, I cut a new 10cm piece off the garden hose and drilled two opposing holes of the size of the components in the centre. To attach the LDR and the LDR I used hot glue only this time. The reasoning behind this is that hot glue has a much shorter drying/hardening time than the All Clear sealant. This allows an efficient applying of layer after layer within a relatively short period. The sealant ideally requires overnight drying which means assembly would span several days instead of hours.
The work with hot glue is messy and requires diligence. Therefor, the purpose of the first layer is to attach the components to the hose and make sure they are facing each other correctly.
After the first layer has been applied I test that the components have not been damaged in the process of hot glueing. The incoming values look good so far, but I am not entirely happy with the design. It is quite hard to apply hot glue around the components evenly. I already spot some small grooves in the glue that could cause some leaks later on.
Part III: Dear hot glue, please protect my components
While applying the next layer of hot glue, I have already made peace with the fact that this probe is going to look very odd. Basically, I am looking at a small dark-green piece of garden hose attached to a long cable with semi-transparent blobs of glue. I also notice that the wire close to the components appears to be under strain caused by the angle the components are attached to the hose. I should have immediately bent the connectors at a right angle to avoid this oddly shaped glue blob altogether.
Despite the aesthetic shortcomings of this turbidity sensor design all components seem to be working, and I am ready to compile a version that sends data wirelessly via the MQTT network so I can safely test the design in an underwater setting, without the need of a laptop attached to any submerged components.
Several participants in my design evaluation interviews indicated the interest in having audio as a medium to access the stream sensor data. As a result of this, I looked at options to use the ESP8266 chip in combination with a simple audio interface. I found some research on using the Wemos D1 for sound applications, a previously purchased microcontroller, the Adafruit Feather Huzzah can be expanded with the Music Maker FeatherWing, which adds an audio interface with a headphone jack output which could be used as a standalone version in the field.
Setting up the Adafruit Feather Huzzah
The Feather requires you to install a USB-driver (USB to UART Bridge VCP drivers) to work with your operating system properly. Note: For this install you need to restart your computer.
The Huzzah is part of the ESP8266 board manager, which needs to be added to the Arduino IDE under via Arduino…Preferences…Additional Board Manager URLs…
If step one and two have been successful, the Feather should be ready to be programmed with the Arduino IDE.
Arduino…Tools menu showing correct Board and Port to work with the Feather
Success. The Blink sketch is running smoothly on my Feather.
Feather Huzzah running the Blink script
I have ordered the Feather ordered at an earlier stage of the research project, but decided in the and not to chose it as the chosen as a central component of my project, mainly because of the price point (currently $33.00pp vs Wemos D1 $10.00pp on nicegear).
The Musicmaker shield adds another $36.00 to the sum.
For a complete audio player setup, an SD card (to store the mp3 files) and headphones are required. The MIDI setup does not require the SD card.
Adding the Audio Shield
Once the Musicmaker arrives I need to install some software as described in the guide by lady ada (2018):
Install the library for the Adafruit VS1053 Codec Breakout (lady ada, p.13).
Test the example code feather_player with two mp3 files on the SD card.
Solder the MIDI jumper on the bottom of the board together and test the MIDI example.
So far so good.
Now I need to connect the Feather to my MQTT network and have audio play triggered by a callback.
After some fiddling with the code, I manage to play the test Ocarina scale from the example code when the EC sensor and the water temperature sensor transmit data across the network.
The audio jar stands now among two visual outputs. While it offers a different mode of access to the stream data, it also breaks with the convention of having one-on-one relationships between input and output nodes.
I also need to consider if the jar casing is the best choice for this node, and how an audience would access the data in the field. The node could be a hidden audio jack that participants can plug their headphones into, or headphones can be provided. Alternatively, I could use a small speaker to play the sound output and make the experience accessible to multiple users at the same time.
The opportunities for this extra node need to be tested and evaluated in the field.
My DIY water sensor nodes need field-compatible outputs so that visitors can easily access and understand the sensor data of the IoT network in real-time. The design for the temperature visualisation is based on the concept of the previous paper circuit for the EC probe, because research participants generally gave the design with cardboard, copper tape and white LEDs positive feedback. For the water temperature jar, however, I am using coloured LEDs, as suggested by one participant. In my development notes below, you can learn how I designed and assembled the device, and how the SHMAK manual (NIWA, 2008) helped to make the visual output meaningful. The idea for using cardboard and copper tape for these prototypes is inspired by the work by Jie Qi (2012) and the High-Low Tech Group at MIT Media Lab (2012).
Similar to the previous LED prototype I use a 12cm high sheet of white card paper as a base for my copper tape trails. During an evaluation discussion on the EC jar design, participant 18 suggested the use of coloured LEDs for future iterations. I am attempting to implement this suggestion in the design for the jar that visualises the data coming from the water temperature sensor (DS18B20).
Visualising stream wellbeing
During the ideation phase, I focused on a suitable way to connect coloured lights meaningfully to the water temperature readouts. Hence, instead of opting for a traditional water temperature colour scale for blue (cold) and red (warm) I departed from the perspective of the stream, and what effect water temperature has on the more-than-human wellbeing of the stream.
Stream temperature is important because every species has a preferred temperature range. The range varies considerably from species to species. Sometimes, a temperature change is important, for example, as a trigger for egg hatching in some mayflies. Many organisms are unable to survive in temperatures above about 30 °C (except for some adapted to life in hot springs). At the other end of the scale, temperatures below freezing point constitute a very harsh environment because of the effects of ice.
A single temperature measurement is not particularly informative, but a series over time will provide a rough picture of the temperature regime in a stream. The longer the series and the closer together the measurements, the more informative the series will be.
Temperature depends largely on time of year and weather conditions. Stream type also plays a part. For example, lowland streams tend to experience quite stable temperatures (i.e., closely following average air temperatures). Shading along streams reduces the occurrence of extremely high water temperatures.
Water temperature fluctuates on a daily basis and for this reason it is suggested that measurements are always conducted at the same time of day.
Less than 5 Rating: fair Score: 5
Less than 5°C
Values below 5 ºC are low and indicative of winter conditions in southern regions. Invertebrate and periphyton growth would be slow in such waters. Some species may be excluded.
5 to 9.9 Rating: good Score: 8
5 to 9.9°C
Values of 5 to 10°C are moderate to low and indicative of winter conditions. Most invertebrates and periphyton can survive well in these temperatures.
10 to 14.9 Rating: excellent Score: 10
10 to 14.9 °C
Values of 10 to 15°C are very suitable for most invertebrates and periphyton.
15 to 19.9 Rating: good Score: 5
15 to 19.9°C
Temperatures of 15 to 20°C will start to be stressful for some invertebrates (e.g., stoneflies).
20 to 24.9 Rating: fair Score: 5
20 to 24.9 °C
Temperatures of 20 to 25°C are moderately high. Some invertebrates, such as some mayflies, stoneflies, and some fish, such as trout, are unlikely to survive such conditions for prolonged periods (e.g., several weeks).
25 to 29.9 Rating: poor Score: 0
25 to 29.9 °C
Temperatures between 25 and 30°C are likely to be stressful to fish, stoneflies, mayflies and some caddis flies. Such high temperatures may be a result of lack of shading and very sluggish flows.
30°C or more Rating: poor Score: -5
30 °C or more
Temperatures over 30°C are likely to be very stressful to most stream life and result in their death. Again, such high temperatures may be a result of lack of shading and very sluggish flows. However, stream temperatures will rarely get to these levels.
Table 1: Habitat indicators of stream health. From NIWA (National Institute of Water and Atmospheric Research), 2008.
The table contains seven water temperature bands rated from poor to good. I opt to use one LED for each band, representing the ratings (poor, fair, good, excellent) with colour. I choose red, yellow and green LEDs to indicate the stream health rating:
Copper tape circuit design and assembly
To accelerate the development, I aim to build simple straight copper trails first as a proof of concept instead of spending time on developing a unique visual aesthetic for the circuit design without knowing whether the general concept works. I use the same circuit design as for the LED jar, but I need to recalculate the spacing for this version to fit eight rows of copper tape on the paper.
The Wemos D1 has seven digital outputs which makes it suitable for addressing seven LEDs individually. With the 8th digital output unused there is an opportunity for of adding a white LED on top later crossing all other outputs with sellotape, that could indicate the status of the network, similar to the EC jar.
The biggest challenge when making circuits with copper tape is the needs careful treatment and patience to make sure connections don’t break.
I use a craft knife to make precise cuts where the LEDs will be soldered in later.
I align the LEDs on the page so that the output can be seen best from one single perspective, that should later face towards an accessible area by the stream.
After all the LEDs are soldered into the circuit I test the quality of my solder points with a voltmeter.
Then I manually apply the forward voltage of each LED separately to test whether the connections work up until the edge of my circuit, where I will later add the connections to the microcontroller.
Challenges, reflections and learning outcomes
When working with SMD LEDs, I encountered the following issues:
The LEDs are tiny and their polarity is barely visible from the top. Sometimes LEDs move during soldering or don’t connect properly. I need to make sure I don’t accidentally move or flip them when working on the circuit touching the circuit with my hands or the tip of my soldering iron.
The LEDs that I am using have a clear lens. I need to be careful to not mix up LEDs of different colours. The only way to know their colour is to power them on, which is tedious when dealing with the SMD form factor.
Components close to each other don’t work well with copper tape. There need to be at least some centimetres of tape between two components.
In the sketch above you can see that my reference paper for the LEDs has moved in the process of adding LEDs which resulted in me picking the wrong LEDs for the first two rows. After removing the wrongly coloured LED I also realise that two green LEDs in series will not work for the “excellent” category as that would require a voltage of 2*2.2V which the microcontroller cannot supply. After making too many errors, I decided that I call it a day after testing that all the other LEDs work and will continue lab development after a healthy amount of sleep.
With this revised prototype I aimed to create a better, more stable design by inserting the LED and the photocell through holes into the hose while improving the sealing of electrical components from the beginning. I also wanted to use a cable with the actual length for use in the field and chose an approximately 2m long stranded core CAT-5 cable.
First I soldered the photocell to the green pair of cables and tested it with the code from yesterday.
I drilled 5mm hole into the hose to fit the LDR neatly.
The 3mm LED requires a 3mm hole respectively. I drilled the 3mm through the 5mm hole to make sure the holes are nicely aligned.
Reconnecting the wires with the breadboard from the previous prototype I ended up swapping the resistor to a 10k one which gave me more consistent readings when the LED was on half brightness.
For the sealing, I purchased the All Clear sealant that I have previously used for waterproofing my hydrophone. As opposed to hot glue, this material stays flexible when dried out and doesn’t run the risk of getting brittle.
Unfortunately one of the LED solder points was not well done, and I only discovered it after having added the sealant. With the cable disconnected, this prototype is unusable in the field, but the process of building it helped me understand possible avenues for improvement:
The design with the components stuck through tight-fitting holes is cleaner but needs to be revised with waterproofing in mind.
Solder points need to be stress tested and – if necessary re-done – before adding sealant.
Cables need to be fixed into place before adding sealant. Sealing might need to be re-done in the 3D workshop with proper ventilation and safety gear as this might require the use of turpentine.
Sealant might need to be changed as it might not be ideal in combination with cables/electronics.
Before using more EC probes in the field and gathering data from different parts of the stream I tested them in a controlled environment in the lab.
The two versions tested use the same materials, same length of chord and same 560 Ohm resistor. The first test involved a jar filled with tap water, immersing both sensors in the jar and monitoring the data via mosquitto_sub.
Note: The pink tape wrapped around one probe was an attempt to avoid the probe mistaken with a power plug on the lab table, which poses a severe hazard. The probes are stored away safely when unattended to ensure health and safety. This version of the probe uses the Live (L) and neutral (N) prong of the plug. To improve the safety of the probe the live (L) prong should be removed and Neutral (N) and Ground (⏚) should be used for measuring the electric conductivity.
The terminal output shows the EC probes publishing the measured values under the topics motorola/ec and moturoa/ecrua. While the test recording was done, the DHT11 sensor was also active in the lab, publishing air temperature (moturoa/atemp) and air humidity (moturoa/ahumid).
This first test showed a deviation of around 10 between both probes, behaving relatively consistent. The next test would require measurements in the stream to see whether the probes return coherent readings from flowing water.
Due to bad weather and high winds it was too dangerous to conduct testing in the field. However, to get a better idea of the consistency between the two probes I went to an easily accessible part of the stream outside of the forested area and collected two samples of stream water.
Back in the lab I pour the first sample into a clean jar that is big enough to contain all three sensors. I prepared a paper sheet for keeping experiment notes, starting with date/time, location of sample taken, last weather and readings from the TDS meter at the beginning and end of the test.
I boot the Raspberry Pi (the Pi acts as Wi-Fi Access POint hosting the Moturoa_Transmissions network and acts as the MQTT-broker).
Connect laptop to Moturoa_Transmissions and start log with timestamp
For this research I want to explore what kind of DIY electronics can amplify the voice of the forgotten streams in Poneke/Wellington, New Zealand. As a first device I want to build a hydrophone that can be used during fieldwork to record underwater sounds.
Hydrophones used in scientific research, for acoustic monitoring, such as for tracking marine animals, are relatively expensive and even DIY solutions feature costly elements (see for example Dawson, 2012). In low-cost DIY solutions old audio components, such as headphones or radios are re-used (e.g. digifishmusic, 2008) and made waterproof with silicone or hot glue.
I decided to combine building a hydrophone based on two instructions. Both are based on using an electret microphone element as the primary component. In the instructions of Decker (2013) the element is enclosed in an empty film canister filled with mineral oil as a medium to optimize the hyrdophone. I chose this design for the first version following a suggestion on the Wellington Sonic Arts Facebook. The instructions by the University of Waikato (2011) feature a component list that is available in New Zealand.
Building the first version of the hydrophone took less than a day and involved researching the best possible option to be done within one day, sketching a schematic alongside a shopping list of necessary parts, planning the quickest route around town to buy all necessary parts and then 2 hours of soldering and assembling plus some extra time for testing and troubleshooting and documenting along the way.
I built the hydrophone as described in Decker (2013) but used a 3.5mm mono headphone jack at the end of the 3 meter long cable. I also soldered 3.5mm sockets to the pre-amp for in- and outputs to keep the device as modular as possible. For testing the hyrdrophone I used a pair of headphones, but I will be looking into options for adding a speaker. Currently, the pre-amp turns on and off by connecting and deconnecting the battery, which is cumbersome, so adding a switch would be a good improvement overall to be added to a (preferably waterproof) enclosure.
Dawson, S. (2012, January 20). Building the “CETOS” directional hydrophone. Retrieved from http://whaledolphintrust.org.nz/wp-content/uploads/Building-Directional-HPs.pdf
Decker, F. C. (2013, June). Underwater sound detection using sea perch through construction and operation of hydrophone. Retrieved from https://seaperch.byu.edu/wp-content/uploads/2013/06/Final.pdf
digifishmusic. (2008, January). How to make a Hydrophone (stereo!). freesound. Retrieved from http://www.freesound.org/forum/production-techniques-music-gear-tips-and-tricks/2631/?page=1#post13253
The University of Waikato, New Zealand. (2011, May 10). Make and Use a Hydrophone. Retrieved October 17, 2016, from http://sciencelearn.org.nz/content/download/20964/411858/version/7/file/Make+and+use+a+hydrophone.doc