Replacing an unknown RGB LCD panel with a generic type - Advice needed please

[Fraser]

Some time ago I purchased a faulty FLUKE TiS10 thermal camera as a little project. It has a totally broken LCD panel.
Now FLUKE chose to use a custom RGB LCD Panel in this camera to make my life more exciting. By ‘custom’ I mean that it uses a non ‘standard’ pin count on the ribbon cable but is likely a conventional QVGA RGB panel electronics.

Whilst I am not a beginner in electronics, I most certainly am when it comes to grafting a generic RGB LCD panel into a product that used a customised panel. Hence why I am asking for advice here 

Some details to consider......

The original LCD panel is a colour RGB TFT type that appears to be parallel driven due to the pin count on the ribbon cable. The ribbon cable contains 22 conductors. Whilst the original panel may be a Winstar product, I cannot find such a panel that uses only 22 connections, but then I am no expert on LCD panel driving ! I am thinking that a standard panel is used with a custom ‘cut down’ version of the ribbon cable that also has the FLUKE PCB connector attached.

The Controller that drives the LCD panel is a Texas Instruments SoC DM3730 that, according to the datasheet, can provide either serial or parallel interfacing to the LCD panel. I am thinking that 22 pins from the LCD panel is too many for serial drive but appears too few for parallel drive. That said, my research suggests that there are different bit widths for RGB parallel drive to an LCD panel so FLUKE may just be using RGB565.

Here is the original post I made about the FLUKE camera diagnosis and I attach some pictures here as well.

https://www.eevblog.com/forum/thermal-imaging/fluke-tis10-thermal-camera-fraser-has-a-new-patient-)/

Basically, I intend to fit a generic QVGA parallel drive LCD panel in place of the original FLUKE item. My first thoughts were to attempt identification of the pins on the FLUKE LCD connector using an oscilloscope in combination with the DM3730 datasheet pin out. Has anyone had experience of carrying out such ‘experiments’ involving fitting a generic LCD panel with full RGB bit width into a system that requires fewer bits in the parallel LCD drive ? I understand that on some generic LCD RGB panels you can just ground RGB pins that are not needed and the panel does not complain. Determining the FLUKE connector pin out of the three colour signals could prove to be ‘fun’ !

Any advice would be much appreciated  

Fraser

[Fraser]

So to my initial questions........

1. Am I correct in thinking that 22 connections to an LCD panel is enough to drive it in RGB parallel mode ?

2. When an embedded controller is not needed in an RGB LCD panel, is there anything else that will likely prevent a generic panel working in my LCD grafting scenario ? The RGB panel has drivers but hopefully there is no compatibility issue between 'dumb' panels?

3. How best to identify the various Red Green and Blue channels and bit order when a test card or plain R,G or B display cannot be produced by the host computer system ? I was considering creating a thermal scene that would create an, all Red, All Green and all Blue display but without the LCD panel, I cannot configure the Fluke camera !

4. Any other advice on such an 'unknown LCD' profiling task ? All hints and tips welcomed 

Fraser

[Fraser]

Further information.....

I purchased a Winstar WF35LTIACDNNZ# LCD panel as the replacement for the original item, at least during the testing phase. I attach the datasheet in case of interest. The panel appears to be a generic item and very common in the marketplace. I am hoping that it is a versatile type that will work for me.

Fraser

[jmelson]

Well, the most obvious method would be to trace the connector back to the controller pins.  UGH, it's a BGA!
Well, is there an LCD controller/interface chip on the damaged panel?  Can you get a datasheet for that and work fron there?

Also, the controller may have other modes where it sends 8 bits of parallel data at a time, that might fit into a 22 pin cable.

Jon

[Fraser]

Hi Jon,

Thanks for the comments.

Yes.... Ugh....it’s a BGA chip  As you say, life is a lot easier when there are pins to probe.

I have carefully inspected the original LCD panel, including dismantling it and removing the rubber coating from over the CoG IC. Sadly there is nothing ,beyond a proprietary manufacturers ID, to identify the LCD panel or the chip that is mounted on it. I am hoping that it is ‘just’ the standard, relatively ‘dumb’ V and H drive chip found on many similar display panels.

At the end of the day, I may just have to rig up 22 flying wires, connect up the power, control and clock wires and wing it from there with the RGB signal pins to see what, if anything, the LCD displays. I just wanted to tap the wealth of knowledge that exists on this forum first as others may have ‘played’ with these types of ‘dumb’ LCD panels and know how they behave. The idea that the panel is using only some of the RGB bit width is a possibility as the colour pallets of a thermal camera is not exactly demanding.

Thanks again

Fraser

[Fraser]

The original LCD panel has the part ID “OSIE320240-035-A, which is easily decoded to the Manufacturer being OSIE, the resolution being 320x240 pixels and the size being 3.5”. They”A” is likely a revision indicator. Sadly OSIE specialise in providing custom display panels for OEM’s. No data sheet could be found.

https://www.osielectronics.com/electronic-manufacturing-solutions/custom-electronics-displays/

Fraser

[jmelson]

Actually, your first schematic shows a 16-bit data bus, and then more extended data bits.  I'm guessing they may not use all of the 16-bits, and most certainly couldn't be using the extended ones.  So, maybe up to 16 bits plus hor and vert signals and power.  Power ought to be identifiable by decoupling caps.  I'd try powering it up and scoping the pins.  Sync should be easily detectable.  the data bits might be detectable by pointing the camera at objects and sweeping it from side to side.

Jon

[Fraser]

Jon,

Thanks. I totally agree about the 16 bits. I was thinking RGB565 (5+6+5 = 16bits)

As you say, I may just have to identify the easy connections with my scope and experiment with the camera to identify the bit  allocations.

I have already mapped out the conductors in the LCD panel ribbon cable to identify the obvious power and ground conductors. I could also see which conductors likely carry data from their grouping together. Hopefully they are laid out in a logical manner such as R data, G data and B data  I can hope !

Fraser

[Fraser]

I have done some reading on the TI web site regarding driving a 24 bit (RGB888) LCD panel with a 16 bit (RGB565) input. There are two ways to do it.....

"There are two ways to interface RGB565 to RGB888.

1. Connect the RGB888 unused LSB's (B - D0, D1, D2, G - D8, D9, R - D16, D17, D18) to GND. In this configuration, the mentioned portions are always black in pixels.

2. Connect the RGB888 unused LSB's to MSB's (B - D0 to D5, D1 to D6, D2 to D7, G - D8 to D14, D9 to D15, R - D16 to D21, D17 to D22, D18 to D23). In this configuration, the mentioned LSB portion replicates the color of MSB to which it is connected."

[ucanel]

Not the same situation but this video may give some directions:
https://youtu.be/T-o-ibGUEoA

Display part is at about 8.00
but video is very well presented, you will watch all of it

[mikeselectricstuff]

Apart from the RGB data, the only other lines are likely to be HS,VS,DE and CLK
Each of these are easy to find - CLK is the fastest (low10s of MHz),VS  is the slowest (tens to low hundreds of Hz), DE is a composite of HS and VS, high ( or low)  during the active part of each line in the active frame. Sometimes HS isn't used at all.
You will need to use an LCD with exactly the same resolution as the original.
Parallel RGB panels rarely have any additional controls (I2C etc.) but not unknown.
It is highly unlikely that there is any signals going back from the LCD to the host. 
Identifying RGB shouldn't be that hard. The bits are almost certainly going to be in order along the cable, i.e. 0..n or n..0 on consecutive pins.
With a relatively "flat" image, the LSbits will be changing the most due to remaining noise, so it's not hard to identify the bit order, and where one RGB channel starts and the next one ends.

[Fraser]

Thanks Ucanel and Mike,

Mike,

Your comments are exactly what I need to move forwards. As stated, I am a total beginner when it comes to modifying RGB888 panels to replace a custom product. I was likely worrying about nothing but thought there could be some 'Gotchas' that I might need to be aware of. Your comment regarding a flat thermal scene and the noise content LCD signal is excellent  I should have thought of that ! Very helpful 

Ucanel,

I will look at that video in a minute. Thank you 

[ucanel]

Good to hear from Mike because i was trying to remember a specific video series and i could not remember it.
While searching that video series i ran into another one i had watched the one i gave the link in above post.

The video i was searching for is @mikeselectricstuff
Ipod Nano Lcd Series
https://youtube.com/playlist?list=PL0KZLmPyL6Ak1bArDuLo77yhx95yMsjHL

Thanks Mike i will watch it again now

[Fraser]

Thanks ucanel.

I just ordered a FPC breakout PCB to make the testing easier. It is located in the UK so should arrive early this coming week.

I was originally going to wire directly to a 54 pin FPC connector but the 0.5mm makes that a PITA so a breakout PCB is the sensible way to go.

Fraser

[Fraser]

While I await the arrival of the FPC breakout board, I will capture the activity on all of the LCD connector pins on the cameras main board. I just bought a MICSIG ATO1102 DSO and this will be its first use on a project. Hopefully by the time the breakout board arrives I will be ready to make the connections from a position of knowledge, rather than stumbling about in the dark. I will document the process here as it may help others faced with a similar challenge 

[simmconn]

Great. I'm tasked to find a replacement of the exact same LCD panel, only that the 'customer' is in a different location and I don't have access to either the thermal camera or the broken panel.

Have you tried to contact Fluke and see if they still offer a replacement part？

A bad situation would be that the original panel works somehow like your replacement, and needs some host configuration from SPI or I2C. The host CPU tries to detect the panel, if it is not there, decides not to turn on the LCD interface data output.

Waiting for your updates.

[Fraser]

I was quoted $480 for a new LCD panel and there would be shipping and 20% VAT on top of that for shipping to the UK. This was from an official Fluke service agent. Generic parallel drive RGB panel costs as little as $13 plus $2 for the ZIF connector, so it is worth the effort to attempt a Generic panel conversion. In my case, I do not even need the camera, it is just a hobby project that I am enjoying.

You will need the camera, or at least the original LCD panel, for this repair as it requires the original LCD connector that mates with the motherboard.

I am hoping that the panel is not something ‘special’ but we will see. The replacement will need to be the same dimensions, orientation, resolution, parallel RGB drive, LED backlight and a suitable viewing angle. With regard to viewing angle there are three common options..... 12 O’Clock, 6 O’Clock and perpendicular. If the LCD panel requirement of the camera is nothing ‘special’ there is plenty of availability of generic QVGA Parallel RGB drive panels to choose from

More when I have news

Fraser

[Fraser]

Just a small update.

The results of testing were not quite as I was expecting. The LCD clock is running at ~19.6MHz and there are only 8 data lines. The two sync signals are as follows ....  HSync = ~14.6KHz  and VSync = ~54.2Hz.

I am currently studying LCD panel driving theory to establish what I am dealing with here. I will be revisiting Mikes Apple IPod Nano display investigation as well. There is mention of MIPI DPI and DBI 2.0 B in the TI datasheet for the DM3730 so some study of that will also follow.

[mikeselectricstuff]

MIPI would be pretty obvious as lines on PCB will be paired.
If the data is changing at the same rate as the clock it's definitely not MIPI, as that usually uses a clock multiplier
It's possible the data might be DDR, or alternate bytes of a 16 bit pixel per clock.
Both should be discernable by looking at data waveform relative to clock
There seems to be a big shortfall between 320x240x54.2Hz = 4.162MHz and the 19.6MHz you are seeing. By the time you account for borders, 3x looks plausible - 24 bits per pixel perhaps.
This should be fairly obvious from the data - you'd see a repeating pattern every clocks.
See if the TI chip supports this format.

If this is the case, it may not actually be that hard to convert to a conventional parallel format - some latches and a counter to de-multiplex the stream

[Fraser]

Mike,

It is looking like it is a MIPI DPI interface rather than the DBI or DSI types. I have found a datasheet for sale a COG LCD driver with DBI and DPI input so I will study that. Sadly I have yet to find a QVGA MIPI DPI LCD panel but I searched only briefly for one.

Thanks for your help Mike 

Fraser

[Fraser]

OK, the camera does use a MIPI compliant interface to the LCD panel. I have managed to obtain the technical manual from TI for DM37xx series. It is a controlled document for an IC that is not available to the general market. The document contains the MIPI information that I need and that is also controlled information. I am indeed fortunate that TI released this document to me. The technical manual has 3674 pages and it contains an awful lot of useful information that will hopefully enlighten me on the operation of the display interface

For information, there appears to be three MIPI compliant possibilities for driving the cameras LCD panel. DPI, DBI and DSI. Finding any information on DPI and DBI is challenging and you have to apply to MIPI for the technical documents.

[Fraser]

For anyone wondering what the MIPI Alliance is........

https://en.m.wikipedia.org/wiki/MIPI_Alliance

To repair the FLUKE TiS10 I will need a MIPI DPI compliant 3.5” 320x240 pixel LCD panel. Such are not common as MIPI DSI compliant panels are the currently preferred standards in mobile devices. A standard Generic parallel RGB drive panel does not appear to be a viable replacement for a MIPI panel without some form of Bridge interface IC.

Sadly this investigation may end here as the TiS10 is not worth spending a lot of time on 

We shall see

[Fraser]

The datasheet for a MIPI compliant parallel drive LCD controller is to be found here.....

https://cdn-shop.adafruit.com/datasheets/HX8357-D_DS_April2012.pdf

An 8 bit wide DBI data bus is detailed on page 19 but not a 8 bit wide DPI type.

I am still deciding whether I am dealing with a DPI or DBI interface in the TiS10. Both a parallel but I will need to study what I thought to be timing signals to determine their exact nature.

[Fraser]

This ST application note provides some simplified descriptions of the MIPI display interface types from page 8 onwards......

https://www.st.com/resource/en/application_note/dm00287603-lcdtft-display-controller-ltdc-on-stm32-mcus-stmicroelectronics.pdf

I had not heard of MIPI or the MIPI alliance before embarking upon this little project so even if I cannot fit a new LCD panel, I have broadened my knowledge of modern interface standards 

Fraser

[Fraser]

Things may be looking up

As I have already stated, LCD panel interface standards are not something with which I am very familiar so this is a voyage of discovery for me. I realised that if MIPI have produced a standard for interfacing a LCD display panel to a microprocessor architecture, those LCD panels cannot be that rare ! I have previously focussed my attention on the most common ‘dumb’ RGB parallel drive LCD panels and ignored the panels that contained a built in ‘intelligence’. That was a mistake. The common Dumb parallel drive LCD panels use 40, 50 or 54 pin ribbon interfaces. The fact that the Fluke LCD has only 22 connections in its ribbon was a definite clue that the LCD panel might contain some ‘intelligence’ that reduced the I/O pin count whilst maintaining the colour bit depth. I think I just did not want to ‘see’ that fact because a built in LCD controller can make life complicated if you do not know it’s identity !

So where to go from here ..... in a word.... Research ! I need to better understand the MIPI interface standards and those offered by ‘Intelligent’ LCD panels commonly found on eBay, but that that do not state MIPI compliance in their title. I already chose one at random to research as it gave the controller chip identity. The data sheet for that controller chip makes mention of different interface methods that may help me to understand and identify any comparability between MCU interface LCD panels and the MIPI compliant panels. MIPI is a licensed standard so some Chinese OEM’s may choose to not use MIPI in their descriptions of a MIPI compliant panel. It certainly makes sense to me that there will be MIPI compliant/compatible LCD panels coming out of China if MIPI is a Worldwide standard for interfacing in mobile equipment, such as phones etc. I am currently looking at the various data sheets for MCU interface type LCD panels.... such as this datasheet to be found here for the ILI9431.....

https://cdn-shop.adafruit.com/datasheets/ILI9341.pdf

I am used to reverse engineering hardware and openly admit that I am a Dinosaur when it comes to working in the digital data domain that exists inside modern digital systems. I am pleased that I started this thread in the Beginners area of the forum rather than in ‘Repair’ as I certainly feel like a Beginner when it comes to unravelling the digital data domain within the TiS10 camera ! Sometimes the knowledge gained during such an investigation far outweighs the intrinsic value of the ‘patient’ and this may well be such a case for me  For any fellow Newbies to any topic, I say to you.... do your research and gain knowledge along the way. It may prove invaluable to you in the future and is far better than just asking a question on a forum and being given the answer without gaining any understanding behind that answer.

Fraser