Brief
This is a simple sound frequency logger which records sounds from the surroundings and logs the data to storage for interpretation and inference. The project is built on the Arduino Uno which runs on an ATMega328P microcontroller, it includes a microphone module with an amplifier, and a temperature sensor as the primary data sensors. The primary purpose of this project was trying to establish patterns in mosquito behaviour and presence depending on temperature changes, and perhaps figuring out a mitigation strategy by the use of this data.
Primary Questions:
- What are the effects of temperature changes on mosquitoes?
- Is it possible to directly apply pesticide to mosquitoes by detecting their presence in real-time?
Hardware
The hardware for this project includes the following as the main components:
- Arduino Uno microcontroller
- Microphone module
- Temperature sensor module
The above hardware is pretty simple. The microphone captures the relevant sound, the temperature sensor gives us the temperature readings from the environment, and the Arduino Uno microcontroller marries all this together and packages the data before sending it to use over the serial port. We can then receive this data on a computer as described in the software section.
Software
The main software component, excluding the firmware running on the Arduino Uno development board, is a Python-Tkinter program that provides a configuration interface for data recording as well as a real-time visualization bar-graph.
The configuration interface
The configuration interface makes it easy, convenient and intuitive to connect to the Arduino Uno board to retrieve data in real-time as it is streamed from the Arduino Uno board.
The interface provides three main sections:
- Port configuration section
Allows the user to select a serial COM port on which the Arduino Uno is connected, and from which the data will be recorded in real-time
- Settings section
This relates to the data recording configuration.
The data is streamed from the Arduino at a very high rate, but we have the freedom to choose how frequently we want to retrieve the data from the Arduino by setting the Sampling Interval parameter. Of course this is not limitless, on the lower limit, we can read only as frequently as the data is being transmitted (the Arduino transmission frequency provides our lower limit). The upper limit is potentially indefinite, but common sense would definitely dictate not to sample too infrequently as it would definitely defeat the purpose of the entire project
The program doesn’t run continuously and instead executes in on-off cycles. It wakes up, records data, and then goes back to sleep. The configuration parameters “Samples per recording” and “Cycle time” define this behaviour. The cycle time is the interval between on cycles, while samples per recording defines how many samples should be taken during a single on cycle. When the defined number of samples have been taken, the program waits for the cycle time to elapse before waking up again.
The real-time graph visualization is however always displayed, and the data is continuously updated for real-time monitoring.
- Output file section
In this section we get to choose the output data file (the default output file includes the date and time when the current program-session was created). We can change as well as open the output data file using an in-system program.
The data is recorded in a CSV (comma-separated value) file, with each entry including the date, and time of the recording as well as 64 distinct frequency-block magnitude recordings between 0 and 2000 Hz (2 kHz), and a single temperature reading.
To begin writing out data to the chosen file, and simultaneously view the real-time graph visualization of the sound frequency magnitude, we can click the “Start Recording” button to begin the recording. This is of course after completing the configuration, and connecting to an appropriate serial port.
The real-time visualization graph
The real-time data of the sound frequency from the surrounding environment is displayed in this window. The data is animated to visualize changes in real-time as they occur.
During this particular run in the screenshot above, the sensors are not connected to the Arduino Uno, hence the input data lines for the sensors are floating, and we see a lot of low-frequency noise.
Challenges
- The system was initially deployed to a non-controlled environment, making it hard to track the presence of mosquitoes in the area. It’s harder to detect the presence of free-roaming mosquitoes.
- The on-off cycles could potentially miss crucial data. Important data points could go unobserved. This of course being a trade-off with running the system all the time, which would create loads more data. Is this an issue though? (Tried to avoid it at first in this version, that would be too much data to sift through)
- The microphone used could not very clearly distinguish the faint sounds made by mosquitoes. This may also be related to the first challenge, perhaps the sound was not as audible due to a lot of audible noise from the surroundings.
Solutions
- The solution to the first challenge is fairly obvious, controlling the environment in which the system is deployed. Perhaps a small box with a substance that attracts mosquitoes to effectively answer the primary questions.
- The second challenge is a little harder to address, while recording data perpetually and continuously may be an advantage, in that we’ll not miss any crucial data, it also exposes us to the risk of acquiring loads of irrelevant data (data that doesn’t particularly help our cause). A potential solution would be singling out detected presence, which would require a more complex mechanism of establishing the presence of our sucker-friends, alternatively powering through sifting through loads of data!
- The third challenge could be addressed in a number of ways, one would be applying signal processing strategies (I’m not the least bit familiar with most of them) to ensure signal integrity, another would be to apply a microphone with better sound quality capture (perhaps a directional microphone?) or perhaps designing a better sound-capture mechanism for our tiny microphone.
Final Thoughts
This project provides some intriguing possibilities when it comes to studying and controlling mosquitoes in homes. Thus far, the project hasn’t provided enough information about their patterns and behaviours. The hardware and software, however, work well together (to the best of their designed capability) and one can monitor sound frequencies in the environment rather well. It would be nice to explore this idea to its limit.
That may be it for this project, or I may choose to revisit it in the future. I guess only time will tell.
GitHub
Check out the code on github!