Experiment #2: Tin Foil Sensor
Noticing how much more responsive the results from the CapacitiveSensor library were when the paper clip was accidentally touched in experiment #1, it was concluded that metal sensors may be superior to graphite. Furthermore, some of the sensors found online were metal. So the obvious next iteration in the design of the instrument’s keys was to try a metalic sensor.
Sensor
For this sensor an approximately 4.7×7.5cm rectangle of cheap kitchen foil was used. This was attached, along it's shorter side, to a slightly larger piece of card using copper tape. The copper tape has conductive adhesive. One pin of a piece of breadboard jumper cable was soldered to the copper tape, leaving the remaining end available to be plugged into a breadboard. The remaining edges of the tin foil were attached to the card using masking tape.
Circuit
The circuit used in experiment #1 was adapted slightly for this sensor. The only change was that a 1kΩ resistor was placed in series with the sensor. This was done to minimise the risk to the micro-processor from any static discharge from a finger through the tin foil.
The circuit was as follows:
Once again, the Uno was supplied with 5V from the PC via it’s USB port. The breadboard and other components were connected in a logically similar way to the following diagram:
Pin 2 of the Uno is configured as an output pin and is connected, via a 1MΩ resistor to input pin 3 and the 1kΩ resistor protecting the sensor.
Tests
Two different tests were run on this sensor.
- To test various sample rates and observe two different attributes of the sensor.
- To determine whether averaging the sensor readings produced smoother, more consistent results.
The tests are described in the following two sections.
Test 1
Methodology
In these tests the aim was to test various sample rates and observe two different attributes of the sensor:
- The difference in value of results when the sensor was touched as opposed to when it was not touched.
- How quickly the sensor responded to taps at different rates.
The code used is the same as that used in experiment #1: SingleSensorRawDataLogger. This code takes repeated sensor readings using the CapacitiveSensor library and reports the results over the Uno’s serial port.
The test was run multiple times, each time with the code altered to use different sample rates. These were 1, 10, 25, 50, 75, 100, 125, 150, 200 and 255. The same test rhythm was tapped out each time. This was:
- A long tap, with the finger held down.
- The rhythm of a single verse of “Happy Birthday” with the finger released quickly after each tap.
- A long tap, with the finger held down.
The output was displayed on the Arduino IDE's serial plotter and screenshots were taken of the results.
Each time an attempt was made to have the same length of long tap and the same tempo when tapping out the tune. However, in order to fit all the results onto a single screen of the serial plotter, the taps were speeded up slightly at the lower samples rates.
Results
There was a readable response at all sample rates, but the sensor code responded much slower at high sample rates. This can be seen in the following sequence of graphs. Note that the X-axis represents the number of readings taken, not time. Consequently fact that the length of the test across the x axis reduces with incresing samples shows that there were less samples taken in a roughly fixed amount of time.
The various screen shots are displayed in the in increasing order of the number of samples in the carousel below.
Test 2
Methodology
The purpose of this test was to determine whether averaging the sensor readings produced smoother, more consistent results.
To this end the code used in test 1 was adapted to average a specified number of consecutive sensor readings and match that reading against the actual readings. This code has two parameters that can be varied: the number of samples used by the Capacitive Sensor library and the number of results from the library that are to be averaged. The code can be seen in the SingleSensorAvgDataLogger directory in the project’s GitHub repository.
The code was run using several combinations of sample size and average size and the results of tapping the sensor were plotted together in the Arduino IDE’s serial plotter. The results were analised to determine if averaging the results made a significant contribution to the accuracy of the sensor.
The pattern used in test 1 was repeated.
On reviewing the result of test 1, two of the most promising sample size were chosen - 25 and 50 - and each was plotted with average sizes of 2, 4, 6 and 8. Screen shots were taken of each of the eight resulting combinations of values.
Results
The results for 25 samples are shown in the following image carousel. The raw readings are shown in blue while the averaged readings are shown in red.
And now the results for 50 samples are shown similarly:
Conclusions
Three things stand out:
- For average lengths > 2, the averaged results are significantly smaller than the raw results for quick taps, but on longer taps the average value approaches the raw value. Thus the average for quick taps reduces the differential between results for touched and untouched states.
- The averaged values lag behind the raw values meaning that the change from touched to untouched state and back again is detected later. Again this is more pronounced for higher average lengths.
- Raw values do not appear to vary significantly from one another. They certainly do not blur the differences between the touched and untouched results.
In general it would appear that averaging readings has no advantage over using the raw readings. In fact. for higher average lengths, averaging could potentially mask the change from untouched to touched and vice versa. Consequently it is not proposed to incorporate such averaging in the final instrument design.