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.

LightCommander- static memory,frame selection,etc...

Hi,

The LightCommander seems to be a promising solution for my application, however, I have a few questions:

Can the static buffer be expanded, by using an external hard drive for example? If so, could I still reach the high frame rates of the gray and binary scales?

Is the ordering of the frames static, that is, once you've defined it and started running the program it is just going to loop around that sequence, or can you update the frame in each iteration? If so, can you still get the 500Hz for the grayscale. The reason I'm asking is because I would like to control what pattern is being projected using an input to my pc computer. Thus, the program would check the input at every iteration in order to figure out what frame should be projected.

Can I substitute all the LEDs by green LEDs and use the same optics? I'm not sure if the optics that combines the light sources has independent filters for the red light path, for the blue path and so on... so that it would not work if I used all green LEDs.

Someone has already asked this, but it doesn't hurt to ask again, maybe there's been an update. Is there a way of getting a Light Commander with an on axis projection optics?

Thank you!

 

 

  • Hi Leonardo,

    Welcome to TI E2E DLP&MEMS forum.

    The static buffer size is fixed; it can store upto 960 binary or 120 8bit grayscale images. With 8bit grayscale you can go upto 500Hz and with binary you can go upto 5KHz.

    Physically the patterns stored at static memory location but you can still change the order by sending the command (calling API) with your desired order; there is no need for a re-download. The LightCommander PC software provides API library interface which can be called to set the new pattern order. For example - suppose you have downloaded patterns in the frame buffer as  1,2,3,and 4 but you would wish to change the order at later point of time; for this all you would require is to call the ImageOrderLut API with new order for example 3,2,1and 4. Further, you should keep in mind that there will be fixed time over-head (~ few milliseconds) for the ImageOrderLut call execution in the controller chip. I hope this shouldn't be a problem for you. There is application note describing the API library usage http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?family=analog&familyId=1746&uiTemplateId=MDLP_PARMSRCH_T&paramCriteria=no

    You are correct on the second part, there are independent filters for each colors; placing all with three with Green LED will not work.

    You would still require to design your own optics to get 'on axis' projection.

    Regards,

    Sanjeev

     

  • Hi Sanjeev,

    Thank you very much for the quick response!

    Just to make it more clear, maybe I should rephrase my question. What I want is a pointer to the frames in the buffer , that can skip randomly between iterations. That is, I don't know a priori what the order of my frames should be. It seems to me that in order to use ImageOrderLUT you have to know a priori the order at which you want to display the frames.

    However it seems that DLP_Display_DisplayPatternManualStep () might due the job. I don't know the syntax but maybe you can understand what I'm trying to say. My application would look something like this:

    while

    ii= input from external source (it is a random number which I don't know  a priori, that corresponds to one of the frames in the buffer)

    DLP_Display_DisplayPatternManualStep (ii)      (displays the frame defined by the input )

    end

    If this works, do you have an idea of what the time over-head is? You mentioned that with ImageOrderLUT you have a time over head of a few milliseconds. Is that in the order of 5 , 30 or 100 ms? The reason I'm asking is because high refresh rate is important for my application. If the time over-head is too large,  I'll have problems.

     

    Thank you again for the help!

     

     

     

     

     

     

  • Hi Leonardo,

    Basically the DLP_Display_DisplayPatternManualStep() API is used for step-by-step display of the pattern instead running continuously. When this API is called it still displays the next pattern in the ImageOrderLUT as programmed. So, you will not be able to select a random pattern with this API.

    Now, for the random pattern selection (from the available patterns in the static memory buffer) you can display any subset of the patterns by sending a new order in the WriteImageOrderLut. I mean you can simulate the randomness just by putting one pattern number information in the ImageOrderLut. When you send this API the DMD displays the single pattern put in the LUT. 

    On the 'time over head' the worst case scenario i.e., when there 960 patterns information in the  ImageOrderLUT  the 'over head time' is around 20mSec. For the single pattern entry into the ImageOrderLUT (as explained above) it will take less than 5mSec. I think this would meet you expectation.

     

    Regards,

    Sanjeev