Pico DLP v2 Question About Structured Light Patterns

Robert,

Things can get confusing.

You are correct, the command: bus3-i2c 0x1b wb4 0xD7 0x00000000 selects the all-black pattern (if not inverted). The pattern numbers are shown, with their pictures, on pages 27 and 28 - section 1.3.6 Internal Pattern Structured Light Command/Field Definitions of the Pico programmers guide. The pattern numbers run from 0x0 (all black) to 0xE. Remember that each hex digit is 4 bits. The lowest cardinal pattern in each command is bits 0-3 of the data, with the next cardinal pattern bits 7-4. Bits 31-8 are unused.

So, you could send something like: bus3-i2c 0x1b wb4 0xD7 0x8A to select two different vertical stripe patterns for patterns 1 and 2, etc.

Remember that you also have to set command 0xD2 to enable the patterns and tell it how many patterns you want to have. Again, pay attention to the usage of the different bits within the data field.

I hope this may help to make it clearer how these commands work.

About the powering of the BeagleBoard with a 5V PS, the postings that you refer to (about not being able to use a 5V PS on the BB and talk to the Pico I2C )  turned out to be due to an error in a logic chip installed in some of the early Pico Kit v2 units. This caused the I2C to become inoperative when the voltage from the BeagleBoard over the HDMI connector exceeded 5.0 volts.by a couple of tenths of a volt (there was no damage, though). This has been completely resolved in all of the Pico Kit v2 units shipped from distribution for a number of months

I don't know why you are seeing what you have described when powering the BB offf the OTG port.

Don't be hesitant to try a 5V (nominal) power supply on the BeagleBoard. The Pico Kit v2 I2C should work fine. Also, I would recommend using the normal uImage to boot the Angstrom.

Best regards,

Pascal

I appreciate your time Pascal. That helps alleviate some confusion. Just to be sure I understand correctly: "bus3-i2c 0x1b wb4 0xD7 0x8A" selects "Pattern Pointer = x8 - 4" in Fig. 13 and "Pattern Pointer = xA" in Fig. 14. (dlpa021.pdf) Correct? 

Assuming the above is correct, my confusion was due to misreading the DLP guide. I thought that "I2C sub-address xDA, data x00000065 (pointers x07, x06)" meant that pattern pointers x07 and x06 were being selected. Instead, it's referring to the pointers addressed by 0xDA. Correct? 

While I have your ear.... dlpa021.pdf says,

3. Set the pattern inversion mask as desired. In this example, all patterns are inverted except the first one.

• I2C sub-address xBE, data x000000FE (mask 7:0)

• I2C sub-address xBF, data x00000007 (mask 15:8)

Robert,

I am on travel today and away from the office. I will work on your question tomorrow when I am in the office and can look more carefully at the documents.

Thank you for your patience.

Best regards,

Pascal

Follow-up: I used a high-speed camera to look at the projected video and was able to see the individual patterns. 

Still a little confused about the aforementioned I2C syntax though

Robert,

Here is something which may help you understand the i2c commands which are needed to use the Pico Kit v2 Internal Structured Light modes. These example commands use the syntax of the i2c-tools available on linux (Angstrom distribution). But, they can be adapted to any means of sending i2c commands to the Pico Kit v2.

Please refer to the the DLP Pico Chipset v2 Programmer's Guide http://www.ti.com/lit/ug/dlpu002a/dlpu002a.pdf

# Show large checker pattern
bus3-i2c 0x1b wb4 0x0B 0x00000000 # Set test pattern checkerboard
bus3-i2c 0x1b wb4 0x04 0x00000001 # Select input, internal test pattern

# select parallel RGB input source
bus3-i2c 0x1b wb4 0x04 0x00000000 # Select Pico Kit v2 HDMI input

# set input resolution to VGA landscape
bus3-i2c 0x1b wb4 0x05 0x00000007 # VGA landscape (640h*480v cropped to HVGA (not scaled)

# select internal vertical sync source
bus3-i2c 0x1b wb4 0x24 0x00000000 # lock to internally generated vertical sync

# disable all non-linear pixel processing
bus3-i2c 0x1b wb4 0x82 0x00000006 # disable AGC (bit 0)
bus3-i2c 0x1b wb4 0x92 0x00000000 # disable CCA
bus3-i2c 0x1b wb4 0x26 0x00000000 # disable Temporal Enhance
bus3-i2c 0x1b wb4 0x62 0x00000000 # inhibit certain non-linear processing blocks to support linear input to output transfer function for structured light processing modes

# set sequence to 1200Hz
bus3-i2c 0x1b wb4 0x1F 0x0000000A # Display Mode Select xA - 1200 Hz pattern rate
bus3-i2c 0x1b wb4 0xBE 0x00000040 # Structured Light Aux Internal Pattern Sync Mux Control x40 - baseline structured light configuration
# set masks to no inversion
bus3-i2c 0x1b wb4 0xD3 0x00000000 # Mask 1 bits 7:0, index number 7:0 0=do not invert
bus3-i2c 0x1b wb4 0xD4 0x00000000 # Mask 2 bits 7:0, index number 15:8 0=do not invert

# set patterns
bus3-i2c 0x1b wb4 0xD7 0x00000015 # 3:0 internal structured light pattern pointer x00; 7:4 internal structured light pattern pointer x01
# this means that we have selected pattern x5 as the first pattern, and pattern x1 for the second pattern

# synchronize and reset
bus3-i2c 0x1b wb4 0x29 0x00000000 # Disable output display processing !!!see CAUTION in Programmer's Guide!!!
bus3-i2c 0x1b wb4 0xD2 0x00000000 # Internal Structuerd Light Configuration Command: disable (bit 0=0)
bus3-i2c 0x1b wb4 0xD2 0x00000011 # Internal Structuerd Light Configuration Command: enable (bit 0=1); bits 8:4, 0x01 here means to use 2 structured light patterns, repeat
bus3-i2c 0x1b wb4 0x29 0x00000001 # Enable output display processing !!!see CAUTION in Programmer's Guide!!!


# to get back to video display
bus3-i2c 0x1b wb4 0x04 0x00000000 # resets input to HDMI (Parallel RGB I/F), but does not restore non-linear video processing which was disabled above

Best regards,

Pascal

Thanks Pascal. Looks similar to what I ended up trying (need to disable the non-linear pixel processing). The main confusion I had was with setting up the inversion mask. dlpa021.pdf says:

3. Set the pattern inversion mask as desired. In this example, all patterns are inverted except the first one.

• I2C sub-address xBE, data x000000FE (mask 7:0)

• I2C sub-address xBF, data x00000007 (mask 15:8)

Robert,

Yes. You are correct. There is a typo (mistake) in the dlpa021.pdf in step 3 on page 15 (and top of page 16). I have this marked in my copy, but it seems that the online version has not been corrected. Thank you for pointing it out. We will get it fixed.

The I2C subaddresses for pattern inversion are 0xD3 and 0xD4.

Best regards,

Pascal

Robert,

The Application Report "Using the DLP Pico 2.0 Kit for Structured Light Applications" has been updated to correct the typo which you reported with the MASK 1 and MASK 2 register addresses. Please see  http://www.ti.com/lit/an/dlpa021a/dlpa021a.pdf.

Thank you for pointing out the error, and sorry for the confusion. This will help others who use this document in the future.

Best regards,

Pascal

Pascal,

I tried running the code you posted in a shell script using Angstrom on the beagleboard and it caused the projector to show black and purple vertical lines (non uniform in color). I had to restart the projector in order to see the terminal. Is this correct behavior? Seems odd.

Thanks,

Steve

Steve,

It doesn't sound exactly right. It is possible, though. It depends on the internal patterns you have selected, and how many, etc. Remember, what you will see is time averaged by the integration time of your eyes.

You may want to set up a pattern sequence of one pattern as a test. You should be able to identify it as a pattern.

Since the commands change the state of the Pico kit, you can restore it to default (splash screen, then HDMI video input) by turning the power off/on.

If you want to return to the HDMI video mode from a command, I give it at the end of the sequence (earlier) - but without restoring the video processing mode. This can cause the picture to look off-color.

I do know that the script I posted works - it has worked for me on several occasions. Let me know if you continue to have problems.

Best regards,

Pascal

Robert,

Thanks for chiming in and confirming that it works. Fast patterns don't look to the eye the way that we may expect. The rapidly changing patterns can induce us to perceive colors, even in monochrome patterns. But - the camera tells the story!

Best regards,

Pascal

Sadly I don't have access to a high speed camera. How would I go about slowing the pattern down? Ideally I would like to be able to display 1 pattern at a time, take a photo with a usb webcam, display another, etc.

Thanks,

Steve 

Steve,

Other than the modes and frame rates described in the App Note Using the DLP Pico 2.0 Kit for Structured Light Applications (Rev. A) (dlpa021a.PDF) there is no way to make the patterns slower.

However, for debugging purposes, it may help if you specify some number of repeats for the pattern, but choose the same pattern for all. This can be done using the pattern setup commands (see dlpa021a.pdf). This should allow you to see or capture a pattern, because it will be repeated some number of times.

The functionality which would be useful is a way to trigger a pattern when the camera wants it (camera triggered pattern). This is not available in the Pico Kit v2, but it is something that could be available in a future development offering.

Best regards,

Pascal

Hi Pascal,

Can I control individual output pixel of the pico projector when using internal pattern?

For example, let's say I want something like this (where the refresh rate between these frames is as fast as the internal pattern)

frame 1	frame 2

If the images are not viewable, please refer to these links for frame1 and frame2 (where frame 2 is simply like frame 1 with the rectangle moved to the right)
In other words, is there a way to control the position of a rectangle on the screen?

Regards,

Tommy

Tommy,

I can see your pictures, and understand your question. Unfortunately, the Pico Kit v2 does not provide a means for doing what you are asking while in the internal structured light mode. In the internal structured light mode, there are a number of internally stored patterns )and their inverses) which can be selected for a sequence of repeating patterns. There is no provision for user defined patterns, such as you show.

It would be possible for you to define such patterns in the external 1-bit (1440 Hz) mode. In the external mode the pattern must be supplied in continuous real-time to the Pico via the HDMI video port formatted as a 60 Hz 24-bit RGB video frame.

If you have not already done so, please refer to the Application Report Using the DLP Pico 2.0 Kit for Structured Light Applications (Rev. A) (dlpa021a.PDF) available from

http://www.ti.com/litv/pdf/dlpa021a

The description and details of the internal and external structured light modes are contained in this app report.

There are upcoming developments which may address your needs. Stay tuned.

If you can do so, please let me know more about your project and goals. This will help us in addressing your questions.

Best regards,

Pascal

Pascal,

Thank you for your prompt response and the helpful information your provided.

The project I am working on involves projecting customized light patterns onto a surface with various veins running across. We want to customize the light pattern outputted by the PicoProjector to trace any given vein segment on the surface. Therefore, control over individual pixel would be great.

We are using a Beagleboard xM as the input for the PicoProjector. Do you know if the HDMI (DVI) hardware on the Beagleboard xM is capable of outputting 1440 Hz signal? If so, does the current driver (DSS2?) provide any interface for such task?

Once again, thank you very much for your support.

Tommy

Tommy,

Thank you for saying what your project involves. Very interesting.

I understand that "control over individual pixel" would make it easier for applications such as this. Unfortunately, that is not available in a direct way with the Pico chipset. It is possible to emulate individual pixel control from user space at the frame by frame level, though - as already pointed out. The composition of each frame is entirely up to the user when the Pico is in the external input modes.

I can not offer an answer for your question about the BeagleBoard HDMI at 1440 Hz. However, I can say that the Pico Kit v2 requires 60 Hz video formatted frames ONLY. The conversion to the higher rate subframes takes place internally. In other words, there is no means to send 1440 fps video to the Pico DLPC100 controller, even if the HDMI channel supported it. I hope this resolves some confusion about how the Pico chipset works.

Best regards,

Pascal

Pascal,

Thank you for clarifying the fact that the pico projector only takes in 60Hz input.

I am not sure I understand the external pattern completely from the description on the structured light app note. Could you give me some more detailed explanation?

When it says "1440 Hz" what is being changed at that rate?

Thank you and Best Regards,

Tommy

Tommy,

Good question. Just as a review, the Pico Kit v2 (DLP1700 chip set) has 2 structured light modes: external and internal.

In the internal mode, the patterns are coming from inside the chipset and are selected and sequenced according to the procedures presented in the App Report Using the DLP Pico 2.0 Kit for Structured Light Applications (http://www.ti.com/lit/an/dlpa021a/dlpa021a.pdf).

In the external mode, the patterns are coming from an external source (in this case, the BeagleBoard) in the form of 60 fps 640x480 video over the Pico Kit v2's HDMI input port. The App Report referenced above also gives the steps needed to set up this mode. Notice that one of the steps sets the Pico Kit up to only use the upper left hand corner of the supplied video frame - or cropped VGA to HVGA (see figure 2). The pattern you want to display must be in this section of the VGA frame.

Also, there are several modes of external SL: see table 3. In each mode, the bits of the incoming video signal, which are formatted as RGB888, will be interpreted differently. In the 1 bit mode (the 1440 Hz mode) there are 24 equally timed binary frames during the period of each 60 Hz frame (24 x 60 = 1440).The RGB888 input (24 bits) will just be interpreted as a string of 24 bits for each pixel location. For each of the 24 "sub-frames" each pixel will be on/off (white/black) according to the corresponding bit value (1/0) in the RGB pixel value. This allows 24 distinct binary pixel patterns in each 60 Hz frame, or 1440 binary frames per second.

Again, the App Report (dlpa021a.pdf) has helpful timing diagrams and useful information.

I hope this makes it a bit clearer.

Best regards,

Pascal

Hi Pascal,

I know it has been a while, but could you help me clarify the following?

In the external pattern 1440Hz mode, there are 1440 binary frames, each last about 1/1440 = 0.694ms

Data will be sent to the picoprojector every 1/60 = 0.0167s. Let's say a "piece" of data is sent very 0.0167s. Is each "piece" a sequence of 640x480x24 = 7372800 bits where:

bit 0 is the value of pixel 0 for the 1st 0.694ms

bit 1 is the value of pixel 0 for the 2nd 0.694ms

...

bit 23 is the value of pixel 0 for the 24th 0.694ms

bit 24 is the value of pixel 1 for the 1st 0.694ms

...

bit 7372799 is the value of pixel (640x480=)307200 for the 24th 0.694ms

Is that correct or did I totally misunderstand?

Regards,

Tommy

Hi again, Tommy,

The way you are describing it is probably unnecessarily complicated - at least conceptially.

For the Pico Kit v2 1440 fps mono structured light mode the data going to the Pico Kit over the HDMI video input is just a normal VGA (640x480) RGB888 (24 bit "color") video frame at 60 Hz frame rate. You will be constructing a 640x480 pixel array for each video frame - but the 1440 Hz SL mode will use only the upper left hand 480x320 partial frame in order to map directly one-to-one onto the mirror array of the DLP1700 DMD. It doesn't really matter what data you put into the rest of the 640x480 frame. However, you do always have to construct a full valid 640x480 RGB888 frame. Only the upper left hand 480x320 corner section of the pixels will actually be displayed during the SL mode zoom-in. See Fig. 2 in the Application Report Using the DLP Pico 2.0 Kit for Structured Light Applications (Rev. A) (dlpa021a.PDF) (available from http://www.ti.com/litv/pdf/dlpa021a).

Now, for each pixel in the 480x320 subframe there are 24-bits of pixel data - R8 G8 B8 ==> 24 bits, b0 - b23.  For each successive 60Hz frame, the 1440 Hz SL mode simply creates 24 binary bit planes out of the 24 bits of data - b0 - b23 in sequence. See Fig. 5 of the AR.

During each 16.67ms "frame" time the SL mode runs through each of the 24 binary planes in sequence - allocating them each 1/24th of the frame time. 24 x 60 = 1440 binary fps.

Section 3.3 of the AR covers this process in detail.

I hope this helps. Remember - the Application Report mentioned above is your friend.

Best regards,

Pascal

Thank you, Pascal.

So my current understanding is:

typedef struct {

char red; //bit23...bit16

char green; //bit15...bit8

char blue; //bit7...bit0

} pixel;

struct frame {

pixel px_array[640][480]; //only upper left 480x320 will be used

}

A "frame struct" is sent to the picoproj every 1/60 = 0.01667s. During each 0.01667s, the picoproj produces 24 "binary frames". The 1st "binary frame" is 480x320 in size where every pixel is a 0 or 1 depending on the value of bit23 for that "pixel struct".

Is that correct?

Nghia,

Yes - this is descriptively correct.

However, you are probably intending to send the video stream to the Pico V2 over the HDMI (DVI-D) connector. This means that the stream is encoded as a sequence of RGB888 video frames at 640x480. So, the construction of the pixels (and the "stacking" of the 24 bits for the subframes has to occur when you are building the individual frames - before they are streamed. The DVI receiver chip in the Pico V2 receives this digital video stream and applies it to the 24-bit RGB parallel data port of the DlPC100. Then, the 1440 Hz external SL mode interprets the 24 bits as the binary pixel values for the 24 SL subframes.

I hope this isn't confusing maters. Does this make sense?

Best regards,

Pascal

Hi there! If you need some help , I have some software that will convert video from monochrom 1bit per color to rgb multiplexed 640*480 60hz video which will be interpreted as 1440 fps by the pico. The input video needs to be 640*480 .. Cheers Gav 

Gavin,

Thanks for offering this to others. This is a exactly what we would like to see happen on this forum - sharing our experiences and offering help to others to get their DLP projects working.

I will also ask you for this software when I need it.

Best regards,

Pascal

Hello Pascal 

What is the slowest possible frame rate it is possible to run the internal structured light? I could not find it in the documentation ( I saw you can set either 1200 or 2400). are there any other options?

Kind regards,

Ohad

Ohad,

If you haven't already done so, please see the document http://www.ti.com/lit/an/dlpa021a/dlpa021a.pdf Using the DLP Pico 2.0 Kit for Structured Light Applications. In the internal pattern mode the two choices are 1200 and 2400 fps. You were correct. In the external structured light mode, the frame rate varies by bit depth. For 8-bit depth external patterns (that is, via HDMI) the frame rate is 120 fps.