DLPDLCR230NPEVM: Image artefacts during fast image presentation

Hello Paul,

Can you tell us what was changed in the config file? What version of the FW are you using as well?

To clarify, these are individual images that the script is selecting and displaying in a specified order? This is not a video input?

Please answer soon and we can get a better idea on this behavior.

Regards,

John

Hello John,

thanks for the quick response. This is my config file:

# For more options and information see
# http://rpf.io/configtxt
# Some settings may impact device functionality. See link above for details

# #########################################
# DO NOT MODIFY THE LINES BELOW THIS POINT
# #########################################

# uncomment if you get no picture on HDMI for a default "safe" mode
# hdmi_safe=1

# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
disable_overscan=1

# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16

# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720

# uncomment if hdmi display is not detected and composite is being output.
#hdmi_force_hotplug=1

# uncomment to force a specific HDMI mode (this will force VGA).
#hdmi_group=2
#hdmi_mode=82

# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2

# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
config_hdmi_boost=4

# uncomment for composite PAL
#sdtv_mode=2

#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
dtparam=audio=on

# Uncomment this to enable infrared communication.
#dtoverlay=gpio-ir,gpio_pin=17
#dtoverlay=gpio-ir-tx,gpio_pin=18

# #########################################
# DO NOT MODIFY THE LINES ABOVE THIS POINT
# #########################################

# Uncomment some or all of these to enable the optional hardware interfaces
dtparam=i2c_arm=on
#dtparam=i2s=on
dtparam=spi=on

# Configure Raspberry PI for SSH over USB
dtoverlay=dwc2

# Configure I2C on GPIO Pins #22 and #23
dtoverlay=i2c-gpio,i2c-gpio_sda=23,i2c_gpio_scl=22,i2c_gpio_delay_us=2

# Configure DPI on GPIO Pins #0 through #21
gpio=0=op
gpio=0=pn
gpio=1-27=ip
gpio=1-27=pn


# Enable DPI18 Overlay
enable_dpi_lcd=1
display_default_lcd=1
dpi_group=2
dpi_mode=87

# Configure DPI Video Timings
# RGB 666 CFG 1 (MODE 5)
dpi_output_format=458773 

# 58 Hz Timings (Low-End Spec)
# Works at GPIO DRIVE 5-7
hdmi_timings=1920 0 20 10 10 1080 0 10 10 10 0 0 0 60 0 130515000 3
# CHANGED: 58 to 60Hz FrameRate
# CHANGED: 125 to 130.515MHZ Pixelfrequency 
# NOTE: GPIO PINS #24 - #27 ARE DRIVEN SEPARATELY BY WiringPi SOFTWARE

[pi4]
#run as fast as board allows
arm_boost=1

[all]
# Enable DRM VC4 V3D driver on top of the dispmanx display stack
# kms newer but not working when init_parallel_mode.py
dtoverlay=vc4-fkms-v3d
max_framebuffers=2
dtoverlay=w1-gpio
enable_uart=1
gpu_mem=252

Yes, the script uses the psychopy library to show .bmp-images. Psychopy uses pyglet as a backend for displaying the images. How can I check the Firmware version?

Regards,
Paul

Hi Paul,

Running sample06_status.py from the DLPDCLR230NPEVM Pi Python support package (found here)  will provide all of the firmware information. Please post the return information on this thread when you have a chance to run it.

Your config file varies from the config file that we recommend (also found in the Pi Python support package). Can you say why these changes were made? Are the artifacts still present when the TI provided config file is used?

Regards,

Austin

Dear Austin,

thank you for your input. This is the information I got from running sample06_status.py:

pi@raspberrypi:~/Documents/dlp $ python sample06_status.py
set slave address: 27
Reading DLPC3436 Status Registers...
----------------------
Short Status Register:
{'SystemInitialized': 1,
'CommunicationError': 0,
'SystemError': 1,
'FlashEraseComplete': 0,
'FlashError': 0,
'Application': 1,}
----------------------
System Status Register:
{'DmdDeviceError': 0,
'DmdInterfaceError': 0,
'DmdTrainingError': 0,
'RedLedState': 1,
'GreenLedState': 1,
'BlueLedState': 1,
'RedLedError': 0,
'GreenLedError': 0,
'BlueLedError': 0,
'SequenceAbortError': 0,
'SequenceError': 0,
'SequenceBinNotFoundError': 0,
'DcPowerSupply': 0,
'ActuatorDriveEnable': 1,
'ActuatorPwmGenSource1080POnly': 1,
'ActuatorConfigurationError': 0,
'ActuatorWatchdogTimerTimeout': 0,
'ActuatorSubframeFilteredStatus': 0,}
----------------------
Communication Status Register:
{'InvalidCommandError': 0,
'InvalidCommandParameterValue': 1,
'CommandProcessingError': 1,
'FlashBatchFileError': 1,
'ReadCommandError': 1,
'InvalidNumberOfCommandParameters': 1,
'BusTimeoutByDisplayError': 1,
'AbortedOpCode': 27,}
----------------------
System Software Version Register:
'Version':  2 . 1 . 3
----------------------
Controller Device ID Register:
{'_value_': 6,
'_name_': 'Dlpc3436',}
----------------------
DMD Device ID Register:
'Device ID':  0x89000d60
----------------------
Flash Build Version Register:
'Version':  7 . 3 . 13
----------------------
FPGA Version Register:
'Version':  0x10001047 'Eco Revision':  0x0 'ARM SW Version':  0x0
----------------------
FPGA Status Register:
'XPR Status':  1 'Pass/Fail Status':  1

Concerning the config file, I originally started using the DLP together with a RPi3B, and was working towards achieving a 60Hz black-white flickering. I need to be as close to 60Hz as possible, because the experiments rely on it. To confirm the flickering frequency, I used an oscilloscope together with a photodiode. There was some progress, but when I was finally able to buy a RPi4B, I switched and kept most of the changes because they didn't seem to have any negative effect.

The most impactful adjustment was changing the pixel frequency in the hdmi timings. Just changing the frequency from 58 to 60Hz had no effect. Additionally changing the pixel frequency got me very close to the desired 60Hz.

I just did the following tests:

using the TI provided config file: no artefacts

using my altered config file posted above: artefacts appeared

using the TI provided config file with ONLY hdmi_timings changed to the settings in my altered config: artefacts appeared

using the TI provided config file again for confirmation: no artefacts

From this I would conclude that changing the hdmi_timings causes the artefacts. I was also a little surprised that using the TI provided config file had no obvious negative impact on the presented stimuli. I thought my changes were helpful, but it seems like they only helped with the RPI3 and not the RPi4. I will switch to the most basic setting as soon as I have time for some additional testing.

However, adjusting the frame rate to 60Hz is still crucial. Do you have any ideas on how to achieve it without getting the artefacts?

Regards,
Paul

Hello Paul,

We will have to take a look at the timing requirements from the RPi to the controller for a solution for you.

Please give us till next week.

Regards,

John

Hi John,

I just wanted to let you know that I am still very much interested in resolving this issue. However, I totally understand if things take a little longer around Christmas of course.

Regards,
Paul

Hi Paul,

Thanks for your patience

Regards,

Akhil

Hi Paul,

Table 9-1 (page 13) of the DLPDLCR230NPEVM User's Guide contains the Raspberry Pi Video Timing Settings for the EVM. Considering these maximums and minimums, I suggest increasing the GPIO drive strength. RaspberryPi.com and other online forums provide good descriptions on how this might be accomplished.

Please note that Texas Instruments recommends the minimum drive strength that will still meet your timing requirements. As the Raspberry Pi documentation states, driving each pin at the maximum current will likely cause the 3.3V supply to fail.

Please try carefully increasing the GPIO drive strength and let us know if this allows you to meet a 60 Hz frame rate.

Regards,

Austin

Hi Austin,

thank you for your answer. Since I have never changed the gpio drive strength before, I would just like to ask a few more questions before experimenting with it:

a) As far as I can see, increasing the drive strength can be achieved by changing the appropriate variable in the provided dlpc343x_xpr4_evm.py script before running init_parallel_mode.py?

b) The reference guide states on page 13 that TI evaluated the setings in the table you mentioned, which also means that increasing the GPIO drive strength up to 7 should be relatively save, right?

c) By carefully increasing the GPIO drive strength, you mean changing it to 6, checking whether the artefacts are gone, and the changing it to 7 if necessary? Or is there any other action I can take to make this more secure?

Thank you for your patience and happy holidays.

Regards,
Paul

Hi Paul,

We will need to look into your questions. 

Please note that with the holidays there may be a delay in response until January. 

Happy holidays!

Regards,

Lori 

Hello Paul,

You are welcome.

a.)This was the intention of that script, but after some investigation I do not believe the command that uses this variable is correctly written.

os.system("gpio drive 0 {0}".format(gpio_drive_strength))

Running this gives an error message. The "gpio drive 0 6"command can be executed the Raspberry Pi terminal to test more directly. I have been looking into how the GPIO drive strength can be set, but have not yet found a solution. I recommend that you do the same. I will investigate this further but will likely not be able to do so until the new year.

Please to try adjusting this variable in the script to test for any improved performance. Though it does not appear to be functional, I would be glad to be corrected.

b.) I believe this to be correct. However, I cannot guarantee that this will not overwhelm your Pi. I am looking into how or if this was tested.

c.) That's correct. The safer method would be to slowly increment your drive strength as well as only increasing the GPIO that is driving the RGB666 DPI output (BCM #0 -21).

I will keep you updated with any progress that I make. Please let me know about yours as well.

Regards,

Austin

I should add that I was able to use your HDMI timings without seeing the artifacts as you have shown here.

Are these anomalies visible by eye? Does other video content show the same issue?

Regards,

Austin

Hello Austin,

the anomalies are visible by eye, yes. I will test other video content as well as increasing the drive strength soon.

Regards,
Paul

Hi Paul,

I understand. It is odd that the issue is not appearing the same way on our hardware.

If the issue is not corrected by different video content, would you be able to say what Debian version you have formatted onto the Pi?

Regards,
Austin

Hi Austin,

I am running

Raspbian GNU/Linux 11 (bullseye),

Debian version 11.5,

Kernel Linux 5.15.61-v7l+, 32-bit kernel.

On another note, I tried other video content (a flicker video displayed via vlc player), and it seems to be unaffected by the artefacts. This seems to be in line with this post I just found in another forum:

https://psychtoolbox.discourse.group/t/rpi4b-bcm2711-what-is-page-flipping/3171/24

From my understanding, software toolkits like Psychopy and Psychtoolbox kind of rely on functionalities provided by vc4-kms-v3d, but it doesn't seem to be fully supported on RPI4?  I will also try to contact the people in the discussion above.

Regards,

Paul

Hi Paul,

I cannot say with certainty if the toolkits you have mentioned are supported by the RPi4. From the post that you have posted it seems that the HDMI timings are ignored in this case.

Please let us know if there is anything further we can contribute to getting your EVM working.

Kind regards,

Austin