Out of Water Turbidity
Contents
10 June 2020
In addition to turbidity it would be interesting to test if velocity could be measured using the sensor by tracking the motion of objects on the surface of the water.
The first step is to investigate if the idea is viable. To do this it would be good to gather raw data on what a camera would see when in a drain. From this we will be able to see how turbidity levels affect the image and determine ways to determine to extract the turbidity component using the small processing ability of the ATmega328p or a similar micro-controller.
The ArduCam module was tested as it is likely to form the backbone of the out of water turbidity sensor. Its standard library was downloaded and it was wired to an Arduino Uno on 5V. This worked well, and photos were able to be taken. Next the power supply was changed to 3.3 V. This also worked well and the camera appeared to still be working normally.
When it was attempted to be connected to a BoSL board. It raised the error of not being able to detect the camera. Currently the 8MHz speed of the ATmega on the BoSL board is the suspect. Plugging in the I2C lines of the device in addition to the SPI lines allow the camera to work somewhat on the BoSL board. The connection is unreliable though, and photos will commonly not transmit. It seems that this issue is mostly due to bad quality wires used in the connection. Holding them down while trying to take a photo mostly solves the issue. The baud rate of the serial port was also decreased to 115200.
13 June 2020
Instead of a BoSL board, initially a Arduino MKR zero will be used to connect to the Arduino CAM in the drain. This is because it has an integrated SD card for storing photos, additional processing power, and is much smaller and compact. It also has an RTC which can be used to set the time of the photos.
It was found that the Ardu CAM code compiled on the MKR zero with no adjustments needed. The camera performance was about the same as on the 3V3 BoSL board: some photos were corrupted however it is thought that this is more to do with the cabling than the powering of the device off 3V3 volts itself.
14 July 2020
The SPI clock speed was adjusted on the Arduino MKR zero to get maximum reliability from the ArduCam, it was found that a clock speed of 1MHz provided the optimal stability.
When logging to SD card the ArduCAM is much more reliable. However an issue is had with the auto exposure system. Taking one frame at a time solved this issue.
The power consumption of the Arduino MKR Zero wsa measured, it was found that the operation used 150 mA, of which the SD card took about 30 mA. Putting the ArduCAM module into low power mode reduced the current consumption by 70 mA.
The SAMD21 also has low power modes. It was difficult to be able to get these to work, and issues were had with activating the serial port after sleep.
The native usb serial port is not able to easily be reactivated once the MCU goes into low power mode. An alternative is to use the Serial1 port. This requires an external USB-ttl converter however the USB is only needed for development so it is a viable work around.
In full sleep mode the whole setup uses 62mA, 57 mA of which are drawn by the camera module. This is when its in its lowest sleep state. A transistor may be needed to switch on an off the module to achieve suitability low power consumption.
20 July 2020
In order to reduce current to acceptable levels during sleep, it was experimented if it was possible turning off the supply voltage to the device. Two BC557 PNP transistors were used in parallel to control the VCC to the arduCAM. This did have the effect of reducing the voltage of the VCC pin to aobut 2.9 volts when on, however this didn't seem to affect the performance of the camera, which still worked well. What was found to be an issue was that the camera did not want to re-initiate once the VCC was powered again.
The above issue was fixed by reinitialize the camera from the library every time it was powered on. In sleep mode the whole setup now uses 5mA. Not completely ideal however significantly better than before.
Work was also done to get the image output in BMP, this was less trivial than assumed, the current version is limited to QVGA in BMP mode. Additionally, the BMP files are quite large 150 kB and so take some time (about 2 seconds) to transfer to the SD card and store. It is potentially possible to throw away pixels and decrease the resolution of the image to make this process faster.
It was found how to set the white balance of the camera. By default this is set to auto on the ArduCam however I have now set it in the script to the predetermined 'Sunny' setting. This should ensure more consistency in the colors recorded by the sensor, critical if we wish to use this to determine turbidity.
21 June 2020
Code was written to upload the time photos were taken on the ArduCam to the cloud. The idea is that the ArduCam could be installed with a turbidity sensor. Comparing the turbidity measurements to the photos should allow us to see if there is a good method of determining turbidity from the image taken.
Above is a basic schematic diagram of the setup. The arduino MKR zero and the arducam will be located in the drain and connected via a cat 5 cable to the bosl on the surface.
22 June 2020
A case was printed for the ArduCam. Since in the prototype version the arducam is connected via jumper leads the case needs to be large to accommodate the run of these cables.
The case turned out a bit large, and it was found that a smaller one would still have room to fit all the components. This will be designed now.
24 June 2020
A new box was printed to better accommodate the size of the ArduCam and Arduino. They fit quite well. A lid is still to be printed.
ArduCam and Arduino MKR zero in box
Issues were had with the wire used to connect to the BoSL. The ArduCam requires about 100 mA. It was found that the CAT5 cable had a resistance of 4 Ω over 10 meters. This meant that significant voltage drop occured over the length of the cable causing power instability issues. A fix was found by powering the device with VBAT instead of 3V3 and adding a 100 μF capacitor between the voltage rails on the sensor side. It is noted that this will have implications for longer cables when used on the BoSL Bus notably maximum current draws particularly on longer cables.
With the lid attache the final enclosure looks like this: Note it is not waterproof and should be kept dry.
Out of water turbidity testing enclosure box
To wire up the sensor the following connections are to be made to a BoSL board.
| Sensor | BoSL |
|---|---|
| GREEN | VBAT |
| HALF GREEN | GND |
| BROWN | D9 |
| BLUE | D8 |
| HALF ORANGE | D7 |
The BoSL code is: File:BoSL Host out of water turbidity.ino
And Arduino MKR zero code: File:Turbidity out of water.ino
The function of the logging setup is to take 5 pictures spaced 2 seconds every 2 minutes. These are saved to the onboard SD card along with the a timestamp. The timestamps are also then uploaded to the BoSL testing site (http://www.bosl.com.au/IoT/testing/a.php) under site name: TURBID_TEST
19 November 2021
In the year and a bit since the last work on this project was done, new sensor technologies may have come out. Therefore, we will investigated if there now exist any better implementations for an low power/cost camera system.
The current solution of using the Arduino Cam is unideal for a few reasons. The first being that module was not designed for ultra low power operations, hence the changes and usage needed to add low power features cause the system to be buggy, additionally the sensor has a very high resolution of sever megapixels. This is more data than we need to detect the tubudity of the water and more data than is reasonably processable on a microcontroller.
Some new solutions include:
https://www.digikey.com.au/en/products/detail/sparkfun-electronics/SEN-15570/10819696
This is small self contained imaging module which has a sensor resolution of 320 by 320. It is addressable by I2C, operates off 3.3V and requires on the order of milliamps of current in operation. Many other similar devices appear to be available at: https://www.uctronics.com/1/9-ov7675-standalone-vga-coms-camera-module.html and here https://www.arducam.com/compact-camera-module-oem-odm/
The ideal set of qualities we are looking for in the image sensor module is:
- Low Cost
- Low Power (mA) on 3.3V supply
- ~QVGA resolution and RGB colour
- easy to interface (I2C, SPI preferable)
- infinity focus
- small (TBD)
- suitable physical connection interface (TBD)
Following investigating the different products available, the arducam OV7670 (https://www.uctronics.com/arducam-ov7670-camera-module-vga-mini-ccm-compact-camera-modules-compatible.html) looks to be the best suited camera for our application. It fits the cost requirement at $4, the current requirement, VGA, it operates through the SCCB bus, which I haven't had as much experience in, but looks reasonable. However the field of view of the camera is a bit small at 45 degrees.
14 January 2022
Performing some further research it seems that the OV7670 is deprecated, it might therefore be worthwhile to use the OV7675, which is the updated version of the OV7670. Specifically the differences are that the newer sensor uses a slightly smaller sensor, has greater standby current. (60 μΑ vs 20 μA), and has a greater sensitivity to light. Both seem to be support by this arduino library https://github.com/arduino-libraries/Arduino_OV767X, so switching between the two later if needed should not require substantial reworking of the design.
20 April 2022
To experiment with these different camera modules and gain an understanding of how they operate, first we will test the camera modules with the Arducam ESP32S UNO PSRAM development board. This board is an arduino which has the OV2640 camera connected onto it. Arducam provides starter scripts to begin working with the camera. Following their guide photographs were able to be captured and stored on the SD card. A typical image from the camera is shown below.
It was found that changing the resolution of the image did not affect the field of view of the image. This allows us greater freedom in choosing a camera with a higher resolution than needed as if downsampling of the image is needed for memory of processing constraints this will not need to crop the image. A quick measurement confirms that this field of view is about 60 degrees.
The example script gives the needed functions to adjust all the key camera parameters (white balance, exposure, contrast, gamma, etc) these will likely need to be set manually for the out of water turbidity sensor as we want a consistent conditions to match images to colours of turbidity. Looking at the code it seems that the setting of these values occurs through setting corresponding bits in the registers mentioned in the datasheet. The manual white balance was a bit difficult the script gave only 4 presets none of which worked very well in the indoor lighting conditions.
27th April 2022
In addition to choosing the correct camera, a lighting system will also be needed for when there is no light in the water system. Using a camera flash is one option, however this will likely need to be a pre-built flash module due to the high voltages involved. An alternate option is using LEDs with a longer exposure time. To see if this is viable we note that the sensitivity of the camera is 1.8 V/(Lux s) and the dark current is 10 mV / s.
Assuming that the led light is co-located with the the camera, then once can calculate that the needed exposure time to get a 50% grey is:
Where Texp is the needed exposure time, Vexp is the 50% grey voltage (~1 volt for our use cases), η is the reflectivity of the water surface, σ is the sensitivity of the camera (~1.8 V/(lux s) for the types of cameras we are using), Icd is the luminous intensity the leds used, θv the half the field of view of the camera, and H the height of the camera and led above the water. For a higher power white led with luminous intensity of about 33 candela and a distance to the water surface of 3 m this gives, a 20% reflection of the water surface and the OV7675 camera module this gives an exposure time of about 7 seconds. This is probably just on the edge of a feasible exposure time, so with higher power or multiple LEDs, using LEDs to illuminate the water subject should be feasible.
Ideally we would want the colour temperature of the LEDs to match that of the sun so that the difference in the illumination conditions can be minimised. Additionally a narrow angle LED would be preferred so the light isn't wasted outside the field of view of the camera something like (https://cree-led.com/media/documents/C503C-WAS-WAN-1098.pdf) would be ideal. Such LEDs tend to find application in road signs or torches when illumination at a long distance is needed.
