DLPC3478: Internal pattern streaming, error after standby mode

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

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

Any update on this?

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