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.

DLPC3478: Internal pattern streaming, error after standby mode

Part Number: DLPC3478

Hi, This is a follow up thread from the closed thread here: e2e.ti.com/.../936452 Now we have reproducing example for evm3010LC development kit.

Previous ticket text: we have a case where we run the DLPC3478 in internal pattern streaming mode.  After projecting a predefined sequence of 1-bit and 8-bit patterns we would like to park the mirrors after the unit is idle for some seconds. When going back to internal pattern streaming mode and configure/display new sequence we would expect the same pattern sequence to work as before, but occasionally (about 1/20 to 1/100 times) we see that the first frame of the sequence is corrupt. It looks like it exposes a corrupted version of the last pattern from before standby. How should we configure the DLPC3478 to switch from standby mode to internal pattern streaming mode to make it work every time?

Please see attached reproducer mirror_park.py for the pico display 3010evm GUI software
mirror_park_test.zip

  • Hello Anders,

    Welcome back to the E2E forum.

    We are looking into your query and will respond by the end of the week. For the time being, would you be able to repost the link to the previous conversation for context? It appears that the link is broken.

    Regards,

    Austin

  • Sorry, just remove the garbage at the end:

  • Thank you for sending this, Anders. We will look this over and get back to you.

    Regards,

    Austin

  • Anders,

    It looks like there is no delay/wait time between the moment you set the system to leave standby mode and when you initate the internal pattern streaming mode. Have you tried adding sleep time to determine the required delay during this transition? This may be necessary to alleviate artifacts during mode switching.

    Regards,

    Philippe Dollo

  • You mean a delay is needed between these two lines? 

        WriteOperatingModeSelect ( OperatingMode.SensInternalPattern )
        # Delay here? 
        WriteInternalPatternControl (PatternControl.Start , 0 )



    1. Can you confirm you have reproduced this issue?

    2. How long delay? Can you please find out exactly how long delay is needed? We have tried putting the operatingModeSelect(internal pattern) before all the pattern configuration, that produces the same results. So I would assume minimum 10-20+ milliseconds of delay is needed. That would be a major setback for us, as we need as short response-time as possible, even after periods of standby.

    If a long delay is actually needed, it is a blocker for us, How can we ensure long lifetime of the DMD without mode-switch that incurs long delay? (We want standby just for putting mirrors in 50/50 duty cycle to increase lifetime)

  • Anders,

    No, we haven't reproduced the issue at this time on our end. 

    Will need some time to investigate. Myself or the team will respond back here in a couple days with what we consider the best solution in your case. It sounds like your main concern is DMD lifetime, so we'll keep that in consideration.

    Regards,

    Philippe Dollo

  • Anders,

    Thanks for your patience.

    The required delay would primarily depend on what you are doing with the system. In cases where the system is reading from the EEPROM flash memory a significant delay can be needed (up to 500 milliseconds in cases such as reading a new splash screen over the SPI bus).

    In most cases where frequent use of operating mode switching is being used, you will probably have better luck if you use the "Image Freeze" command to hide artifacts. I don't believe you will be able to eliminate them entirely (though you should be able to prevent them from appearing on the screen). See 3.1.18.2 of the DLPC3478 Programmer's Guide for more information.

    I hope this helps.

    Regards,

    Philippe Dollo

  • Hi again,

    I don't think our problem would be solved by using image-freeze. The problem is that the wrong pattern is being displayed in internal pattern mode about 1/20 to 1/100 of the sequences if changing operating mode to internal pattern mode first. We are using the dlpc3478 to trigger camera-exposure. We do believe we have the same issue upon first boot, but there we can work around it by running one dummy internal pattern sequence as part of boot up and disregard the data.

    Our problem arises when we want to switch back and forth between standby (to park mirrors) and internal pattern mode during normal operation, and we need as short delay as possible from standby to starting a new sequence. Adding a 0.5s delay there is not feasible for us. 

    We have tried switching from test-pattern mode as well, but we see the same issue with wrong first pattern a significant fraction of the time when running internal pattern sequence right after coming from test-mode.  

    Are there any other way to "park" the mirrors to increase lifetime, without hitting this mode-switch issue, and allowing very short delay from un-park to internal pattern sequence?

    Can you also please try to run our python-reproducer, it is quite obvious that the wrong pattern shows up one out of 20-100 times.

  • Anders,

    Interestingly enough I am not actually seeing the issue you describe with your script. I ran it for a while and didn't see any glitches in the pattern output.

    I am using v2.2.0.6 of the Pico Display and Light Control EVM GUI, executing your script in the "Scripting" mode of the Advanced control page.

    There is a "Mirror Lock" command that does park the mirrors, but I do not believe it is suitable for what you are trying to do. The standby mode is probably better for this kind of application.

    Are you adjusting any other settings when running your script? I am running it from boot with default settings.

  • How do you look for glitches? I can only spot it if I actually trigger a camera with the exposure-trigger output from the DLPC. See attached image of some captures images, and one single first image which is different. This only happens a few percent of the sequences, and only if we go to a different mode (standby or test-pattern or external) and back to internal pattern. If we stay in internal pattern all the time, we can run for days before we get other issues (I2C timeout for example, different support ticket on that). 

  • Anders,

    Thanks for elaborating. I wasn't triggering with a camera, as it sounded like the issue was noticeable to the naked eye from your explanation above.

    I'll inquire with the team if we can get a camera trigger setup to try to replicate the issue here.

  • Any update on this issue? Have you managed to reproduce yet?

  • Anders, 

    I tried to reproduce it last week but couldn't do so. I will be trying this again with the FLIR camera and will let you know my findings before end of this week.

    Regards,

    Mayank

  • Anders,

    I believe the team is still working this issue. We will post here with more information when it is available.

    Thanks ahead for your patience.

    Regards,

    Philippe

  • I am reopening this so the customer can post again.

  • Thanks for reopening this issue, is there any progress on reproducing this?  have you connected a flir-camera you can trigger with the trig_out_2 signal?

  • Anders, 

    No problem. I'm not sure of the current status. Will inquire with the team and see if they can post back here as soon as possible.

    Regards,

    Philippe

  • HI Philippe, Is there any update on this?

    Thank you,

    Albert

  • Albert,

    Unfortunately not. Team has been backlogged too much to be able to delve further into this issue. Will keep you posted.

    Regards,

    Philippe

  • Albert,

    There are still no updates on this particular issue. Apologize for the inconvenience. Will post back here soon.

    Regards,

    Philippe

  • Hello Anders and Albert,

    We couldn't make progress in looking into this issue the the team has been fully occupied in other activities.

    Kindly reach out to us via mail if this is a major blocking issue for you and we will try to take it up accordingly. 

     

    I am going ahead and closing this thread. 

    Regards,

    Mayank