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/1661352/dlp3940s-q1-quincunx-algorithm-details-for-soc-cpu-gpu-implementation-dlp3940s-q1-dlpc231s-q1/6418655Thu, 16 Jul 2026 06:39:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:db7bd0d6-53b0-4f94-b49a-7fa4fc48d1e4Aishwarya K AithalHello Jim, I have provided access. You would have received an email with the link. Thank you, Regards, Aishwaryahttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1664760/dlpnirnanoevm-additional-componentThu, 16 Jul 2026 03:10:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:61234364-691a-4a27-a8c3-6bce31c5ff94Marlon ReisPart Number: DLPNIRNANOEVM Hello, We would like to purchase and additional &#39;Compact illuminaton module (for NIRscan Nano) to adapt it for fibre optic connection and I was just wondering if that is available for sale? Kind Regards, Marlon 2513885A_NIRscanNano_COMPACT_ILLUMINATION_MODULE_2LAMP.pdfDLPNIRNANOEVMhttps://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-fineThu, 16 Jul 2026 01:55:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d55c6198-ed9a-4f52-902e-da05190ba7ccbai baiPart Number: DLPC900 System Info Controller: DLPC900 Firmware:6.3.0 Interface: Linux (ARM), I2C bus 1, slave address 0x1A Reference: DLPC900 Programmer&#39;s Guide (ZHCU950J – OCTOBER 2014 – REVISED JUNE 2024) Problem Description We are trying to set the Minimum LED Pulse Width (ns) via I2C, but the written value has no effect on the actual projection exposure time. The same operation works correctly via the official GUI tool over USB. What We Have Confirmed I2C communication is working I2C bus scan shows device at address 0x1A responds correctly We can successfully read registers via I2C We can read back the value we wrote to 0x67, confirming the I2C write ACK is received USB works correctly The official GUI tool (USB HID) can successfully set LED Pulse Width and the projection changes accordingly USB capture confirms the command sent is CMD2=0x1A, CMD3=0x43, with 4-byte LE payload I2C write appears to succeed but has no effect But by using USB to write and then I2C to read, the shortest exposure time set by USB can be read So I would like to ask, is there a problem with the register I am writing to? I tried using i2cTransfer to write data to registers 0x62 and 0x67, but when I read the data using i2c, I found that it did not take effect. We have tried the following methods sudo i2ctransfer -y 1 w5@0x1A 0x62 0x88 0x13 0x00 0x00 sudo i2ctransfer -y 1 w5@0x1A 0x67 0x88 0x13 0x00 0x00 sudo i2ctransfer -y 1 w2@0x1A 0x62 0x88 sudo i2ctransfer -y 1 w2@0x1A 0x67 0x88 Then use sudo i2ctransfer -y 1 w1@0x1A 0x63 r16 sudo i2ctransfer -y 1 w1@0x1A 0x65 r16 After completing the USB settings, the above command is also used for reading.DLPC900https://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/6418385Thu, 16 Jul 2026 01:25:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:8235c8cd-cb7c-41db-a554-55e36332d251jim liuHi Aishwarya, Thank you for your reply and for offering the MATLAB suite. I really appreciate it. My email associated with myTI account is: jim.liu@arrowasia.com Please feel free to share the quincunx processing matlab suite there. If anything else is needed from my side, just let me know. Best regards, Jim Liuhttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1664321/dlp5531a-q1-dlp5531-q1-output-image-of-black-and-white-line-pairs-is-unclear-with-1902x1521-input-resolution/6417780Wed, 15 Jul 2026 16:26:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:bf7a817c-c978-4303-a0cb-01226e6ece5bMichael LyHi Eric, Thanks for raising this to us. May I ask a few initial questions just to better understand what is going on? Is this a custom design you are working with that has a DLP5531 DMD installed in it, or is this TI&#39;s EVM. If so, which one? Please copy and paste the product page here. What software are you using? Are you able to tell us the project file? How did you load your image into flash, and what file format was it originally? I would assume this is some splash image, right? Or is this external video of some sort? Did you check your error log in DLPC230 Automotive Control Program? If so, what did it say, or what does it say when you load and project this image? Normally, inputting an unsupported resolution would mean the DLPC230 does not have video lock or should not display--at least to my knowledge. Which batch command set are you using? Below is an example. May you please send us a few photos of your setup? Photo of full system put together with power supply Photo of individual boards with jumper configs (if any) if you are using TI EVM Be sure to include any LEDs if TI EVM Is there anything else you are doing to get to this point you have not mentioned yet? Sorry for the large list of questions--I just want to be sure I can help you without taking on any assumptions and missing anything! 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/6417748Wed, 15 Jul 2026 16:12:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:66fbf642-2811-4ff1-9fb7-9be5e630faeeAishwarya K AithalHello Jim, My apologies for the delayed response. We can provide a sample matlab suite for the quincunx processing. Please share the email associated with you &quot;myTI account&quot;. You can share it over private E2E if that is preferred. Thank you, Regards, Aishwaryahttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1663720/dlpdlcr3010evm-g2-dlpdlcr3010evm-g2-disable-internal-leds/6417727Wed, 15 Jul 2026 16:03:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:38aee40c-0c5d-46ae-8a91-fef627565c6dKevin RiveraHi Christian, Welcome to E2E forums! I am looking into this and will share information soon. Thank you, Kevin Riverahttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1664321/dlp5531a-q1-dlp5531-q1-output-image-of-black-and-white-line-pairs-is-unclear-with-1902x1521-input-resolutionWed, 15 Jul 2026 02:51:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:fa04d286-0c35-4a8f-8f07-707deacf48b3Eric LeePart Number: DLP5531A-Q1 Hi TI Team, I am currently using the DLP5531-Q1. When I input an image with a resolution of 1902x1521, the black-and-white line pairs in the output image appear blurry and are not clearly resolved. Could you please explain what changes or effects occur in the projected output when the input resolution exceeds the native resolution of the DMD? Thank you!DLP5531A-Q1https://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1636590/dlpnirnanoevm-dlpnirscan-nano-dlpspec_scan_interpret-returns-rc--4-not-a-valid-tpl-file-on-linux/6416638Tue, 14 Jul 2026 23:57:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d922a8ec-7c90-45cf-8201-456bad60a470Shiva ReddyDear Aaron, I need TI&#39;s help - Treat this as SoS. Thank youhttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1664131/dlpnirnanoevm-program-firmware-version/6416408Tue, 14 Jul 2026 20:13:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:4b0aa05c-865f-43cb-894b-91544c528b69Aaron BlackHello Chenglq, Please advise where you are seeing this because the latest version should be v2.1.0 under the TIDCC48 Support Software and the spectrum library is v2.0.3 for Windows. Best, Aaronhttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1660841/dlp991u-dlp991u-for-static-full-array-per-pixel-binary-patterns-no-xpr-minimum-drive-system-and-400-nm-operation/6416337Tue, 14 Jul 2026 19:14:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:44ae4146-f7f3-4319-889f-57fbf95bd76dTristan BottoneHello Joongwon, Yes, every pixel is an independent physical mirror for the DLP991U. The DLP991U has ~8.9 million mirrors and is native 4K (4,096 x 2,176) with no XPR, pixel shifting, or multiplexing of any kind. Each mirror is individually switched to +12&#176; (ON) or −12&#176; (OFF) and held there between clocking pulses. A static line-strip or grid pattern will remain locked in the array until new data is explicitly loaded onto the array which serve use for LDI, machine vision, and precision patterning applications. The DLPC964 controller has no HDMI or USB video input path. Its pixel data interface is a 32-lane differential high-speed serial interface (HSSI) running up to 120 Gbps across 12 input lanes, and an external FPGA is required to source bit-plane data over this interface. The DLPLCRC964EVM-SW GUI provides I2C-based configuration and status control from a PC, but that does not substitute for the FPGA in the data path. The DLPR964-FW firmware does include a set of fixed internal test patterns that can be displayed without custom FPGA code, which is useful for initial optical setup, but for loading arbitrary user-defined bitmaps a programmed FPGA is required. We also provide the DLPC964-APPS-FPGA-FW firmware which includes the configuration file for programming the VC-707 using Vivado and the Apps FPGA VC707 VHDL code for the DLPC964 Controller. The Apps FPGA (VC-707) source code and firmware file provided with the DLPLCRC964EVM is intended as a reference design and starting point, demonstrating how pattern data can be streamed to the DLPC964 for display on the DLP991U. It intentionally implements smaller pattern memories that are replicated across the DMD to support common structured-light use cases out of the box. From an architectural standpoint, the Apps FPGA (VC-707), DLPC964 controller and DLP991U DMD are capable of supporting full-resolution custom patterns; however, achieving this requires customer-specific FPGA development. For applications that require full control, customers are expected to extend or replace the reference FPGA design with their own implementation that supports higher-bandwidth data delivery and full-resolution pattern storage. Also, it&#39;s important to note that the VC-707 became obsolete and is very expensive to obtain. We are in the process of reporting the VC-707 Apps FPGA to a different external FPGA, that being the ZCU102. Regarding wavelength at ~400 nm, the DLP991U is rated from 400 nm to 700 nm, so 400 nm sits right at the minimum specification boundary. The 97% window transmission and 89% mirror reflectivity specs are stated across the rated range, and 400 nm is within that range for the standard DLP991U. For illumination that is primarily visible with a near-UV edge at 400 nm, the DLP991U is still fine. The DLP991UUV is a UV-only device rated from 343 nm to 410 nm with an AR coating and window optimized for that narrow UV band, so it is not intended for full visible-spectrum use. Since your illumination spans visible wavelengths including ~400 nm, the standard DLP991U is the appropriate choice. Check out the app note System Design Considerations Using TI DLP Technology Down to 400 nm (DLPA052A) . This provides relevant guidance on operating at the UV edge of the visible range. On the question of highest native resolution, the DLP991U (4,096 x 2,176) is DLP&#39;s highest native-resolution industrial DMD with no XPR. The next options would steps down in resolution for the Industrial portfolio, these would be the DLP670S (2,716 x 1,600) and DLP9000 (2,560 x 1,600). There are no other native-4K non-XPR DMDs in DLP&#39;s current product portfolio. For a lower-cost and simpler configuration without an external FPGA, the recommended path is the DLPC900 controller. The DLPC900 includes a USB port that allows full pattern loading from a PC with no FPGA required. It has 128 MB of internal DRAM capable of buffering several hundred 1-bit patterns where patterns can be managed and triggered directly from the DLPC900 GUI software . For the simplest possible evaluation path, a single DLPC900 paired with the DLP6500 (1,920 x 1,080 native, 420 - 700 nm) is the easiest starting point and controllable entirely over USB. If you need more pixels, the DLP9000 (2,560 x 1,600) is the next step, but note it requires two DLPC900 controllers in a dual configuration — the DLPLCRC900DEVM hosts both. Given that your application is static or slowly changing patterns, the DLPC900&#39;s pre-stored pattern mode is well-suited for your application since the patterns are loaded into DRAM over USB and then displayed on demand without any continuous host interaction. The resolution trade-off relative to native 4K is affected, but for optical inspection grids and line strips the question is whether the pixel pitch and field of view are sufficient for your specific feature sizes and image coverage. If your inspection targets can be resolved at 1080p or WQXGA with appropriate projection optics, the DLPC900-based systems offer a substantially simpler and faster evaluation path! Best Regards, Tristan Bottonehttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1662061/dlp650lnir-dlp650lnir-informations/6416051Tue, 14 Jul 2026 16:10:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:722b2053-9be0-44e7-ba23-822883ca3240Tristan BottoneHello Stephane, The DLP650LNIR is fully compatible to operate with wavelengths at 940 nm. Regarding optical power, 200 W exceeds the device’s maximum rated incident power of 160 W. This limit is based on the DMD’s thermal capability, and operation above 160 W risks permanent damage to the micromirror array and window. The DLP650LNIR is the highest-power NIR DMD in DLP&#39;s current portfolio, so there would be no alternative TI device that supports 200W at this wavelength. To use the DLP650LNIR, the source power would need to be reduced or attenuated to 160W or below before reaching the DMD. Your 2.2 mm diameter Gaussian beam is also an important consideration. Before the beam reaches the DMD, it should be expanded to illuminate as much of the active array as possible. Since the DLP650LNIR has an active area of 13.824 mm &#215; 8.64 mm, expanding the beam reduces the optical power density (irradiance) on the DMD which is critical for staying within the device’s thermal limits. For beam-shaping applications, the recommended optical architecture is to first expand the beam so it fills the active area, then use the DMD as a spatial light modulator to generate the desired intensity pattern. At 160 W, if the beam is expanded to illuminate the full active area of the DMD, the average irradiance is approximately 134 W/cm&#178;, which is below the DLP650LNIR thermal design limit of 204 W/cm&#178;. This information can be found within the DLP High Power NIR Thermal Design Guide (DLPA104) and DLP650LNIR datasheet (DLPS136), which provides the detailed thermal calculations and heatsink design procedure . In summary, the DLP650LNIR would be a suitable choice for dynamic CW laser beam shaping at 940 nm, provided the source power is reduced to 160 W or less and the beam is expanded before reaching the DMD. I also recommend reviewing the DLP650LNIR datasheet , DLPA027B , DLPA104 , and chipset documentation ( DLP650LNIR + DLPC410 + DLPA200) before finalizing your optical and thermal design. If your application requires high-speed beam shaping, the OPTECKS-3P-SPARKNIR optical engine module is a third-party solution built around the DLP650LNIR with AR coatings across the 600–1050 nm wavelength range. Hope this helps! Best Regards, Tristan Bottonehttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1664131/dlpnirnanoevm-program-firmware-version/6416025Tue, 14 Jul 2026 15:52:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:51d7b5a6-8ed6-4051-a7c6-81cb6a4a3ce2Tristan BottoneHello Chenglg, Thank you for reaching out and using the E2E forums! An expert from our team will review the thread and get back to you shortly. Regards, Tristan Bottonehttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1659083/dlplcr70evm-questions-about-new-dlpm980e2evm-plm-evaluation-module/6415928Tue, 14 Jul 2026 15:01:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:f34fa1e8-baba-438c-a50b-3bb0bf27cd36Tristan BottoneHello Peter, Thank you for the questions regarding the DLPM980E2EVM. Please see my response below. For your first question, the 16-pin MBRST connector on the DLPM980E2EVM exposes the MCP (Mirror Clocking Pulse) signals generated by the DLPC641 Controller. You can use it to passively monitor MCP activity with a scope or logic analyzer (reasonable debugging approach), but externally driving the MCP through this header is not supported. The DLPC641 generates all MCP timings internally and manages the setup time, hold time, and sequencing relative to the DMD data load cycle. Injecting an external signal into this path would bypass these timing constraints, risking unreliable mirror switching or damage to the DMD. If you wanted to drive the PLM with an external MBRST source after disconnecting the existing trace, t he only &#39;possible&#39; solution I can think of would be to replicate the controller’s load-pulse sequencing and issuing a reset before the corresponding block data has fully loaded. Any externally generated MBRST pulses will need to respect that same timing or you risk loading data into mirrors that haven’t finished settling. For the second question regarding switching noise vs. traditional tilt, the PLM utilizes a piston motion rather than the traditional tilt method. Each mirror moves up/down through discrete height levels to impose a phase shift rather than flipping between two angular positions. Since the PLM moves in a piston motion rather than angular, the switching noise/flicker mechanism is fundamentally reduced by the piston architecture, producing less lateral/rotational coupling into the optical path. Best Regards, Tristan Bottonehttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1659564/dlpc964-the-hssi_bus_err-status-of-dlpm980e2evm-is-abnormal/6415911Tue, 14 Jul 2026 14:52:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:db86a48a-4b76-4c7e-922b-f8cfc1be5370Tristan BottoneHello Yaohong, Thank you for the question and for sharing the waveform. The HSSI_BUS_ERR signal going high after asserting DMDLOAD_REQ is most commonly caused by one of two issues, and both relate to how DMDLOAD_REQ is being asserted. This issue is likely due to a DMDLOAD_REQ setup time violation. If you refer to Section 4.3.3.11 of the DLPC964 Apps FPGA User&#39;s Guide (DLPU133) , it specifies that DMDLOAD_REQ must be asserted no sooner than 300ns after the first TVALID data packet of that block was sent over the Aurora interface. This requirement accounts for the Aurora TX channel path latency and ensures the DLPC964 receives the DMDLOAD_REQ only after all block data has already arrived at the controller. This timing window becomes especially critical when sending small or partial blocks (few rows) where the entire data transfer may complete in under 300ns. Please measure the time from your first TVALID assertion to your DMDLOAD_REQ assertion on your waveform and confirm this 300ns minimum is being met. The second thing to verify is that all four Aurora data channels have completed their transfers before DMDLOAD_REQ is asserted. As noted in Section 4.3.3.10, the four Aurora channels (CH0-CH3) are not synchronous to one another and do not complete on the exact same clock cycle. Asserting DMDLOAD_REQ before completion of the Aurora block transfer can result in data not loaded properly onto DMD, cause sync errors on the HSSI bus and assert HSSI_BUS_ERR signal. Please confirm all four gt_s_axi_tx_tvalid/tready signals are asserted high to indicate to Aurora core the DMD pixel data is valid to transmit and are fully complete across all channels before DMDLOAD_REQ is driven high. Best Regards, Tristan Bottonehttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1664131/dlpnirnanoevm-program-firmware-versionTue, 14 Jul 2026 13:08:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:dec61ecd-9907-4133-b0b5-db97741dde7fchenglqPart Number: DLPNIRNANOEVM Regarding the official links for the DLPNIRNANOEVM, is there a newer version of the Tiva SW available? Also, the spectrum library on the official website is currently v2.0.3 – is there a newer version? I saw online that someone mentioned their spectrum library is already v2.1.2. If there is a newer version, could you please provide it? Thank you! My email is chenglq@gttc.com.DLPNIRNANOEVMTest &amp; Measurementhttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1663355/tpsm863257-non-china-products-xxxxxxx-a/6415673Tue, 14 Jul 2026 11:51:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:6847f081-33c6-472b-a5f2-b4f5c45c0defAlla UshasriHi Guela, Alternate part numbers with a “.A” suffix use a wafer fabricated in the U.S. and can be imported into the U.S. without potential future tariff impact. Please refer www.ti.com/.../import-details.html for more details. Regards, Usha.https://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1663720/dlpdlcr3010evm-g2-dlpdlcr3010evm-g2-disable-internal-ledsMon, 13 Jul 2026 14:47:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:6a005788-32e0-47e6-a8b0-6efb1414babaChristian BlumPart Number: DLPDLCR3010EVM-G2 Hello, I would like to use the DLPDLCR3010EVM-G2 for a projection system using an alternative light source. For this purpose I ideally would like to disconnect the internal LEDs as I would not be using the LED driver of the EVM. Is it possible to update the firmware such that the internal LEDs can be disconnected? I&#39;ve found a similar question to a previous model here and would essentialy want to do the same. ThanksDLPDLCR3010EVM-G2Medical &amp; healthcarehttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1636590/dlpnirnanoevm-dlpnirscan-nano-dlpspec_scan_interpret-returns-rc--4-not-a-valid-tpl-file-on-linux/6413192Mon, 13 Jul 2026 01:21:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:01b8bdb9-4f52-4992-83ee-66aea3942a95Shiva ReddyThanks for the quick response, Aaron. To clarify exactly what &quot;the issue&quot; is : it&#39;s not a later scan failing — it&#39;s the NNO_CMD_SCAN_CFG_APPLY command&#39;s own USB HID reply. Every reply&#39;s first byte is a flags byte where bits 5:4 encode 00=Success, 01=Error, 10=Busy . Every time we send CFG_APPLY , we get 0x50 back immediately — bits 5:4 = 01 (Error), zero bytes of response data — as the direct reply to that single command. We never see 10=Busy . So we never get as far as attempting a scan; the config-apply step itself is rejected on the spot. We tested your status-check suggestion directly : we now poll NNO_CMD_READ_DEVICE_STATUS (cmd 0x03 , group 0x04 ) before and after every step in our sequence ( CFG_ERASEALL → CFG_SAVE → SET_ACT_CFG → CFG_APPLY ), rather than relying on a fixed delay. It consistently returns 0x05 (Tiva Active + SD Card Present, no busy bits) at every single point — including immediately before and after the CFG_APPLY failure. So the device isn&#39;t reporting itself busy or mid-operation when we send it. New finding since our first post — we also checked NNO_CMD_READ_ERROR_STATUS (cmd 0x04 , group 0x04 ) Immediately after a CFG_APPLY failure, which we hadn&#39;t tried before. It returns: error bitmask = 0x00000020 -&gt; Spectrum Library Error This is a much more specific signal than the generic Error flag. Per the firmware source ( cmdProc.c , cmdSetConfig_wr() ), only the branch where dlpspec_scan_read_configuration() itself fails calls nnoStatus_setErrorStatusAndCode(NNO_ERROR_SPEC_LIB, ...) — the downstream Scan_SetConfig() Validation failures (pattern count, repeat count, Hadamard geometry) do not set this specific bit. So this points at the deserialization step itself failing on the firmware , before scan-config validation even runs. That&#39;s puzzling given what we&#39;ve verified: our payload is a byte-for-byte match (aside from the auto-incrementing scanConfigIndex ) to a capture we independently confirmed succeeded three times in a real Windows GUI session. If the same firmware function is parsing byte-identical data, we wouldn&#39;t expect it to fail for us but succeed for the GUI. One thing we noticed while tracing the GUI source ( API.cpp / NNOCommandDefs.h ) that may be relevant here: the wire length for CFG_APPLY / CFG_SAVE is a fixed constant ( sizeof(scanConfig)*2 = 124 bytes / *2+2 = 126 bytes) left over from the flat Column/Hadamard scanConfig struct, not sized for the actual ~155-byte slewScanConfig Serialization of our Slew-type config needs — so the GUI always truncates the real serialized buffer down to this fixed length before sending, for every Slew scan config, not just ours. On the firmware side, cmdSetConfig_wr() in turn calls dlpspec_scan_read_configuration(pBuf, bufSize) with a fixed bufSize = sizeof(scanConfig)*4 (248 bytes) — not the number of bytes actually received over USB. Given both of those are fixed, oversized constants rather than the true transmitted length, our working theory is that the parser ends up reading past the genuinely received 124 bytes into whatever was previously sitting in that static receive buffer, to satisfy the section array&#39;s own internally declared (but not fully transmitted) length. If that leftover buffer content happens to differ between sessions — ours has been through a large number of CFG_SAVE / CFG_APPLY cycles during this investigation — that could plausibly tip an otherwise-identical payload from parsing successfully to failing. Could you confirm or rule out: Is this truncation ( sizeof(scanConfig)*2 used as the wire length for a slewScanConfig payload) expected/intentional, or a known gap in the GUI/firmware interaction for Slew-type scans specifically? Does dlpspec_scan_read_configuration() &#39;s handling of the two-part (head + section array) TPL structure tolerate a section array that&#39;s shorter than its own internally declared length, or does it require the full declared length to be genuinely present in the buffer? Is the firmware&#39;s receive buffer for this command guaranteed to be cleared/zeroed before each transmission, or could its content depend on what a prior command left there? Happy to share the exact byte sequences (captured working payload vs. ours) and our full error-status dump if that&#39;s useful for someone on your side to reproduce. Really appreciate you looking into this. Regards Shiva Reddyhttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1663355/tpsm863257-non-china-products-xxxxxxx-a/6413142Sun, 12 Jul 2026 16:06:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:eededa4b-2d80-4536-8d4a-8e57bb691f39Alla UshasriHi Guela, Can you refer to which thread your saying about? Regards, Usha.