This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DLP4500: Two bit planes of red, green , and blue, are not showing on the DMD

Part Number: DLP4500
Other Parts Discussed in Thread: DLPC350,

Hi,

We have a DLP4500-AFQD which is being driven by a custom board with a DLPC350 chip.
We are supplying a video signal into the LVDS port of the DLPC350 which is being sequenced onto the DMD.

One test we perform is to set the DMD into pattern streaming mode from the video port, and select only a single bit plane at a time (0, 1, .... through to 23) and ensure that we can see the image corresponding to that bit plane.
(The test image is something like this, where each bit plane has a different number in it, making it easy to see on the DMD).

 

This test typically works fine, but recently we have had a situation where we see nothing on the DMD when we select bit planes 0, 1, 8, 9, 16, and 17.
That is, when cycling through the bit planes, we can successfully see all numbers except 0, 1, 8, 9, 16, and 17.
In other words, it looks as if there are now only 6-bits for red, green, and blue.

Interestingly, it looks like the bit planes that are not visible are the first two bits of the red, green, and blue channels.

We have a hub in the system so that our video signal goes:
Laptop --> (USB3.0 Hub (USB-C connector) with HDMI port out) --> (Custom board for conversion from HDMI to LVDS) --> DLPC350 --> DLP4500

If we remove the Hub from the chain and go straight from Laptop --> (Custom board...) then we get the missing bit planes back.

In addition, we are testing a new custom PCB for connecting to the electrical pads of the DLP4500-AFQD part.

Questions:
1. could the Hub cause something like this?  How?
2. could the new custom PCB for connecting with the DLP4500-AFQD cause this? How can we diagnose this? (perhaps some of the data tracks are degrading the signal?)
3. Does TI offer any PCB checking services e.g. to look over some of our custom boards to see if they are in spec?

4.  In general, what can cause this problem?

Many thanks,

Oliver.

  • Another question:
    5. are you able to provide any more information about how exactly the DLPC350 transfers pattern data to the DLP4500?
    Section 8.1 in the datasheet of the DLP4500 says "The CMOS memory array is addressed on a column-by-column basis, over a 24-bit DDR bus" and then the DLPC350 datasheet says "DMD data pins. DMD data pins are double data rate (DDR) signals that are clocked on both edges of DMD_DCLK.".
    Does this mean that on each edge of the DMD_DCLK signal, 24 mirrors worth of data is transferred?
    So in general, each data line corresponds to the state of a single mirror?
    (We are trying to better understand how any defects in out PCB routing might effect the data going to the DMD)

    Thanks.

  • Hi Oliver,

    If the hub cannot handle 24-bit RGB data, then we recommend using  a separate piece of hardware. Please provide some more information on your system schematics so that we can review with our hardware team. 

    For more information on the interface between DMD and DLPC, please see the DLP4500 datasheet here: https://www.ti.com/lit/ds/symlink/dlp4500.pdf

    Thank you,

    Chris

  • Hello Oliver,

    Welcome to DLP forum and  thank you for your interest in DLP technology.

    I assume that you have your own board and not using TI EVM.

    Laptop --> (USB3.0 Hub (USB-C connector) with HDMI port out) --> (Custom board for conversion from HDMI to LVDS) --> DLPC350 --> DLP4500

    If we remove the Hub from the chain and go straight from Laptop --> (Custom board...) then we get the missing bit planes back.

    In addition, we are testing a new custom PCB for connecting to the electrical pads of the DLP4500-AFQD part.

    Questions:
    1. could the Hub cause something like this?  How?

    Based on your description , it seems the hub is causing a problem. When you drive directly from Laptop  through HDMI port , it works. It is very difficult to guess why? One of the  possible reason - Hub is converting data from Type C to HDMI (video over type C). The HUB is treating the data as video image and processing it is based EDID description of HDMI in the custom board. There could be miss-match.

    2. could the new custom PCB for connecting with the DLP4500-AFQD cause this? How can we diagnose this? (perhaps some of the data tracks are degrading the signal?)

    Your previous statement says, image plane are back if you drive it directly. If that is true, this should be be the cause.

    3. Does TI offer any PCB checking services e.g. to look over some of our custom boards to see if they are in spec?

    Such services can get through our third-party network . Please contact them directly.

    https://www.ti.com/dlp-chip/display-and-projection/pico-chipsets/buy-optical-engine/design-houses.html

    5. are you able to provide any more information about how exactly the DLPC350 transfers pattern data to the DLP4500?
    Section 8.1 in the datasheet of the DLP4500 says "The CMOS memory array is addressed on a column-by-column basis, over a 24-bit DDR bus" and then the DLPC350 datasheet says "DMD data pins. DMD data pins are double data rate (DDR) signals that are clocked on both edges of DMD_DCLK.".
    Does this mean that on each edge of the DMD_DCLK signal, 24 mirrors worth of data is transferred?
    So in general, each data line corresponds to the state of a single mirror?

    The Controller send one bit plane at time i.e. single bit data for all pixels in the DMD is sent at time. 

    regards,

    Vivek

  • Hi Vivek,

    Thanks for your reply.
    1. We have tested by using a different brand of Hub, which does not seem to cause those issues.  We have a custom EDID structure, can we send this to you by email for inspection?
    2. The "missing" bit planes are missing when we use the hub, but are present when not using the hub.  In both these cases we are using the SAME custom PCB.   So, putting the hub into the system causes the bit planes to go missing.  Can the custom PCB cause only some of the bit planes to go missing, perhaps because the addition of the hub changes the timing ever so slightly?
    3. Thankyou, we will reach out to them.

    5.
    Thanks for the explanation, but I was hoping for a bit more detail.
    For example, I see that the DCLK is the data clock for the DLP4500.  And on the rising AND falling edges, data is clocked in.  Does this mean that:
    on the first rising edge of DCLK:
    the data lines D0 - D23 are the pixel values for mirrors on rows 0,1,2..23 on column 0
    on the following falling edge of DCLKL:
    the data lines D0 - D23 are the pixel values for mirrors on rows 24, 25, 26...47 on column 0
    on the following rising edge of DCLKL:
    the data lines D0 - D23 are the pixel values for mirrors on rows 48, 49,50...95 on column 0
    etc.

    is that correct?

  • Hello Oliver,

    I am glad to hear that you found another hub which works well.

    2. The "missing" bit planes are missing when we use the hub, but are present when not using the hub.  In both these cases we are using the SAME custom PCB.   So, putting the hub into the system causes the bit planes to go missing.  Can the custom PCB cause only some of the bit planes to go missing, perhaps because the addition of the hub changes the timing ever so slightly?

    The hub is transforming the data. It is difficult to say/guess what the format and content of the data to custom PCB.

    hanks for the explanation, but I was hoping for a bit more detail.
    For example, I see that the DCLK is the data clock for the DLP4500.  And on the rising AND falling edges, data is clocked in.  Does this mean that:
    on the first rising edge of DCLK:
    the data lines D0 - D23 are the pixel values for mirrors on rows 0,1,2..23 on column 0
    on the following falling edge of DCLKL:
    the data lines D0 - D23 are the pixel values for mirrors on rows 24, 25, 26...47 on column 0
    on the following rising edge of DCLKL:
    the data lines D0 - D23 are the pixel values for mirrors on rows 48, 49,50...95 on column 0
    etc.

    is that correct?

    The DLPC350 controller has two image buffers  It writes in incoming image data in to one buffer. While it is receiving  the current image frame , the previous image which stored in other buffer is processed and  displayed om the DMD. After the complete current frame buffers are swapped.

    The image data (912 x 1140) pixel image is  sliced  into 24 bit planes. The bit plane 0 contains bit 0 of each pixel in the image. The Bit plane 1 contains the bit 1 of the image , and so on. 

    One complete bit plane is displayed on DMD at time. Please refer to page 27 of DLPC350 datasheet , in section 8.1 it explains bit planes.

    https://www.ti.com/lit/ds/symlink/dlpc350.pdf

    Hop this explains.

    regards,

    Vivek

  • Hi Virek,


    Thanks for your responses.

    Regarding number 5. I was actually wondering how exactly the data is transferred across the parallel bus from the DLPC350 to the DLP4500 chip.  Are you able to provide some details on this?

    To put it another way, you say "One complete bit plane is displayed on DMD at time", my question is, how exactly does that bit plane get to the DLP4500 from the DLPC3500?

    Many thanks.


  • To put it another way, you say "One complete bit plane is displayed on DMD at time", my question is, how exactly does that bit plane get to the DLP4500 from the DLPC3500?

    Hello Oliver,

    I am  not able to understand the intent or question. The bit is transferred from  controller to DMD over data lines. The DMD is organized in vertically split blocks. The data is transferred one block at a  time .

    regards,

    Vivek