DLP4710EVM-LC: Internal pattern display issue

PiotrGiza,

Thanks for your thorough report on the issue.

From the screenshots you provided it seems like there is an issue with communication with the two DLPC3479 devices. Since each side of the DMD receives communication from one of the two controllers, it appears at first glance like one of the controllers is not receiving instructions as it should.

This process of intercommunication between the two controllers should be autonomous, so something is probably wrong in the software as you mentioned.

The team will investigate and report back within the next couple of days.

Best Regards,

Philippe Dollo

Hi Philippe,

How is the progress - is this issue very serious? Sorry for my impatience, but this is important for me to know how long will it approximately take to fix this. Without working projector we cannot continue our project (and we're short on time).

With regards,

Piotr Giza

Hi Piotr Giza,

I tried to reproduce the issue using DLPDLC-GUI ( https://www.ti.com/tool/DLPDLC-GUI ) 

And I am able to display patterns correctly using the GUI. Can you please share the exact pattern configuration details (pattern sets, pattern set order etc) so that it enables me to see if I can reproduce the issue using GUI.

Regards,

Mayank

Hi Mayank,

example patterns are in the attachment:

 example_patterns.zip

The pattern configuration can be combined in any way from these patterns (by, for example, taking 8 or 9 first binary patterns). I tried both loading binary and 8bit patterns separately (when there was only one pattern set) and loading them one after another (giving 2 patterns sets total: binary + 8bit).

I wasn't able to reproduce the issue with DLPDLC-GUI - there was no "split screen" effect. This is strange, but the real problem is related to the dlpc-api and the firmware. Please try to reproduce the problem from the dlpc-api level. Even if the GUI gives correct results, it is useless as long as the module cannot be fully controled from the c/c++ level. 

One more thing: when I try to display patterns stepwise and check internal pattern status after every step, the "Number of displayed patterns from current set" entry is always 1. 

Example output from internal pattern status check after making a couple of steps (preloaded single pattern set consisting of 12 horizontal binary patterns):

Pattern ready: yes
Number pattern order table entries: 1
Current pattern order table entry: 0
Current pattern set: 0
Number of patterns in current set: 12
Number of displayed patterns from current set: 1
Next pattern set: 0

With regards,

Piotr

Hi Piotr,

Thank you for this information. Our team will review and respond back by EOD Monday, 2/15.

Regards,

Austin

Piotr,

Have you made any changes in the API? 

If yes, please point those out.

Regards,

Mayank

Hi Mayank,

the only change I made was to copy-paste all api-related source files to a new project to compile it to a static library. 

Anyway, the same problem exists when I run sample (file "dlpc347x_dual_samples.c") from pure, unchanged dlpc_api_lib project.

The other thing I've observed recently is that when I load patterns using DLPC GUI and display using api calls, there is no "split screen" effect (although internal pattern status show invalid number of patterns displayed). When I reverse roles, i.e. when I load patterns from api level and display it using DLPC GUI, the displayed image is split into right and left halves. There must be something wrong with api pattern loading procedure.

Regards,

Piotr

Piotr,

Thanks for the update. Based on your explanation above it does seem like there may be an issue with the API's method of loading patterns.

The team will work to provide an update within the next couple of days once we have had a chance to investigate.

Regards,

Philippe Dollo

Hi Phillipe,

how is the progress in work on this issue?

Regards,

Piotr Giża

Hello Piotr,

Thank you for your patience as our team is limited on resources for the time.

Please expect a reply from a member of our team by the end of Tuesday (3/2).

Regards,

Austin

Hello Austin,

Any progress?

Regards,

Piotr

Hi Austin,

Any progress?

Regards,

Piotr

Piotr,

We have just released version 1.8 of the DLPC API, which can be found on ti.com here: https://www.ti.com/tool/DLPC-API

Can you please test it and verify that it resolves this problem for you?

Regards,

Andrew Thomas

Hi Andrew,

Thanks for the new release. There is an improvement, but there are still some problems with this software.

1) Steps are not doubled anymore, so I can go through sequence normally (single pattern set, to be precise) - one step = one pattern. But during vertical display I've noticed that right and left halves are swapped. Example: the "pattern_09" picture is the base pattern, but displayed image is swapped ("pattern_09_display"). I've made a swapped version of original pattern in GIMP afterwards ("pattern_09_swapped") and it looks the same as the displayed pattern. Horizontal patterns are displayed correctly since swapping right and left halves doesn't change anything.

2) When using more than one pattern set (for example few binary patterns + few 8bit patterns) the full sequence is only displayed after sending "DLPC34XX_DUAL_PC_START" command. If I use step mode ("DLPC34XX_DUAL_PC_STEP" after "DLPC34XX_DUAL_PC_RESET" or "DLPC34XX_DUAL_PC_PAUSE") I can display only patterns from currently displayed set (i.e. when pause happens while displaying some pattern set I make step only within this particular set). I just can't access all patterns making single steps. 

The API definitely needs further changes.

Piotr,

Thanks for the feedback and images. We'll respond back once we determine whether we need to adjust the API (or scripts) to resolve the behavior your are seeing.

Regards,

Philippe Dollo

Philippe,

Thanks for your response. I forgot to mention about the strange behaviour of "internal pattern status". Making steps doesn't change anything - the status seems to be frozen in a state it had in the moment of pausing/reseting.

Regards,

Piotr

Piotr,

I'm working on a fix for the first issue. It seems that the API isn't properly flipping the image halves, so I'm implementing support for that.

I'm less sure about what's going on with your other issues; at first glance it seems that the EVM GUI is sending the same command that you're sending via the API, so I'm going to have to do some testing to find the cause of this.

Just to clarify, can you confirm that you're calling: DLPC34XX_DUAL_WriteInternalPatternControl( DLPC34XX_DUAL_PC_STEP, 0)

from the API?

Hi Andrew,

Thanks for your answer. So far I was calling:

DLPC34XX_DUAL_WriteInternalPatternControl( DLPC34XX_DUAL_PC_STEP, 0xFF)

but according to the DLPC34xx Constroller API User Guide the second parameter (Byte 2) is only used when Start is selected. I've just checked the api behaviour after calling it with 0 instead of 0xFF - it makes no difference. 

Regards,

Piotr

Hi Piotr,

Thank you for your feedback.

As Andrew mentioned, the team is looking into the command write issues and image flipping. A member of the team will respond to this thread when they have more information.

Regards,

Austin

Piotr,

I thought I'd go ahead and give you an update. I've made the changes required to flip the image, but haven't been able to test them due to difficulties sharing the EVMs we have between the team during the pandemic. However, we've had more hardware on order that should be coming in this week, so I'll be able to resume testing soon.

Regards,

Andrew

Piotr,

Version 1.9 of the DLPC API library is going to be released on ti.com (https://www.ti.com/tool/DLPC-API) within the next couple days.

To summarize the changes, two new variables have been added into `main` (dlpc347x_dual_samples.c):

• EastWestFlip
• FlipImage

EastWestFlip gets passed as an argument into the pattern data generation functions (GenerateAndProgramPatternData and GenerateAndWritePatternDataToFile, which have been modified to accept this additional argument).

If EastWestFlip is true, the pattern data will be reversed before being written. This will cause each half (split vertically) of the final image to be flipped vertically (left to right, or East to West). After this flipping, the final image will look "correct", but will be mirrored.

Because of this, I added the FlipImage variable, which, if true, will cause a DLPC34XX_DUAL_WriteDisplayImageOrientation(...) command to be sent, set to flip the image along the long axis.

After those two flip operations, the image should be displayed exactly as expected.

With regards to your other issue, I've confirmed that it works as you described. To summarize:

• Stepping through the patterns only steps within the current pattern set, and will not allow you to move onto the next pattern set
• The data returned from the Read Internal Pattern Status command does not update after performing a step, meaning we can't identify which pattern is being displayed unless we track it externally

I'm working with the firmware team to get this resolved. When it is, I'll update the EVM GUI and the DLPC API to add a way to step through all patterns instead of only the patterns in the current set.

Regards,

Andrew

Hi Andrew,

I'm glad that you've resolved the flip issue. I will download and try the DLPC API 1.9 when it will be released.

I'm also looking forward to further changes (stepping through all pattern sets).

Thanks for your work on this.

Regards,

Piotr

Piotr, 

We will update the ticket once the API is released. 

Regards,

Mayank

Piotr,

The update is available. Please let me know if it works for you when you're able to test it.

I'm still working with the firmware team about the stepping issue, and will try to have an update this week.

Regards,

Andrew

Andrew,

Here is the effect of what you actually did:

I took a look on the new code, here is the reason:

void ReversePatternData(DLPC34XX_INT_PAT_PatternData_s* PatternData)
{
	for (int i = 0; i < PatternData->PixelArrayCount / 2; i++)
	{
		uint8_t Tmp = PatternData->PixelArray[i];
		PatternData->PixelArray[i] = PatternData->PixelArray[PatternData->PixelArrayCount - 1 - i];
		PatternData->PixelArray[PatternData->PixelArrayCount - 1 - i] = Tmp;
	}
}

And this is how it should be done:

void ReversePatternData(DLPC34XX_INT_PAT_PatternData_s* PatternData)
{
	const int halfPixelArrayCount = PatternData->PixelArrayCount / 2;
	for (int i = 0; i < halfPixelArrayCount; i++)
	{
		uint8_t Tmp = PatternData->PixelArray[i];
		PatternData->PixelArray[i] = PatternData->PixelArray[halfPixelArrayCount + i];
		PatternData->PixelArray[halfPixelArrayCount + i] = Tmp;
	}
}

Because mirroring the image doesn't help much when the image halves are being swapped.

To be honest, one could do the swapping simply just by passing properly preprocessed buffers to the api routines, so this is a workaround, not a real solution.

Regards,

Piotr

Hello Piotr,

Thank you for your response. Please allow the team a few days to further investigate the stepping issue.

Regards,

Austin

Hi Andrew,

Thank you for the update. The double-staged buffer flipping seems to work correctly - the patterns look as they should.

I've tested all 4 configurations (binary vertical, binary horizontal, 8bit vertical, 8bit horizontal). Flipping must be enabled for vertical patterns and disabled for horizontal. Which is quite obvious, because horizontal patterns were fine before.

But the interesting part is the flipping behaviour when using horizontal patterns:

The displayed image should be different from source pattern (because of unnecessary flipping), but definitely not this way. Right and left halves shouldn't be different.

Brief look into the code: in WritePatternSets function (dlpc347x_internal_patterns.c) the pattern data is written separately for each controller. The second controller gets differently flipped data. This is not a real problem since fliping shoudln't be used in horizontal mode (as said before). But it's quite important to keep the code clean and make such combinations impossible, so that new users could use the api with less pain. This is my suggestion:

1) replace double flipping (longAxis + eastWest) with just one loop that swapes left and right halves (exactly like in my previous post). Proof:

input sequence: [ 1, 2, 3, 4, 5, 6 ]

after longAxis flip: [ 6, 5, 4, 3, 2, 1 ]

after eastWest flip: left half: [ 4, 5, 6, 3, 2, 1 ] right half: [ 6, 5, 4, 1, 2, 3] 

Including fixing the data after writing we have 8 flips in total. The same effect can be achieved by simple right-left swap:

input sequence: [ 1, 2, 3, 4, 5, 6 ]

after leftRight swap: [ 4, 5, 6, 1, 2, 3] -> sequence ready to upload for both controllers.

This reduces array operation to 4 or even to 1 (+ copy operation) when using a backup buffer.

OR the same can be probably achieved by changing controllers order - currently the first controller is considered to be responsible for left image half and the second controller for the right. It seems that the real controller arrangement is reversed: main controller controls the right side, secondary controller takes care of the left side. I've checked it and it seems to be the best solution. Less options, less operations (no flipping needed), more robust. It is very simple, just change this:

// Write pattern data
if (s_DMDInfo.RequiresDualController)
{
    // Write primary data
	for (PatternIdx = 0; PatternIdx < PatternSet->PatternCount; PatternIdx++)
	{
		PatternData = &PatternSet->PatternArray[PatternIdx];
		
        if (LongAxisFlip)
        {
			Reverse(PatternData->PixelArray, 0, PatternData->PixelArrayCount);
        }

		/* When East/West flipping on a dual controller system, we reverse the primary/secondary halves
		   of the data independently. For example, if the original pattern data was:
		   [1,2,3,4,5,6],
		   it gets written to flash as:
		   [3,2,1,6,5,4]*/
		if (EastWestFlip)
		{
			// Reverse primary/master half of the data
			// i.e.: [1,2,3,4,5,6] -> [3,2,1,4,5,6]
			Reverse(PatternData->PixelArray, 0, PatternData->PixelArrayCount / 2);
		}

		WritePatternData(PatternSet, PatternData, true);

		// We don't own this data, so make sure to put it back
		if (EastWestFlip)
		{
			Reverse(PatternData->PixelArray, 0, PatternData->PixelArrayCount / 2);
		}

        if (LongAxisFlip)
        {
			Reverse(PatternData->PixelArray, 0, PatternData->PixelArrayCount);
        }
	}

    // Write secondary data
	for (PatternIdx = 0; PatternIdx < PatternSet->PatternCount; PatternIdx++)
	{
		PatternData = &PatternSet->PatternArray[PatternIdx];

        if (LongAxisFlip)
        {
			Reverse(PatternData->PixelArray, 0, PatternData->PixelArrayCount);
        }

		if (EastWestFlip)
		{
			// Reverse secondary half of the data
			// i.e.: [1,2,3,4,5,6] -> [1,2,3,6,5,4]
			Reverse(PatternData->PixelArray, PatternData->PixelArrayCount / 2, PatternData->PixelArrayCount / 2);
		}

		WritePatternData(PatternSet, PatternData, false);

        // We don't own this data, so make sure to put it back
		if (EastWestFlip)
		{
			Reverse(PatternData->PixelArray, PatternData->PixelArrayCount / 2, PatternData->PixelArrayCount / 2);
		}

        if (LongAxisFlip)
        {
			Reverse(PatternData->PixelArray, 0, PatternData->PixelArrayCount);
        }
	}
}

to this:

// Write pattern data
if (s_DMDInfo.RequiresDualController)
{
    // Write primary data
	for (PatternIdx = 0; PatternIdx < PatternSet->PatternCount; PatternIdx++)
	{
		PatternData = &PatternSet->PatternArray[PatternIdx];

		WritePatternData(PatternSet, PatternData, false);
	}

    // Write secondary data
	for (PatternIdx = 0; PatternIdx < PatternSet->PatternCount; PatternIdx++)
	{
		PatternData = &PatternSet->PatternArray[PatternIdx];

		WritePatternData(PatternSet, PatternData, true);
	}
}

________________

I've tested the StepAllPatterns function. After integrating it with my software I couldn't access all sets (there were 2 sets available). This condition was preventing me from accessing the last pattern set:

if (++patternSetIndex >= lastPatternSetIndex)
{
    patternSetIndex = 0;

    if (++Repeats >= RepeatCount)
    {
        return;
    }
}

after changing it to:

if (++patternSetIndex > lastPatternSetIndex)
{
    patternSetIndex = 0;

    if (++Repeats >= RepeatCount)
    {
        return;
    }
}

it works as expected. The "patternSetIndex" was incremented before checking its value and the loop was designed to include "lastPatternSetIndex". 

Anyway, thank you for this trick. Switching between pattern sets using this method takes only about 27ms in my case, so it's fully acceptable. Now the debugging and testing will be possible. It's worth mentioning that one should reload patterns from flash to restore original state after stepping through all patterns with provided function.

________________

The thing that is still not resolved ist the "internal pattern status". After reading it with this function:

DLPC34XX_DUAL_InternalPatternStatus_s patternStatus;
bool res = DLPC34XX_DUAL_ReadInternalPatternStatus(&patternStatus) == 0;

I get only few values that are actually correct. For example "pattern ready" and "number of patterns in current set" are ok, but "number of displayed patterns from current set" is mostly stuck on 0. Could you fix this?

Regards,

Piotr

Piotr,

Thank you very much for your feedback. The team should be able to get back to you sometime early next week.

Appreciate your patience while we work through these updates.

Best Regards,

Philippe

Philippe,

Is there any progress? I've tried to find the reason of this strange Internal Pattern Status behaviour in DLP C API code, but I've found nothing. Maybe this time it's a firmware bug?

Regards,

Piotr

Piotr, 

First of all, thanks for suggesting all the improvements in the DLPC-API. 

Can you please let us know when are you using the Read Internal Pattern Status command - is it when Write Internal Pattern Control is set with Start as the control parameter? 

Note : The Read Internal pattern status command is intended to work when the Internal Pattern Control parameter is set as Start. 

Regards,

Mayank

Mayank,

No - I was using the Read Internal Pattern Status command when stepping through patterns.

I've checked it with the Internal Pattern Control parameter set as Start - it works. But it means that this feature is completely useless, because it takes about 30ms to read internal pattern status. In many cases multiple frames or even full pattern sets can be displayed within this time. There is no point in reading the status from some unknown time point while the display state is changing rapidly.

I have antoher question, is there any way to upload custom 2D patterns (splash images) to EVM? 

Regards,

Piotr

Piotr,

You can upload splash images to the EVM using the DLP LightCrafter Display and Light Control GUI:

https://www.ti.com/tool/DLPDLC-GUI

However, I would note that splash screens must be loaded through the EEPROM when activated, so there is a delay that occurs before a splash screen can be displayed on a DMD. For this reason, splash screens are not suitable for any high-speed applications.

Best Regards,

Philippe

Phillipe,

Thanks for your response. I've managed to customize the splash screens. Although with the DLP LightCrafter Display and Light Control GUI version 3.1.0.3 it was impossible - there was one error on the startup (keystone):

And another one every time I tried to connect with the EVM:

Fortunately I had a backup of version 2.2.0.6, which is working correct.

Anyway, just like you said, the splash patterns are very slow to display. And when it's done via DLP C API, the EVM can hang when switching between splash screens is done too fast. After that it needs a manual reset (power off, power on, reconnect). So this mode is slow and unstable and indeed not suitable for high speed applications.

I appears that there is no possibility to dynamically display 2d patterns other than to use HDMI port.

This is a little bit offtopic now, but I have also tried to trigger a camera (using internal pattern mode). It seems that the signal produced by the EVM is very week - it's unable to trigger the camera via opto-isolated port.

I have found this topic: https://e2e.ti.com/support/dlp/f/dlp-products-forum/864450/dlp3010evm-lc-dlp3010evm-only-provide-3-26v-trigger-output-signal-not-enough-to-trigger-the-camera

I suppose there is no option to strenghten the trigger out signal without external amplifiers? I mean now it theoretically provides ~3.3V, but the current is very small and the voltage drops below half of that value when anything is connected to it.

Best regards,

Piotr

Piotr, 

1. Can you please give some additional information regarding the error that you are facing while communicating with the latest GUI. We are able to use the latest GUI to communicate with the EVM. 

2. Regarding your query related to the Trigger signal strength, I believe the e2e ticket that you had mentioned might have addressed your query. 

3. The only way to display high speed 2d patterns is via external pattern mode.

Regards,

Mayank

Mayank,

1) Concerning the latest GUI:

There is an error (Get Video Information Error) every time I try to connect and get information from the EVM:

But when I switch to the "Debug" tab:

I can connect to I2C and SPI without problems:

And when I get back to the "Information" tab, the error is gone and info loads properly to the GUI:

The previous GUI version was able to connect and load info in the first place.

2) After few trials we still haven't managed to get any of the output triggers working with opto-isolated camera input port, but "Trigger out 2" works with a non-isolated port. "Trigger out 1" is either too short or too week. Apparently the user can only customize the delays (which affects the trigger length only in "Trigger out 2" case), so this functionality is really very limited. The EVM is very poor when it comes to hardware triggers. They are not fully  configurable and the signal is very weak - small current and voltage barely reaching the minimal value required by  machine vision cameras.

Regards,

Piotr