Out of Water Turbidity
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 June 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.
