• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 29 subscribers
  • Views 167 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

DLPDLCR4710EVM-G2: DLPDLCR4710EVM-G2: I2C Communications Issues, I2C bus bussy.

DLPDLCR4710EVM-G2: Short Delay after frame-buffer manipulation.

user4081360
Prodigy 30 points
Part Number: DLPDLCR4710EVM-G2
Other Parts Discussed in Thread: DLPC3439

Hi,

With our DLPDLCR4710EVM-G2 module we are trying to get the most accurate frambuffer timing. To check we are on the right track we are using a variant of this code (running on Linux - Debian 9) to set the screen blue for a frambuffer and then black into the next one.

In the next images we see in Yellow the ITE6801_VSYNC_OUT, pin 1 J4 and in Blue the DLP response measured with a photodiode power-meter.

       

In the images we see a delay just before we set the framebuffer to blue (1) and also a delay in the next one, when the framebuffer should be black (2). 

For reference, we use the same setup but this time the framebuffer is "cyan" (green and blue), in this case the green color wave looks perfect, but the behavior in the blue is equal to the one seeing above.

Do you guys know if this is a hardware error or if it is a software issue?

Thanks for your help.

  • 0
    TI__Genius 12575 points

    Hello User,

    Welcome to the E2E forum and thank you for your interest in DLP technology!

    Our team is limited on bandwidth at the moment, but a member will reach out to you by the end of the week.

    Regards,

    Austin

  • 0 in reply to Austin Snyder
    TI__Mastermind 28005 points

    Hello User,

    You should note that the video stream for the DLPC3439 is double-buffered, so there will be a one-frame delay in the data that you input to the system.

    What frame rate and video timings are you using with the system? 

    Regards,

    Philippe Dollo

  • 0
    Prodigy 30 points

    Currently our frame rate is ~60Hz.

    Our main issue with this lies in the signal cut we have seen at the start of the blue LED (and that seems to be shifted out to the next frame, wich is suposed to be black).

    At the end what we want is to show an image exactly n frames (so maybe it doesn't matter the frame delay if is always the same).

  • 0 in reply to user4081360
    TI__Mastermind 28005 points

    User,

    I understand. It does look from your image like the image color sequence is somehow being interrupted by the input VSYNC signal. Typically this sort of behavior may be triggered if the VSYNC is coming too early. 

    It sounds like your current setup is using a manual framebuffer write operation to send data to the EVM. Do you see the same behavior using the internal test pattern generator mode? I recommend trying the same scenario, but with internal TPG selected. In particular, use the DLP LightCrafter GUI to set the test pattern to a Cyan Solid Field (which would mimic the data you are sending with your frame buffer).

    If the photodiode reaidng looks the same as your frame buffer with the above TPG configuration, then that may indicate something strange happening within the DLP software side. However, if the data is good then you may have an issue with the timings used to execute your framebuffer writes.

    Feel free to share your scope plots from the above if you are able to test it. 

    Best Regards,

    Philippe Dollo