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.

DLP2021-Q1: Tools for DLPC34xx Controller Image Calibration application note

Part Number: DLP2021-Q1

Tool/software:

Hello,

The DLPC34xx Controller Image Calibration application note (link) mentions in section 4.1 some Factory Floor Utilities, a TI tool and a Duty cycle database.

How could we provide a customer with these utilities?


Best regards,
François.

  • Francois,  These utilities are not available for the DLP2021 platform with Sitara.  I would recommend that the customer use the concept.  However, they will need to adjust the "RGB PWM" in place of the "RGB duty cycle" to target the correct white point in the system.   The Sitara platform does NOT have the ability to easily adjust across many different RGB Duty cycles like the DLPC34xx based systems.   We (TI) are not able to make this utility tool at this time for the Sitara.

    The customer would need to use the recommended test equipment, but they would need to make their own utility that is compatible with their HW and factory test platform.   Normally, this is just a simple utility that can automatically collect the measurements from Konica Minolta CL200 for example, which are then put into to a tool that calculate the RGB PWM for the desired color point, per the formulas listed in the app note.

    Jason

  • Hello Jason,

    My vision/need, is to calibrate the white point dynamically by SW. The initial calibration could be configured as the time allocated for each colour inside PRU (after fixing the max level current for each colour). Is it possible to change this initial calibration dynamically (by implementing a shifting colour law) by the PRU? or the PRU can configure only the static value (unchangeable when running)?

    I understood from your answer that we should adjust LEDs PWM in place of RGB duty cycle (time allocated for each colour), because we can not dynamically ajust it by PRU? (link with first question :) )

    Besides, from your point of view, it is better to implement all that with analog dimming? no impact of accuracy and timing constraints from LED driver?

    Please could you share with us your experience on the topic? and if possible to share the configuration you did for RGB applications using DLP and why it was choosen?

    Best regards,

    Ned,

  • Hi Ned,

    A couple of points:

    1. The RGB Duty cycle is tied to the bitplane and video generation process which is not easily updated.  The PRU is just reading back the final processed bitplanes, so it is possible to modify the RGB Duty without completely regenerating all of the video content.  In general, this would be impractical for a factory operational as the time per units would take a very long time.  

    2. The RGB PWM is very consistent (as consistent as the RGB Duty cycle), so I do not see this as an issue in terms of accuracy.  We actually use PWM to set the color point for AR HUD systems, which have a very tight tolerance.  My experience is that this will work well.

    The main factors for color variation of hte LEDs will come from operating temperature.   The Red LED especially becomes less efficiency at higher operating temperature, thus the color point will shift to more blue/green at higher temperatures.  However, the PWM level will be consistent.  The temperature actually can be characterized reliable and some "offset" can be added at higher temperatures to help keep the color point at higher temperatures.  

    Basically, you can do some "pre-work" or use the LED datasheet to estimate the lower efficiency at higher temperatures, and then you can adjust by this offset from the initial room temperature calibration levels.

    Let me know if this helps in your understanding.

    Thanks,
    Jason