Non-Contact Infrared Thermometer - Part 3

 

Welcome to another installment of "Dabbling in Electronics"! This is Part 3 of a series on my journey to design and build, starting from scratch, a complete prototype of an open source, handheld, non-contact infrared thermometer (NCIT). I've previously described why I was doing this, my basic design, and my discovery of the value of manufacturer product datasheets. In this article, I'll describe my loose plan for getting from start to finish, and what that meant about the parts, supplies, tools, equipment, and new skills I could expect to need to acquire along the way. The photo above shows some of what I acquired and accomplished so far, but let me not get ahead of myself.

What I started with in my original design proposal was a simple functional diagram like the one to the right. I hadn't drawn any circuit schematic diagrams in a long time, and even then they had all been hand drawings on paper, so I didn't provide one.

The requirements were straightforward:

• after pointing the device at a forehead, pressing a button would display the temperature of the forehead
• the device must be battery-powered, and a set of batteries should last at least through a 10-hour day of steady use

This was my starting point for building a prototype. I wasn't experienced at working with embedded microcontrollers (MCUs), or the MLX90614 temperature sensors, or liquid crystal displays (LCDs). What I did have going for me was years of software engineering experience and confidence from reading manufacturer datasheets that the right variants of these parts could be made to work together.

An Initial Plan

For building a complete, working prototype, I needed at least a loose plan. I would complete things in steps, tackle one challenge at a time, because I was dealing with so many unknowns. The initial plan I came up with was the following:

1. Review the product requirements.
2. Create a repository for holding all the design and source code digital files.
3. Create a sufficiently detailed firmware design.
4. Create a candidate complete circuit design, including producing a schematic diagram.
5. Demonstrate the MCU blinking an LED
6. Demonstrate the circuit displaying something on the LCD.
7. Demonstrate detecting a low battery condition and displaying it.
8. Demonstrate using the pushbutton to simulate reading and displaying temperatures.
9. Demonstrate the circuit and full firmware.
10. Design a candidate printed circuit board suitable for a handheld enclosure.
11. Design a 3D-printable handheld enclosure.
12. Build at least one working NCIT using the final designs.
13. Publish the designs so that others could use them as-is or as examples to help them with similar parts of their own projects.

I expected the plan to change as I learned things. This was common in any creative effort, where one didn't know in advance everything one needed to. I also wasn't just going to take the steps in strict order without considering the needs of future steps. I knew from experience that I might discover something at some step of the project that required me to back up and change, or even substantially rework, what I did at prior steps.

What the Plan Told Me I Needed

Remember, I was starting this project with no parts, supplies, tools, equipment, or deep knowledge except for having years of software development experience, a couple of home computers, and a basic knowledge of electronics.

In determining what I needed to acquire, not necessarily all at once, I looked to see what I would need for each step. I will now go through the steps and describe what I gleaned from each one.

Review the Requirements

The starting point for the development of any product is to decide what is required of the product. For example, during development of the NCIT in the original project, we discovered that the FDA standards for any battery-operated, electronic, medical device required the device to give a "low battery" warning, when possible.

Several things I knew from datasheets or other research:

• the MLX90614 sensor required at least 2.6V to operate
• the microcontrollers (MCUs) I was considering could operate as low as 2.3V, or in some cases, even as low as 1.8V
• the MCU had a charge pump (voltage converter) that would allow it to provide 3V to the LCD even when the batteries were lower than 3V; if I didn't use the charge pump, the contrast of the LCD would fade as the batteries got used up, and at some lower voltage that I didn't know yet the LCD contrast would be too faint to read
• when a 1.5V alkaline AA battery wears out to the point that it can provide only 1.2V under load (or 2.4V for a pair of batteries in series), it is considered discharged (as good as dead)

So, I had an additional requirement:

• display a message when the batteries were too low to run the sensor (take a temperature) but still high enough to run the MCU and LCD

I knew from the datasheet that the MCUs I was considering had analog-to-digital converters (ADCs) that would allow them to measure voltages relative to the battery voltage. But I didn't know yet what techniques I could use to measure the battery voltage itself. I didn't know, for example, if I would need any extra parts and need to devote one or more of the MCU pins to measuring the battery voltage.

That wouldn't be the only requirement I would add.

One requirement of the original project's NCIT was so taken for granted it was not originally stated: temperatures should be displayed in degrees Fahrenheit. I decided that I wanted an NCIT suitable for international use, just on principle. The new requirement was:

• temperatures can be displayed in either Fahrenheit or Celsius, depending on user choice; that choice will be used until changed and remembered by the device even if the batteries are removed

I knew from the datasheet that the MCUs I wanted to use had reprogrammable read-only storage (EEPROM) that would persist if the batteries were removed or went dead, but I didn't know how to use the EEPROM yet.

Create a repository

Since I was planning to publish the results of my work online somewhere, I wanted to keep all the digital files for the project collected together in some organized way from the beginning. That was easy. I already used Dropbox to keep cloud copies of all my important files and files that I want to share between my laptop and desktop computers. Under my Dropbox folder, I created an E-Projects folder, and under that I created a pic-ir-thermometer folder where all my digital files for the NCIT would go.

I already knew that I would publish the project on GitHub, a popular service for storing and sharing repositories of open source projects. I already had an account there. That meant I would have to eventually put my pic-ir-thermometer folder under version control using the Git version control application and link my local and GitHub repositories, so I did that right at the start.

I created a GitHub project at https://github.com/kamorrissey/pic-lcd-demo. It already has content, and I will be updating it as I progress on this project. So feel free to check it out.

Create a sufficiently detailed firmware design

What is "firmware"? Although this is not the only meaning of the term, an executable form of software (often called object code or binary code) that is kept in read-only storage and not easily changed, such as the software running on a microcontroller embedded in an appliance, is often called "firmware." The software that will run this NCIT fits this meaning and will be called firmware from here on.

The following is a flowchart of the firmware I submitted in my original design proposal. I used the drawing tools within Microsoft Word to produce it.

This design didn't include some of my new requirements, so I would have to revise it.

Create a candidate circuit design

My next step in actually building an NCIT was to design its circuitry in full detail. I couldn't build a circuit unless I had a design for it. Moreover, designing the circuit in full detail would ensure I knew all the parts I needed and that the parts could all be wired up appropriately. For example, maybe I would discover that an MCU I was going to use didn't have enough available pins to connect to everything it needed to. That could happen because the various pins of an MCU are often dedicated to certain purposes. Sometimes a pin is available for multiple purposes, but can be used for only one of them in a given application. What if I discovered I needed to use an essential MCU pin for two different, conflicting purposes? I might have to use a different MCU or significantly change the circuit to resolve the conflict. It was okay if I discovered the circuit needed changes after this. The goal was to get a complete circuit that connected all the parts I needed to use, to have a starting place that had some hope of working.

Schematic diagrams that express circuit designs can be done on paper. I wanted to at least use a drawing program, such as Microsoft Visio, so my schematics would be nicer than if hand-drawn, but I remembered that my friend who designed printed circuit boards (PCBs) for medical equipment used an Electronic Design Automation (EDA) application called OrCAD for her work. OrCAD did much more than allow her to create pretty circuit diagrams. It actually extracted from those schematic diagrams the same important information that humans did: the lists of electronic parts in the circuit and how those parts were electrically connected to each other. It could then use that information to help a user design a PCB that would properly connect those parts when they were soldered to the board.

Since I wanted to not only produce a circuit schematic but a PCB design too, it made sense to use an EDA tool like OrCAD. I didn't want to use OrCAD in specific, because it is commercial software that is too expensive for a hobbyist to use ($1000 or more). Here, I made the decision to use free, readily available software tools as much as possible not only to minimize my own project costs, but those of people who might try to use my designs.

So, the needs I discovered here are

• a free, readily available EDA tool to design my circuits and PCBs
• learn to use it to create circuit designs

I will further discuss my search for an EDA tool in a later article.

Demonstrate blinking an LED

Here was the first step getting the MCU to do something. A common first demonstration of making an MCU do something was to control one of its pins to make a light-emitting diode (LED) repeatedly turn on and off. It would not be complicated to write the program, freeing me to focus on learning everything that was new. This was the first step where I would begin to electrically hook up parts, the first step where I would write some firmware and load it into the MCU to run it. Thinking about this step would begin to uncover some of the physical things I would need.

To begin, I needed to construct a temporary, easily changeable version of my circuit, or at least part of it. It was far too soon to be soldering things together in any kind of permanent way, because I was likely to discover changes I needed to make. I was in luck, because there are products meant to help with this: solderless prototyping boards, often called "breadboards" because very early circuit prototypes were sometimes literally constructed atop breadboards or other flat pieces of wood. The opening picture of this article shows several breadboards, including two that were joined edge-to-edge to give a larger working space.

While I could plug my parts into the breadboards, I also needed a way to temporarily wire those parts to each other. The wires for doing this are often called "jumper wires."

I already knew about one kind of jumper wire meant to work with breadboards. These are lengths of wire with pins on the ends that could plug into the breadboard. These pins (or sockets that can accept such pins) are called Dupont connectors--a brand name--and wires with them are sometimes called Dupont wires.

It was also possible to cut lengths of wire and plug the bare, stripped ends of the lengths into the breadboard. Conveniently, I discovered, you can get kits of wire pieces pre-cut to useful standard lengths.

What parts would I plug into the breadboard to start? Well, there were the MCU (the specific model of which I would figure out from finishing an initial circuit design) and the LED.  I learned from the datasheets that I would need some parts called "capacitors" for the MCU and (later for) the MCU's charge pump. Capacitors store and release electrical energy in a way similar to how springs store and release mechanical energy. They come in different values (electrical sizes) but I didn't know all the specific values I needed yet, so I decided to just get an assortment of capacitors to start. I did know from the MCU family that I would need at least some of a specific kind known as "ceramic" capacitors. Besides, capacitors are one of the basic, commonly used electronic parts and might be needed for later projects, so getting an assortment of capacitors was not a waste.

Typically, a bare LED needs a companion part called a "resistor" to keep from running too much electrical current through it, causing it to burn out earlier than necessary. Resistors are used to introduce something like friction into electrical flow. As with the capacitors, I wasn't sure yet what value of resistor I needed, so I would buy a kit with assorted common values. Like capacitors, resistors are one of the basic, commonly used electronic parts, and I would likely need them in future projects.

I needed a way to load my baby-step firmware into the MCU. I knew the MCU could be programmed in-circuit from my home computer by way of a special device often called a "programmer" that was connected between my computer and the circuit with the MCU. The PIC MCU manufacturer, Microchip, made programmers for this purpose. I decided to use their most current version, named the PicKit 4. The PicKit 4 was meant to plug into "pin headers" on the circuit board, so I would need to get some pin headers.

To have any firmware to load, I would need to write the firmware source code and have a way to  compile that source code into the loadable form. Microchip had an application for this, MPLAB X IDE, and it had a free version that could run on my home computers running Microsoft Windows. I had two options for the programming language to use: assembler or C.

Assembler languages require you to write the individual machine steps directly understood by the specific kind of computer you are trying to use. Assembler programs are verbose and tedious to write. The language is specific to a given model of computer.

The C programming language is a higher-level programming language than assemblers. It is widely used, and I already had substantial experience writing programs in it. I chose to write the MCU firmware source code in C.

Another thing I would need for my initial circuit was a way to power it. I could use batteries, but I already knew that in later steps I would want to test the circuit at different voltages. So, it might be easier to use a variable-voltage power supply that plugs into AC, often called a "bench" power supply (because it is often used on engineering or scientific laboratory bench tops).

So, my list of needs so far were

• breadboards
• jumper wires, both Dupont and pre-cut lengths
• an MCU
• an assortment of ceramic capacitors
• an assortment of resistors
• a bench power supply
• a PicKit 4 MCU programmer
• the MPLAB X IDE application
• learn to write a simple program for the MCU and load it onto the MCU, where it would run

Display something on the LCD

Now that I knew I could successfully write a firmware application, load it into the MCU, and run it, I could move on to one of the big unknowns in this project: getting the MCU to display content on a liquid crystal display (LCD).

What I would do to start was to write firmware to turn all the pixels (displayable elements) of the LCD on and off repeatedly in tandem with the LED. The LED would provide a "heartbeat" to prove the firmware was running even if the LCD did not display anything due to some error.

It would be useful to measure the electric current needed by this circuit, because it would help me to estimate the battery lifetime of the NCIT. For that, I needed an ammeter. Rather than buy an ammeter in specific, it would be just as easy and inexpensive to buy a multimeter, which often was 3-in-1 capable of measuring current, voltage, or electrical resistance.

The new things I needed for this step were

• an LCD (specific model to be decided as a consequence of completing the candidate circuit design)
• a multimeter
• learn how to control the LCD from the MCU

Detect a low battery condition and display it

If I hadn't previously identified a good need for a bench power supply, I would have here. In this step I needed to simulate a low-battery situation. Since that meant I needed some sort of variable-voltage power source, I might as well use a bench supply, although I could have rigged up a variable-voltage supply with batteries and an inexpensive variable resistor called a potentiometer as a voltage divider.

The firmware will repeatedly measure the battery voltage and display it for one second. If the battery is low, a message indicating low battery will be displayed for an additional second before repeating.

Now I didn't know at this point in the planning whether I would need additional parts for the circuit to measure the battery voltage, but at least I knew I might.

I would need to

• learn how to measure battery voltage from the MCU
• learn how to display numbers and messages on the LCD, and program it

Detect button pushes and flesh out firmware

This step brings in the need for a pushbutton switch. The way switches and MCUs work together also meant I might need some additional resistors.

I will write and test the bulk of the firmware, doing everything but reading real temperatures from the sensor. Instead, I will simulate reading temperatures by some simple means so that every time I press the button, I will get a different temperature.

I will need to accommodate a quirk of mechanical switches. They tend not to open or close instantaneously or decisively. The switch contacts can physically bounce and vibrate, quickly making and breaking contact repeatedly for a short while until the switch settles down mechanically over a period as long as 10ms (10 milliseconds). This can look to the MCU, which can operate very fast, like the button is being pressed repeatedly. We don't want it to do that. We want, in some way, to neutralize the effects of the switch bouncing. This is often called "debouncing" the switch, and can be handled with software and/or circuitry.

MCUs are often loaded with handy, optional-use circuitry. When considering how to debounce the button, I should look whether the MCU has helpful circuitry.

So the list of needs now includes

• some pushbutton switches
• learn the most effective way to debounce the button
• learn how to tell whether the button is pressed

Demonstrate the full circuit and firmware

This step brings in using the MLX90614 temperature sensor. I would need a capacitor and two resistors here, according to the datasheet. The firmware should be stable at this point, with reading from the sensor being the only thing missing.

Since it might be difficult to hold the breadboard to my forehead, I would try reading skin temperature from my free palm or forearm. I should also be able to just point the sensor into the room and get a background temperature reading. 

If I were building a commercial medical device, at this point I would be doing tests with sophisticated, expensive sources of accurately controlled temperatures. Alternatively, I will compare my NCIT readings to that of a consumer, FDA-approved NCIT.

Added to the list:

• at least one MLX90614 temperature sensor
• learn how to read temperatures from the sensor
• a consumer, FDA-approved NCIT

Design a candidate printed circuit board

By this point in the project, the breadboarded circuit should be working and the firmware stable enough that it will not likely need any changes that might require corresponding circuit changes. Now I'll use the EDA tool to design a PCB to hold my finished circuit. A proper EDA tool can produce industry-standard digital files, called Gerber files, that can be sent to a PCB manufacturer, informally called a "board house." These files completely describe the manufacturing details of the PCB. Board houses can often quote the price of PCB orders based on the Gerber files.

I'll need to think a little bit ahead here, and plan for a layout of parts that makes sense. For example, where does the pushbutton go? I need to accommodate now that the device will be held in one hand, and the hand shouldn't block either the LCD or the sensor. I already at this time need to be thinking of the design of the handheld enclosure. It's possible that I may need multiple circuit boards to get everything positioned properly inside the enclosure.

Since I was planning to have my PCBs manufactured by a board house, I needed to

• learn how to use the EDA tool to design PCBs and produce Gerber files from them
• find one or more board houses that were affordable for small runs of boards

Design a 3D-printable handheld enclosure

Now that I know the layout of the PCB(s) and have some idea of the design of the handheld enclosure, I need to finish that design. For that, I will use a Computer-Aided Design (CAD) application.

Since I'm designing the enclosure so that it can be produced by 3D printing, where an object is built up in layers, I will need either access to a 3D printer or a service that will 3D print my draft enclosures for me. Hopefully, the CAD application I select can output files suitable for 3D printing, otherwise I may need some additional file conversion applications. I will go into more detail about 3D printing in later articles. If I'm printing the enclosures myself, which I will be because I already own a 3D printer, I will need supplies, such as the raw plastic materials used to print the enclosure.

I will need to determine whether I'll need additional hardware, such as screws, to hold the enclosure together. It would be really nice if the enclosure could snap together, but I had never designed snap-together parts before.

For now, I know to add to the list:

• a CAD application (and maybe CAD file conversion applications)
• access to a 3D printer or a 3D printing service
• 3D printing supplies (because I am 3D printing myself)
• learn how to design small enclosures to be 3D-printed

Build at least two working NCITs

At this step, if not some of it done earlier, I am going to assemble everything into (hopefully!) a working device. If successful, I will then build a second one as a memento to an electronics engineer at work who provided me advice on my NCIT design. That means I must have all the parts to be assembled. I will be soldering all the electronic/electrical parts to the PCBs.

I need

• final PCBs from a board house
• final 3D-printed enclosures
• equipment and supplies for soldering
• any additional assembly hardware, such as screws, and tools for them

Since I haven't done any electrical soldering in a long time, I should practice. I learned that one fun way to practice soldering was by assembling kit circuits. So, the last things I will add to the list are

• one or more circuit kits for soldering practice
• relearn how to solder using the new equipment

Publish the designs

Once I have finished my designs, I will upload the final designs and working files to GitHub. I will finish out initial publication by writing and uploading any documentation I think will be useful to anyone trying to replicate the NCIT or use any of its design parts in other projects. I shouldn't need anything new for this step.

Conclusion

I have laid out an initial plan to get from start to end in building an NCIT from scratch and publishing the design as an open-source project. I now have a list of needs, but with a few items not yet fully specified.

In the next article, I will select some applications and use them to create candidate designs for the circuitry and firmware and order some initial parts, supplies, tools, and equipment.

Until next time...

Non-Contact Infrared Thermometer - Part 2

 

Welcome to this installment of "Dabbling in Electronics"! This is Part 2 in my series on building a non-contact infrared thermometer (NCIT) from scratch and making the design open source. Last time I explained why I was building it (mostly for fun and self-education) and highlighted my basic design. This time, I want to describe some of the things I had to learn to get started, since I was starting from scratch with no parts, tools, supplies, equipment, or deep knowledge. All I was starting with was my years of experience as a software engineer, a couple of home computers, a basic knowledge of electronics, and a little freedom to spend money on this pursuit.

Non-Contact Infrared Thermometer - Part 1

 

Welcome to the next installment of "Dabbling in Electronics"! Over the spring and summer of 2020, I helped a non-profit develop an open-source, non-contact infrared (IR) thermometer, the kind you point at someone's forehead and press a button or pull a trigger to take a temperature. They believed at the time that due to the COVID-19 pandemic there would become a shortage of commercial units of these thermometers for screening people for fever at businesses and non-profits. I submitted a proposal to the initial design competition, but it wasn't selected for further development. 

Mostly for the fun of learning new things, but also to validate my design choices, I decided to build a prototype of my proposed design mostly on my own. This article is the first part in a series about developing that prototype from scratch and what I learned by doing so. I will be writing this series as I progress step-by-step toward having a completed thermometer including custom printed circuit board (PCB) and 3D-printable handheld device enclosure. Right now, I will just describe the basics of the thermometer and some key design choices.