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.

DLP Light Commander - phase shift in the beginning of a sync'ed ordered pattern



Hi


We're trying to use the Light Commander in order to project an ordered sequence of images with a sync signal. The index in the cycle of the image (i.e the phase) is crucial in our case - and yet it seems that once we set the order via  DLP_RegIO_WriteImageOrderLut, and run DLP_Display_DisplayPatternAutoStepRepeatForMultiplePasses -- in the images we get back according to the 1st, 2nd, etc.. sync signals, we get initially other images, and not the 1st, 2nd, etc.. images from the order LUT. Could this be? I mean, in many applications the beginning of the patterns cycle is important. How can it be fixed so that we get the sync signals without a phase shift in the cycle? Can we reset some register in order to tell the LC where to start cycling bit planes?

Thanks,


Guy

  • Hi Guy,

    Welcome to DLP & MEMS forum.

    I would like to better understand on the problem; as per your comment in above description "in the images we get back according to the 1st, 2nd, etc.. sync signals, we get initially other images, and not the 1st, 2nd, etc.. images from the order LUT" What do you mean by " initally other" images? Are you seeing "consistent" behavior in other captured images or does is it random?

    One work around to over come this problem  -

    Call the APIs in following order,

    1) DLP_Display_DisplayPatternManualForceFirstPattern ()

    2) DLP_RegIO_WriteImageOrderLut()

    3) DLP_Display_DisplayPatternAutoStepRepeatForMultiplePasses ()

    Regards,

    Sanjeev

     

  • Hi Sanjeev,

    Thanks for the prompt reply.. We've looked, and tried your proposed workaround, but still - if our sequence of images is [0,1,2], then we get either [1,2,0,1,2,0,..], [2,0,1,2,0,1,..], or [0,1,2,0,1,2..], but without  any visible consistency (we've tried to reset the DLP Light Commander). By "initially other" - I mean the sequence does not begin from frame 0. The beginning frame seems random. In our code we use an initial batchfile for most of the initalization and set a few parameters via the API. I attach the relevant code snippet, and the batchfile, in case they are of help. Please let me know if more information is required / relevant.

    Thanks,
    Guy

    $L2.5 ExecutePassthroughDLPAPI  _DisablePwmSeq
    $L2.5 DLP_RegIO_BeginLUTdata SEQ_LUT
    $L2.5 WriteReg 0x1111, 0x000000c0
    $L2.5 WriteReg 0x1111, 0x00000008
    $L2.5 WriteReg 0x1111, 0x00260005
    $L2.5 WriteReg 0x1111, 0x00080004
    $L2.5 WriteReg 0x1111, 0x00080004
    $L2.5 WriteReg 0x1111, 0x00080004
    $L2.5 WriteReg 0x1111, 0x00080004
    $L2.5 WriteReg 0x1111, 0x00080004
    $L2.5 WriteReg 0x1111, 0x00080004
    $L2.5 WriteReg 0x1111, 0x00080004
    $L2.5 WriteReg 0x1111, 0x00080004
    $L2.5 WriteReg 0x1111, 0x00080004
    $L2.5 WriteReg 0x1111, 0x00080004
    $L2.5 WriteReg 0x1111, 0x00080004
    $L2.5 WriteReg 0x1111, 0x00080004
    $L2.5 WriteReg 0x1111, 0x00080004
    $L2.5 WriteReg 0x1111, 0x00080004
    $L2.5 WriteReg 0x1111, 0x00080004
    $L2.5 WriteReg 0x1111, 0x00680004
    $L2.5 WriteReg 0x1111, 0xa030000a
    $L2.5 WriteReg 0x1111, 0xffff0003
    $L2.5 WriteReg 0x1111, 0x752e0004
    $L2.5 WriteReg 0x1111, 0x752e0004
    $L2.5 WriteReg 0x1111, 0x752e0004
    $L2.5 WriteReg 0x1111, 0x752e0004
    $L2.5 WriteReg 0x1111, 0x752e0004
    $L2.5 WriteReg 0x1111, 0x752e0004
    $L2.5 WriteReg 0x1111, 0x752e0004
    $L2.5 WriteReg 0x1111, 0x752e0004
    $L2.5 WriteReg 0x1111, 0x752e0004
    $L2.5 WriteReg 0x1111, 0x752e0004
    $L2.5 WriteReg 0x1111, 0x752e0004
    $L2.5 WriteReg 0x1111, 0x752e0004
    $L2.5 WriteReg 0x1111, 0x752e0004
    $L2.5 WriteReg 0x1111, 0x752e0004
    $L2.5 WriteReg 0x1111, 0x752e0004
    $L2.5 WriteReg 0x1111, 0x752e0004
    $L2.5 WriteReg 0x1111, 0x752e0004
    $L2.5 WriteReg 0x1111, 0x752e0004
    $L2.5 WriteReg 0x1111, 0x752e0004
    $L2.5 WriteReg 0x1111, 0x752e0004
    $L2.5 WriteReg 0x1111, 0x752e0004
    $L2.5 WriteReg 0x1111, 0x752e0004
    $L2.5 WriteReg 0x1111, 0x752e0004
    $L2.5 WriteReg 0x1111, 0x752e0004
    $L2.5 WriteReg 0x1111, 0x752e0004
    $L2.5 WriteReg 0x1111, 0x00300004
    $L2.5 WriteReg 0x1111, 0x00000001
    $L2.5 WriteReg 0x1111, 0x00180005
    $L2.5 WriteReg 0x1111, 0x00f9f004
    $L2.5 WriteReg 0x1111, 0x0e669004
    $L2.5 WriteReg 0x1111, 0x002f9008
    $L2.5 WriteReg 0x1111, 0xc6109f04
    $L2.5 WriteReg 0x1111, 0xc6109f04
    $L2.5 WriteReg 0x1111, 0xc6109f04
    $L2.5 WriteReg 0x1111, 0x0f901f04
    $L2.5 WriteReg 0x1111, 0xbc771004
    $L2.5 WriteReg 0x1111, 0x00180004
    $L2.5 WriteReg 0x1111, 0x00000001
    $L2.5 DLP_RegIO_EndLUTdata SEQ_LUT
    $L2.5 WriteReg 0xC0, 0x00000044
    $L2.5 WriteReg 0x4C4, 0x00196e6a
    $L2.5 WriteReg 0xCC4, 0x00000000
    $L2.5 WriteReg 0xCD0, 0x000003c0
    $L2.5 WriteReg 0xCC8, 0x00000001
    $L2.5 WriteReg 0xCCC, 0x00000001
    $L2.5 WriteReg 0xCD8, 0x00000104
    $L2.5 WriteReg 0x500, 0x00000000
    $L2.5 WriteReg 0xCD4, 0x00002576
    $L2.5 ExecutePassthroughDLPAPI  _EnablePwmSeq
    $L2.5 DLP_Source_SetDataSource  3
    $L2.5 DLP_Trigger_SetExternalTriggerEdge  1
    $L2.5 DLP_Display_HorizontalFlip  1
    $L2.5 DLP_Display_VerticalFlip  0
    $L2.5 DLP_Display_SetDegammaEnable  0
    

    InitPortabilityLayer(loglvl+1, loglvl, Logit);
    DLP_Display_DisplayStop();
    const bool STOP_ON_ERROR=true;
    RunBatchFile(batch_name,STOP_ON_ERROR));
    DLP_LED_SetLEDEnable(LED_R,R_LED_active);
    DLP_LED_SetLEDintensity(LED_R,R_LED_intensity);
    DLP_Sync_SetEnable(1,1);
    DLP_Sync_SetEnable(2,1);
    DLP_Sync_SetEnable(3,1);
    DLP_Sync_Configure(1,1,0,(UInt32)sync_pulse_width);
    DLP_Sync_Configure(2,1,0,(UInt32)sync_pulse_width);
    DLP_Sync_Configure(3,1,0,(UInt32)sync_pulse_width);
    
    DLP_TPG_SetTestPattern(DMD_XGA,SOLID,TPG_WHITE,1);
    // ..
    // read all images to DLP memory using WriteExternalImage(),
    // store display order in array "order"
    
    DLP_RegIO_WriteImageOrderLut((Byte)nbpp, order, (UInt16)cnt));
    DLP_Display_DisplayStop();
    
    // 
    // Initialization code for another device
    
    DLP_Display_DisplayPatternAutoStepRepeatForMultiplePasses();
    

  • Hi Guy,

    Your code snippet doesn't have call to DLP_Display_DisplayPatternManualForceFirstPattern () API. From your comment I presume you have already tried this option as well. Please confirm if this is not the case.

    I know that we had issue with first pattern skipping (but not the randomness like you are observing) we are close to making a new  firmware upgrade for the LightCommander it is in final stages of DVT; I think this will also fix the issue you are seeing.

    In case of randomness there is another way to over come -

    Insert a known pattern in the image order i.e, instead of 0,1,2, add one more known pattern in the begining 0, 1, 2, 3 with 0th position occupied by known pattern (you can insert a black pattern); after the patterns capture you can search for black pattern then from that position you will get the 1st pattern, 2nd pattern and 3rd pattern so on.

    Regards,
    Sanjeev