DLP550HE: Binary pattern rate and other questions

Part Number: DLP550HE
Other Parts Discussed in Thread: DLP7000, , DLPC410, DLPC4430, DLP651LE, DLP5500, DLPC900, DLPLCR55EVM, DLPLCRC900EVM

Tool/software:

Hi, I have a few questions about 13.8um pitch DMDs. Can you confirm if only DLP7000 and DLP550HE have this pitch?

Our application requires larger pitch and height of optical area together with smaller resolution in terms of pixels.

I want to understand to what extend DLP550HE could be useful for binary pattern applications, basically in the area where DLP7000 excels.
What is the realistic binary pattern rate of DLP550HE? If it's capable to do 5kHz it will perfectly fit our application. And finally, our optical power will not exceed 20mW/mm2. Will DLP550HE support this, provided that we make sufficient heatsink ad cooling to keep the DMD in acceptable temperature range.

Thanks!

  • Hello Karen,

    I am not aware of any other 13.68 um pixel pitch DMDs.  This was a very early architecture pixel and as such there are very few products that still have this pitch.

    The DLP7000 is driven by an FPGA based controller - the DLPC410, which is basically a binary passthrough controller.  That is why it can be so fast.

    The DLPC4430 which drives the DLP550HE is a display controller and as such this controller does not comprehend binary pattern display in the way that you desire.

    Your optical power of 20 mW/mm^2 translates to 2 W/cm^2 which should still be fine.  Just make sure to provide a thermal solution to dissipate any heat.

    Fizix

  • Thanks for quick reply. So that display controlled approach basically discards the idea of DLP550HE. I also shortlisted DLP651LE, 10.8um pitch but looks like it's being driven by the same chipset. Apart from DLP7000, does TI provide other, less expensive FPGA based solution that would still be good for approx. 5kHz binary patterns?

  • Karen,

    If you are considering a 10.8 um pixel then the DLP5500 (XGA) or DLP6500 (1080p) with the DLPC900 controller will do binary patterns and can reach up to about 9 kHz from patterns placed into DRAM memory.  The DRAM can only hold 1024 binary patterns for the DLP5500 or 400 binary patterns for the DLP6500.

    Streaming using DP video input at 60 Hz will get you to 1.44 kHz, but not 5 kHz binary pattern rate.  This is a limitation of the video input frame rate.

    FPGAs are much costlier than ASICs.  The other part of the cost for the DLP7000 is that it is a Type A package (hermetic) device.  This means that unfortunately we do not have any FPGA based systems that are lower cost.

    Fizix

  • DLP5500 looks very interesting. And to start with I would bundle DLPLCR55EVM with DLPLCRC900EVM. If I understand correctly there is no FPGA in this solution and DLPC900 handles data from USB and HDMI. Its pre-Stored Pattern Mode up to 1024 patters, with 94us pattern time (with DLP5500) are sufficient for our needs. But can we use external trigger to change the patters at this rate? Another question is the further development of our own system. Is there an API and can Texas TI license the DLPC900 controller IP for our development?

  • Hello again Karen,

    There are external trigger inputs to facilitating advancing the patterns.  I do not know if we have tested at full speed.  However, if I remember correctly adding a wait for trigger adds a dark load each time there is a wait which would slow it down to about 5 kHz for the DLP5500.  Now if you run groups of patterns then wait for a trigger, then only the pattern before the triggered one will have the dark time.  

    Fizix

  • Thanks Fizix, 5kHz should be sufficient. I just noticed something in our previous conversation - 20mW/mm^2 doesn't it correspond to 2W/cm^2 - will DLP5500 manage that power? And finally could you give some insight to my last question about licensing the DLPC900 firware IP?

  • Karen

    Good catch.  I edited it in the message (I see in my calculator sheet I typed in 2 mW/mm^2).  2W/cm^2 is manageable, but definitely mind the thermal solution.

    I am not sure what you mean regarding licensing.  We have the API source code (PC communication to the ASIC) available as part of the GUI installation.  The Firmware is specific to this ASIC, so I am not sure what you are wanting to "license"  The Firmware code is not open to the public.

    Let's connect on the private messaging about this.

    Fizix