Making a case for Gyro’clock

I officially finished all my school work since last week and finally had some time to think about my projects. There are two projects I started a while ago that I would like to finish off first. They are the Smart Turn project and the Gyro’clock project.

The only big thing left to do for the Gyro’clock is to make a case for it.  This means that I am finally getting around to the 3D print scene. This is exciting because I am going to be learning a new trick that has lots of potential. But first I have to learn about making 3D models.

There are many software programs out there for making 3D designs. After some search I decided to go with FreeCAD mainly because it is fairly sophisticated. After spending some time playing around with it and watching some tutorials I am able to find my way around it.

My approach for designing a case was to import the board layout that I have already created in KiCad and then build a simple case around it. Importing a 3D model of a PCB designed in KiCad to FreeCAD is quite simple. But the problem is I didn’t have 3D models for all the components in my Gyro’clock PCB. Importing 3D models from FreeCAD to KiCad is not that straight forward since KiCad only accepts a certain kind of .wrl files only.

After doing a bit of search online I found a nice tutorial that explains step by step how to create 3D models for PCB components. The steps I followed to make 3D models for components in KiCad are

  1. Design the 3D model in FreeCAD
  2. Export the 3D model as a .stl (stereolithography) file
  3. Import the .stl file to Wings3D
  4. Add colour to the model
  5. Export the model as WRML 2.0 (.wrl) file
  6. Import the .wrl file to KiCad
  7. Scale and position as necessary

Here’s the complete 3D model of the Gyro’clock board:


3D model of Gyro’clock board

After completing the 3D model of the board I imported it to FreeCAD. The case has two pieces. The bottom piece wraps around the board and holds the rechargeable Li-poly battery. The top piece is just a cover and snaps on to the bottom piece.


Bottom piece of the Gyro’clock case holding the PCB and the Li-poly battery


The top piece snaps on to the bottom piece

Designing the case in FreeCAD is just a matter of knowing the proper dimensions. Since I had a life size model of a fully assembled Gyro’clock PCB it was really easy. Of course I don’t know how well it will come out of the 3D printer yet. Since this is going to be my first 3D experiment I am not going to go super fancy.

Speaking of 3D printers I have already ordered one and waiting for it to arrive. It is a Reprap Prusa I3 3D printer kit and I found it on for $420 (CAD). It is a DIY kit so it comes with more fun.

Asset Monitor

For the past three months I have been working on a school project. It is called an Asset Monitor. The Asset Monitor allows you to monitor your assets remotely through a smart phone.

The Asset Monitor consists of a network of Asset sensors that monitor the status of assets for motion and temperature. A central controller records all the data sent by all the Asset sensors, and forwards critical messages to the user’s mobile phone. Figure 1 shows an overview of the Asset Monitor.


Figure 1: Asset Monitor overview

The Asset Monitor has four major components:

  • Asset sensors
  • Controller
  • Google Cloud Messaging server
  • Asset mobile app

Asset sensor

An Asset sensor is a small battery powered device that is attached to the asset to be monitored. It monitors the asset for motion and temperature, and reports data to the controller periodically and in case of an event. The communication between the Asset sensor and controller is done using Bluetooth Low Energy (BLE).

BLE is a low power version of classic Bluetooth that is designed for low power applications such as battery powered sensors. The Asset sensors for our project are developed using the BLE121LR modules from Bluegiga. The BLE121LR module is built around the TI CC2541 microcontroller. The BLE functionality for the BLE121LR is already implemented by the BLuegiga software stack, and Bluegiga has also developed a scripting language called BGScript to program the modules. The main components of an Asset sensor are:

  • BLE121LR Bluetooth Low Energy module
  • MMA8452Q accelerometer
  • CR2032 coin cell battery
  • Push button

Figure 2 shows the prototype of an Asset sensor I have created.

IMG007 - Copy

Figure 2: Prototype of an Asset sensor

The motion detection is done using the MMA8452Q accelerometer. This accelerometer has a built-in motion detection capability, which can generate an interrupt signal when the acceleration exceeds a given threshold. This relieves the host processor from having to constantly poll the accelerometer for acceleration. The BLE121LR interfaces to the accelerometer using the IIC interface. Figure 3 shows a schematic of the Asset sensor prototype.


Figure 3: The schematic of Asset sensor prototype

The BLE121LR module has a built-in analog temperature sensor that can be used for temperature sensing. BLE121LR has a dedicated ADC channel to read the output of the temperature sensor. BLE121LR also has the capability to monitor its battery voltage. This is also done using the internal ADC.

Asset sensor firmware

The Asset sensor firmware is designed as a state machine. It can be in any one of five states at any given time as shown in Figure 4.

Asset sensor state machine

Figure 4: Asset sensor state machine

Asset sensor spends much of its time in the Idle state; the state that consumes the least amount of energy. To join a sensor to the Asset sensor network, it must be put on the Network Join state. This can be achieved by doing a two-button press (pressing the button twice within one second). Once joined to the network the sensor will wake up every second and increments a counter. If the counter matches the reporting interval (15 minutes), the device will read the temperature and battery voltage and enters the Report state, where it reports the data to the controller.

The Asset sensor firmware also supports message routing, which allows a sensor to act as a relay between another sensor and the controller. To join a sensor to the network through a relaying-sensor (parent device), first the joining-sensor (child device) must be put on the Network Join state. Then the parent device must be put on the Add child state by issuing a four-button press command. During the Add child state the parent device will automatically find and add the child device to the network.

Each sensor can support up to seven child devices. When one or more child devices are added to a sensor, it switches between the Scan and Idle states every second with a 10% duty cycle.  During the Scan state, the parent device is able to accept messages from a child device.

Figure 5 shows the packet structure used by an Asset sensor to report data to the controller or a parent device.

Advertisement packet

Figure 5: The advertisement packet used by an Asset sensor to report data

The type of packet used is a BLE broadcast packet, which is also called an advertisement packet. The firmware modifies the payload section of the advertisement packet to include battery voltage, motion status and temperature data. The device address helps the controller distinguish the data belonging to a child device from that of a parent device. A message id is added to help the controller eliminate duplicate messages. The advertisement packet can contain up to 37 bytes of data and can be easily extended to add additional parameters if necessary.

Motion detection

The flow chart in Figure 6 shows the steps used to configure the MMA8452Q accelerometer for motion detection.

Accel config flow chart

Figure 6: Flow chart for configuring the MMA8452Q for motion detection

Motion detection is configured on all three axes (x, y & z) of the accelerometer. The threshold is set to be just above ±1 g such that motion will not be triggered simply due to gravitational acceleration. The interrupt functionality of MMA8452Q is used to avoid the need for excessive polling by the CC2541 to check if motion is detected. In the interrupt mode, the accelerometer will generate an interrupt signal whenever the acceleration exceeds the set threshold value. The interrupt signal wakes up the CC2541 microcontroller so that it can report the motion detected event to the controller.

The motion de-bounce interval of 50 ms eliminates spurious detections due to noise. Once the CC2541 receives an interrupt signal from the accelerometer, it reads the motion threshold register of the accelerometer to clear the interrupt status. Three seconds after reporting the motion detected status to the controller, and if no other motion interrupts are received by the CC2541, then a no motion status is reported to the controller.

Temperature sensing

The temperature sensing ability of the Asset sensor is utilized from the built-in temperature sensor of the CC2541 microcontroller. The analog temperature sensor of the CC2541 is capable of monitoring temperature across the full operating range of the BLE121LR module (-40ºC to +85ºC). The temperature sensor outputs a voltage proportional to the temperature, which is read by the internal ADC of the CC2541. The sensor does not calculate the temperature with the ADC value, rather it sends the ADC result to the controller, and the controller performs the conversion from the voltage to the temperature in Celsius.

Battery voltage detection

In addition to motion status and temperature, the sensor also monitors its battery voltage level and reports to the controller. This allows the user to know when the battery needs to be replaced. Battery voltage detection is performed similar to the temperature detection. The CC2541 internal ADC has a dedicated channel for reading the battery voltage.

The Asset sensor is powered by a CR2032 coin cell battery. This battery has a capacity of 240 mAh and is rated for +3 V. However, when the battery is loaded with a circuit, the maximum voltage output of a new battery drops to around 2.65 V. When the battery is near the end of its life the output voltage drops to 2 V. The sensor reads and reports its battery voltage to the controller every 15 minutes.


The controller is the most critical component of the Asset Monitoring system since all messages from the Asset sensors must pass through the controller. This section provides an overview of the controller, its functionality and implementation. The main roles of the controller are to

  • Create and manage a network of Asset sensors
  • Record messages sent by all Asset sensors
  • Promptly alert the user of all critical messages

In order to carry out its duties the controller must have the following three key requirements:

  • Must support Bluetooth Low Energy
  • Must be connected to the internet
  • Must have a display for user interaction

For our project we used an old cell phone as a controller since it supports all three requirements above and can be easily programmed. A laptop, a desktop PC or a Raspberry Pi are all suitable choices for a controller. Figure 7 shows the cell phone that is used as the controller for the Asset Monitor.


Figure 7: A mobile phone is used as the controller since it has BLE and Wi-Fi

The controller application is simply an Android mobile phone application developed using Android Studio development environment. The controller must be connected to a Wi-Fi network with internet access. The controller application keeps the CPU of the phone awake at all times. Therefore, the controller must be connected to a power outlet through an adapter to provide a constant source of power.

Figure 8 shows the controller application window with two sensors connected to the network.


Figure 8: The controller application showing two sensors added to the network

The controller application allows the user to add sensors to the Asset Monitor network. When a sensor is successfully added to the network, it will appears as an item in the sensor list as shown in Figure 8. For each sensor, the controller displays the most recent data received from the sensor including temperature, motion status, battery status and the time of last report.

Controller software

The controller application must continuously listen for messages from child devices, since a sensor may report a critical message at any time. Before the controller is able to join devices to its network it must configure the Bluetooth LE adapter and register itself with the Google Cloud Messaging server. Figure 9 shows the initial configuration steps carried out by the controller application.

Asset controller startup

Figure 9: Flow chart showing the initial configuration steps of the controller application

After the Bluetooth LE adapter is configured, the controller app connects to the BLE service, a process that runs in the background, which provides BLE functionality to the app. Then the app registers itself with the Google Cloud Messaging (GCM) server and obtains a registration token. This step allows the controller to receive status update requests from the Asset mobile app. More information about GCM will be covered in the Google Cloud Messaging section.

The final configuration step is to start a repeating timer that periodically checks to see if the connected sensors are sending reports at regular intervals. If the controller has not received a message from a sensor within 17 minutes from the last report, an alert message is sent to the Asset mobile app. Once the initial configuration is complete the app simply waits for user to add sensors to the network.

User can add sensors to the network by clicking the Add Device button in the controller app. Figure 10 shows a flow chart of the process of joining a sensor to the network.

Add device flow chart

Figure 10: The flow chart for adding a device to the Asset sensor network

When the Add Device button is pressed, the controller app scans for network joinable Asset sensors and creates a list, which is presented to the user after the scan timeout occurs. The user selects a device for joining from the scan results list. Then the controller temporarily establishes a connection with the device, which indicates to the device that it has been added to the controller’s network. The sensor records the Bluetooth MAC address of the controller as the address of its parent. Afterwards the controller disconnects from the device and starts scanning for data reporting messages from the sensors.

When one or more sensors are joined to the controller, the controller begins to scan for messages from the sensors. Figure 11 shows the flow chart for scanning messages from connected sensors.

Asset controller scan messages flow chart

Figure 11: Flow chart for scanning messages from connected sensors

The controller only responds to messages from Asset sensors connected to its network. This allows two separate Asset Monitor systems to coexist at the same location. When a message is received from a child device, the controller responds with a scan request message. This message acts as an acknowledgment for the child device that the controller has received its message. If the message reported by child device is critical, such as a motion detected event, then the controller immediately sends a message to the Asset mobile app on the user’s cell phone via GCM server.

Sensor network topology

Figure 12 shows the topology of the Asset sensor network and two methods for joining sensors to the network.

network topology

Figure 12: The Asset sensor network has an extended star topology

Asset sensors can be joined directly to the controller or they may be joined to another sensor that is already joined to the network. This feature allows the range of the Asset Monitoring system to be extended beyond the maximum range of BLE. Each sensor has a parent device and may support up to seven child devices.

The direction of data flow is from a child device to its parent with the final destination being the controller. The child device does not receive data from its parent or the controller except for an acknowledgement that the data has been received.

There is no limit to the number of hierarchical levels that can exist in the network. However, adding more levels increases the network delay. Unlike the controller, a parent device cannot be listening to messages from child devices continuously as it significantly increases the energy consumption of the device. To conserve energy, a parent device scans for messages for only 100 ms and sleeps for 1 s before scanning again. Furthermore, a parent device only accepts a single message during scanning. So each level may increase the network delay by up to 7 seconds.

GCM connection server

This section explains how messages are exchanged between the controller and the Asset mobile app on the user’s mobile phone using Google Cloud Messaging (GCM). GCM is a third party service that is provided free of charge by Google Inc. to send messages between an application server and mobile devices. In our project, the controller or the Asset mobile app becomes the application server when one needs to send a message to the other. Some of the features provided by GCM include

  • Downstream and/or upstream messaging using HTTP or XMPP protocols
  • Group messaging for up to 20 devices
  • Maximum 4 kB of data per message
  • Store and deliver messages when devices are available

For our project we are using HTTP protocol since it provides the simplest implementation and does not require maintaining an active connection with the GCM server as in XMPP.

GCM service setup

Before using the GCM service both the controller and the Asset mobile app must register with the GCM servers. To register with the GCM service, a Google API project must be created in the Google Developers Console. The Google API project provides a project id and an API key. The project id is used during the registration process to identify a particular GCM enabled project. The API key gives access to the GCM service when a message needs to be sent.

After successfully registering with the GCM servers, the Asset mobile app subscribes to receive group messages. In GCM group messages (or multicast messages) are called topics. By subscribing to a certain topic, the mobile app receives all messages sent to that topic. Topics allow the controller to send only a single message rather than sending messages individually to all registered mobile devices.

The Asset mobile app subscribes to three topics: status, alarm and warning. The controller sends status updates of all Asset sensors to the status topic. Critical messages such as motion detection are sent to the alarm topic. Non critical alerts such as “sensor battery low” are sent to the warning topic.  When a message from a certain topic is received the Asset mobile app executes the appropriate course of action for that topic.

Similar to the Asset mobile app, the controller also registers with the GCM server, but subscribes to only a single topic: controller. When the user requests a status update from the mobile app, it sends a status request message to the controller topic. When the controller receives a status request message, it assembles the latest information from all the sensors and sends the data to the status topic.

GCM message format

When using the HTTP protocol a GCM message is sent as an HTTP post request to the GCM server. Figure 13 shows the structure of the message sent to the GCM server.


Figure 13: Structure of HTTP post request message sent to the GCM server

The HTTP post request sent to the GCM server contains a HTTP header and a HTTP body. The header contains the API key that is used to access the GCM service and the type of data contained in the HTTP body. The content in the HTTP body is of type JavaScript Object Notation (JSON). JSON is a data transfer format that arranges the data attribute value pairs. Each message contains an address specified by the attribute “to”. The address can be a registration token for a specific device or a topic in the case of a group message.

The optional attribute “priority” is used to indicate the urgency of the message. The GCM servers will attempt to deliver a message immediately if the priority is set to “high”. The “data” attribute is another JSON object that contains the message delivered to the recipient. The “data” attribute can contain up to 4 kB of data.

Asset mobile app

The Asset mobile app is the interface that allows the user to monitor his/her assets from any location. The only requirement is that the user’s mobile phone must be connected to the internet either through Wi-Fi or a mobile network. The Asset mobile app has two tasks:

  • Receive and display messages sent by the controller
  • Send status request messages to the controller and retrieve the latest sensor status

For our project we implemented the Asset mobile app for the Android operating system. A similar application can also be created for other mobile phone operating systems such as iOS. Figure 14 shows how notifications and sensor status are displayed to the user by the Asset mobile app.

Figure 14: The Asset mobile app showing a notification message and the sensor status

Figure 14: The Asset mobile app showing a notification message and the sensor status

The very first time the user executes the Asset mobile app, it registers itself with the GCM server to receive messages from the controller. The app initiates a process called GCM listener service that runs in the background, which periodically checks in with the GCM servers for any pending messages. If the GCM server sends a message, the GCM listener service receives the message and hands it over to the Asset mobile app. If the message is from the alarm or warning topics, the app assembles a notification message and displays it to the user. If enabled by the operating system the notification message will also generate an audible sound.

The user can request a status update by clicking the Refresh button (see Figure 14). When the refresh button is clicked, the app sends a status request message to the topic controller. Upon receiving the status request message the controller will send a message that includes an updated list of all sensors to the status topic. When the Asset mobile app receives a message from the status topic the app updates its sensor list with the latest information and displays it to the user.

And this is not so quick introduction to my latest project. If you are interested to learn more about the project and to see some of the results we achieved you can access the full report here.

Special thanks goes to my Local/Wide Area Networks instructor at BCIT, John Dian, for providing us with the Bluegiga development boards for this project.

Capacitive touch sensing alarm clock

This is a side project I worked on recently as a present for a special person. It has some new cool features that I thought is worthy of a mention here. What’s different about this clock is that it uses capacitive touch sensing to display and adjust the alarm and time.

Here’s a video of the clock I made that explains how to use it (The time is a bit difficult to see in the video because of the glare)

Capacitive touch sensing is a technology that detects the change in capacitance as a result of the presence of a human finger. Nowadays this technology is used everywhere from phones to elevator keypads to pedestrian crossing activators in the streets. A capacitor is formed when two conductors are separated by an insulator or dielectric material. The typical capacitance created by a human finger is in the order of ~100 pF (according to the human body model as defined by the Electrostatic Discharge Association).

Capacitive touch sensing involve detecting a change in capacitance. The capacitance can be measured by measuring the time it takes for a capacitor to discharge across a known resistance. The capacitive sensing element I used in my clock is shown in the schematic below.


The basic capacitive touch sensing element consists of a capacitor and a resistor in parallel

The sensing element is simply a capacitor and a resistor in parallel. I used a 22 pF capacitor because it is smaller than a typical capacitance created by a human finger (~100 pF). I chose a 1 Mohm resistor to increase the capacitor discharge time so it can be conveniently measured by the ADC.

The capacitive elements must be connected to ADC pins (analog pins) of the microcontroller if using the ADC to measure the voltage across the capacitors, which is what I used in my project.

Sensing the human finger

To sense the capacitance, first we charge the capacitor by driving the pin High. Then we configure the pin to be an input. When the pin is configured as an input, the capacitor begins to discharge across the 1 Mohm resistor. After a set period of time, we measure the voltage at the input pin using the ADC. This voltage value will depend on the capacitance at the sensing element. If a human finger is present, it increases the capacitance and therefore the time it takes for the capacitor to discharge to a given voltage. So the ADC will read a higher than normal voltage if a human finger is present.

The following shows a basic flowchart of the process for capacitive touch sensing I used in my project.



Flow chart for capacitive touch sensing

The four capacitive touch sensing pins can be checked sequentially following the same process shown in the above flow chart.

Below is code snippet that implements capacitive touch sensing in Arduino:

// set capPin as output and drive high
DDRC |= (1 << capPin);
PORTC |= (1 << capPin);
//set capPin as input and turn off pull-up resistor
DDRC &= ~(1 << capPin);
PORTC &= ~(1 << capPin);
// turn on ADC and enable interrupt
ADCSRA = (1 << ADEN) | (1 << ADIE);
// select capPin as input channel to ADC and AVCC as voltage reference
ADMUX = capPin | (1 << REFS0);
// delay before reading pin value
// start a conversion
ADCSRA |= (1 << ADSC);


First Gyro’clock board assembled!

Since I have finished building my home made reflow oven, now I can use it to assemble parts in the Gyro’clock boards.

The first step is to ensure that I have all the parts for the board. Since ideally you would only want to reflow the board once. I organized this in my project book as shown below. This makes it easier to find all the parts when it is time to place them on the board. Also the parts will not get mixed up! (The 0.1 uF, 22 pF and 4.7 uF caps all look the same!)


Making sure all the surface mount parts I need for the board are there before starting

Then I realized that I am missing a key component: 3.3 V Zener diode. Ordering just a single part from Digikey is quite expensive and I will have to postpone the board assembly yet again. Luckily I had a through hole 3.3 V Zener in my parts inventory. So I made a choice to do the reflow without the Zener, and then afterwards solder in the through hole Zener to the surface mount pads.

The next step is to put solder paste on the pads. I am using Chip Quick no clean lead free solder paste (SMD291SNL-ND). The solder paste came with a syringe and a nozzle. Ideally to put solder paste on a board you have to make a stencil first. Getting a professionally made stencil for a board can be quite expensive. So I decided to do it the hard way by putting solder paste manually on the pads using the syringe.

I had no idea how difficult it is to put solder paste onto a pad with a syringe. The paste didn’t really stick at all. You have to make sure not to put too much solder paste on a pad. If you do then you run the risk of making solder bridges. Too little solder paste and it won’t make a good connection. Having never done this before, I had a high risk of making one of or both of those two errors. Solder bridges on pins can easily be corrected later so I wasn’t too worried except for two components: The ADXL345 accelerometer and the HSMF-C165 bi-color LED. All the pads of these chips are located underneath the component. I only had one chance to get it right with these two.

With care and patience I put solder paste on all of the surface mount pads.


Solder paste applied to surface mount pads on the board

Once solder paste is applied to the pads it is time to place the components on the board. I must say this part is quite fun. Specially putting the resistors and capacitors. Once placed on the pads the solder paste holds the component in its place. The ATmega328p took a little aligning and the ADXL needed quite a bit of nudging to get it in place. Once all the components are placed on the correct pads (also in their correct orientations; watch out for those polarized caps!)


Once all the components are placed on the pads the board is ready for the reflow oven

Once all the components are placed in the pads I put the board carefully in the reflow oven and ran a previously prepared custom reflow profile. After about 10 minutes the board was ready to be taken out of the oven.


Gyro’clock board out of the reflow oven

Initial inspection showed that there were no solder bridges! All the resistors and capacitors showed solid connections with their pads. The only issue was the 3PDT switch, and this could have been totally avoided. The heat caused the plastic parts of the switch to melt. The switch was unusable.

So I removed the switch and manually soldered in another one in its place. After that I soldered in the Zener diode, the seven square LEDs that go on the edge, and the 150 mAh liPo battery. And then the moment of truth; Did the accelerometer and the bi-color LED make it? Did all the parts survived the heat inside the reflow oven?

They did! I was able to upload the bootloader to the ATmega328p and program it. The bi-color LED was working, which also meant that the LiPo battery charge circuit was also working.


A fully assembled Gyro’clock board (left) next to a bear Gyro’clock board (right)

I am very happy that the first try on my home made reflow oven was a success. The next step for the Gyro’clock project is to make a case for it. That is another completely new avenue for me to explore. Until next time!

Reflow Oven Build – Part 3

In the first part of the Reflow Oven Build series of posts I explained how I transformed a regular toaster oven into a reflow oven. The second part was dedicated for the Reflow Oven Controller (ROC). And now the third and  final part will focus on the Reflow Oven Manager (ROM). The ROM’s job is to talk to the controller, upload new temperature profiles, receive profile data from the controller, and display current status of the oven and a running profile to the user.

In short it looks like this…


Reflow Oven Manager (ROM) user interface

I decided to use Python to write the ROM program simply because I like programming in Python and making a graphical user interface with Python is easy.

Creating a new reflow profile

A reflow profile is list of target temperature values to be achieved by a reflow oven at certain times after starting a profile. Recommended reflow profiles can be found in the device datasheet for certain devices. A typical reflow profile can be broken down into five stages as shown in the diagram below:


Stages of a typical lead-free reflow profile

A custom reflow profile must be created for each board by consulting the device datasheets of the components to ensure the temperature in the oven does not exceed the specifications. If none of the devices have recommended reflow profiles then standard reflow profiles must be followed. The reflow profile will also depend on the type of solder paste used. Typically Lead-free solder paste require a higher temperature than lead solder.

Creating a reflow profile with the ROM is simple, as it asks the user for all the necessary temperature and time values to create a profile (see figure below). Once a profile is created it can be viewed and edited. The program automatically saves each new profile that is created so it is available the next time the program is used.


Creating a reflow profile using the reflow oven manager is as easy as entering a few temperature and time values

The ROC (Arduino) does not store any reflow profiles. So each time the controller is power cycled a profile must be uploaded using the ROM. Once a profile is successfully uploaded to the controller, it can be started; The status of the active profile will be displayed on the GUI. Profile data sent by the controller will be saved in a file so it can be viewed later on.

A complete program listing of the ROM is available here.

Now the reflow oven build is complete. All that is left to do is to test it by running a profile. Figure below shows the result of the first test run with the oven.


First test of the reflow oven. The actual oven temperature lags the target temperature

The results in the plot above shows the oven temperature is not able to follow the target temperature very accurately, specially at higher temperatures. The oven takes too long to heat up and as a result the actual temperature lags the target temperature.

The reason why the oven takes too long to heat up is because it doesn’t do a good job of retaining the heat. This was built after all from a $20 toaster oven from Walmart. I found that most of the heat is escaping through the glass door (which gets really hot!). After some searching around the internet I found a simple and a cheap solution to the problem: Just wrap the glass door with some aluminum foil! After wrapping the glass door with aluminum foil I ran the test again. This time the results were much better


Reflow oven test after adding the aluminum foil to prevent heat from escaping through the glass door

It takes a bit more time for it to cool down after about 160°C, but this is not an issue. At the end I can always open the door to allow more heat to escape if necessary.

Now the reflow oven is ready to take on a real job; That is to assemble the components on my Gyro’clock boards. This is the reason why I wanted to build this thing in the first place. I will cover that in my next post.

Reflow Oven Build – Part 2

In Reflow oven build – part 1 I showed how I modified a simple toaster oven to function as a reflow oven. In this part I will explain the reflow oven controller. The purpose of the reflow oven controller is to control the temperature inside the oven to follow a standard reflow temperature profile. The controller must have the ability to do the following tasks:

  1. Be able to turn on and off the heating elements of the oven
  2. Measure the temperature inside the oven
  3. Ability to modify the existing profile or upload a new reflow temperature profile
  4. Report current status and temperature data from the reflow oven to a user interface (the user interface will be covered in part 3)

This job is made for a microcontroller. For my reflow oven I am using an Arduino Micro. The diagram below shows the schematic of the controller:

Schematic of the reflow oven controller

Schematic of the reflow oven controller

I assembled the circuit inside a small first aid case, and made two openings on the side to connect a USB cable to the Micro and a +12 V adapter to power the CPU fan of the reflow oven. On the opposite side I made another hole to run the wires that connect to the reflow oven (thermocouple, GND, +12 V for fan, and signal to solid state relay).

The controller circuit assembled in a small box

The controller circuit assembled inside a small box

The reflow oven and the controller

The reflow oven and the controller

The next thing to do is to write code for the controller. Inside the controller a reflow profile is stored as time-temperature value pairs. These are target temperature values that need to be achieved at the specified times after starting a profile. The controller has only a single reflow profile at a time. A new profile can be uploaded to the controller using a separate program on a computer (reflow oven manager), which will be discussed in part 3. The controller also sends profile status and temperature data to the reflow oven manager so that it can be monitored in real time. The following flow chart shows the basic structure of the program that controls the reflow oven:

Basic flow chart of the reflow oven controller program

Basic flow chart of the reflow oven controller program

A complete program listing for the controller can be found here. On the next post I will discuss the reflow oven manager program that talks to the controller.

Reflow Oven Build – Part 1

There are many tutorials, instructables and youtube videos about DIY reflow ovens. I have checked out some of them myself before deciding to make my own. This however is not a tutorial or a set of instructions on how to build a reflow oven. This is a just a record of the steps I took to build my reflow oven in case some of my (crude but cheap) methods suits you.

Parts used:

  1. Rival 4 slice toaster oven – I got this from Walmart for $23 (CAD). The main reason for choosing this other than it being cheap is that it has quarts type heating elements, which warm up fast and cool down fast unlike the thin grey type heating element found in most regular ovens
  2. Arduino Micro – I already had one of these lying around that wasn’t being used for anything else.
  3. K-type Thermocouple – $4.50
  4. MAX31855 thermocouple amplifier breakout board from Adafruit – $14.95. This was a rather expensive choice. But this breakout board accepts 5V inputs and outputs the temperature in digital, making the coding and the rest of the circuit fairly simple.
  5. Solid state relay (SSR) – $19.95. input: 3-32 VDC, output: 24-380 VAC, 25A
  6. Heat sink for SSR – scavenged from an old project
  7. Computer fan – rescued from an old PC power supply unit
  8. 12V DC power supply – Burrowed from my Music and Lights project

Total spent for parts above: $62.40 (CAD)

I broke the design of this reflow oven into three Major parts:

  • oven
  • controller
  • user interface

The oven

The oven must be capable of heating up and cooling down at a rate sufficient to follow a reflow temperature profile. A slow oven that stays too long in the critical zone of the reflow profile (above 217 °C) could potentially end up damaging the components.

Most of the home made reflow ovens I have seen started out as typical toaster ovens. But typically a toaster oven manual does not say how fast it can heat up or cool down. So which one to choose? Some sources suggest to use a toaster oven that has quartz heating elements. Since this type of toaster oven was proven to work in the R&TPreppers video, I decided to get the cheapest toaster oven I could find nearby that had quartz heating elements.

The quartz heating elements of the toaster oven

The quartz heating elements of the toaster oven

Step 1: Open the case and strip all the knobs and dials (2 in this one) that are no longer necessary. That job will be taken over by the reflow oven controller.

Remove the existing controls of the toaster oven as they are no longer needed

Remove the existing controls of the toaster oven as they are no longer needed

Step 2: Cut a hole on the side of the oven to attach the cooling fan. This fan keeps the electronics (most importantly the solid state relay) inside the reflow oven cool. It needs access to fresh air, so I had to cut a 6 cm diameter hole on the side of the cover. The metal case was thin so I was able to cut it with a heavy duty scissor (not a very clean job, but got the job done).


Attach the PC fan to the side of the cover to bring cool air inside to keep the electronics cool

Step 3: Attach the SSR to a heat sink and mount the heat sink on the other side of the hole so that it is in the direct path of the cold air coming from the fan.


SSR attached to a heat sink and mounted directly opposite the cooling fan inside the oven cover

Step 4: Drill a small hole into the oven chamber to feed one side of the thermocouple wire.


A small hole drilled to the side of the oven chamber brings in the thermocouple

Step 5: Wire everything up that goes inside the cover of the oven. This includes all the connections shown in the wiring diagram below


Wiring diagram for the components inside the reflow oven.

Once all the wiring is done and the cover is put back on the reflow oven is built! But without a controller, this oven is pretty useless. So in the next post I will cover the controller. Most reflow ovens I have seen integrate the controller inside the oven as well. But since I have no idea how hot it will get inside the cover when the oven is running, I thought it is better to have the controller outside. Also having the controller outside makes it easier to program it.