A case study describing the influence of TFT LCD graphics on automotive radiated emissions testing and its impact to the FM band receiver. The underlying root-cause of the EMI issue is determined using a novel technique that decodes the display’s graphics into the transmitted RGB data and predicts the data’s impact to radiated emissions. The countermeasure implemented to resolve the issue is equally novel and does not involve any hardware optimizations. The use of test images to be used in component level EMC testing is also discussed.
© 2010 IEEE Reprinted, with permission, from 2010 IEEE International Symposium on Electromagnetic Compatibility Proceedings.
In the automotive industry, thin-film transistor liquid crystal displays (TFT LCDs) are being utilized more frequently in navigation units, rear seat entertainment DVD systems, and instrument clusters. As these systems become more complex, so do the EMC issues.
While there are hardware factors to consider such as grounding contacts, interconnect cables, and filtering, an often overlooked factor is the application software for the human-machine interface (HMI.)
The software development typically follows the hardware development. However, when software changes are made after the hardware design is frozen and validated, there is a potential to introduce new EMC issues late in the product design cycle. In the case study presented in this article, late changes made to the product’s HMI graphics introduced a vehicle level radiated emissions issue.
PRODUCT DESCRIPTION
The product in this study is a high end instrument cluster with two 4.2” TFTs driven by a graphics controller. The TFTs are WQVGA (480×272), 18 bits-per-pixel (bpp) displays. The displays are located about a centimeter above the PCB surface and are equally spaced horizontally about the PCB’s center line. Each TFT is connected to the main PCB by a flexible flat cable (FFC).
The HMI graphics are assembled by the graphics controller from the combination of multiple bitmap (BMP) images and alpha masks. From the graphics controller, display information is sent to the TFT via the RGB (Red, Green, Blue) bus. At the TFT display, image data is received and interpreted spatially as pixels displayed as the appropriate combinations of red, green and blue intensities.
The graphics data for each display is transmitted by an 18‑bit wide parallel RGB bus that is referenced to a 10.34 MHz pixel clock. For this product, six bits of parallel data are used for each of the red, green, and blue components of the transmitted pixel data. This is referred to as RGB666 format data.
Also part of the transmission of graphics data are the display enable and synchronization lines. Since the focus of the case study is the transmitted graphics data’s effect on radiated emissions, the display enable and synchronization lines will not be discussed as they are independent of transmitted image. The data patterns transmitted on these lines are constant regardless of the RGB data content.
Worth noting is the use of spread spectrum technology was pursued, but was not implemented because the graphics controller supplier could not guarantee adequate functionality when implemented.
DESIGN PROCESS
The product design process starts with the creation of an EMI control plan. [1] At this time potential EMC concerns are identified and mitigation plans are developed for each item. Floorplanning, constraint development, pre-compliance test strategy and simulation strategy are addressed at this phase also.
After the first PCB goes into layout and critical EMC, thermal and SI/timing simulations indicate acceptable design criteria, the board is built. At this point the first prototype will generally have minimal software functionality to keep the board alive.
After the EMC issues are identified in pre-compliance testing, root-causes are identified and addressed in the second prototype PCB layout. During the second prototype phase, the expectation is to satisfy all EMC requirements. The software development lags behind the hardware design and has greater functionality than the first phase, but is not mature and therefore continues to be under development in contrast to the hardware readiness.
In this case study, the lag between the hardware and software design maturity exposed a gap in EMC issue identification.
For the cluster in this case study, the primary concern after the second prototype phase PCB was built was the emissions in the FM band caused by noise radiating from the pixel clock lines (10.34 MHz). The component level data for CISPR 25 radiated emissions [2] showed a borderline pass with the pixel clock’s 9th and 10th harmonics (93.0 and 103.4 MHz) at the 12 dBuV limit. No other emissions were near the limit. While marginally passing component level was a concern, passing vehicle level FM audio interference testing was a larger concern as component level borderline performance does not guarantee a vehicle level pass. Also, based on customer’s scheduled vehicle testing date and our final production timing, there would not be any time to react with hardware improvements if there were non-compliances.
FM BAND VEHICLE LEVEL FAILURE
When the vehicle level FM audio interference test was run, a failure was reported. The pixel clock harmonics were compliant, but an issue was reported at 87.9 MHz – a frequency that had never shown up at the component level. This was confusing because the same exact sample evaluated a few months earlier showed no component level issues at 87.9 MHz.
Following notification of the FM audio interference failure, the cluster was retested for CISPR 25 radiated emissions at the component level. This time, the 87.9 MHz emission was the only failure at about 17 dBuV (Figure 1). For this frequency, that was nearly 10 dB higher than the component level data collected prior to the vehicle level testing. Also of significance was that emissions at 98.2 MHz and 108.5 MHz had increased. It was noticed that the delta between the three frequencies was 10.34 MHz – the same frequency as the pixel clock, but not a harmonic of the clock’s fundamental frequency. The three frequencies lay exactly midpoint between the pixel clock’s harmonics which could indicate that these may be odd harmonics of a source running half the frequency of the pixel clock (5.17 MHz).
Figure 1: CISPR 25 FM band radiated emissions for software B
If an alternating bit pattern (101010…) were transmitted on any of the RGB lines, it could resemble a clock source. The graphics processor and TFT used in this product design sends one bit of display data per pixel clock cycle. If an alternating bit pattern is transmitted, it takes two pixel clock cycles for the “fake-clock” cycle to be completed. Since the data’s fake-clock cycle duration is twice the length of the pixel clock’s cycle, the frequency will be one-half the pixel clock’s (5.17 MHz).
It was discovered during the troubleshooting that there was a software upgrade after the passing component level tests and before vehicle testing occurred. One change between the original software (here on referred to as SW A) and the software tested in vehicle (here on referred to as SW B) was that the HMI graphics were fully developed for SW B. For SW A, a placeholder graphic was used for a feature that was not yet implemented in the software (Figure 2).
Figure 2: HMI test screens for SW A (left) SW B image (right)
The change in the graphics combined with the frequencies of the negatively affected harmonics aligning with a two-bit data pattern indicated a further investigation should be made into the graphics change.
As mentioned, the possibility of alternating bit patterns on the RGB data lines was thought to be the most likely cause of deterioration in performance between SW A and B. One challenge would be to identify where in the image this pattern of 1s and 0s existed. Also, if the pattern was found, could anything be done about it?
From a hardware perspective, the best option was to identify the noisy RGB nets and filter accordingly. This course of action was far less favorable because the production level PCB design had already been released.
Since a software solution was preferable, LabView code was developed to read bitmaps for the HMI graphics and reproduce the transmitted RGB data patterns. The hope was that one of the BMPs used to construct the HMI graphics could be identified as the primary noise source and be quieted through pixel modifications.
SIMULATING RGB DATA PATTERNS FROM BITMAP IMAGES
To understand how the RGB data patterns can be extracted from a bitmap image, it is helpful to understand bitmap images and how the processed data is output to the RGB bus.
Bitmap Images
A bitmap image represents an image through a grid of pixels defined by RGB triplets (r,g,b.) [3] These pixels form points of color which contribute to an overall finished image. Each component of the RGB triplet is represented as an integer to indicate its intensity in the pixel. Black would be indicated by an RGB value of (0, 0, 0). White would be represented by the RGB value (255, 255, 255) where red, green and blue are at maximum intensities. The maximum value of 255 is true for 24 bit bitmap images (8 bits/color). The maximum value is defined by the following equation:
Depending on the hardware and RGB data format used in a graphics application, there can be less than 24 bits of data output from the graphic processor. Formats such as RGB555 (15bpp), RGB565 (16bpp) and RGB666 (18bpp) are commonly used in the automotive industry and require the graphics data to be scaled down from the BMP color depth of 24bpp.
When the color depth is reduced from 24bpp, the graphics designer needs to account for the loss in resolution and will sometimes have to implement dithering techniques to prevent banding. Banding is when abrupt changes in color occur due to the loss of color depth. Dithering gives the illusion of seamless transitions between colors.
To explain how the RGB data sequences are extracted from graphics data, this explanation will be kept simple by assuming the graphics processor utilizes an RGB888 (24 bpp) format from which the data is being output in parallel to a 24 bit wide RGB bus. Within the bus, each color component has eight lines. Each line sends data for one of the eight bit positions of the color’s value (Figure 3).
Figure 3: Bitmap pixels conversion from RGB components to binary bit planes
During a pixel clock period, the 24 bits of RGB data defining a single pixel are transmitted. Pixels are transmitted in horizontal lines. At the end of each line the transmission continues from the beginning of the next line. This continues until the last line is sent at which time it returns to the top, continuing with the next frame. At the beginning and end of the horizontal line data, there are the front and back porches which are margins around the graphics data for horizontal line synchronization. There are front/back porches in the vertical direction which exist before the first and after the last line of image data. The data for these porches are sent as binary 0s.
Based on the sequence of pixel transmission and the conversion of the pixel’s color components to binary, the data patterns on each of the RGB data lines can be determined.
Graphics Analysis Software
The graphics analysis software allowed the conversion of the loaded graphics data to representative data streams for each of the RGB data lines. From these data sequences, potential noisy graphics can be identified. The software had the ability to show each of the 18 RGB data line’s frequency content in addition to its binary image otherwise known as a bit plane [4].
The frequency content of a data stream allows noise producing patterns to be identified. From the frequency profile, a noise source’s fundamental frequency can be identified. With the following equation, the number of bits in the pattern can be identified:
When the number of bits in the pattern is known, the corresponding bit plane can be searched for the pattern to reveal the locations of potential EMI issues within the image. It is important to note that these patterns need to be searched for in the frame’s horizontal lines – the same direction the data is transmitted. The presence of these patterns in the vertical direction is not relevant to the frequency of interest.
Putting the Software to Use
From the BMP objects, a composite BMP was constructed for the HMI screen that caused the issue at 87.9 MHz. Next, using the analysis software, the image was analyzed for frequency content. Several of the RGB data lines indicated higher frequency content at 5.17 MHz – the fundamental frequency of the 87.9 MHz harmonic. This confirmed a two pixel pattern was the source. Examination of the bit plane images revealed the same region in twelve of the 18 bit planes as having varying degrees of the alternating bit pattern (Figure 4). The region of the HMI screen causing the issue was a horizontally oriented “fade” object.
Figure 4: Bit planes for original “fade” BMP object
Using another feature in the analysis software that highlights the number of RGB bus lines concurrently transmitting the alternating bit pattern, it was revealed that one of the frame’s rows had twelve RGB lines concurrently transmitting the pattern (Figure 5). The reason the emissions issue did not present itself in SW A was the placeholder graphic masked the majority of the fade.
Figure 5: Number of RGB bus lines exhibiting occurrences of 101010 data pattern within “fade” BMP object
The alternating bit patterns were present in the three least significant bit layers (lsb) for each color component. The color intensity contribution of the lower significant bits to the image is less and is hard to detect by eye. This makes detecting patterns by eye near impossible.
The msb layer, when viewed as an image, shows the roughest and most critical contribution of the color component. The second msb layer contributes half the intensity of the msb. Each subsequent layer contributes half the intensity of the layer prior to it. The lsb layers are the most difficult to see and generally contain the highest number of data transitions.
ROOT CAUSE AND SOLUTION
The cause of the repetitive pattern nature in the fade pattern was due to dithering. To correct the occurrence of the alternating bit patterns, the fade object was redrawn to avoid or reduce the cumulative bit patterns found earlier and retested at a component level for radiated emissions in the FM band. The noise level at 87.9 MHz dropped about 7 dB and the other odd harmonics of 5.17 MHz at 98.2 MHz and 108.5 MHz dropped sharply (Figure 6). The pre-compliance radio listening test was run and also showed a dramatic improvement.
Figure 6: CISPR 25 FM band radiated emissions for corrected fade object
TEST PATTERNS
As this case study has shown, testing with an unfinished HMI image in the early design phases can lead to unexpected issues showing up if there is a change to the tested graphics. Potential issues can also go untested when the product’s worst case HMI selection has not been chosen for testing. It is very possible an untested sub-menu will produce higher emissions than the HMI configuration chosen for testing. A robust test pattern causing the RGB bus to be exercised in a realistic worst-case manner reduces the need to evaluate all HMI configurations. Since it is not feasible to test every option in every submenu, a robust test pattern causing the RGB bus to be exercised in a realistic worst-case manner can assure the product is being adequately tested. With a robust test pattern available early in the design cycle, potential issues can be identified and mitigated without having to wait for final graphics to become available.
The challenge in defining a test pattern is determining what defines a realistic worst-case image. With the sample set of graphics limited to a few products, there is not enough data for the author to determine what criteria would define a realistic worst-case test pattern that could apply to the entire automotive industry.
Further complicating the implementation of a common standard to which a test pattern is defined is there are multiple factors that vary from product to product that affect the resulting data streams. For example, the method with which an image is converted from the original graphic to the transmitted binary data sequences is dependent on the graphics processor and the display requirements of the display. A pattern designed for one product may be ineffective for another product if there is a difference in
color and display resolution. If quantizing and rescaling to the test image occurs, data interpolation may cause the intended data to be altered and ineffective. Also, a test pattern created for use on a parallel RGB bus will be ineffective for a product transmitting RGB data by low-voltage differential signaling (LVDS).
If it is understood how an image is converted to be read by the graphics processor, subsequently processed and output to the RGB data lines, a test pattern can be created. The test pattern will likely have to be unique to the product unless there are hardware commonalities with other products. Certain criteria pertaining to the data sequences on the RGB nets should be met when designing the test pattern. By starting with defining the binary data sequences on each of the RGB lines, a pixel pattern can be establish to create a test image.
Using this method of building the pattern in reverse by starting from the binary data sequences, a test pattern was developed for the product in the case study (Figure 7). The two main factors considered when defining the data sequences for the 18 RGB nets were the noise frequencies to generate and the number of nets to be simultaneously sending the same sequences.
When deciding the fundamental frequencies to generate, consideration was given to the frequency ranges that were to be tested. In the case study, a two bit sequence producing a 5.17 MHz fundamental frequency was responsible for FM band issues. Also, other lower level harmonic emissions were present in the measurements as a result of bit patterns that were from four and ten bit cycles. These cycles produced harmonics of 2.59 MHz and 1.03 MHz respectively.
One intention for the test pattern design was to stay consistent with the problematic fade graphic and to keep the fundamental frequencies above 1 MHz. For the test pattern’s design, cycles of two, three, four, five and ten bits were distributed between the 18 RGB nets. To expose all nets to the different data cycles, the data sent on each net was alternated between the different bit cycles after every line within the frame.
The second intention was to replicate the occurrences of simultaneous data cycle transmissions over multiple nets. In the case study there was one line of pixels in the frame that produced the toggling bit pattern on twelve of the 18 nets. It is difficult to say whether twelve nets concurrently toggling the ‘101010’ pattern is a realistic worst case or an outlier due to bad dithering within the fade pattern. For seven of the frame’s lines, six nets concurrently transmitted the toggling bit pattern. When examining the entire library of graphic images used in the design, it was not uncommon to see six nets simultaneously sending the same pattern. This was particularly true in gradients.
For the product in this case study, hundreds of graphic objects were evaluated and fewer than five percent showed any significant frequency content. The ones that did have notable frequency content had one thing in common – they contained gradients. In particular, the gradients were fades between gray and black. Gray gradients exercise the RGB bus more severely than other colored gradients because red, green and blue components are needed to build the different shades of gray.
Since gradient fades of gray to black were the common factor between all the graphic objects showing elevated frequency content, lines of gradient fades were integrated into the test pattern.
CONCLUSION
The experience gained through this case study shows the value of having a test image that effectively exercises the RGB bus early in the design cycle. A realistic worst case test pattern will allow future products to have EMC issues identified and mitigated in the early design phases. Also, it is not possible or realistic to have all HMI graphic combinations evaluated, but a realistic worst case test pattern reduces the concern for untested HMI configurations presenting issues late in the product design cycle.
This case study shows that it is possible for a graphics object covering a small percentage of a frame to cause radiated emission and radio listening issues. The possibility of a single graphics object affecting performance is very real. By not having an image that adequately exercises the RGB bus, the supplier and the original equipment manufacturer (OEM) can gain a false sense of security and be unpleasantly surprised when it is too late to make an easy fix. 
REFERENCES
- S. Mee, S. Ranganathan, R. Taylor, “Effective use of EMC Analysis Tools in the Automotive Product Development Process,” 2005 IEEE International Symposium on Electromagnetic Compatibility, August 2005, Chicago, IL.
- International Electrotechnical Commision, “International Special Committee on Radio Interference Document 25 (CISPR 25),” International Electrotechnical Commission Central Office, November 2002.
- Maureen C. Stone, “Representing Colors as Three Numbers,” IEEE Computer Graphics and Applications, Volume 25, Issue 4, pp. 78-85, July/August 2005.
- Ramiro Jordán, Roberto Lotufo, 1995, “Bit Plane Splicing,” .
- S. Ranganathan, S. Mee, “Automotive EMC Measurement Techniques Based on New Technologies and Vehicle Packaging,” IEEE International Symposium on Electromagnetic Compatibility, August 2008, Detroit, MI.
Steve Mainville, Johnson Controls, Inc., Automotive Experience, steven.m.mainville@jci.com
