Dawn Dusk Henhouse Door Controller Instructions

Pictured below is the connection diagram for the Arduino based standard REUK Dawn/Dusk Henhouse Door Controller. This device is sold as shown including the light detector (non-waterproof), but NOT including the rollers switches and motor which you must source yourself. We recommend the following:

Connection Diagram

connection diagram for Arduino based dawn dusk hen house door opener

Choosing a Motor

The choice of motor is particularly important. We favour the high torque low RPM type of motors linked to above because they are very strong, slow moving, and they do not draw a lot of current. Most importantly, if they are prevented from turning, they still draw well under 1 Amp. Other motors may draw only a couple of Amps in normal operation, but if the door becomes jammed (debris, snow, ice, motor or mechanism seizing, etc) then they can draw very high currents which exceed the 10 Amp rating of the components used on this controller. We suggest that a 5 Amp fuse is fitted in the positive line between the 12V battery (or power supply) and the positive Power Input of the controller.
You will have to double check which way the motor turns to open/close the door, and reverse the connections to it from the controller if the motor is turning the wrong way – i.e. trying to open the door at night, or close the door in the morning.

Roller Switches

For the roller switches, pretty much any will do the job electrically, so you just need to ensure that the ones you choose are sturdy enough to operate reliably with the door mechanism you have put together. The switches need to be wired to the controller such that the terminals are shorted out (closed) when the switch is closed, and are open when the switch is open. Most roller switches have three terminals – a COM (common), an NO (normally open), and an NC (normally closed). You need to use the COM (usually found in the centre), and the NO.

Setting the Light Level Threshold

You have one thing to set up – that is the light level threshold at which you consider it to be the point between day and dusk (and therefore the point between night and dawn). This calibration option is only available between connecting the power to the controller and it detecting dusk – i.e. during what it considers to be day time.
To calibrate the light level threshold, press and hold the Light Level Calibration Button. The red and green LEDs will both turn on. When they turn on (after around one second), release the button. Whatever is the measured light level by the light detector at this time will be stored in memory as the light level ‘threshold’. The red and green LEDs will rapidly flash for 10 seconds to let you know that calibration has been successfully completed. From now on, whenever the light level is brighter than this threshold it is ‘day’, and whenever the light level is darker than this threshold it is ‘night’. Obviously you need to go through this process at dusk when the ambient light level is the same as you want it to be when the door is to close. You need to have the light detector in the actual location and orientation it will have in operation.
The light detector is not waterproof and must therefore be protected from rain and also condensation. Ideally face it in a Southerly direction – if it is facing East or West then then ‘dawn’ will be detected late or early respectively.

Using the Door Controller

The controller starts off assuming that it is day time, so you want to start off with the door open. If the light level falls below the threshold you have set, the red LED will turn on. If the light level remains below the threshold continuously for 10 seconds, then the controller will assume that it is now dusk and will run the motor to close the door until the lower roller switch closes. The controller will then sleep for 2 hours to avoid a false dawn detection if the sun brightens up as it gets close to the horizon (as it often seems to do). During this time the red and green LEDs will blink so you know what is happening.
When the controller finishes sleeping, the ambient light level will be much lower (since it will be 2 hours further into the evening). The light detector will then wait until dawn. When the measured light level exceeds the threshold, the green LED will turn on. If the measured light level remains higher than the threshold continuously for 10 seconds, the controller will assume it is now dawn and run the motor to open the door until the upper roller switch closes. Again the controller will sleep for 2 hours to avoid false dusk detections.
This process will repeat every day.

Further Information

If you have any questions about the connection, setup, and use of this controller, email neil@reuk.co.uk.

Arduino Thermostat with Full Code

We are often requested to build simple thermostats – devices to turn something on or off depending on a measured temperature. Pictured below is an example of one such thermostat we made recently using an Arduino Pro Mini.

arduino thermostat

This particular thermostat was designed to keep a 12V 2A output turned on unless the temperature measured on a waterproof DS18B20 digital temperature sensor reaches above 80°C. The output must then remain off until the measured temperature has fallen to below 70°C.

The thermostat was designed to control a low voltage pump, turning it off if the water in a hot water tank fed by a solar water heating panel gets to be too hot. The 10°C temperature difference between the turn off and turn back on temperatures is hysteresis to prevent the pump being turned on and off rapidly multiple times.

In the image above a MOSFET is used to switch the small pump on and off, but typically a relay would be used in most pump controlling thermostats so that high currents and high voltages can be switched by the low voltage powered thermostat. Therefore, in the Arduino sketch, all references are to a relay. The relay will need to be connected to the relevant Arduino pin via an NPN transistor.

Here is a poorly drawn and badly photographed circuit diagram of the thermostatic relay controller. Click on the image to view it in larger size.

circuit diagram for arduino thermostat relay controller

We used an Arduino Pro Mini because of its small size and price, but any Arduino board could be used for this type of controller.

While the Arduino Pro Mini has an on board 5V regulator, we prefer to use an external low drop 5V regulator (lp2950cz-5.0) because they are much more robust and will cope with higher input voltages – for example 12V batteries while they are being heavily charged.

The red LED shown on the circuit board at the top of this page is not used in this project.

Here is the full sketch (source code) for this thermostat

 * REUK.co.uk - 2017
 * This is a thermostat which will keep a relay closed
 * until the temperature measured reaches 80 degrees C, and then will then
 * then re-close the relay only when the temperature falls to 70 degres or below.

// For the temperature sensors
#include <OneWire.h>
#include <DallasTemperature.h>
// Data wire plugged into pin 3 on the arduino
#define ONE_WIRE_BUS 3

// Setup a oneWire instance to communicate with any OneWire devices (not just Maxim/Dallas temperature ICs)
OneWire oneWire(ONE_WIRE_BUS);

// Pass our oneWire reference to Dallas Temperature. 
DallasTemperature sensor1(&oneWire);

const int relay = 5;

// Fixed temperature thresholds - turn off output at >80C, and turn back on again when <70C
const float onTemp = 70.0;
const float offTemp = 80.0;

// Keep track of whether the relay is energised/closed (1) or open (0). Start with closed (1).
int relayStatus = 1;

void setup(void)
 // Start up the library
 //set the resolution to 10 bit ADC
 // Set up the relay output for the arduino, and start with it high
 // since the thermostat only turns off at >offTemp degrees.
 pinMode(relay, OUTPUT);
 digitalWrite(relay, HIGH);

void loop(void)
 // Read in the temperature of the sensor
 sensor1.requestTemperatures(); // Read temperature of sensor1
 float sensorOneTemperature = sensor1.getTempCByIndex(0);

if(relayStatus == 1 and sensorOneTemperature >= offTemp-0.00001){
 // Relay is currently closed, but the temperature exceeds offTemp - therefore open the relay
 digitalWrite(relay, LOW);
 // Remember the new status
 relayStatus = 0;

if(relayStatus == 0 and sensorOneTemperature <= onTemp+0.00001){
 // Relay is currently open from a previous high temperature event, but now the temperature 
 // is below the threshold so close it again
 digitalWrite(relay, HIGH);
 // Remember the new status
 relayStatus = 1;

// Wait 1/10th of a second before we measure the temperature again.

Testing Arduino Low Power Library with Pro Mini

In general when using an Arduino Pro Mini in one of our projects or products, we use an external LP2940CZ-5.0 voltage regulator instead of the on board regulator. This is because most things we make are for 12V battery systems, and the voltage from a 12V battery can get to well over 12V which is the specified upper input voltage for a Pro Mini. We have measured that one of these regulators with a 10uF capacitor across its 5.0V output, draws a quiescent current of only 0.079mA.

We have found that an Arduino Pro Mini, whether powered as described above, or with the on board regulator draws around 20mA @ 12.0V. This is very high for an always on battery powered device – it will use 500mAh (0.5Ah) of battery charge per day. Therefore, we are always interested in testing ways to minimise power consumption.

breadboard test of low power library for arduino pro mini

We set up the above test circuit with a 12V input, and our usual LM2940CT-5.0 regulator connected to an Arduino Pro Mini (16MHz / 5V). With a sketch containing just delay(8000); in the loop() function – i.e. the Arduino will wait 8 seconds, then wait another 8 seconds, then wait another 8 seconds, etc – we measured a current draw of 19.793mA @ 12.0V input voltage.

We downloaded and installed the following Lightweight low power library for Arduino – LowPower.h, and modified our test sketch as shown below to power down the microcontroller for 8 seconds within the loop.


This time we measured the current draw to be just 6.265mA @ 12.0V input voltage – a huge reduction of around 70% power consumption obtainable just by replacing the delay function with the powerDown function from the LowPower library.

We make a lot of dataloggers and monitoring devices which spend most of their time doing nothing – just waiting to take the next measurement. Therefore this low power library is a quick and easy way to reduce power consumption.

(Note that 8 seconds is the maximum power down duration that can be set with this library, but by using loops of multiple 8 second intervals in your sketches, you can create a low power consumption delay of as long as you want.)

A standalone arduino in a low power consumption circuitIf you use a Standalone Arduino on a breadboard directly powered by a battery pack of the correct voltage (i.e. no voltage regulation required), it is possible to run your Arduino off less than 50uA @5V (<1000th the power consumption of our tests above) and therefore power something for years with a AA cells or smaller. See here for an excellent article How to Run An Arduino For Years on a Battery from the Open Home Automation website where they use the JeeLib low power library with a standalone Arduino.

Picaxe Based Dual One Shot Timer Relay with Code

Pictured below is a simple timer relay circuit we recently made which we will detail here together with the source code for the microcontroller since we have had many requests for example code for timers of this type.

Two option one shot timer relay circuit - PICAXEWe received a request for a timer with two buttons. Pressing the first button was to cause a relay to close for 10 minutes, and pressing the second button was to cause the relay to close for 30 minutes. The relay was to be used to switch a mains powered appliance.

In our article Make a PICAXE Repeating Timer, we show how to make a repeating on/off timer using a PICAXE microcontroller. The timer pictured above differs in that it has button inputs to deal with and also a one-shot instead of repeating timer.

The red LED is used to show which timer is running – off, but flickering on briefly once per second is the 10 minute timer; on, but flickering off briefly once per second is the 30 minute timer. The green LED is connected across the coil of the relay (with a current limiting resistor) to show when the relay is closed.

The PICAXE code below could be greatly reduced in length but to keep it simple to read through, understand, and adapt, we have left it with separate functions for the 10 minute and the 30 minute timers (instead of making one general function which could run for any duration in response to any button press).

symbol button1 = pinC.1
symbol button2 = pinC.2
symbol led = C.0
symbol relay = C.4

' Start with the relay open and the red LED turned off.
low relay
low led

   if button1 = 1 then goto run10minutes
   if button2 = 1 then goto run30minutes
   pause 100
   goto main

   'make sure button is held a little before closing the relay,
   high led
   for b0 = 1 to 5
      delay 50
      if button1 = 0 then 
         low led
         goto main
   next b0

   'Close the the relay
   high relay 

   'wait for the button to be released.
      pause 50
   loop while button1 = 1

   low led

   for b0 = 1 to 10 'minutes
      for b1 = 1 to 60 'seconds
         high led
         pause 100
         low led
         pause 900
      next b1
   next b0

   'Open the relay.
   low relay

   goto main

   'make sure button is held a little before closing the relay,
   high led
   for b0 = 1 to 5
      delay 50
      if button2 = 0 then 
         low led
         goto main
   next b0

   'Close the the relay
   high relay 

   'wait for the button to be released.
      pause 50
   loop while button2 = 1

   low led

   for b0 = 1 to 30 'minutes
      for b1 = 1 to 60 'seconds
         high led
         pause 900
         low led
         pause 100
      next b1
   next b0

   'Open the relay.
   low relay

   goto main


Saving Arduino Collected Data to Text File on Windows

We are often asked how to log data from an Arduino to a text file saved on a Windows PC. This is very simple with Linux and Mac OS, but it can be also be achieved on Windows with minimal effort.

We make a lot of dataloggers, the majority of which either store data internally and then output a summary to an LCD display, or dump all collected data to an SD card for later processing and analysis on a PC. However, it is relatively simple to collect data from any number of sensors connected to an Arduino board and send that data over a serial connection directly to a text file on a PC.

There are many software options available, but we typically use CoolTerm (available free of charge here: download CoolTerm) which is a serial monitor which will also capture transmitted data to a text file and automatically add time stamps to each line of data which are essential for a good datalogger.

As an example we slightly modified the code for our 2016 solar water heating pump controller so that every time data is taken from the two connected digital temperature sensors, those measurements and also the system status (pump ON or OFF) are output through the serial port to a connected PC. (Full details on generating Serial output from an Arduino are available here: Arduino Serial from the official Arduino Reference site.)

Download CoolTerm from the link already provided above. You will end up with an approximately 10MB zip file which needs to be extracted. When that is done, go into the folder created, and double click on the CoolTerm application.

Launch CoolTerm applicationClick on Connection > Options and then in Serial Port Options select the Port you would like to use. If you are using the Arduino IDE, in the bottom right hand corner of the window will be shown the type of board you are using followed by COM# where # is the number of the port your Arduino is currently set up to use and is also the port you should select within CoolTerm).

Selecting the serial COM port to use with CoolTerm with ArduinoAt the same time set the baudrate to 9600 (making sure that in the sketch you have uploaded to your Arduino, you have also included Serial.begin(9600); in the setup() function.

CoolTerm connection options

Assuming that you would like all data to be timestamped (adding the date and time to every line of data sent), do Connection > Options > Receive and check the ‘Add timestamps to received data’ box.

timestamp serial data from Arduino and store in text file on PC

Then to have any serial data from your Arduino automatically stored in a text file on the PC, do Connection > Capture to Text File and then click on Start. You then just have to set the name for the file that you would like your data to be stored in, and your datalogger is complete.

arduino coolterm serial monitor showing arduino collected data

To stop collecting data, you can either click on the large Disconnect icon, or if you want to stay connected to the Arduino board, do Connection > Capture to Text File > Stop.

Once you have either disconnected the Arduino board or Stopped the capture, you cannot then restart and append data to the same file – you can only overwrite the original file or start a new one. If you want to pause capture and then restart it to append to the same file, do Connection > Capture to Text File > Pause to pause, and then Connection > Capture to Text File > Resume to resume it at a later time.

Data collected from solar pump controller from Arduino via Serial and CoolTerm to PC

When you have finished capturing data, you will end up with a text file of everything captured which can be processed and visualised using Excel or a similar application.

Testing Accuracy of micro:bit Internal Clock

At REUK.co.uk we make a lot of timers for a wide range of different applications. Most projects only call for a timer to be accurate to within around 10 seconds per hour. For those that require greater accuracy, we sometimes use a real time clock such as the DS3231, and other times (when the microcontroller we are using is inaccurate but CONSISTENTLY inaccurate) we just calibrate the timer against a previously tested and known accurate timer.

While having a first play around with MicroPython on the micro:bit, we ran a few one minute tests of the accuracy of the internal clock. When hand timing with a stopwatch we consistently found that one micro:bit minute was actually around 59.85 seconds. That is of course very close to the 60.00 seconds of a true minute and the error could well have been due to human error with the stopwatch, but it did appear that our micro:bit was running a little fast (since its ‘minute’ was finishing quicker than a true minute). Being 0.15 seconds fast every minute may not sound a lot, but it equates to the internal clock being minutes fast per day. Had the timing appeared to be a tiny bit slow, it could just have been that there was a delay due to the time taken for the micro:bit to do internal processing etc, but as the timings appeared to be fast, they must actually be fast.

In order to test this properly, we connected a relay via a transistor to one of the digital output pins of the micro:bit. The NO and COM terminals of this relay were in turn connected in parallel across the contacts of the start/stop button on a previously cannibalised stopwatch. We then wrote a small MicroPython script to briefly set the output pin to digital HIGH to start the stop watch, and then after 10 minutes sleep(600000) – i.e. sleep for 600,000 milliseconds, 600 seconds, 10 minutes – again briefly set the pin high to stop the stopwatch.

testing the micro:bit internal clock accuracy

Running this test ten times and averaging the results we found that the micro:bit ten minutes was actually 9 minutes, 58.51 seconds (598.51 seconds instead of 600.00). The timings were very consistent with the shortest and longest measured times both being just 0.03 seconds away from the average – a tight range of 9m58.48s to 9m58.54s measured over the ten ten minute periods.

Looking at the average time, 9 minutes 58.51 seconds is 0.248% faster than 10 minutes. Being 0.248% fast is not a big deal when timing events lasting seconds or a couple of minutes, but over the course of a 24 hour period, our micro:bit would gain 215 seconds, or over 3.5 minutes which is not insignificant.

The consistency we had found in the inaccuracy was a very good sign. It made manual calibration of our micro:bit a possibility so that we would forever know (at least if timing accuracy is not significantly affected by changes in ambient temperature or input voltage) that this particular micro:bit’s clock could be trusted without the need for an external real time clock (RTC).

The Python command we used to get the micro:bit to sleep for one second was sleep(1000). Apparently with our micro:bit this resulted in it sleeping for a little less than one true second, therefore we needed to increase the sleep time by the 0.248% that the internal clock was now known to be fast. It would be nice to use the command sleep(1002.4833), but unfortunately it is only possible to use a whole number (integer) value – i.e. sleep(1002) or sleep(1003). Either of these approximations would make times measured by our micro:bit 5 times more accurate, but that is still around 45 seconds too fast per 24 hours – not good enough.

Therefore, when we want to time long intervals – hours and days – we need to sleep for longer intervals such as sleep(601489.98) corresponding to 10 minutes to increase the accuracy possible. Luckily enough 601489.98 is almost exactly 601490 micro:bit measured milliseconds. So, in any projects which require us to measure long time periods with our micro:bit, we will count the number of our pre-calibrated 10 minute intervals have passed measured with sleep(601490). Now calibrated, our micro:bit should certainly be accurate enough for a wide range of future long duration projects.

The timing accuracy we found for our micro:bit before calibration was 25 ppm (parts per million) which compares favourably with the typical 50 ppm found with Arduino boards, and we found the consistency in timing inaccuracy to be better with micro:bit than we have previously found with Arduino. However, we could have been lucky or unlucky with our particular micro:bit board. We will need to repeat our experimentation with multiple micro:bits to find the typical timing accuracy of micro:bits in general in the future.

micro:bit Battery Capacity

In our recent blog post: micro:bit Power Consumption, we look at how much power the micro:bit draws at different input voltages while idle, illuminating the full array of 25 LEDs, or with the processor operating at 100% load carrying out calculations. In this post, we will look at how this power consumption relates to battery life.

The micro:bit is supplied with a 2xAAA battery holder. Assuming that the majority of users will put a pair of good quality alkaline cells into this battery holder for powering their micro:bit projects, we will use 3 Volts as the input voltage in the calculations to follow. Good alkaline cells start off at just over 1.5 Volts and maintain this voltage until it begins to drop off only when the cells are almost depleted of charge. (The calculations would be quite different if rechargeable NiMH cells were to be used for example since with an input voltage of 2.4-2.5V, the power consumption is notably lower.)

Referring to the table of power consumption results (available in the post linked to at the top of this post), with 3 Volts on the input we saw the following:

microbit power consumption with a 3V input voltagei.e. at idle (minimal processing and no LEDs on), power consumption is just 5.83mW, but with the processor working at 100% and all of the LEDs on, power consumption is over 43mW.

Good quality AAA cells typical hold a charge of somewhere from 800-1000mAh, AA cells from 1800-2400mAh. There are higher capacity cells available, but these are usually optimised for use with digital cameras and similar supplying high current briefly each time a picture is taken rather than the steady state constant low current typical for a micro:bit project. They also tend to be much more expensive.

battery life testing with micro:bitThe table above takes the power consumption data previously measured with a 3 Volt input voltage and shows for how many days the battery pack will last for a wide selection of different capacities. For example, if you had a processor intensive project which made use of all or nearly all of the LEDs at once, and a pair of 1000mAh Duracell Plus AAA cells, you could expect to get approximately 3 days of battery life. If on the other hand you had a project which was not processor intensive, did not make use of the LEDs, and used a pair of 2400mAh AA cells, you could expect around 50 days of battery life.

There are many factors above which will affect the real world battery life including the ambient temperature, the specific features of the project to be built, and of course any additional components, sensors, or devices to be powered at the same time as the micro:bit. However, it will hopefully give you a pretty accurate idea of what to expect and to inform your choices when you are choosing how to power your project.

Bookmark microbit.me.uk to view all our previous and future micro:bit related articles.

micro:bit Power Consumption

Having finally managed to obtain a micro:bit, the first thing we wanted to test was the power consumption at different input voltages.

The micro:bit is supplied as a kit together with a 2xAAA battery holder which plugs into the micro:bit, two cheap generic AAA cells, and a USB cable for connecting the micro:bit to a PC to upload your code to it (and which can also be used to power the micro:bit via the onboard voltage regulator).

The input voltage for micro:bit is labelled as 3 Volts. Alkaline AAA cells such as those offered by Duracell supply around 1.5-1.7 Volts each when fully charged. Rechargeable NiMH cells, something around 1.25 Volts. Therefore, since the micro:bit is designed to be battery powered by TWO AAA cells, it must be able to operate reliably from a wide range of input voltage – e.g. just 2V from a pair of depleted rechargeable NiMH cells, up to at least 3.4V to cope with a pair of brand new out of the box Duracell cells.

In order to test power consumption, we used the Microsoft Block Editor (available for use at the official micro:bit website) to build a simple project as shown below. Click on the image to see it in full size.

Power testing the micro:bit

This will first turn off all of the LEDs in the 25 LED array so the micro:bit is not doing anything apart from background processing. If the A button on the micro:bit is then pressed, all LEDs will light up and remain on for five seconds. If the B button is pressed, the processor of the micro:bit will be worked hard by generating 233,000 random numbers. (The reason that 233,000 was chosen was that it took the micro:bit 10 seconds to complete that many iterations of the loop, and that gave the time necessary to reliably measure the minimum and maximum current drawn by the micro:bit while under this heavy load).

Powering the micro:bit from a variable DC power supply starting down at 1.5V, the voltage was increased until it was sufficient to have the LEDs turn on. We found this voltage to be at around 1.80V. We then tested different input voltages from around 1.8V up to just over 4.0V in 0.2V steps with the micro:bit either resting, with all the LEDs on, and then with it doing repeated random number generation.

We found that the current draw fluctuated constantly (by around 1mA), probably due to the internal workings of the micro:bit which we have not yet studied in detail. We found that in all three tests for all input voltages, there was a minimum current, a maximum current, but the typical current draw was found to be around one-third of the way between the minimum and maximum. We called this the mean (average) for this rough and ready set of experiments and the final table of results is given below.

results of micro:bit power consumption experimentsEach row in the table shows a different input voltage. The Resting (Idle) Mean, LEDs Mean, and Working Mean have been described in the previous paragraph. P(Resting), P(LEDs), and P(Working) are calculated using Ohm’s Law that Power equals Current multiplied by Voltage.

It is immediately apparent the massive effect that input voltage has on total power consumption. At 1.83V input voltage with all the LEDs on, only 3.76mW is consumed, but with an input voltage of 4V, 78.7mW is consumed – 21x as much power. Even with input voltages of 3V and 2.4V (typical alkaline and NiMH rechargeable voltages respectively) the power consumption is 31mW compared to 14mW – more than twice as much. Therefore, unless you need the LEDs to be very bright, it is better (if power consumption is important to you) to use a low input voltage, or to use the built in PWM to reduce the brightness of the LEDs and therefore their power consumption.

For projects not requiring the LEDs, the power consumption is not so affected by input voltage. At idle, approximately twice as much power is consumed at 4V as it is at 1.8V. Under heavy load, more than three times as much power is consumed at 4V compared to 1.8V. Therefore, if the LEDs are not required, it is more power efficient to use a good voltage regulator to bring the input battery voltage down to around 2V than it is to just run the micro:bit at the battery voltage. Important things to consider if you intend to power your micro:bit by solar power or some other limited power source.

Finally we noted that the 10 seconds it took the micro:bit to generate 233,000 random numbers in our experimentation was completely unaffected by changes to the input voltage – i.e. it took 10.0 seconds with an input voltage of 1.83V and still took 10.0 seconds with 4.05V. Again this shows that where the LEDs are not being used, a low input voltage is the way to go if you need to minimise power consumption.

Bookmark microbit.me.uk to view all our previous and future micro:bit related articles.

micro:bit Arrives at REUK

After a long wait we have finally got our hands on a micro:bit, the fully programmable pocket-sized computer which will be given free of charge to every year 7 child across the whole of the UK – a total of one million units to be distributed by the BBC in partnership with a wide selection of commercial partners.

BBC micro:bit

BBC micro:bit LED array and buttons

We have many plans for our micro:bit, starting off looking at its power consumption and the practicalities of powering it with a PV solar panel. We will then move on to show how a micro:bit can be used with a range of renewable energy based systems, home automation, and other useful projects.

We will also be publishing (free of charge and in full detail) how a micro:bit (with a few additional external components) can be used to reproduce the functionality of all of the microcontroller and Arduino based products which we currently sell in our REUK Store, including our popular solar water heating pump controllers, battery monitoring devices, programmable timers, and more.

Bookmark microbit.me.uk to view all our previous and future micro:bit related articles.

Using the Buttons on a TM1638 Module with Arduino

Following on from our recent blog post on using the 8-digit 7-segment display on TM1638 modules with Arduino, here we will look at taking advantage of the eight push buttons on a TM1638 module (labelled S1 to S8 in the photograph below). Click here to buy TM1638 modules for under £2 delivered.

The array of 8 user input buttons on a TM1638 module - used with ArduinoThe tm1638 library for Arduino has a function getButtons():

byte buttons=module.getButtons();

…which returns an 8-bit byte value which tells you which of the eight buttons are currently being pressed.

Press the left most button S1, buttons returns 1, press S2 and get 2, press S3 and get 4, press S4 and get 8, S5=16, S6=32, S7=64, and S8 returns 128. Pressing multiple buttons at the same time results in buttons having a value equal to the sum of the values for the individual buttons being pressed – e.g. press S1 and S2 simultaneously and the value of buttons will be 1+2=3.

If only one button is being pressed at a time, then you can easily test for it – e.g. if buttons is equal to 64, we know that button S7 is being pressed; but if S7 is pressed simultaneously with another button, the returned value of buttons will not be equal to 64, and without doing some messy calculations, we cannot know which other button(s) have been pressed.

Here is the code required to display the 0-255 value of buttons on the LED display of the TM1638 corresponding to the button(s) currently being pressed.


We know that the value of buttons is always a number between 0 to 255 – an 8-bit byte. Knowing that 1 = 00000001, 2 = 00000010, 4 = 00000100, 8 = 00001000 etc in binary, we can simply examine the bits of the byte, and where we find 1s, we know that the button corresponding to that bit is being pressed.

If S1 and S3 are pressed simultaneously for example, module.getButtons() will return the value 4+1 = 5 which is 00000101 in binary. The bit furthest to the right (the least significant bit) corresponds to S1, the second from the right to S2, the third from the right to S3, and so on. 0 indicates not pressed, and 1 indicates pressed.

With Arduino we have the handy function getBit(x, n) where x is the byte to be examined, and n is the position of the bit within that byte to be checked – 1 for the least significant bit to the right, and increasing as we move left to the more significant bits.

(Note that as the 8 LEDs on the TM1638 are controlled using an 8-bit byte also, if you get the value of the byte buttons=module.getButtons(), you can illuminate the corresponding LEDs with module.setLEDs(buttons). For example, module.setLEDs(1) will illuminate the first (left most) LED, module.setLEDs(128) will illuminate the last (right most) LED. With this code, whichever button(s) are pressed, the corresponding LEDs will all light up simultaneously.)

Below is an example Arduino sketch we have written to show how the TM1638 buttons can be tested individually to see if they are currently being pressed. The function we have written isButtonBeingPressed(buttonNumber) is used to test if a particular button (from 1 to 8) is currently being pressed. Knowing that button is being pressed can be used for user inputs to control your projects.

 * REUK.co.uk - February 2016
 * Useful function to test if one of the eight user input buttons
 * on a TM1638 module is currently being pressed.

// The byte buttons is the value returned by the TM1638 to indicate
// which buttons are currently being pressed.
byte buttons;

#include <TM1638.h>

// define a module on data pin 8, clock pin 9 and strobe pin 7
TM1638 module(8, 9, 7);

void setup(){}

void loop(){
 // The buttons S1 to S8 have the following values:
 // S1 = 1, S2 = 2, S3 = 4, S4 = 8, S5 = 16, S6 = 32, S7 = 64, S8 = 128
 // If multiple buttons are pressed simultaneously, add their values together.

 // DEMONSTRATION - Loop through the 8 buttons, testing each to see if it is
 // currently being pressed. If a button is being pressed, show its number (1-8)
 // on the LED display...Leave it displayed until a different button is pressed.
 for(int buttonToTest = 1; buttonToTest < 9; buttonToTest++){
   // Let the TM1638 process the button inputs
   buttons = module.getButtons();
     // This button (buttonToTest) has been found to be pressed, so display it's number S1-S8
     module.setDisplayToDecNumber(buttonToTest, 0, false);

// This function will return true if a particular button n is currently being pressed.
boolean isButtonBeingPressed(int n){
 // Button 1 status shown by bit0 of the byte buttons returned by module.getButtons()
 // Button 2 status shown by bit1 or the byte buttons ...
 // Button 3 status shown by bit2...etc

 // n - the number of the button to be tested) should be an integer from 1 to 8
 if(n < 1 or n > 8) return false;

 // Read in the value of getButtons from the TM1638 module.
 buttons = module.getButtons();

 // Which bit must we test for this button?
 int bitToLookAt = n - 1;

 // Read the value of the bit - either a 1 for button pressed, or 0 for not pressed.
 byte theValueOfTheBit = bitRead(buttons, bitToLookAt);

 // If the button is pressed, return true, otherwise return false.
 if(theValueOfTheBit == 1) 
   return true;
   return false;