1. List of Hardware Components
2. Parts
   1.The Body 2.The Case 3.Solar Panel Holder 4.Interior Housing 5.Camera Module 3.Power

The body of the camera is a waterproof case from an old point-and-shoot canon camera. My original intention with the project was to re-use old hardware. I detail the struggles I had with this in the re-use section. My hardware is fitted using 3D printed parts that have been modelled around the case.

After trying and failing to reverse engineer the firmware of old point-and-shoot and video cameras I decided to use my fallback option: an ESP32-Cam (which I detail in the next section) with my own powering system. None of this hardware is weatherproof and so a case was required. Designing a weatherproof camera case from scratch would require designing the body around the parts, creating the body (e.g. 3D printing, CNC’ing + moulding), creating a waterproof seal, then testing the body for waterproofing and iterating on the design. That would require a lot of time, energy and resources. So, I found an alternative.

Luckily there is an abundance of existing cases for cameras that people in general don’t want anymore: waterproof cases for obsolete (or at least aging) digital cameras. These are mostly from point-and-shoot cameras that create lower quality images than many of today’s smartphones.

£8-15

This board is at the smallest end of single-board computers. When stressed, it will draw around 550mA (0.550A), so around 2.75W and around 240mA (0.240A) in idle mode

https://ffseb.files.wordpress.com/2017/10/800dpoweruse.pdf This device will use between 120 and 365mA in standard modes at 8V so between 1 and 3W, and 550 - 990 mA in continuous shooting mode, so between 4.4 and 9.9W A timelapse, which is an equivalent to the processes done on my cameras draws between 0.83 and 2.55W

1600 x 1200 px This is the main ‘payout’ of the ESP32-Cam. The image sensor is fairly tiny. As I discuss in the image-making process this limitation can be viewed in some sense beneficially, reducing the storage size and forcing more creative ways of processing and displaying the images.

There is potential to ‘upgrade’ to a ESP32 board that uses the OV5640 sensor (2592 x 1944 https://www.waveshare.com/wiki/OV5640_Camera_Board_(C)) I haven’t used this yet but it should work.

6000 x 4000 px

4000 x 3000 px

160 Degrees Fish-eye Lens £5

Standard OV2640 lens £3

All of the code needed to use the ESP32-Cam is open-source. The camera is also fully programmable. This means we can create versions of this firmware and create custom image creation processes. The GPIO pins mean we can control the device from a sensor, like a microphone or distance sensor. For example, experimenting with the function that moves the image sensor readings into temporary memory. The firmware I have written uses Espressif’s ESP32-Cam library. Details of this firmware are in the manual but the general gist of it is like this:

• The camera has a settings mode where it is accessible via a Wifi connected device such as a mobile phone or a laptop. You can use a website I’ve designed to adjust the settings, check the result of the settings and then choose what imaging mode you’d like to use
• A series of imaging modes, some that use timers, some using sensors, some for multiple connected cameras, some for one individual camera. The imaging modes correspond to different image processes. Currently they’re 1-1 but they could easily be 1-many or many-many
• Turns off when the battery is too low

Wifi and Bluetooth Capabilities This allows for the possibility of ‘connecting up’ multiple cameras. I intend to use this to do some collaborative photographs, where multiple cameras and camera users collaborate to create photographs together. This also allows us to control the camera from another device, like a smart phone or another ESP32. This can include: Changing what image process to do Changing the settings for the sensor (exposure, brightness, contrast etc.) Controlling the camera shutter from another device (say a device connected to an underground microphone) Creating time-based processes that are not just timelapses or panoramas This also allows us to reprogram the device without dismantling the device. We can add new image processes, or change settings via Wifi. This is done via Over The Air (OTA) programming.

The solar panel is very cheap and is essentially generic. You could replace it with a larger power panel, but I’d recommend keeping the voltage at 5V so that it works with the board. It would be fun to salvage a solar panel from another device rather than getting something new. If you have one you'd like to use, feel free to let me know to see if I can help. If you use a different panel to mine, you’ll need to modify the Solar Panel holder 3D model.

The power manager (https://wiki.dfrobot.com/Solar_Power_Manager_5V_SKU__DFR0559): allows the battery to be charged while the camera is in use the new version also has protection circuits which is very important, since lithium-ion batteries can be very dangerous if not handled properly (e.g. never store them completely full) Steps up the voltage from the battery (3.7V) to 5V with a steady current draw up to 1A. The ESP32-Cam runs at 5V and has a max draw of around 260mA so this board is perfect. Maximises the efficiency of the solar panel with MPPT It’s a really great board (thanks to Marguerite for showing it to me!). I tried to design a similar circuit for myself and it was pretty tricky, this board handles a lot of electronics.

The battery is a rechargeable lithium-ion battery. Ecologically, these are extremely problematic and are in almost all new tech today. My aim is to design the firmware to maximise the longevity of the battery. The larger the amp hours the longer the camera will last without resorting to deep sleep. I am yet to experiment with smaller battery sizes but I hope to in the future. I would also like to experiment with salvaging batteries from devices that are not used to their limit. For example, Elf Bar vapes are made with rechargeable batteries that are never recharged.