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.
The picture above is a Melexis MLX90614 infrared thermometer. It lets in through a window the infrared radiation from whatever object it is pointed at, measures it, and calculates an approximate object temperature, making the temperature available to other connected circuitry. It is the heart of my thermometer. I didn't have any to start, and I didn't know in detail how to use it. That, and my search for an MCU to use in my thermometer, led me to my first lesson in electronics and physical product development: datasheets.
Datasheets
I should have dicovered this earlier than I did, but manufacturers of parts that go into products, especially electronic parts, tend to publish a document for each part or part family that describes the details of the part(s). Generally, one of these manufacturer documents is called a "datasheet," but that word is misleading. A datasheet can vary in length from one page to hundreds of pages, ranging in scope of content from essential information only to great detail.
At one end of the spectrum was the datasheet for the Lumex LCD-S401M16KR numeric display I was considering. This datasheet is one page long and has only the essential details of the part. It assumes the reader already understands how to work with LCDs. I'll show in later articles how the absence of certain information in this datasheet inplied certain facts that influenced certain implementation details for my NCIT.
At the other end of the spectrum was the datasheet for the PIC16(L)F191XX MCU family that I settled on using. It is over 750 pages long and describes all the features of these MCUs and how to use them, both in summary and in great and precise detail. I used the opening summaries of PIC datasheets to quickly exclude the PIC models and families that didn't have all the features I was looking for.
The difference in length and detail in the datasheets for the LCD and MCU family is mostly explained by the difference in complexity between the two parts. An MCU, especially one with special features, is far more complex a device than a 4-digit LCD.
Something I realized about good and detailed datasheets is that they probably reduce the customer service demands on a manufacturer. The first place an engineer should look to answer a question on using a part is the associated datasheet. Only if the question is then unanswered would an engineer have to reach out to others, whether the manufacturer or other engineers.
A simiar kind of document I have worked with as a software engineer is the decription of an Application Programming Interface (API), for, say, a software library or web service. Another similar but not quite the same, kind of document is an official description of a particular programming language, for example, the standard for the C++ programming language.
Application Notes
Manufacturers of parts sometimes provide white papers that describe how to use a certain part (or combination of parts) for a particular purpose (an "application" of the part(s)). These white papers are sometimes called application notes (or app notes, for short). One app note I depended on in designing and attempting to build an NCIT was Microchip's document AN658, which explained the fundamentals of how LCDs work and how to use the LCD driver circuitry built into some models of their PIC MCUs.
Conclusion
So, that was maybe my first lesson from trying to design an NCIT: look for helpful manufacturer documentation such as a datasheet or an application note, because it probably exists, when trying to understand how to use a particular part you have chosen to use or are considering using.
Next time I will describe my initial, loose plan for how to approach designing and building my NCIT and what each step of the plan told me, since I was starting from scratch, about the parts, supplies, tools, equipment, and skills I would have to acquire to complete the project.
Until next time...
