https://e2e.ti.com/support/dlp-products-group/dlp/<p style="display:none;">blank</p>en-USTelligent Community 13https://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1667250/dlp9000x-dlp9000x-vbias-operating-voltage-question/6428564Fri, 24 Jul 2026 16:50:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:102e19ca-a57e-4e84-aae0-89864de59387Aaron BlackHello Tanaka-san, Thank you for coming to E2E with your question! I&#39;m asking an expert on my team to come help with your question, they should be able to respond to you shortly! Best, Aaronhttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1661352/dlp3940s-q1-quincunx-algorithm-details-for-soc-cpu-gpu-implementation-dlp3940s-q1-dlpc231s-q1/6427992Fri, 24 Jul 2026 08:02:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d3540105-eced-49c5-b234-991dc83681d7jim liuHi Aishwarya, Thank you for the confirmation and the good news. I have checked our schematic: LS_WDATA and LS_CLK are directly connected between the DLPC23x and the DMD, without going through the FPGA. So from a hardware perspective, we are ready to remove the FPGA. Regarding the software: you mentioned that the final version will have an option to bypass FPGA configuration completely. The DLPC23X firmware version we currently obtained are 1.8.0.B1h . Could you please help clarify the following: Does the current version (1.8.0.B1h) already support running without an FPGA, or does it still expect the FPGA to be present during initialization? If not yet supported, are there any workarounds or configuration changes we can apply to make it work on our FPGA‑less board with this version? When do you expect the final software version (with the FPGA bypass option) to be available for release? Knowing this will help us plan our next steps — whether we can proceed immediately or need to wait for the upcoming release. Thank you very much for your support. Best regards, Jim Liuhttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1667250/dlp9000x-dlp9000x-vbias-operating-voltage-questionFri, 24 Jul 2026 06:55:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:63de8700-f3bd-461f-a411-6abc8a8492b0? ??Part Number: DLP9000X Other Parts Discussed in Thread: DLPLCR99UVEVM , TPS65145 Hello, We are developing a controller board using the DLP9000X and have a question about the VBIAS voltage. We understand that the Recommended Operating Conditions for the DLP9000X specify a VBIAS voltage range of 15.5 V to 16.5 V. Our question is: from the standpoint of the device&#39;s actual operating capability, is it possible for the DLP9000X to operate normally with a slightly lower VBIAS voltage, such as 15.4 V? We designed our own controller board based on the schematic of the DLPLCR99UVEVM evaluation board. However, due to component tolerances, some boards have a VBIAS voltage that falls slightly below the recommended minimum of 15.5 V. We also have a question regarding the VBIAS voltage of the DLPLCR99UVEVM evaluation board. According to the TPS65145 datasheet, when OUT1 (VOFFSET) is configured for 8.5 V and the device is used in 2&#215; mode as shown in the evaluation board schematic, the maximum OUT3 (VBIAS) voltage is approximately: 15.5 V with I_VBIAS = 7 mA 15.2 V with I_VBIAS = 14 mA (maximum) Does the DLPLCR99UVEVM actually provide a VBIAS voltage of 16.0 V? If the evaluation board achieves a VBIAS voltage higher than 15.5 V, could you please let us know whether any modifications were made from the published schematic DLP083D_SCH.pdf to accomplish this? Thank you very much for your support. Hiroshi TanakaDLP9000XIndustrial AutomationDLPLCR99UVEVMTPS65145https://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1664737/dlpc900-dlpc900-i2c-write-to-led-pulse-width-has-no-effect-usb-works-fine/6427650Fri, 24 Jul 2026 00:40:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:213f9c63-09b5-431f-9664-63a119328033bai baiDear Faizan, Thank you for your prompt response and clarification. However, we would like to respectfully point out an inconsistency between your explanation and our actual test results, and we hope you can help us resolve it. Based on your guidance, we understand that: The DLPC900 expects the logical sub-address (0x62) as documented in the Programmer&#39;s Guide. The MSB-set format is a controller-side software convention, not a hardware requirement . Yet our practical tests show the opposite behavior : Command Result i2ctransfer -y 1 w3@0x1A 0x62 0x10 0x00 Does NOT work — exposure setting does not take effect i2ctransfer -y 1 w3@0x1A 0xE2 0x10 0x00 Works correctly — minimum exposure is set successfully In both cases, i2ctransfer is sending the sub-address byte directly to the DLPC900 with no additional controller-side software layer. The only difference is the value of the sub-address byte itself (0x62 vs. 0xE2). Furthermore, for other registers , writes using the logical sub-address (without MSB set) work as expected. This is what makes the behavior of register 0x62 particularly confusing — it appears to be an exception rather than the rule. To summarize, we have two specific questions: Could you reproduce this behavior on your side? We would appreciate it if you could test writing to register 0x62 using sub-address 0x62 vs. 0xE2 on a DLPC900 system and confirm which one takes effect. If the DLPC900 truly expects 0x62, what could explain our observation that only 0xE2 works? Could there be a firmware version difference, a specific configuration state, or an undocumented register access rule that causes this behavior? We want to make sure we follow the correct and intended protocol for all register accesses in our production firmware. Your help in resolving this contradiction would be greatly appreciated. Best regards, Bai baihttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1659463/dlp4710-dlp4710afql-window-optical-specifications-surface-quality-flatness-twe-and-wedge/6427587Thu, 23 Jul 2026 22:49:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:2acad092-2bc5-412e-a3a1-829343f2359aAaron BlackHello Simeon, I apologize for the confusion here - there was some assignment issues and it&#39;s finally come to the right team to discuss this. I secondly apologize because much of the questions you are asking are not information we can share. Although this might be the case, here is a good paper we&#39;ve made for Wavelength Transmittance Considerations for DLP&#174; DMD Window . Best, Aaronhttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1664737/dlpc900-dlpc900-i2c-write-to-led-pulse-width-has-no-effect-usb-works-fine/6427502Thu, 23 Jul 2026 21:36:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:8dbbc805-3747-42ff-aa26-075519bd4bc9Faizan KalamHello Bai Bai, Thank you for the update, and I&#39;m happy to hear that the system is working! In regard to your questions, please see below for a clearer understanding: 1. The DLPC900 expects the logical sub‑address (0x62). The “MSB‑set” formatting is only a convention used by some controller‑side I2C applications. It is not a hardware requirement. 2. As mentioned above, the DLPC900 always requires the logical sub‑address shown in the Programmer’s Guide. The “MSB‑set” version is a controller side software convention depending on what factor you are modifying in your system. Use the logical sub‑address from the Programmer’s Guide. The MSB‑set form is a controller side addition. 3. For further documentation related to your question, please refer to the following guides: DLPC900 Programmers Guide and DLP LightCrafter SDK Guide . Please let me know if you have any further questions. Thank you! Best regards, Faizan Kalamhttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1666997/dlp991uuv-dlp991uuv-maximum-illumination-power-at-375nm-and-how-the-limit-applies-in-pulsed-operation/6427014Thu, 23 Jul 2026 15:33:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d6c0beb4-974b-4f18-927f-bf6ab5c87a9bMichael LyHi Sun, I&#39;ve assigned this ticket to another apps engineer, but they may need an additional 2-3 days to consult with our optics and thermal colleagues. Regards, Michael Lyhttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1661352/dlp3940s-q1-quincunx-algorithm-details-for-soc-cpu-gpu-implementation-dlp3940s-q1-dlpc231s-q1/6426946Thu, 23 Jul 2026 14:59:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:efe6c39d-0246-4643-aafd-bbb04e31c1f8Aishwarya K AithalHello Jim, That is great news! Thank you for sharing. Can you please confirm if you have the LS_WDATA and LS_CLK connected through FPGA? If these signals are directly connected between the DLPC23x and DMD, you can completely remove the FPGA. The final version of the SW will have an option to bypass FPGA configuration completely, which you can use. Thank you, Regards, Aishwaryahttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1666997/dlp991uuv-dlp991uuv-maximum-illumination-power-at-375nm-and-how-the-limit-applies-in-pulsed-operationThu, 23 Jul 2026 10:19:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:3a59df99-e68d-4762-a4b5-edce957af0aesun+kook kimPart Number: DLP991UUV Dear, DLP Expert. We are evaluating the DLP991UUV (datasheet DLPS269A) with the following illumination conditions: Conditions - Light source: single wavelength at 375nm (ILL_UV3 band, ≥365nm and &lt;385nm, MAX 5.9 W/cm&#178;) - Illumination: uniform over the full active micromirror array (22.1184mm &#215; 11.7504mm = 2.599cm&#178;), 0% overfill assumed - Thermal: all Recommended Operating Conditions (T_ARRAY 20 –30&#176;C, etc.) will be maintained Q1. For CW operation, following Section 6.7 (Micromirror Power Density Calculation), we calculate the maximum total incident power as 5.9 W/cm &#178; &#215; 2.599 cm&#178; ≈ 15.3 W. Is this understanding correct? Q2. If the light source is operated in pulse mode instead of CW, does the 5.9 W/cm &#178; ILL_UV3 limit apply to the time-averaged power density, or to the instantaneous (peak) power density? Q3. If it applies to the average, can the peak power be increased inversely with duty — e.g., at 5% duty (5% on / 95% off, repetition rate 5kHz, pulse width 10&#181;s under consideration), up to 20&#215; (peak ~118 W/cm&#178;, ~306 W total)? Please also let us know if there are any separate limits for pulsed illumination, such as peak power density, pulse energy (fluence), or pulse width / repetition rate constraints. Thanks and Regards, SUNDLP991UUVIndustrial Automationhttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1661352/dlp3940s-q1-quincunx-algorithm-details-for-soc-cpu-gpu-implementation-dlp3940s-q1-dlpc231s-q1/6426481Thu, 23 Jul 2026 07:48:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:4860da0c-cde5-4598-92fd-748a9717c4cdjim liuHi Aishwarya, Thank you again for the MATLAB suite. We have successfully ported the quincunx processing to our SoC and verified it is working correctly. Now we are evaluating whether we can completely remove the FPGA from our design, since the image processing is now handled by the SOC. To be certain, could you please help confirm the following: In the reference design (DLP3940S-Q1 + DLPC231S-Q1), does the FPGA perform any function other than quincunx processing ? For example, any mandatory interface bridging between the FPD‑Link de-serializer and the DLPC231S-Q1, or any timing / control logic that the DLPC strictly depends on. In another word, Can the FPD‑Link de-serializer output to the DLPC231S-Q1 directly? Are there any hidden dependencies (such as configuration loading or GPIO strapping) that would prevent us from removing the FPGA entirely? Thank you very much for your support. Your confirmation will help us finalize the schematic. And i f you need any feedback or data from our side, please don’t hesitate to ask. Best regards, Jim Liuhttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1664737/dlpc900-dlpc900-i2c-write-to-led-pulse-width-has-no-effect-usb-works-fine/6426339Thu, 23 Jul 2026 06:00:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d633284a-6b72-47db-93ce-d28ce092a1c0bai baiDear Faizan, Thank you for your detailed response regarding the I2C transaction structure and the write sub-address convention for the DLPC900. Following your guidance, we tested the write sub-address with the MSB set (e.g., using 0xE2 for register 0x62) and confirmed that it works correctly for the exposure register: text sudo i2ctransfer -y 1 w3@0x1A 0xE2 0x10 0x00 → Works (min exposure set successfully) sudo i2ctransfer -y 1 w3@0x1A 0x62 0x10 0x00 → Does NOT work sudo i2ctransfer -y 1 w3@0x1A 0xE2 0x10 0x00 → Works (min exposure set successfully) sudo i2ctransfer -y 1 w3@0x1A 0x62 0x10 0x00 → Does NOT work However, we have observed the following inconsistency that we would like your help clarifying: For other registers (e.g., LED current, pattern configuration, etc.), we are able to successfully perform write operations using the original sub-address directly (without setting the MSB) . For example, writes to registers such as 0xF5, 0xF8, etc. all take effect using the sub-address as documented in the Programmer&#39;s Guide, without needing to set bit 7. This raises the following questions: 1. Is the MSB-set write sub-address convention (e.g., 0xE2 for register 0x62) only required for specific registers , or should it theoretically apply to all write operations? 2. Why do some registers accept writes at the original sub-address while others (like 0x62) require the MSB to be set? Is this related to internal register mapping, memory page boundaries, or some other hardware-level distinction? 3. Is there any documentation (beyond the Programmer&#39;s Guide) that clearly specifies which registers require the MSB-set sub-address for write operations and which do not? This would be extremely helpful for our development workflow. We need a reliable rule for determining the correct write sub-address for any given register. We appreciate your continued support and look forward to your clarification. Best regards, [Bai bai]https://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1666697/dlplcr67evm-can-the-dmd-dlplcr67evm-be-controlled-by-an-fpga-without-the-dlpc900/6425607Wed, 22 Jul 2026 16:40:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:a1ea016a-a603-4f97-a285-43ab3193d840Aaron BlackHello Shannon, Thanks for coming to E2E! The short answer is no, TI offers the DLP670S as a DMD within the chipset and a chipset is composed of a DMD, Controller, and usually a power management IC (PMIC) or related device. The DLPC900 is already an ASIC specifically designed to control the DMD. Additionally, we don&#39;t share TI Intellectual Property nor condone the function of the DLP670S outside of it&#39;s intended chipset. Best, Aaronhttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1659063/dlplcr65evm-dlp-lightcrafter-6500-video-pattern-mode-unexpected-photodiode-signal-dips-in-255-greyscale-during-16-5-ms-rgb-frame-window/6425567Wed, 22 Jul 2026 16:18:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:4933fcba-d965-4fa6-afc4-0f7f92f8efa9Aaron BlackHey Dorrin, Thank you for providing this view of your output! Is your exposure set to &#39;Repeat&#39;? The timing seems much slower than your expected input source - 16.667ms as you&#39;ve said if you&#39;re using 60Hz input. Could you please provide a closer look at that timing from the initial rising edge to the first falling edge with a cursor? Also, are these evenly spaced within the exposure time? Are the times consistent? Best, Aaronhttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1661372/dlplcr99uvevm-the-evm-board-has-no-v-bias-18v-voltage-output/6425533Wed, 22 Jul 2026 15:56:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:cfa9e893-f566-4b07-93ea-ccb00ef0ec5frichard parkHi Tilden Thank you for your reply I repeat my message to you. Because I can not receive your reply.... I neans Power-up instruction 1,2,3,4, are OK. and 5. 12V power (D1), DLPC964 Power Good (D2), and DMD Power Good (D3) LEDs illuminate indicating that power is present on the DLPLCRC964EVM and DLPLCR99EVM / DLPLCR99UVEVM boards. My Answer =&gt; D1, D2 are OK,, D3 is not OK.( I think it&#39;s because of the Vbias problem of DMD Mirror Board) The DMD Power Good( D3) LED is not OK Now. the Power_en Signal is High for DMD Mirror Board. Please let me now what caused it. Regards Richard Parkhttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1666697/dlplcr67evm-can-the-dmd-dlplcr67evm-be-controlled-by-an-fpga-without-the-dlpc900Wed, 22 Jul 2026 14:58:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d008406b-d4ad-4e6c-ad7c-2a1c978a6718Shannon MountPart Number: DLPLCR67EVM Other Parts Discussed in Thread: DLP670S , DLPC900 Can the DMD DLPLCR67EVM be controlled without a DLP, and just by an FPGA?DLP670SDLPLCR67EVMDLPC900https://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1666168/dlp6500fye-dlp6500evm-gui-related-to-firmwar-4-0-0-version/6424425Tue, 21 Jul 2026 22:56:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:6967aad3-8e4f-420e-8250-d020a8a34d77Aaron BlackHello Gwan, Thank you for coming to E2E! 1. I&#39;ve done a bit of digging and GUI version 4.0.0 requires version 5.0.0 firmware. I am unaware of a firmware version 4.0.0, it might exist in an archive from more than a decade ago, but I would need to ask my team where this might be. 2 &amp; 3 Again, I would need to discuss with my team where this repository might have been archived to. 4. It is highly likely that the latest GUI has changed what that command does while firmware doesn&#39;t recognize it. It would be more advantageous to have the latest combination with bugs removed and added features which are available for reading within the Readme.txt file of the GUI. 5. I would highly recommend you to update to the latest as there have been many updates since then that support the chipset more fully. The GUI has kept to it&#39;s same look over the years, but if you run into issues you can always post another question on here, or we could have a short call to get you back into a working mode. Best, Aaron e2e.ti.com/.../Readme_5F00_5.3.0_5F00_GUI.txthttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1664737/dlpc900-dlpc900-i2c-write-to-led-pulse-width-has-no-effect-usb-works-fine/6424405Tue, 21 Jul 2026 22:32:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:f41d4b16-55e9-40be-90b2-f94c4fa113a1Faizan KalamHi Bai Bai, Thank you for elaborating on this question. In the DLPC900 Programmer&#39;s Guide , section 1.1 gives an overview of the transaction structure for I2C read and write commands. All I2C transactions are composed of a number of bytes, combined in the following order: START Condition, 7-Bit Secondary Address Byte + 1 R/W Bit, Sub-Address Byte, N-Data Bytes, and finally the STOP Condition. Please note that our internal systems operate in a Windows environment, so we do not provide direct support for Linux based tools. Please try the following resolution steps: Please try using the default 7-bit write address of 0x34 (read is 0x35) rather than 0x1A. Additionally, please ensure you use the Little-Endian format (LSB first) for the exposure timing and the correct write sub-address. For the DLPC900, the write sub-address is the read sub-address with the most significant bit set. Therefore, for register 0x62, you should use 0xE2 for writing. Thank you! Best regards, Faizanhttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1660469/dlpnirnanoevm-dlpnirnanoevm-software-issue/6424339Tue, 21 Jul 2026 21:20:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:19a408ca-a33e-4732-815d-ac63cbd67bddAaron BlackHello Chenglq, This thread is redundant and should be closed. Best, Aaronhttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1645507/dlpnirnanoevm-dlpc150-program-issue/6424337Tue, 21 Jul 2026 21:19:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:513007dd-5477-4818-9485-5efe9926c168Aaron BlackHey Chenglq, I&#39;ve looked at this with another member of my team and we are not clear on what commands are being sent. Beneath the &quot;GetCommunicationStatus&quot; log there seems to be a UART log of 0xD3 [Read Communication Status] that is also not shown in your source code or ours. Additionally, there are no debug_print prompts in the output, so we assume this is all contained within the single &quot;GetCommunicationStatus&quot; command. Best, Aaronhttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1666168/dlp6500fye-dlp6500evm-gui-related-to-firmwar-4-0-0-versionTue, 21 Jul 2026 10:40:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:5492384f-19ec-4118-ac3f-bf05251ae234Gwan Woo LeePart Number: DLP6500FYE Other Parts Discussed in Thread: DLPC900 Hello, I am using a DLP6500EVM with the following firmware: Firmware version: 4.0.0 Firmware tag: DLPR900PROM-6500-v4.0.0 The currently installed DLPC900 GUI version is 5.3.0. The DMD Park &quot;Set&quot; command appears to work, but when I click &quot;Get&quot;, the GUI displays the following error: Unable to read DMD park status! Error: Invalid command number: 0x0609 I suspect that DLPC900 GUI 5.3.0 is not compatible with firmware 4.0.0. Could you please confirm the following? 1. Which DLPC900 GUI version is officially compatible with firmware 4.0.0? 2. Is the corresponding legacy GUI installer still available for download? 3. Can you provide a download link for the correct GUI version? 4. Is command 0x0609 unsupported in firmware 4.0.0? 5. If no compatible legacy GUI is available, is updating the firmware to version 6.3.0 the recommended solution? The device is currently operating normally for pattern display, so I would prefer not to update the firmware unless necessary. Thank you.DLP6500FYEDLPC900