Turbidity Visualization – alternative design

In the first turbidity node design I re-used leftover plastic of one of the bottle designs as the circuit carrier and copper tape for connections. This proved to be tricky as the heat during soldering would distort the plastic and dissolve the glue of the copper tape, making it lift off the surface and weaken the connections.

In a new attempt to provide a seamful design, this new prototype uses copper coated welding rods and copper wire as conducting elements and at the same time as structural element. This means the circuit would not require a surface, such as paper or plastic, but would only consist of conducting copper elements. For a first test I used a 1.2mm rod and experimented with soldering various wires and components to the rod. Soldering wire to the copper rod works well after removing the oxidation layer with sandpaper. The enameled copper wire also only solders well after sanding, which is time consuming when many components are involved. The advantage of this, however, is that the 3 dimensional circuit is less likely to be short-circuited, if parts accidentally touch – except for the conductive elements of the LEDs and the solder points.

I envisioned the test design to contain a set of 3 addressable LED sets that fit inside a glass jar. I bent the Ground wire into a circular shape to act as a base for the circuit which will connect to a set of LEDs to be controlled by a Wemos D1 board. After a hopeless attempt to use SMD LEDs for this circuit I found that 3mm LED diodes are much better suited for this kind of circuit.

In the end, I connected a set of three LEDs to three individually addressable wires. The copper rod needs to be bent carefully with flat pliers while the copper wire bends into shapes very easily. This gives the final circuit a quite messy look and I am unsure the design in this form would be suitable to provide any meaningful visualization of the turbidity reading.

The circuit appears quite fragile, the copper wires can be bent and crushed in the hand which gives it quite a unique aesthetic when handheld. Once transferred into a glass jar, the intricacies of the circuit design fade into the background, and the bright blue LEDs, as well as the battery and the small circuit board, distract from the fragile wires. I programmed the board with a simple test sketch that loops through the three LEDs.

The next step involves connecting this design to the turbidity sensor through my local MQTT network. I submerge my turbidity sensor into a glass bowl filled with water to get more realistic sensor data readings for this test. Unfortunately, the circuit design appears to be tricky to be programmed, and only after a while am I able to successfully de-tangle the wires that must have short-circuited somewhere, causing the code to malfunction and print nonsensical glyphs in the serial monitor when I try to debug my code.

Once my LED node is properly connecting to the WiFi network and correctly receiving the sensor data I map the turbidity to the amount of LEDs being switched on. To achieve a more murky fluid for this test I add a teabag to the water. I notice that the value changes are not as extreme as i would have hoped for and assume that a different resistor, perhaps a trimpot, would help to get more accurate data. Another issue with the sensor data is jumpiness. This could be because the LDR is just not suitable for an accurate measurement, or perhaps the sensor design is not waterproof and hence unreliable. Perhaps the code could be improved by measuring a running average over a couple of miliseconds, instead of measuring the brightness only once sand immediately transmitting this data.

Despite issues with the quality of sensor data, I learned a lot about the feasibility of this circuit design. While the copper wire gives the circuit a unique, messy look that I generally like, it is unsuitable for providing an easily understandable visualization of sensor data. Using only copper rods in combination with 3mm LEDs could work with a refined sketch on how to accurately map the sensor reading to an arrat of LEDs.

Temperature visualization: Part II

The design for the temperature visualisation is based on the concept of the previous paper circuit for the EC probe but uses coloured LEDs that indicate the water temperature in relation to stream health, as listed in the SHMAK manual by NIWA (2008). 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).

For finishing the circuit, I need to add resistors to the design as they have a smaller forward voltage than the white LEDs I used in the previous design. Using Ohm’s law, I calculated that 43 Ohm resistors are a good choice for all three colours.

After all the LEDs are lighting up when tested with a constant 3.3V output from a desk power supply, I use a Cat5-cable to connect the paper to two sets of header pins so I can test the work with the WEMOS D1.


Here you can see me testing the connectivity of components on bent paper. It appears that the angled copper-tape connections are the most fragile element of the design, especially the bent overlap that I have taped down with sellotape.

After powering the circuit with the desk power supply once more to test whether the LEDs still work with the cable bridges I add header pins to the end of the cables to provide a stable connection to the Wemos D1 mini microcontroller. I use colored heat shrink at the end of the header pins to identify cables with the respective LED color for more clarity if  debugging is required later.

The next step involves addressing all LEDs correctly with the Wemos D1 mini.

I had previously noted down the temperature ranges from the SHMAK manual (NIWA, 2008) and also added all values to the header comment of the testing code for easier reference later. This information also contains the colour of CAT5-wire strand, the digital pin connected, and the range of temperature as per SHMAK kit and the colour of LED (red/yellow/green) used to represent each state.

After some bugs in my code addressing all LEDs correctly (I ended up using digital ports D1–D8) I finally got all LEDs working with a simple looping sketch.

// Kaituhituhi-rua prototype - temperature

// blue wire - G

// brown wire          D7 - <5°C – 5°C - fair:5 (yel)
// green wire          D4 - 5°C – 9.9°C - good:8 (grn)
// orange wire         D2 - 10°C – 14.9°C - excellent:10 (grn)
// blue/white wire     D4 - 15°C – 19.9°C - good:5 (grn)
// green/white wire    D8 - 20°C – 24.9°C - fair:5 (yel)
// brown/white wire    D5 - 25°C – 29.9°C - poor:0 (red)
// orange/white wire   D6 - 30°C< - poor:-5 (red)


// LEDs
int ledPins[] = {D1, D2, D3, D4, D5, D6, D7, D8};

int ledState[8];

unsigned long previousMillis = 0;

const long interval = 1000;

void setup() {
  for (int p = 0; p < 8; p++) {
    pinMode(ledPins[p], OUTPUT);
    ledState[p] = LOW;
  }
}

void loop() {
  for (int c = 0; c < 4; c++) {
    for (int p = 0; p < 8; p++) {

      digitalWrite(ledPins[p], HIGH);
    }
    delay(500);


    for (int p = 0; p < 8; p++) {

      digitalWrite(ledPins[p], LOW);

    }


    delay(500);
  }

}

Next, I cut the paper into a smaller size and test how it fits in two different types of jars.

While fitting the paper into the jar I leave the microcontroller connected to evaluate how stable the solder and copper tape connections are. The power supply to the LEDs needs to remain stable while repeatedly inserting and removing the circuit from a jar. The LEDs indeed keep blinking which is a good sign. The smaller jar that was initially intended for the circuit has a pattern on the top and bottom of the glass which diffracts the LEDs and might make it hard to read.
The taller jar is clearer which makes it easier to see the LEDs, but from an aesthetical point of view, the circuit paper would have needed to be cut a bit larger to neatly fill the height of the jar.

In the end, I decide that both jars are suitable from a technical and practical perspective. The final choice of enclosure needs to be made after testing the prototype with the final code, showing only the LED of the respective temperature zone on.

High-Low Tech Group, MIT Media Lab. (2012, August 21). Paper circuits. Retrieved February 27, 2019, from http://highlowtech.org/?p=2505
NIWA. (2008, December 17). Habitat indicators of stream health. Retrieved February 27, 2019, from https://www.niwa.co.nz/our-science/freshwater/tools/shmak/manual/9habitat
Qi, J. (2012). The Fine Art of Electronics: Paper-based Circuits for Creative Expression (Master of Science in Media Arts and Sciences). Massachusetts Institute of Technology, Massachusetts, NE. Retrieved from http://web.mit.edu/~jieqi/Public/Jie_Qi_MS_thesis.pdf

Lab EC-sensor tests

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.

Experiment 1: 

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.

Jar filled with tap water for testing two DIY EC probes

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). Output showing values returned by two EC probes (moturoa/ec and moturoa/ecrua) and DHT11 sensor showing 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.

Experiment 2:

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.

  1. I boot the Raspberry Pi (the Pi acts as Wi-Fi Access POint hosting the Moturoa_Transmissions network and acts as the MQTT-broker).
  2. Connect laptop to Moturoa_Transmissions and start log with timestamp
    mosquitto_sub -v -h 192.168.42.1 -p 1883 -t '#' | xargs -d$'\n' -L1 sh -c 'date "+%D %T $0"' > data.log
  3. Immerse probes into water sample and activate by connecting the Wemos D1 micro controllers to power supplies (USB batteries).

The raw data of both test results can be found on the development repository.