DLP products forum - Recent Threads

DLPC900: [DLPC900] I2C Bus Hang (SCL/SDA held low) in dual-DLPC900 + DLP9000 system during video input config - seeking guidance

bai bai — Mon, 03 Aug 2026 06:01:53 GMT

Part Number: DLPC900

Hello TI DLP Support Team,

We are using **two DLPC900 controllers driving a DLP9000 DMD (dual-controller, split-screen)** in a Video Pattern Mode projection system, controlled by a Xilinx Zynq/ZU+ SoC over I2C. We are experiencing an intermittent I2C bus hang, and we would really appreciate your technical guidance on the likely root cause and recommended handling.

## 1. Symptom

- The I2C bus hangs: **both SCL and SDA are pulled low and held low persistently** (confirmed on a logic analyzer / oscilloscope).
- Once this happens, the DLPC900(s) no longer respond on I2C and the whole system only recovers after a power-cycle / full reboot.
- We cannot yet determine with certainty whether the hang originates in the DLPC900 I2C slave or in our I2C controller.

## 2. System / bus topology

- Dual DLPC900 controllers (main + secondary) driving one DLP9000 DMD. The main/secondary assignment is **fixed** (not reconfigured at runtime).
- Both controllers share the **same I2C bus and the same slave address (0x1A)**. We use the broadcast I2C address for all configuration commands.
- The **same I2C-1 bus also carries 3 LM75 temperature sensors** used for thermal monitoring.
- I2C at 400 kHz, Linux, standard `/dev/i2c` adapter accessed via `I2C_RDWR` ioctl.

## 3. Our current I2C communication method

1. All register **writes** are a single I2C write transfer: `[command byte][payload]`.
2. All register **reads** are done as two separate I2C transfers: first "write the command byte", then "read back N bytes", with a configurable inter-command delay between them (our default is 10 ms).
3. We protect all traffic on this bus with an in-process mutex, because the 3 LM75 temperature sensors share the same bus and are read periodically by a thermal-control thread.
4. We deliberately **disable the "wait-for-idle before write" feature** (the pre-write polling that reads main status register 0x22 to detect whether the DLPC900 is still busy, as a way to tolerate clock stretching). Instead, we rely purely on a fixed delay between successive I2C transactions.
5. This inter-command delay (we call it `cmd_interval`) is a **host-side sleep inserted after each successful I2C write or between the two phases of a write-then-read**, to give the DLPC900 command pipeline time to finish. It is NOT a register value written to the DLPC900. We tune it per operation:
- ~100 ms during initialization,
- ~50 ms during normal configuration,
- ~3 ms while streaming many LUT-definition entries,
- 10 ms as the gap between the "write command byte" and "read data" phases.
6. We currently have **no explicit I2C bus-recovery routine**; we rely on the Linux I2C driver, but once SCL+SDA are both low we observe no self-recovery.

## 4. The configuration sequence where the hang most often occurs

This is the video-input path setup on a single DLPC900 controller, executed at startup and on some re-configurations. The operations below are all **single I2C write transactions** to the given command byte (register) of the DLPC900:

1. Set **display mode to Video** — write register `0xE9`, then poll read register `0x69` until it confirms Video mode.
2. Set **input source to parallel RGB 24-bit** — write register `0x80`.
3. Set **input channel swap for Port 1 to ABC** — write register `0x84`. ← **commonly hangs here**
4. Set **input channel swap for Port 2 to BAC** — write register `0x84`. ← **commonly hangs here**
5. Set **pixel format to RGB** — write register `0x82`.
6. (skipped) external video power.
7. Set **port/clock config: data port 1+2, pixel clock 1, data enable 1, sync source P1** — write register `0x83`. ← **commonly hangs here**

So our "wanted behavior" is simply: after power-up, configure the DLPC900's video input path by writing registers `0xE9, 0x80, 0x84, 0x84, 0x82, 0x83` in sequence, each as a single I2C write. The two writes to `0x84` (channel swap) and the write to `0x83` (port/clock config) are the ones where we most often see the bus latch SCL+SDA low.

We should also note: these writes are sent back-to-back with our `cmd_interval` host-side delay (50 ms) between each. We have not found a `cmd_interval` value that fully removes the hang.

## 5. Other reproduction conditions we have observed

1. **Too short a gap between the write phase and the read phase of a "write-then-read" register read.** If the internal delay between writing the register address and starting the read is too short (our default is ~10 ms), the DLPC900 I2C interface appears to hang.

2. **A DMD-idle/sleep command colliding with a DLPC configuration sequence.** If we finish a configuration (e.g. LUT definition, register `0xF8`/`0xF5`) and immediately send the DMD idle command (register `0x8D`), the lockup becomes essentially guaranteed. We have partially mitigated this by adding a delay after LUT definition plus locking, but it only reduces, not eliminates, the occurrence.

3. **Immediately sending DLPC parameters right after reading the LM75 temperature sensors** (same bus) also appears to trigger the hang.

4. Intermittent lockup during power-on / startup (not yet stably reproduced).

## 6. Measures we have already tried / currently take

- Increased the host-side inter-command delay (`cmd_interval`): 100 ms during init, 50 ms during normal config, 3 ms only for LUT-definition streaming, 10 ms for the write-then-read gap.
- Added an in-process mutex shared with the LM75 temperature reads to avoid concurrent access on the same bus.
- Added a fixed delay after LUT definition before entering DMD idle, and added locking around the idle/config sequence.
- These reduce but do **not** eliminate the hang; SCL+SDA can still be latched low.

## 7. Question about DLPC900 GUI "Power Up Defaults" settings

We also have the DLP® Control Program (DLPC900 GUI) "Power Up Defaults" page. Some of the fields there look like they could affect I2C timing or behavior:

- **Firmware Tag**: `DLP9000_6.3.0_00B`
- **I2C Secondary Addr**: `52`
- **Read Delay**: `19`
- **Write Delay**: `2`
- **Write Pulse Width**: `11`
- **CS/Data Hold time**: `2`
- **Debug Mask**: `0x80000003`
- DMD Bus Swap / DMD Bit Swap: mostly disabled

Could you tell us:

- Do the **Read Delay / Write Delay / Write Pulse Width / CS-Data Hold time** fields actually affect the DLPC900 I2C slave timing on the bus, or are they purely GUI-host pacing values? If they are stored into the firmware's power-up defaults and affect slave behavior, they look like the most direct lever for our hang.
- Is the **Debug Mask** `0x80000003` known to enable verbose error reporting that could be useful for diagnosing the hang? Should we change it?
- Is there a newer **firmware (DLP9000_6.3.0_xx)** or batch-file defaults configuration that is recommended to improve I2C robustness for this kind of dual-controller application?

## 8. Other questions for TI

1. Is there a **known DLPC900 I2C slave behavior** where the interface can leave SCL/SDA driven low (bus stuck) under the conditions above? What are the **recommended minimum inter-command / write-to-read delays** for DLPC900 over I2C, especially for the channel-swap (0x84) and port-clock (0x83) commands?

2. Does the DLPC900 I2C slave implement **clock stretching**? If so, what is the maximum stretch duration, and how should the master behave to avoid a hang (instead of disabling the pre-write idle check)?

3. For the **dual-DLPC broadcast** configuration (both controllers at 0x1A), is there any known risk of one controller driving the bus during a broadcast write? Is there a recommended ordering / delay when back-to-back broadcasting commands like 0x84 and 0x83?

4. Is there an **official recommended I2C bus recovery procedure** for DLPC900 (e.g., clock-toggle SCL ~9 pulses with SDA high, then a STOP), and does the DLPC900 I2C peripheral support such recovery? If SCL+SDA are already latched low by the DLPC, is there any register or external recovery that works without power cycling?

5. For the **3 LM75 temperature sensors sharing the same I2C bus** as the DLPC900, do you recommend keeping them on a separate bus? Is a back-to-back LM75 read followed immediately by a DLPC900 command known to be unsafe?

6. Could you point us to any **application notes / TI E2E threads / latest DLPC900 firmware** that address I2C robustness, command pacing, or dual-controller I2C handling?

We would be very grateful for any suggestions on robust I2C handling (timing, bus recovery, sequencing) for a dual-DLPC900 / DLP9000 system.

Best regards,
[Bai bai]

DLPC4420: Implementing I2C Control for FPGA Error Recovery on DLPC4420 Custom

kent gu — Wed, 29 Jul 2026 00:20:14 GMT

Part Number: DLPC4420

Background:
We have developed a custom board based on the DLPC4420 and 0.47-inch 780 DMD, referencing the official 4420 Demo board schematic.

The Issue:
We occasionally experience a “half-screen” display issue after power-up, which we have traced to an FPGA status error. While we can successfully clear this error using DLP Composer (via USB) by reading the “FPGA Error Status” and performing an “Error Reset,” our end-users operate the system without a PC connection and cannot use DLP Composer.

Proposed Solution:
We intend to integrate an MCU into the design to monitor and reset the FPGA status via I2C automatically. We need technical clarification on the following points to proceed:

1. I2C Interface Selection:
Which I2C interface (I2C_0, I2C_1, or I2C_2) provides access to the FPGA status registers?

2. Command Protocol Translation:
We need to translate the DLP Composer USB commands into I2C transactions.

Current USB Command (Write): 34 f3 37
Current USB Command (Read): 35 15 00
Question: What is the equivalent I2C command sequence? Specifically, what are the Slave Address, Register Address, and Data bytes required for the I2C write and read operations?

3. Bus Traffic Analysis before design :
We attempted to sniff the I2C traffic (specifically on I2C_1) using a Logic Analyzer (50M bandwidth, 500M depth) while triggering the “Get FPGA Err Status” command in DLP Composer. We observed I2C clock activity (~1us period), but the specific command bytes (34 f3 37, etc.) were not present on the bus. Please clarify the relationship between the DLP Composer USB commands and the actual I2C traffic.

Any reply is appreciated!

Best Regards,

Kent

RE: DLPC4420: Implementing I2C Control for FPGA Error Recovery on DLPC4420 Custom

kent gu — Fri, 31 Jul 2026 23:13:48 GMT

Hi All, attached our test setting, hope can help to understand!

Look forward for replying.

Best Regards,

Kent

RE: DLPLCRC900DEVM: Trigger unstable from DLPLCRC900DEVM board

Aaron Black — Fri, 31 Jul 2026 18:33:29 GMT

Hello Callum,

Thank you for coming to E2E with your quesiton!

Jumper J27 on the dual DLPC900 schematic have connections as below:

#5 is Trigger Out 2 and #6 is ground. I apologize, I don't see any video attached but the Trigger Out 2 can be understood to be an active high trigger output that indicates the start of each pattern display within a sequence.

Could you share an image of the 'Video Pattern' page to see what settings you are running?

Best,

Aaron

DLPLCRC900DEVM: Trigger unstable from DLPLCRC900DEVM board

Callum Jones — Fri, 31 Jul 2026 12:10:44 GMT

Part Number: DLPLCRC900DEVM

Hello,

We have a problem with our DLPLCRC900DEVM board, we're using it to control a DLP6750Q1EVM gamma NIR PLM.

The trigger signal taken from pins 5 & 6 on J27 has the correct voltage and frequency, but the frequency is unstable as shown in the video below. This happens both using the DisplayPort and HDMI connections, and with two NIR PLM heads we have tested. When we use this to trigger a camera, the frame rate is correct but the image flickers between showing the zero order only and the zero + first order diffracted spots which we expect to see (we are displaying a blazed grating on the PLM).

Is this a known fault and should we replace the board? Any advice on this would be greatly appreciated.

Many thanks,

Callum

DLPC900: GUI and Firmware Issue

Renan Santos Adriano — Thu, 30 Jul 2026 22:53:45 GMT

Part Number: DLPC900

Hello Experts,

Posting on behalf of my customer:

I’m having some trouble loading image patterns onto my DMD (DLPC900EVM + DLP6500) using the GUI version 5.3 and the firmware version 6.2.

I have the same issues as one of the other people in the forum has previously stated, so I reiterate those three issues here:

1. Standby to Normal Mode Toggle: When I connect the module via USB, the DLP900 GUI shows a green "Connected" status. However, when I attempt to switch from Standby to Normal mode, the software immediately toggles back to Standby. I can only successfully enter Normal mode if I press Reset first.

2. Operating Mode Lock: Once in Normal mode, I am unable to select other operating modes, such as Pattern on-the-Fly. The GUI seems locked to Video Mode; whenever I try to toggle to a different mode, it automatically reverts to Video. I can only force it to stay in the Pattern-on-the-fly mode if I check the DMD park and set it.

3. GUI Initialization Checks: none of the status boxes are checked.

A few days ago, when I was first trying to operate the DMD, despite all the above-mentioned issues, I somehow was able to force it into pattern-on-the-fly mode and not go back to video mode and load three different binary images on the DMD, as instructed in the tutorial. Then I tried setting the DMD park (on the system settings tab). After that, I am unable to load any patterns. The DMD shows the last loaded image (0145). I have attached screenshots showing the DMD screen as well as other issues I mentioned.

I also tried to update the firmware to 6.3, but I'm getting the error message saying "Unable to read flash device IDs. Error: Invalid command number: 0x15"

I’d really appreciate it if you could guide me on how to troubleshoot the setup.

attachement.zip

Regards,

Renan

RE: DLPC900: GUI and Firmware Issue

Aaron Black — Fri, 31 Jul 2026 18:17:21 GMT

Hello Renan,

Thank you for including the firmware and GUI version, we recommend customers to utilize firmware v6.3 with v5.3 GUI. If the GUI does not match with the firmware currently installed - there may be miscommunication to which commands are available and this case (0x15) is simply putting it into a programmable mode.

You will need to populate jumper J12 while powered down. There is also another customer who had experienced issues that can be seen here that are similar, but I'm not sure if this is the same customer you are working with now.

Best,

Aaron

RE: DLPC4430: Questions related to overlap on DLPC4430 LED project

Josiah Hamilton — Fri, 31 Jul 2026 15:44:41 GMT

Wayne,

In the reference project the "25% Overlap" sequence set is available for you to use.

1. Open the "Group Definition/Calibration" section on the navigation bar

Then on the page that appears

2. select the sequence set "25% Overlap" and

3. click "begin Auto Calibration" and follow the Automatic Calibration Wizard

CL200 is a chroma sensor that is suitable here.
LS100 + PR650 can be an alternative, but those instruments are not available to me to test.

If you need additional meter support, you will need to reach out to our FAEs

Then for Luminance

1. Navigate to the Luminance Ribbon

2. Select Sequence Set "25% Overlap"

3. Select desired framerate (There is a sequence for each frame rate)

4. Select "Computed"

From there you should be able to build the project with Color/Luminance calibration.

Josiah

DLPC4430: Questions related to overlap on DLPC4430 LED project

Wayne Cheung — Wed, 24 Jun 2026 04:02:36 GMT

Part Number: DLPC4430

Dear all, about DLPC4430 LED project, now we are developing on TI_Ref_DLPC4430_p78_1080p_S600_HEP_LED platform.

Could you please share some Instructions or Documents refer to How To Set Overlap? We need the whole process which we can follow to calibrate the Brightness and Image Qualitites.

Many thanks.

BRs

DLPC231-Q1: NTC selection in DLPC231+TPS99002S application

jim liu — Fri, 31 Jul 2026 08:04:18 GMT

Part Number: DLPC231-Q1

Dear teams,

In the reference design DLP121E2_SCH_20260311.pdf , TPS99002S has NTC resistors for temperature acquisition and feedback of LED, but the complete model of NTC resistor is not reflected in the design. Can you help find the drawing of the other end of the connector J6 and the complete model of NTC resistor?

Best

Jim

RE: DLPC231-Q1: NTC selection in DLPC231+TPS99002S application

Aishwarya K Aithal — Fri, 31 Jul 2026 14:33:17 GMT

Hello Jim,

The thermistor would be located on the LED board. The DLP121E2 reference design does not include the LED board designs.

Here is an example of a typical thermistor usage:

You can read the voltage across the thermistor using the ADC measurements command, calculate the resistance, then use the B-constant of the thermistor to calculate the junction temperature of the LED.

Thank you,

Regards,
Aishwarya

DLPDLCR230NPEVM: Again: DLPDLCR230NPEVM: DLP LightCrafter 230NP EVM – I2C not detected and init_parallel_mode.py fails on Raspberry Pi 4

Takashi Matsumura — Thu, 30 Jul 2026 22:46:41 GMT

Part Number: DLPDLCR230NPEVM

Dear TI Team,

Greetings.

I would like to follow up regarding the thread below:

https://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1658769/dlpdlcr230npevm-dlp-lightcrafter-230np-evm-i2c-not-detected-and-init_parallel_mode-py-fails-on-raspberry-pi-4

I previously posted this question on the TI E2E forum, but the thread was locked before any response was provided, and I can no longer reply or add further information.

Could you please explain why the thread was closed without a response?

Our end customer is currently experiencing this issue and is becoming increasingly frustrated due to the lack of feedback. We would appreciate any information you can provide regarding the status of this issue.

If this is a known issue, hardware defect, or any other recognized problem, please let us know. Even if the details cannot be shared publicly, we would greatly appreciate a direct message or private communication so that we can provide an update to the customer.

We would appreciate your assistance and look forward to your response.

Kind regards,

Takashi

T4933502

RE: DLPC964: What is the high output conditions for the init_done pin (F23) of DLPC964ZUM ?

richard park — Thu, 30 Jul 2026 21:50:56 GMT

HI Tilden

I am waiting for your reply.

Regards

Richard Park

DLPC964: What is the high output conditions for the init_done pin (F23) of DLPC964ZUM ?

richard park — Fri, 03 Jul 2026 08:32:58 GMT

Part Number: DLPC964

I have some question about the DLPC964ZUM output pin(F23)

my question) What is the high output conditions for the init_done pin (F23) of DLPC964ZUM ?

We are developing a DMD Mirror control board using DLPC964 app Source.

FPGA is using kintex ultra.

In DLPC964, the init_done pin keeps the output low. Please let me know what the conditions are for the init_done pin to output high. I can't find the reason in the datasheet.

Regards

Richard Park

RE: DLPLCR65EVM: DLP LightCrafter 6500 Video Pattern Mode: unexpected photodiode-signal dips in 255 greyscale during 16.5 ms RGB frame window

Aaron Black — Thu, 30 Jul 2026 18:22:29 GMT

Hello Dorrin,

I will test this myself and share my findings.

Best,

Aaron

DLPLCR65EVM: DLP LightCrafter 6500 Video Pattern Mode: unexpected photodiode-signal dips in 255 greyscale during 16.5 ms RGB frame window

Dorrin Ashrafi — Fri, 26 Jun 2026 18:23:14 GMT

Part Number: DLPLCR65EVM

Hello TI Support,

I am using a DLP LightCrafter 6500 system with the DLPLCR65EVM / DLP6500 DMD and DLPC900 controller. The system is being driven from a Kria KV260 through video input via HDMI. I am testing Video Pattern Mode timing using a photodiode and oscilloscope. Why does the 255 greyscale output show narrow dips and acts unexpected in the photodiode signal during the expected 16.5 ms active RGB frame window?

Our workflow is:

We first start the LightCrafter in Video Mode and use the Kria KV260 via HDMI as the video input source.
Then we switch the LightCrafter to Video Pattern Mode.
In Video Pattern Mode, we upload/load the pattern file(see below)
We then test the DMD output using a 405 nm laser + optics to reflect the light from the DMD to the photodiode/measurement system.

Operating conditions:

DLP board label: DLPLCR65EVM DLP040
DLP system: TI DLP LightCrafter 6500 EVM
Software: LightCrafter software version 5.3.0
Initial mode: Video Mode
Test mode: Video Pattern Mode
Input source: Kria KV260 video output connected to DMD with HDMI
Kria board: AMD/Xilinx Kria KV260 Vision AI Starter Kit- part number: SK-KV260-G
DLP board powered with its standard external power supply
USB connected to PC for LightCrafter GUI control
Photodiode
Oscilloscope analog discovery 3
- waveform software using the exact settings shown on red 255 image

Steps to reproduce

Connect the Kria KV260 HDMI output to the DLP LightCrafter 6500 HDMI input.
Connect the LightCrafter 6500 to the PC using USB and open the LightCrafter GUI.
Power the DLP LightCrafter 6500 using its standard external power supply.
Start the LightCrafter in Video Mode and confirm that the Kria HDMI output is displayed correctly on the DMD.
Once your video gets locked, from the LightCrafter GUI, switch the system from Video Mode to Video Pattern Mode.
Load the attached Video Pattern Mode pattern file.
Use the following pattern entries with 8-bit RGB slots and 5500 µs exposure per slot:

0,8,5500,0,1,1,0,1
8,8,5500,0,1,0,0,1
16,8,5500,0,1,0,0,1

Select the icon with a checkmark on it and press UPDATE LUT
Display a 255 greyscale 100x100 box test image in the middle of the screen using Kria on the DMD
Align the 405 nm laser and optics so the reflected light from the DMD test box reaches the photodiode.
Press on single run on waveforms and then once it is ARM'ed, go ahead and start the pattern on the LightCrafter.
Record the photodiode output using the oscilloscope once you see the trigger.

Based on this setup, I understand that one 60 Hz video frame contains three 5500 µs color slots, so the active display window should be approximately:

3 × 5500 µs = 16.5 ms

For a greyscale 255 input image, I expected the photodiode signal to remain ON across all three RGB slots, meaning the measured ON time should be close to 100% of the 16.5 ms active window. However, the oscilloscope signal shows narrow dips inside the frame.

For reference, I also attached 255 red, and that signal appears to behave as expected. I have attached the 255 greyscale plot/CSV and the 255 red reference data to show the difference. The red case suggests that the timing setup and photodiode measurement are working, but the 255 greyscale case is showing these extra dips.

My main questions are:

What is the likely cause of these dips in the 255 greyscale photodiode signal?
Are short dark gaps expected between RGB slots in Video Pattern Mode, even for greyscale 255?
Should a 255 greyscale input be expected to remain ON across all three 5500 µs RGB slots, or does the DLPC900 insert blanking/switching intervals between color slots?
When analyzing ON time for greyscale 255, should these dips be counted as actual OFF time, or treated as normal slot-transition behavior
Could you please point me to the TI or Lightcrafter documentation that explains DLPC900 Video Pattern Mode timing, including any RGB slot-transition blanking, mirror-reset delay, or expected gaps between pattern slots?

For my analysis, I am using fixed voltage thresholds derived from the 128-level captures because lower greyscale values are close to the noise floor. I want to confirm whether my interpretation of the 16.5 ms timing window is correct and whether the observed dips are expected behavior for DLPC900 Video Pattern Mode.

Let me know if you need more information.

Thank you.

255greyscale.csv

RE: DLPNIRNANOEVM: DLPNIRscan Nano – dlpspec_scan_interpret() returns rc=-4 ("not a valid tpl file") on Linux

Shiva Reddy — Thu, 30 Jul 2026 17:35:57 GMT

Hello Aaron.. Any update ? Please let me know.

Regards

Shiva

DLPNIRNANOEVM: DLPNIRscan Nano – dlpspec_scan_interpret() returns rc=-4 ("not a valid tpl file") on Linux

Shiva Reddy — Tue, 14 Apr 2026 22:58:22 GMT

Part Number: DLPNIRNANOEVM

Hello TI Team, @Aron

I am interfacing with DLPNIRscan Nano (DLPNIRNANOEVM) from a Linux system (Raspberry Pi) using USB HID and the DLP Spectrum Library ( Programing Lang : C)

What

What is working : HID communication (VID:PID 0x0451:0x4200), Scan execution (NNO_CMD_PERFORM_SCAN, NNO_CMD_SCAN_GET_STATUS), File retrieval (NNO_CMD_FILE_GET_READSIZE,NNO_CMD_FILE_GET_DATA) and Full scan file download.

However when calling dlpspec_scan_interpret(data, size, &results) returns "not a valid tpl file rc = -4"

Diagnoistic Info

Device: (via NNO_CMD_TIVA_VER) : Tiva SW: 0.1.2.0 , DLPC SW: 3.0.5.2 , Spectrum Library (device): 3.0.2.0

Host Library Version From dlpspec_version.h:

#define DLPSPEC_VERSION_MAJOR 2
#define DLPSPEC_VERSION_MINOR 0
#define DLPSPEC_VERSION_BUILD 3
Host Library : 2.0.3


Looks like a TPL format incompatibility, likely due to Device Spectrum Library (3.0.2.0) vs Host Library (2.0.3)

Please let me know:

Is dlpspec_scan_interpret() backward compatible across Spectrum Library versions?
Do I need a matching 3.x version of the DLP Spectrum Library for Linux?
Where can I obtain the correct Linux library version?
Alternatively, should device firmware be downgraded to match v2.0.3?
Is the TPL format documented for manual decoding?

Any guidance on resolving this compatibility issue would be greatly appreciated.

Thank you!

DLP4710LC: Regarding the question of whether the grayscale discontinuity is related to bit-planes

Jeenter.Wu — Tue, 16 Jun 2026 03:00:43 GMT

Part Number: DLP4710LC

Hello, TI Engineer,

We have built an optical projection system using one DLP4710LC with two DLPC3479 controllers, running firmware version DLPC3479-DLPA3005-TIEVM-v8p4p0.

Test setup:

The projector displays solid-color patterns, captured by a high-speed global industrial camera. Both the projector and camera are set to an Exposure Time of 4 ms. The camera is triggered by the projector's Trigger2 signal. Only the blue channel is active on the projector.
All parameters remain constant except for the Pattern, which cycles through 256 variants corresponding to grayscale values 0–255 (256 solid grayscale images in total).
The mean grayscale value of each captured image is computed to generate the line plot shown. Multiple curves were obtained by varying the LED current; they exhibit similar trends to the issue in question. Please focus on the dark blue curve only.
Due to ambient light, the mean value captured for the grayscale-0 pattern is not zero.

Observed issue:

The plot clearly shows discontinuities at grayscale values 16, 32, 64, and 128. Notably, at grayscale 64 and 128, the response even drops. Upon examining the raw data, we found that the problematic points—grayscale 8, 16, 32, 64, 128, 128+8, 128+16, 128+32, and 128+64—all exhibit a pronounced slow rise or even decline.

We suspect this is related to bit-plane behavior, but we have been unable to verify or debug it further.

Question: Have you encountered this issue, or does it correspond to a known behavior? Is there a workaround or an updated firmware that addresses this?

Thanks,

Jeenter

RE: DLP4710LC: Regarding the question of whether the grayscale discontinuity is related to bit-planes

Jeenter.Wu — Thu, 30 Jul 2026 01:45:26 GMT

Hi Aaron

Any recent updates on the technical front?

Best,

Jeenter

RE: DLPLCR65EVM: DLP LightCrafter 6500 Video Pattern Mode: unexpected photodiode-signal dips in 255 greyscale during 16.5 ms RGB frame window

Dorrin Ashrafi — Wed, 29 Jul 2026 22:11:21 GMT

Hi Aaron,

Thank you for taking a look at the output. The LightCrafter sequence was configured to repeat, with a 60 Hz input frame period of approximately 16.667 ms. The original screenshot was zoomed out, which made the timing appear slower than it actually was.

I have attached a closer view of the acquisition with cursors marking the relevant timing:

The scope was triggered at the rising edge
Cursor 1 (Atart of Frame) was manually set at t=0.
- This is the rising edge from the trigger settings
Cursor 2 (Unexpected dip in red) was visually placed on the first falling edge
- Seems to be 1.65 ms after the rising edge
Cursor 3 (Unexpected dip in green) was manually placed by setting it at Cursor 2 + 5500us
- The 5500us being the channel duration set in light crafter using the attached light crafter settings file - essentially assuming it would land in the same place in the green channel as it did in the red - and it did.
Cursor 4 (Unexpected dip in blue) was manually placed by setting it at Cursor 3 + 5500us
- Same as the green channel
Cursor 5 (Total Active Area) was manually placed by setting it at Cursor1 + 3*5500us
- Basically the expected active time based on the settings file; 3 channels of 5500us
Cursor 6 (Total Frame) was manually placed by setting it at Cursor1 + 16.66666667 ms
- This is where a hypothetical 60Hz frame ends, and is, as you would expect from the settings file, about 167us after the end of the active period.

we have the binary data for overnight test as well if you would like us to send that over.

I've attached the analysis project for WaveForms (the program for controlling our Digilent Discovery3 scope) that I made based on our acquisition in that test, along with the light crafter configuration file. If you want to run your own analysis, you should be able to do this from this data, but I'd be happy to provide it if you don't want to install WaveForms.

I've also included the cumulative acquisition screenshot. This screen shows that less than 0.01% of all acquisitions in the total capture were different from the acquisition I based my measurement off of. So I can confidently assert that at least 115,712 acquisitions were of the shape that my cursors were put on.

e2e.ti.com/.../60Hz_5F00_VPM-_2800_2_2900_.txt. . .

DLPDLCR230NPEVM: Is the DLP LightCrafter Display 230NP evaluation module compatible with Raspberry Pi 5?

Ali Bagheri — Wed, 29 Jul 2026 21:04:55 GMT

Part Number: DLPDLCR230NPEVM

The DLPDLCR230NPEVM says "Raspberry Pi 4 compatible out of the box," but doesn't mention Pi 5.

Has anyone gotten it working on a Pi 5?

I know Pi 5 moved DPI video output to their new RP1 chip instead of the main chip, which might not be compatible with the this projector's display controller.

Is there an updated config for Pi 5, or would I need to rework the Pi 4 setup myself?

I'm building a hand-held device and want to use a Pi 5 for better camera, and faster compute. Any information is appreciated.

Thanks.

SN74LXC2T45: Top marking

Norma Dixon — Wed, 29 Jul 2026 10:24:46 GMT

Part Number: SN74LXC2T45

SN74LXC2T45DCUR

The part has a top marking of 2LDT

However, the datasheet does not have any details for this part, so we cannot confirm if this is correct or not.

Can you please confirm the top marking is correct.

Many thanks

RE: SN74LXC2T45: Top marking

Joshua Salinas — Wed, 29 Jul 2026 15:13:41 GMT

Hello Norma,

The top side marking is 2LDT.

Regards,

Josh

DLPC231S-Q1: Failed to program the DLPC231

nick LEE — Wed, 29 Jul 2026 03:35:24 GMT

Part Number: DLPC231S-Q1

Programming Failure Process of DLPC231.docx