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.

How do I do the equivalent of 60Hz 1bpp on the Lightcrafter 4500?



On the previous LightCrafter, it was trivial to display at 1440 fps by setting Video Mode Setting to "Bit Depth = 1, Frame Rate = 60"; you could then send a 60Hz video signal over HDMI with one frame encoded in each bitplane. However, with the 4500, I don't see how to do this - It looks like it might be possible using the steps outlined in "3.3.1.1 Pattern Sequence Example" in the Lightcrafter 4500 Users Guide, but it's both laborious and hasn't worked so far.

Is there no trivial way on the Lightcrafter 4500 to drive it at 1440/2880 fps via a 60/120Hz 1bpp signal with multiple bitplanes?

  • Hi Aaron,

    You must create a pattern sequence for the LightCrafter 4500 to display 1bpp images from the video port. Could you send me a screenshot of your settings from when you tried to create a pattern sequence?

    Best regards,

    Blair

  • Here are my current settings:

    I've also noticed that if I hit "Send", I get no errors, but if I follow it by hitting "Read", it loses my settings and switches back to "Flash->Internal/External"

  • Thank you Aaron. I believe your problem with displaying the sequence is that you did not remove the external trigger (the VSYNC signal from the HDMI) before the patterns following your first pattern. Before each pattern (except for the first one), right-click on the trigger icon....

    ...and select "Remove Trigger-In". Do not remove the trigger before the first pattern though.

    I will need to look into the "Read" problem you're seeing. Thank you for notifying us. Let me know if you need any more help and if what I've suggested solves your problem.

    Best regards,

    Blair

  • So in this case, "Trigger-In" is making it wait for VSYNC on every sub-frame? That would explain what saw earlier. However, I've spent a few hours trying to get this to work and still have had no luck. I'm using an app which we developed for the original LightCrafter; it buffers 24 frames up in an R8G8B8 texture and sends them over HDMI, where they're interpreted as 24 sub-frames at 60Hz for 1440fps. It works perfectly for on the old LightCrafter, but can't get it working correctly on the 4500.

    Are there any examples/walkthroughs of how to drive 1440Hz or 2880Hz sequences over HDMI on the new LightCrafter? It currently takes over 100 mouse clicks to set up a sequence like this in the new GUI, where it used to take less than 10; Please tell me there's an easier way to do this.

  • I've tried a number of things, and still can't get the 4500 to display 1440/2880fps sequences over HDMI. To isolate the problem, I've removed as much complexity as possible. I'm now creating the same video sequence I was sending before to get a 1440fps sequence (60Hz X 24 bitplanes @ 1 bit per pixel) to the previous LightCrafter; however, I'm only displaying a two-frame sequence; I've attached a snapshot of my setup below:

    With these settings, I'm seeing a number of problems that look like bugs, but may be related to the reason why this isn't working for me:

    1) With these settings, If I hit "Send" and then later hit "Read" (under Pattern Sequence in the lower left), it switches back to "Display Patterns from: Flash", which is incorrect - Nothing should change. If I then switch it back to "Display Patterns from: Video Port", I have to re-create the Pattern Sequence.

    2) If I only set two bitplanes in the video sequence (G0 and G1 in the case above), I see clear cross-talk between the bitplanes. For example, if the first and second bitplanes contain overlapping solid rectangles, the region of overlap is inverted (off).

    3) If I set more than the two bitplanes in the video stream, I see even more crosstalk, even if I'm only referencing a subset of bitplanes in the pattern sequences as in the case above; the other bitplanes are being presented as well, and a high-speed camera shows that two frames are being presented in the timing I'd expect, but the pixels illuminated are a jumble of pixels from the other bitplanes. If I didn't know better, I'd assume the light engine's logic is stepping in and complicating things rather than presenting each of the bitplanes as its own one-bit image during its frame.

    4) I see a significant chunk of noise at the bottom of the screen. I suspect it's the difference between the 1280x800 resolution detected by Windows and the 912x1140 mirror array, as it appears to cut of right around 800 pixels down the screen.

    On a side note, does anyone know what the "Frame Index" does for patterns displayed via the video port? I've tried both leaving it zero and incrementing it per-frame, but have had no luck with either, and the documentation gives no insight into what it means.

    In conclusion, has anyone managed to get high-framerate (1440/2880fps) sequences running via HDMI on the LightCrafter 4500? It's the sole purpose we bought the device for, but so far it's been a huge time sink. Any help would be greatly appreciated.

  • Hi Aaron,

    I was finally able to get in the lab today and test your use case. Please read my responses below:

    1. We identified an error in the GUI which caused the "Read" pattern sequence function to operate incorrectly.

    2,3,4. In pattern sequence mode the image source is required to have a resolution of 912x1140. Any other resolution will cause unexpected behavior.

    5. The "Frame Index" does not do anything for streaming pattern sequences.

    After spending much time in the lab, we identified another error in the GUI that prevented the EVM from correctly displaying high-framerate streaming sequences. Thankfully we were able to fix the problem and the next release of the GUI will have these fixes implemented. 

    I'm terribly sorry about the problems you've had using the LightCrafter 4500 and I will let you know as soon as possible when the next release will be. Please send me a private message if you have further questions.

    Best regards,

    Blair

  • Aaron,

    Thank you for providing feedback on your experience so far. We are evaluating your concerns and are working to improve your experience with our next software release.

    As Blair mentioned, to stream in patterns, it is best to have a 24-bit 912 x 1140 resolution. Otherwise you could see negative effects. Knowing what 24 patterns map to the 24 individual bit-planes will help.

    Second, the next software release will have a simpler interface for streaming patterns, as well as a way to save solutions.

    Lastly, we recognize your cross-talk of the bit-planes concern and we are re-evaluating the issue in our lab. To ensure we are fully understanding the setup, can you please tell us the status of your Buffer Freeze status indicator when you connect HDMI? Please check this indicator both when in video display mode and when you are streaming patterns. Also, are you using a PC to stream at 60 Hz?

    Thank you for your patience. We will provide you with updates as we have them. Also, as Blair mentioned, if you have more specific questions and would like to have a detailed discussion, please send one of us a message.

    Best regards,
    Stuti

  • First, let me answer your questions: 1) I've got the device in 24-bit 912x1140 at 60Hz running from a PC via HDMI, and the "Buffer Freeze" icon is greyed out (as it is in the screenshot I posted above). Yes, I'm using a PC to stream at 60Hz; Currently, I'm sending it two bitplanes (G0 and G1) in a 24-bit bitmap at 60Hz. I've got Internal Trigger and Pattern Exposure set to 8000us, with Vsync at 16667us, and "Clear DMD after exposure" set on the second frame; that should produce a 120Hz image from the two bitplanes.

    Bitplane G0 contains a rectangle starting at x,y position 330, 700, and 100 pixels in width and height. Bitplane G1 contains an identically sized rectangle at a 20 pixel offset to positions 350, 720. I would expect to see the two rectangles in dark green, with a brighter area in the 80x80 pixel section where they overlap. Instead, the overlap area is pitch black. If I film with a high-speed camera, here's what I see:

    * 8ms - Bitplane G0 (minus the area where it overlaps with the rectangle in G1 as described above)
    * 8ms - Bitplane G1 (minus the area where it overlaps with the rectangle in G0 as described above)

    (repeat)

    So as long as I have enough time to clear DMD after exposure (that one bit me when I was running 8333 rather than 8000us with a 16667us), I get a 120Hz sequence. However, the bitplanes are clearly interacting here. If I have overlapping data in other bitplanes (G3, G4, for instance), subsets of the other planes get jumbled in the two frames (G0 and G1) that do get rendered.

  • On the off chance that a pattern would emerge, I tried the same pattern sequence (G0 and G1 each presenting for 8000us in a 16667us frame) with 100x100 rectangles rendered in bitplanes G0, G1, G2, and G3 of the video stream in following positions:

    G0: 330, 700
    G1: 350, 720
    G2: 370, 740
    G3: 390, 760

    With these settings, the Lightcrafter displays the following two-frame sequence:

    Frame 1 (8ms)
    * Pixels set only in bitplane G0
    * Pixels set in bitplanes G2 and G3
    * Pixels set in all four bitplanes

    Frame 2 (8ms)
    * Pixels set only in bitplane G1
    * Pixels set only in bitplane G2
    * Pixels set only in bitplane G3
    * Pixels set in bitplanes G1 and G2 and no others
    * Pixels set in bitplanes G1, G2, and G3 (but not G0) 

    Pixels on simultaneously in both bitplanes G0 and G1 (but no others) are not displayed. There's clearly some sort of pattern to which combinations of bitplanes get presented in which frame, but it's not immediately obvious.

  • Hi Aaron,

    We created several sequences that had overlapping data and we did not see the strange behavior you've described. However, when we tried the HDMI output from our PC's we did not get pixel/bit accurate images and saw very strange results even when the resolution was correct.

    Could you send me the image you're using? I will test it to see if I get the same results you've been seeing.

    Best regards,

    Blair 

  • Ah - That's it!

    For the sake of anyone else who comes across the thread, this last bug was on us. I sent a snapshot from our video stream to Blair via email, who reproduced the issue and confirmed that the pixel values were not as expected. As it turns out, one of our engineers had swapped our back buffer format to SRGB, which was causing our color values to be bit-incorrect, causing what looked like bitplane cross-talk.

    We're in good shape for now, and are eagerly awaiting the next UI update.

    Thanks,
    Aaron