Skip to content

14. Input Devices

This week, I looked at different input devices. Together with my group (group assignment webpage) we used input devices and I also added some input devices to the board I design in Electronics Design week.

Background - Input Devices

In the past, I used different input devices on projects of mine. These covered the range from analog sensors over digital sensors all the way to digital sensors communicating over I2C or SPI. Here’s a few examples of past input devices usages:

  • analog sensors:
    • sliding potentiometers as inputs to change servo angles and speed values on an actuator demonstrator
    • light dependent resistors (LDR) to control educational robots (steering towards/away from light)
    • LDR to create a simple complex eye arrangement (e.g. a 2x2 matrix) for educational purposes
    • piezo buzzers as surface transducers in a baby-kick sensor belt
    • strain gauges in Wheatstone-bridge circuits for measuring beam strain
  • digital sensors:
    • buttons on various projects
    • light barrier switches on drive shafts for creating reference positions
    • old-school tilt switches for detecting robot tilt
    • ultrasonic range finders for robot and human-interaction devices
  • advanced digital sensors
    • Real Time Clock (RTC) modules on Arduino and Raspberry Pi for accurate timekeeping in time lapse projects
    • Inertial Measurement Units (IMU) for determining orientation on simple robotics projects
    • Infrared Detector Modules for robot control using simple, universal television Remotes

Adding a Sensor to my Board

In our lab, we have several educational kits of little sensor boards. Going through the list of sensors, one caught my eye, as I had never used a sensor like that before: a digital flame sensor:

The sensor does seem to have an infrared photo diode on it (which makes sense for detecting fire) as well as some additional circuitry. Using a trim potentiometer, sensitivity of the device can be set. When the set threshold gets passed, the digital output of the sensor triggers. Using a multimeter, I found out that the sensor uses an active low signal, meaning that when flames are detected, the output goes low, being high when no fire is in sight.

How to Connect the Sensor

I connected the sensor board to 5V, GND as well as one of my own board’s FTDI header pins (brown/yellow/orange servo cable, the other 6-pin cable is just used for programming the ATTiny board):

Since I was not using Serial Communication in this example, I felt free to simply reuse the pins for the sensory input here. The pin I connected to was Pin 0 on the ATTiny44, as by the clockwise notation from this diagram (notice this is used as TX in Neil Gershenfeld’s Software Serial implementation of the t44 Echo firmware, not as in the pinout image where pins 1 and 2 are TX and RX):

How to get Feedback from the Sensor

Since I was not using Serial Communication, I needed some other way of seeing when the sensor triggered. The sensor actually has an LED on board showing exactly that, but nevertheless I went ahead and made my own board’s LED on pin 8 turn on when the ensor output fell low, too (so when it triggered). To avoid any floating pin issues, I also used the ATTiny44’s internal pullup resistor on the input pin so it was pulled high when not actively pulled low by the sensor:

int ledPin = 8;
int flameSensorPin = 0;

void setup() {
  pinMode(ledPin, OUTPUT);
  pinMode(flameSensorPin, INPUT_PULLUP);
}

void loop() {
  digitalWrite(ledPin, !digitalRead(flameSensorPin));
}

Using a lighter I found that the sensor did in fact react to seeing fire:

Following video shows the sensor reacting to the lighter’s flame, reacting by turning on the LED on the sensor PCB as well as the LED on my own board:

Troubleshooting: Changing Sensor Thresholds

Turned out it also reacted to seeing windows though, so it seems to be triggered easily by sunlight, too (pointing it at the large window in following video - I also covered it with my finger to make sure it was the window light triggering it):

Using an electronics screwdriver, I managed to lower the threshold for triggering enough so that the sensor did not get triggered by the windows, mostly, but only by the lighter’s flame:

This was not terribly stable though - and of course this also lowered the sensitivity to flame emitted light. In the end, I would probably not use a sensor like this for anything sensible or make sure that no sunlight would be able to mess with the area detected. TV remote sensors actually have similar problems, which can easily be overcome by signal modulation and demodulation. Whether a flame emits a detectable pattern of radiation though I don’t know.

Just for funsies, I merged the fire detector code with my SOS code, making the board flash SOS whenever fire was detected:

#include <avr/power.h>

int ledPin = 8;
int buttonPin = 7;
int flameSensorPin = 0;

int ditMs = 100;
int dahMs = 3 * ditMs;
int delayBetweenCharacters = 2 * ditMs; //theoretically, this is 3 dit, but 1 dit is already included in the dit and dah functions
int delayBetweenSos = 6 * ditMs;  //theoretically, this is 7 dit, but 1 dit is already included in the dit and dah functions

void setup() {
  clock_prescale_set(0);
  pinMode(ledPin, OUTPUT);
  pinMode(buttonPin, INPUT);
  digitalWrite(buttonPin, HIGH);  //Internal pullup on Button Pin
  pinMode(flameSensorPin, INPUT_PULLUP);
}

void loop() {
  if(digitalRead(flameSensorPin) == LOW){
    sosBlink(ledPin);
    delay(delayBetweenSos);
  }
}

void dit(int blinkPin){
  digitalWrite(blinkPin, HIGH);
  delay(ditMs);
  digitalWrite(blinkPin, LOW);
  delay(ditMs);
}

void dah(int blinkPin){
  digitalWrite(blinkPin, HIGH);
  delay(dahMs);
  digitalWrite(blinkPin, LOW);
  delay(ditMs);
}

void sosBlink(int blinkPin){
  dit(blinkPin);
  dit(blinkPin);
  dit(blinkPin);
  delay(delayBetweenCharacters);
  dah(blinkPin);
  dah(blinkPin);
  dah(blinkPin);
  delay(delayBetweenCharacters);
  dit(blinkPin);
  dit(blinkPin);
  dit(blinkPin);
}

Conclusion

This was a fun little exercise. From my past experience with sensors, I know that there is a vast plethora of different ways to speak to sensors, depending on the type. In my experience, a good first step is to look for existing libraries for sensor boards - if it has a name, chances are it also has a library already programmed for it.

While it can be an interesting exercise (and sometimes needed) to figure out the exact inner workings of a sensor, often times the bulk of the work is already done and a high-level way of talking to the sensor from the Arduino or other boards already exists. It certainly is useful to know how to manually talk to an I2C sensor for example though, just in case one has to work with a new or exotic sensor. In the end, I2C can even be used for simple communication between two micro controller boards, so this should not be overlooked.

Last update: June 24, 2022 15:11:48
Back to top