Sample Rate Jittering

When you are designing a system that has a sensor that must be sampled, eliminating noise from the readings should be one of your concerns. Averages and other low-pass filters do a good job at smoothing the signal which reduces the amount of white noise, but if the sample rate of your system is a harmonic of the noise’s frequency a different approach is needed.

First, we need to understand what is going on in the system that is causing us to change our sampling behavior. The picture below shows a normal sensor signal that has been injected with a single-frequency noise signal. The sampling rate occurs at a harmonic frequency to the noise and so the samples are not occurring at random locations on the noise – they are following a harmonic sine wave.

If each sample is processed individually, the system will have to filter out the sine wave which could slow the response time. If multiple samples are added together or averaged, the resulting stream of samples will look like they have a large increase in the amount of white noise. This will have to be filtered out which will decrease the sensitivity of the sensor.

The solution to this problem is to slightly jitter the sampling rate of your system. Instead of sampling every X ms, sample every X+Y ms, where Y is a random value that is much smaller than X. For example, if your system is sampling once every 10 ms, then the sampling rate may be jittered by +/- 25 µs. (TIP: To create a simple, pseudorandom number, you can take the least significant bits from the previous sample and add them to the sampling rate timer. It’s not perfectly random, but it should be random enough.)

The result of this technique will be that your system will sample with the behavior shown in the picture below. Notice how the samples are still following the sample rate, but now they are more randomly distributed throughout the injected noise signal. Now if the system processes one sample at a time, it will see a small amount of increase white noise which will be solved with a simple averaging filter. If the system takes several samples and combines them before processing them, the white noise should naturally eliminate itself and the samples will hover around the normal sensor signal.

Tags: Filter, Jitter, Noise, Sampling, Sampling Rate, Sensor, Signal

PC productivity tools for embedded programmers

As embedded programmers, we all write firmware. Small projects are not so hard to manage. But as projects get bigger and with more than just one programmer involved, it’s time to look around for tools to help keep the team’s productivity high.

To write this blog, I simply dig into my computer and pick out the tools I use often. Here they are, in random order…

Comparing files, well, the worst way to do is to open up two source files and compare them by eyeballing. Comparing files is often needed when working with other people, you want to see what others have changed. Even by yourself, you may want to compare the file you are using today against the file from 5 days ago. Something was working, now it’s not, what’s changed? I personally use Beyond Compare from, http://www.scootersoftware.com. This is not free, but very affordable. It can compare files, folders, you name it. It shows result in a very intuitive manner, can’t live without it. Alternatively, you could use WinMerge, http://winmerge.org. WinMerge is free. Check them out.

Next is version control. At work, the team I’m with uses SVN, http://subversion.tigris.org, and TortoiseSVN, http://tortoisesvn.tigris.org. Both are free. First is the server side software, the heart and soul of the version control system. Second is the client side GUI interface. Nothing too fancy, they just work. Also make sure to backup the SVN repository regularly. Other choices are also available, such as CVS, etc. You can also set TortoiseSVN to use any file comparison tools, in my case, I set it to use Beyond Compare.

Another neat tool we started to use recently is the UniversalIndentGUI, http://universalindent.sourceforge.net. This tool helps in formatting codes, by processing them per the formatting rules given. If you need to publish your code, whether publicly or just to your customers, this tool helps make everything looks consistent as though the codes were written by just one programmer. UniversalIndentGUI doesn’t solve all the consistency issues, like variable and function names. For that, your team need to have a coding style policy to follow in the first place. But for indentation, parenthesis, and other formatting related items, this tool takes the meaning of the word quality to another level.

Moving on to text editor. In all likelihood, your computer has the Notepad program that comes with Microsoft Windows, and you also have an IDE (Integrated Development Environment) installed. Your source code files are probably associated with the IDE. But there will be times when you just want to browse folders, and all you want to do is to quickly inspect a source file, both Notepad and IDE may not be a good solution. Notepad doesn’t highlight syntax, and IDE doesn’t load quickly. In this case, I use another text editor that can highlight syntax, better than Notepad, but also light-weight when compared to an IDE. The program I use is Notepad++, free and can be found at, http://notepad-plus.sourceforge.net. Many other options are also available, such as EditPlus, TextPad, etc.

Talking about editor, another good tool to have is a hex file viewer/editor. I use XVI32, http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm. Not everything you work with is in a text readable form, so something like the XVI32 is a must have.

Another good tool is TreeSize Free, http://www.jam-software.com/freeware/index.shtml. This tool helps you analyze the disk size allocation of files and folders. I typically use this tool to scan code repository before each public code release. It helps me to understand the file organization from the size perspective. I also tend to use it to look out for any unexpected files that may get introduced to the SVN repository unintentionally. This is helpful when the code distribution is large, and you want to keep the installer package size within a reasonable level.

When it comes to documenting APIs, there was a time when we documented our function APIs by writing them out again manually in a separate document, be it a Microsoft Word or Acrobat PDF. This was an insane way of doing things. Mistakes can happen left and right. Synchronization between the actual code and help file was also very hard to keep up with. When an actual function API changed, we would have to remember to update the documentation too. Typographical errors were also very common, which made the document harder to understand for the end readers. The whole process of tracking and editing was also very time consuming. Fortunately, those were the old days. Now we use Doc-O-Matic, http://www.doc-o-matic.com. The tool scans source codes for comments and function headers and use them to outputs documentation help file in various formats automatically. Doc-O-Matic is not free, but a great investment that helps save countless hours of manual work, which makes it a cheaper choice in the long run. A free alternative is Doxygen, http://www.stack.nl/~dimitri/doxygen. If you are not using a help authoring tool, you should start, today.

Lastly for packaging an installer, we use Nullsoft Scriptable Install System (NSIS), http://nsis.sourceforge.net, which is free. For a programmer, learning how to use NSIS should be easy, as you will be writing a script. Many functions and templates are provided. We use the Modern UI template. You will see this template once you have installed NSIS. I’d highly recommend this template and I believe most NSIS users use this template also. To learn the in and out of the Modern UI template, start by reading here: http://nsis.sourceforge.net/Docs/Modern%20UI/Readme.html.

The list above shows just some of the tools we have used within our work environment, some maybe applicable to you, some may not. At some points in the past, we never used to use them either, but we observed where we could improve our productivity and efficiency, and started introducing these tools into our work culture. You could do the same. If the tool doesn’t exist, consider in building one.

Tags: embedded, PC, productivity, progammers, tools

Interesting Webcast about microcontroller in Human Interface

Technical Editor Robert Cravotta explores processor and software-processing architectures and the impact they have on system and software development. Relevant architectures include microprocessors, microcontrollers, digital signal processors (DSPs), multiprocessor architectures, processor fabrics, coprocessors, and accelerators, plus embedded cores in FPGAs, SOCs, and ASICs.

EDN Webcast

Touch Blog General Touch Screens

Touch Screen Article, Blog Aug 2009:  Cassandra Backus, Charlie Riegert

Touch screens are user-friendly input devices that are becoming widely accepted in everyday human-machine interaction.  From large industrial machines to groceries store check-out lines, all the way down to our cell phones and personal media players, touch screens are quickly becoming the standard interface.

It is important to understand that there is not a single perfect touch technology that fits every design and application. The three primary touch technologies each have different strengths and weaknesses. This chart highlights the main topics for consideration when choosing a touch technology: Cost/Optics/Sensor Life/ Integration Ease/ Multi Touch capability/ and Touch Object (the user input method)

Touch Technology Comparison Chart

Resistive technology easily dominates the touch market, accounting for over 80% of all touch designs, boasting several desirable qualities: low cost, ruggedness, ease of integration, and the ability to use any type of user input method (gloved hand/ stylus/ finger). The only major drawbacks for resistive technology are the optical quality of the sensor and its limited multi touch capability. This article will discuss the basic theory of resistive touch technology and address the crucial role of the resistive touch screen controller within a completed touch system, focusing on the embedded market. 

Resistive Touch Technology

Resistive 4, 5, and 8-wire touch sensors consist of two facing conductive layers, held in physical separation from each other. The force of a touch causes the top layer to move and make electrical contact with the bottom layer. Touch position measurements are typically made by applying a linear voltage gradient across a layer or axis of the touch sensor. The touch position voltage for the axis can be measured using the opposing layer.

4 wired Diagram

The basic decoding of an 8-wire sensor is similar to a 4-wire. The difference is that an 8-wire sensor has four additional interconnects used to reference sensor voltage back to the controller. A touch system may experience voltage losses due resistance changes in the bus bars and connection between the controller and sensor. The losses can vary with product use, temperature, and humidity. In a 4-wire sensor, variations in the losses manifest themselves as error or drift in the reported touch location. An 8-wire touch sensor automatically adjusts for the changes, with the additional four reference lines. The reference lines allow the controller to know what the voltage is, at the touch sensor bus bars.

5 wire Diagram

5 wire resistive technology is a bit different and is designed to allow damage to the top layer without interfering with the touch solution. The voltage is not directly applied to the edges of the active layer, as it is for 4-wire and 8-wire sensors. The voltage is applied to the corners of a 5-wire sensor. To measure the X-axis, the left edge of the layer is driven with 0 Volts (ground), using connections to the upper left and lower left sensor corners. The right edge is driven with +5Vdc, using connections to the upper right and lower right sensor corners. To measure the Y-axis, the top edge of the layer is driven with 0 Volts (ground), using connections to the upper left and upper right sensor corners. The bottom edge is driven with +5Vdc, using connections to the lower left and lower right sensor corners.

Resistive Touch Electronics

Most resistive “touch controllers” on the market are basic analog-to-digital converters.  They convert the raw electrical data from the sensor to a digital signal.  The basic analog-to-digital converters can handle this operation, but still require more development to make them work properly as a touch screen controller.

To measure a touch position, the controller must drive the X axis and then the Y axis, creating a voltage divider where the voltage is sensed off the non-driven axis. While on the surface this is a simple concept, the sensor contains both resistive and capacitive elements that must be taken into account when designing this type of a device. These elements cause an associated RC rise time that varies both with pressure and the aging of the sensor. The analog-to-digital converter logic must be designed with this rise time in mind.  In addition, filtering algorithms must be implemented to eliminate any invalid electrical data from the sensor.  Calibration routines must also be defined, and then implemented, to map the electrical data to the visual display.  Often, the analog-to-digital converter logic is designed around the characteristics, and anomalies, of a particular sensor.  This can cause the integrator to pigeon-hole themselves into a single sensor sourced for the system.  This can quickly turn sour, should the sensor no longer be sufficient for the system.  This could be due to environmental damage to the sensor, manufacturer changes, or trying to implement the controller in a different application that requires a particular sensor construction, optic qualities, or durability.  This then forces more engineering time to develop more algorithms for compensating for a different sensor to create a functioning system again.

As you consider touch screen controller options, investigate the details to be certain that you have a complete touch controller solution, rather than just an analog-to-digital convertor.  A true turnkey touch screen controller should eliminate the need for reiterative engineering costs by providing filtered, reliable touch coordinates which ultimately provides for lower costs and quicker development cycles for embedded products.

How to minimize the issues caused by PCB variations in Capacitive Touch Application?

       The capacitive touch is a “cool” alternate to the tactile switches and membrane switches, but when it comes to the layout of the key board in a capacitive touch application, there are many challenges. Ideally, having the same trace length from the microcontroller to the Cap touch pad is desired. But in real life applications there are many challenges, the major challenges are the keys area being too small in size and the application needs the keys to be placed very close to each other,. In addition to this, the form factor of the board to fit the application can add another level of complexity, where the microcontroller may be on one end of the large board and the keys may be on the other end. This makes the traces to the touch pad are too long. Also in many applications a display may be placed in the middle of the board and the keys placed on the either side of the display.

       In these situations, the trace resistance and inductances connecting the sensor to micro varies from each other based on the key placement with respect to the microcontroller. The Charge Time Measurement Unit(CTMU) on many PIC24F and PIC18F architectures give a solution to tune the channels to read more of less the same voltage. To state in simple words, the CTMU is a constant current source. The nominal current source selections available are 0.55uA, 5.5uA and 55uA. But it has this great feature where the current source can be trimmed upto + or – 62% of the nominal value. On the channel that uses long trace to connect to the capacitive senor, the current can be scaled up to compensate the transmission losses in the trace. On the channels that are short, it can be scaled down to keep the ADC reading at the same level as the other channel with long trace length. This simplifies the algorithm to a great extent, not having to have the trip levels and filtering mechanism much different for each channel. This reduces the code size used for the cap touch application.
          A simplified flow chart below shows an automatic leveling of the channels, that trims the current according to the trace length and variation in sensor size.

Selecting a Color TFT LCD display for your embedded application – Part 2

In the previous post, we talked about the terminologies of color depth, display size, resolution, and backlight. I’d like to dedicate this post to discuss about the frame buffer and why understanding if your display has a built-in frame buffer or not is important. As always, Wikipedia has a good generic summary on the frame buffer, http://en.wikipedia.org/wiki/Framebuffer. I will elaborate more from the perspective of an embedded system. First, let’s imagine a typical embedded system with a display; this will help illustrate key points in this article. At its simplest, there are 4 components, a microcontroller, a frame buffer, a display controller, and a display glass as shown in Figure 1.

Figure 1:

The potential confusing part is you may see other names in the real world for some of the four components that I’ve mentioned. So to avoid any confusion, I will explicitly explain what each of the above components does in my imagined system.

Starting from the right of Figure 1, we have the display glass; it displays screen images from the data-stream fed by the display controller. If the display controller stops feeding data to the display glass, it will stop showing meaningful images, and stay blank/dark. Next is the display controller, its only job is to continuously read from the frame buffer and stream pixel data to the display glass. The frame buffer stores color information for each pixel on the display glass. If the display glass supports 1-bit color depth, then 1-bit of frame buffer memory is required to represent 1 pixel. If the display glass supports 16-bit color depth (RGB 565), then 2 bytes of frame buffer memory are required per pixel.

Assuming that we have a display glass with a resolution of 320×240 and 16-bit color depth, how much frame buffer memory would be required to display one full screen? Well, the calculation is easy:

Frame Buffer Required in Byte:

= Number of Pixels x ( Color Depth in Bits / 8 )

= 320×240 x (16/8)

= 153,600 bytes

Let’s try another example. You may see a device advertised as having a frame buffer size of 256Kbytes. Is this big enough for a 480×272 display with 16-bit color depth? Let’s calculate:

Frame Buffer Required in Byte:

= Number of Pixels x ( Color Depth in Bits / 8 )

= 480×272 x (16/8)

= 261,120 bytes

A 256KBytes is equal to 262,144 bytes. Since 262,144 is larger than 261,120, a 256Kbytes frame buffer is therefore large enough to support a 480×247 display with 16-bit color depth. I hope you are now more comfortable with the concept of the frame buffer and how its size relates to the display resolution and color depth.

The last piece of the puzzle is putting useful data into the frame buffer. This is typically done by a microcontroller transferring data into the frame buffer. The microcontroller does not need to update everything in the frame buffer to change the screen. It only has to update what needs to be shown differently from the previous screen. This could be something as simple as changing a red square area on a yellow background to blue. See Figure 2 as an example, assuming a display resolution of 8×8, 16-bit color depth.

Figure 2:

Assuming the application is already displaying a red square on a yellow background. When the screen information is to be updated, the microcontroller doesn’t need to write color yellow to the frame buffer again, that information is already there. It only needs to write to memory areas that store the color red and change them to blue. In this case, only 4 pixels have to be updated, represented by 8 bytes of memory. Processing just 8 bytes of data once instead of having to always update the whole screen continuously (which would be 8 x 8 x (16/8) = 128 bytes in this case) is the key architectural factor which allows a non 32-bit microcontroller to be used in an embedded graphical application. Do also note that when there’s nothing to change on the display screen, the microcontroller doesn’t have to spend any CPU time to deal with the graphical sub-systems at all.

So far I’ve described 4 basic components that make up an embedded display system, but how are they packaged and sold in the market? Figure 3 shows four common architectures of an embedded display system available in the market place.

Figure 3:

In Figure 3-A, when a display has a built-in frame-buffer, I call it a display module. This is not a standard terminology, but it helps differentiate what I’m referring to in this article. The size of the built-in frame buffer varies, depending on what the display glass needs. A microcontroller can typically connect to a display module via a parallel or serial interface. Not every display has a built-in frame buffer. Smaller displays with lower resolution tend to have a built-in frame buffer, while bigger displays do not.

When a display doesn’t have a built-in frame buffer, it is often referred to as a ‘dumb glass’. In this article, I refer to the dumb glass purely as just a display glass, while a display with a built-in frame buffer is referred to as a display module. A display glass typically has what’s called the RGB interface. An RGB interface is identifiable when you see the following signals: HSYNC, VSYNC, Pixel Clock (Dot Clock), and Red/Green/Blue data lines. A RGB interface is not the same as the parallel interface mentioned in Figure 3-A. When I talk about a parallel interface, I’m talking about the Intel 8080 or Motorola 6800 like buses. I hope this is clear.

So when you shop for a display, you can identify if it’s just a display glass or a display module by checking if it has a RGB interface and/or a built-in frame buffer. Most display datasheets do not use the term ‘module’ or ‘dumb glass’; so the only way you could tell what it does is to look at the specifications and be knowledgeable about you what you are looking at. As a recap, if you see a built-in frame buffer and a parallel interface, the display is a module; and if you see a RGB interface, it is just a display glass. Some devices support both modes, such as any displays with the SSD1289 from Solomon-Systech (http://www.solomon-systech.com).

If your display has just a RGB interface, you will need to use either architecture B, C, or D shown in Figure 3. Not all microcontrollers have a built-in display controller, so I won’t spend too much time on architecture C or D. Let’s focus on Figure 3-B for the moment. A microcontroller may not have enough processing power to continuously feed data over the RGB interface, let alone having enough RAM to be used as a frame buffer. In this case, a 3^rd device is required to interface between the display glass and the microcontroller; I call this device a graphic controller chip. A graphic controller chip has exactly the two things that were missing, a frame buffer and a display controller. It connects to a microcontroller via a parallel or serial interface, and to a display glass using a RGB interface. There are many choices available for a graphic controller chip, an example is the SSD1926. Chip suppliers tend to have different names for this kind of device, such as image processor, graphic controller, LCD driver, LCD controller, etc. They all tend to have at the basic level, a frame buffer and a display controller, but some do have additional features such as 2D hardware accelerator, JPEG decoder, etc. The discussion related to these additional features is beyond the scope of this article.

To wrap things up, architectures C and D show a microcontroller with a built-in display controller, this means it can drive a display glass with just a RGB interface directly. Do beware though that some of these microcontrollers have internal frame buffer, and some don’t. When they don’t, an external memory will be required. Knowing these differences and requirements is crucial in being able to calculate the total cost in implementing an embedded display system. Now that you are armed with the understanding of frame buffer, you would have no problems when someone tells you “The display I’m using in my project is a 3.5″ display with 320×240 resolution, supporting at least 16-bit color depth, with LED backlight, and 256KB frame buffer, connected to the main microcontroller using Intel 8080 16-bit parallel bus.” Way to go. There’re still a lot of materials left to be covered in future posts, but this one will have to do for now. Happy shopping for a display!

Tags: backlight, controller, display, frame buffer, Graphics, lcd, pixel, resolution, RGB

Selecting a Color TFT LCD display for your embedded application – Part 1

I’ve been astounded by the number of electronic gadgets with small to medium size color TFT LCD displays that are in the market. Looking back at a recent weekend trip, I remembered calling friends on the cell phone to arrange the trip, there’s a LCD display on the phone. Then while driving, I used my GPS to get to the destination, there’s another LCD display there. Then trip’s moments were captured on my digital camera, there’s another LCD display there. Coming home, I loaded the pictures onto the digital picture frame in the living room, there’s another LCD display there. The small size LCD displays are everywhere! I looked around the house and pondered, what else could use a small LCD display? A quick glance, and I came up with – thermostat, security system, stereo system, light control panel (see Figure 1 for example), remote control, running treadmill, washing machine, car’s instrument cluster, .. and the list goes on and on. The bottom line is, as a human interface, the LCD display can help enhance the end users’ experience which is a competitive advantage.

Figure 1: A Control Interface for RGB LED Lighting

In the past, not so many products could afford to feature a color LCD display, but the price has come down dramatically in recent years driven by the economies of scale and competitions between display manufacturers. As an embedded application designer, you maybe looking at using a color LCD display in your next product design. There are a number of things to understand in order to make informed design decisions, the major steps are:

- Selecting a color TFT LCD display for your project

- Selecting a microcontroller and interfacing the display

- Drawing something on the screen, display driver development

- Saving some time, using existing tools, Graphics Library, development hardware platforms

In this first post, I will cover the topic of selecting a color TFT LCD display from the aspects that relate to the end usage experience. As with any other specialized field, the display market has its own unique terms and terminologies. So let’s get that out of the way first so we all can speak the same language. When talking to a display manufacturer, you may hear something like, “This display model is a color 3.5″ QVGA with LED backlight.”

Let’s break this sentence down one by one:

Color – In the simplest sense, one may think of this as either ‘black and white’ or ‘color’. But there’s more to it than that. We will cover more on this later.

3.5″ – This is simply the size of the display, similar to when buying a TV.  You get different sizes. The bigger the screen the further you can see from a distance, but also more expensive.

QVGA – A reference name for a display with the resolution of 320×240 pixels. Similar to a digital camera, given a display area, the higher number of pixels shows more details of an image.

LED backlight – Without a light source from the back, you won’t be able to see anything on a TFT LCD display

I will now cover each of the four factors above in more details.

Color Depth:

The topic of color depth seems trivial at first and in a way it is. But I’d like to spend some time explaining the details because it will have a significant implication on the interface between microcontroller and display, and also the firmware. A monochrome screen has only two states for each pixel, on and off, and only requires one bit of memory per pixel. When more colors are desired, more bits are required per pixel to represent the color of that pixel. If using 2 bits per pixel (bpp), then each pixel can display 4 different colors. Typically, with low number of bits per pixel, the display only supports different shades of gray colors. For example:

1 bpp

2 bpp

Moving away from black, white, and grays, we enter the realm of RGB colors. What is RGB you may ask. In short, RGB is a color model that represents each color with the intensity values of the prime colors Red, Green, and Blue. Wikipedia has a detailed explanation on RGB and I will not try to reinvent the wheel here. Check out http://en.wikipedia.org/wiki/RGB_color_model to read up more on RGB. Do pay close attention to the section ‘Digital Representations’.

In the market place, some display vendors will simply state that a display is an RGB screen. This is good enough to recognize that a display supports colors in the sense that you and I would expect. Some will also specify either 65K, 262K or 16.8 million colors, it may be true that human eyes are probably not capable of differentiating all these different colors, and the display do not have enough pixels to show all the different colors it can do in one screen; but knowing that a display supports either 65K, 262K or 16.8 million colors is still important for an application designer.

If a display supports 65K colors, it means each pixel is represented by a 16-bit value, the RGB color model used is 565, meaning Red is represented by 5-bit, Green 6-bit, and Blue 5-bit. Therefore, to represent each pixel, 2 bytes of memory are required.

If a display supports 262K colors, it means each pixel is represented by a 18-bit value, the RGB color model used is 666. It gets tricky to represent 18-bit in memory since 2 bytes and 2 bits are required per pixel.

If a display supports 16.8 million colors, it means each pixel is represented by a 24-bit value, the RGB color model used is 888, and 3 bytes of memory are required per pixel.

Without going too much into further details just yet, it’s clear that color depth has an impact on memory usage, often known as (image) frame buffer. I will cover this more once other basic terms are explained.

Display Size and Resolution:

Most of us are familiar with the concept of display size and resolution from buying a computer monitor. My laptop’s display size is 15 inches measured diagonally with the resolution of 1400×1050 pixels, this resolution is also known as SXGA+. I don’t remember all the names given to a particular pixel resolution, but a decent reference can be found on Wikipedia, http://en.wikipedia.org/wiki/Display_resolution

In an embedded systems, the screen size and resolution are much smaller. For example, there is a 320×240 pixels screen, also known as QVGA (Quarter VGA, where VGA is 640×480). I personally think using the name reference is dangerous, the actual pixel resolution should always be used when communicating with suppliers, design team members, customers, basically everyone. It is dangerous to use reference names because misunderstanding can happen. Try asking someone what the WQVGA resolution is, and you will probably get different answers from different people ranging from 480×272, 480×247, 432×240, 400×234, … You get the idea that this can be pretty confusing.

For a given resolution, you can find different sizes of the display to fit your application requirements. A 320×240 display can be found in the range from 2.4″ to 5.7″. You won’t really find a screen bigger than 5.7″ with 320×240 resolution because each pixel becomes too big and the granularity of each pixel becomes too coarse to an average end user at that point. From my experience, one doesn’t really choose a display resolution first, then the size. It’s more of an iterative process, you define a combination that fit kind of what you are looking for, then check the market to see what out-of-the-shelf components are available, then go back to fine tune your selections and requirements again. Alternatively, you have the option to work with a display manufacturer to custom tooled a display that would fit your need, tooling charge typically applies and what you want has to still be manufacturable by the existing manufacturing process.

Backlight:

Again, wikipedia has a short article on backlight, http://en.wikipedia.org/wiki/Backlight, check it out. Most small to medium size LCD displays for embedded applications are available with LED or CCFL backlight. What you need to know is, most screens that you would choose use LED backlight. The forward voltage to turn on the LED array is different from display to display, but is specified in the display data sheet. The backlight power supply is typically separated from the operating power supply of the display itself which can be 3.3v and/or 5v. Additionally, all LCDs require positive and negative drive voltage. Many displays have this circuit built-in, simplifying the design process. But some don’t and additional external circuitry will be required, so do pay attention to this.

Tags: backlight, display, Graphics, lcd, pixel, resolution, RGB

Grandmother in the kitchen

Let’s take a look at the modern kitchen and the interaction we have with it today.  If you where to standing in the middle of a modern kitchen, or even the local appliance store, you would find that mass about of buttons, knobs, colors displays, buttons that light up, make sounds, and even disappear when not needed.  This could borders on overload for some.

When I look at the modern appliances, one vision that I remember as kid growing up was my Grandmother cooking lunch for me.  It was not a fancy lunch, usually grilled cheese and soup, but the vision of her standing there with her apron on, oversized oven mitts, and wooden spoon in one hand will never leave my mind.  The stove she used was not fancy, but efficient in how the user interacted with it with simple knobs that she could turn to adjust the temperature of the cooking surface.

Today, the style of the appliance is an important aspect when selecting one.  Does it have buttons that light up, or is it stainless steel.  What about a solid surface to clean?  These are some of the items that my Grandmother would look at today.  So how do you operate one of these modern cook top will still keeping your hands inside the oven mitts or even use the wooden spoon to press the off button?  The answer to this question is simple…Inductive touch .

Image if you will a Grandmother standing in front of the stove as a child has just come in out of the cold from building a snowman in anticipation of warm soup.  The Grandmother has on the classic oven mitts, as she just finished making chocolate chip cookies, and is stirring the soup as it begins to boil over the top of the pot.  Instantly she reacts and uses the end of the spoon to press the off key while removing the pot from the hot burner.

The cook top that she is using has single face plate made of stainless steel for the control buttons.  These buttons are etched or silk-screened on the faceplate providing the elegant look and feel demand by today’s consumers.  But how was she able to use the end of the spoon to control the buttons.  The inductive touch solution is a complement to the capacitive touch solutions out there today.  Capacitive solutions make use of the person to change the value of a capacitor and this is hard to do with a wooden spoon.  While the wooden spoon will not work for capacitive, it will work with inductive touch.

Inductive touch makes use of the metal or in this example the stainless steel ability to move.  The movement is so small that the consumer will not even know that it is moving as it only moves about 10 – 20 microns.  That is less than 1/1000 of an inch.  This movement is sensed by a circuit that is mounted behind the user interface panel.  Once the movement is sensed and debounced, the rest of the operation is the same as if there was a mechanical or capacitive button in the design.

Inductive touch technology is not a replacement for capacitive touch, but one that will work in different environments.  For example capacitive touch can sense a finger just slightly above the user surface, where inductive can not.  On the other side, when you clean capacitive buttons you will be pressing the buttons as you wipe across them.  This is not the case with inductive touch as you need to physically press the button to create the deflection.

Now that I have introduced inductive touch to the blog, we will be adding further blogs talking more about the technology itself and some of the other uses for it.

Tags: Inductive Touch

Welcome to Our Blog

If you search the internet for information on user interfaces for embedded systems, you eventually run across the term ‘ubiquitous computing’, and the search for the post-desktop model of human-computer interaction. For the most part, this seems to be an investigation into how the user interface will change as the electronics around us shift from isolation systems to more integrated networks.

This seems to be a laudable goal and I whole heartedly support the people doing the investigation. Unfortunately, it is not something that appeals to me, I am more of a down-to-earth hands-on kind of engineer and to tell you the truth, this goes far enough over my head to seriously boor me (and make my head hurt). So, while I can see the advantages of networking my lights into a house control, I am far more interested in finding easy ways turn on my lights when I get up in the middle of the night. After all, how many of us are really coherent enough at 3:00 AM to navigate a lighting menu.

So, while the computer science PHDs argue over the post desktop model of human-computer interaction, my co-writers and I have decided to put together this blog to explore some new, old, traditional, non-traditional, and even off the wall forms of user interface for embedded controls. Along the way we might find some of the hidden truth the PHDs are searching for, but at a minimum, we can certainly through around some interesting ideas in area of embedded user interfaces.

ug3ybs6i8x

Tags: Embedded User Interface