News:

Server migration complete, Welcome to version 2.1.1

+-+-

+-User

Welcome, Guest.
Please login or register.
 
 
 
Forgot your password?

+-Site Stats

Members
Total Members: 15497
Latest: packhawk
New This Month: 5
New This Week: 33
New Today: 5
Stats
Total Posts: 127083
Total Topics: 15590
Most Online Today: 98
Most Online Ever: 7634
(January 21, 2020, 02:14:03 AM)
Users Online
Members: 5
Guests: 71
Total: 76

DPIPixels on Pi Zero 2

Started by ElfStuart, June 20, 2022, 11:16:51 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

ElfStuart

Hi

After some assistance...

I have created a new 24ch cape that is using the new DPI driver on a reaspberry PI zero 2 running bullseye as it's brain (have also tried SD card in a pi 4 with similar results) running latest current master branch code as of today.  It is using SN74AHC245N chips (concious they react slightly faster than the SN74HC245N's that I have seen people using so wonder if that could be a contributing fact to my error?)

My GPIO config is as follows:

"outputs": [
        {  "pin": "P1-7" },
        {  "pin": "P1-11" },
        {  "pin": "P1-13" },
        {  "pin": "P1-15" },
        {  "pin": "P1-19" },
        {  "pin": "P1-21" },
        {  "pin": "P1-23" },
        {  "pin": "P1-29" },
        {  "pin": "P1-37" },
        {  "pin": "P1-35" },
        {  "pin": "P1-33" },
        {  "pin": "P1-31" },
        {  "pin": "P1-40" },
        {  "pin": "P1-38" },
        {  "pin": "P1-36" },
        {  "pin": "P1-32" },
        {  "pin": "P1-26" },
        {  "pin": "P1-24" },
        {  "pin": "P1-22" },
        {  "pin": "P1-18" },
        {  "pin": "P1-16" },
        {  "pin": "P1-12" },
        {  "pin": "P1-10" },
        {  "pin": "P1-8" }
    ]


when running a simple RGB chase test from fpp the string outputs are misbehaving in 2 different failure modes depending on the port, ...which I think are both timing related.

Issue 1 - the string chases RGB correctly apart from the first pixel in the string which only comes on blue and is off when it should be red or green

Issue 2 - the string chases blue,yellow, off (and occasionaly has a red flicker)

Here is the alignment of port to issue:

   
port #pixel countissue type
port 150issue 1
port 250issue 1
port 3400issue 1
port 4472issue 1
port 550issue 1
port 650issue 1plus lots of flickering
port 750issue 1
port 8100issue 2
port 9100issue 1
port 10100issue 2
port 11100issue 2plus flickering - might be solder related
port 12100issue 2
port 1350issue 2
port 14200issue 2
port 15375issue 1
port 16375issue 2
port 17129issue 2
port 18129issue 2plus flickering - might be solder related
port 19150issue 1
port 20150issue 2
port 2150issue 2
port 2250issue 2
port 2370issue 2
port 2470issue 2


This is a prototype board so would expect the odd dodgy solder joint but the pattern of the issue suggests it more down to config than hardware

my /boot/dpipixels.txt looks like (is this correct as I have been testing for a few months and might have something hanging over in this):

#####################################################################
# DPI Pixels framebuffer config
# https://www.raspberrypi.com/documentation/computers/config_txt.html
#
# Date Added: Sun 27 Mar 2022 06:42:47 AM BST
######################################################################
# Enable DPI
enable_dpi_lcd=1
#
# Set group/mode to allow custom resolution and timing
dpi_group=2
dpi_mode=87
#
# RGB24 888, RGB color order
dpi_output_format=0x17
#
# Enable DPI framebuffer on < Pi 4
max_framebuffers=2
#
# Make onboard HDMI fb0 and DPI fb1 if HDMI is in use, otherwise DPI is fb0
framebuffer_priority=2
#
# Force HDMI on (as fb0) so DPI becomes fb1
hdmi_force_hotplug=1
#
# Custom resolution with 40 FPS timing
dpi_timings=362 0 0 1 0  162 0 1 1 1  0 0 0  40 0 2400000 1
#
# Enable UART2 on Pi 4 since UART0 TXD pin is used by DPI
dtoverlay=uart2
#
# Disable SPI
dtparam=spi=off

Is there a parameter I can tweak somwhere to test timings?

Thoughts anyone?

CaptainMurdoch

The dpipixels.txt file would be updated at a reboot if the timings line needed updating.  This file hasn't changed much until recently when I fixed the timings line for the Pi 4.  I just pushed this fix on Thursday, can you confirm what exact version you are running to make sure you have that fix?  I haven't seen the issue #1 you are referring to and I have the DPIPixels code running on about 6 systems including Pi 4B, 3B, 2B, and 1B.

Have you tried connecting the first pixel directly to the GPIO pin and seeing if the issue goes away?  That would tell you whether it is the cape or not.  At a short distance, the 3.3V signal coming off the Pi should be good enough to drive the first pixel, we have lots of users driving pixels directly off the Pi without any cape, I do it myself for a small infinity mirror in my office.
-
Chris

ElfStuart

Cheers Chris

Sorted the issue - wasn't a config or PCB design issue

Was my fault - I accidently loaded the board with SN74AHC245N buffer chips rather than the lower input voltage version SN74AHCT245N - that pesky missing 'T' in the model number causing the issue.

Now have 24 channels all prefectly behaving ;)

CaptainMurdoch

-
Chris

Support FPP

+- Recent Topics

Think I found a bug/corner case...please help by breese
Today at 04:19:41 AM

Fpp 6.2 ui password by Mat-Moo
Today at 01:31:11 AM

Controller not keeping accurate time by jnealand
December 01, 2022, 09:38:16 PM

Raspberry PI 4 won't connect to WIFI by Poporacer
December 01, 2022, 07:28:48 PM

BRP Voting Plugin - Allow others to vote for your songs! by Barkers Random Projects
December 01, 2022, 07:20:53 PM

All pixels group ON effect by tkelba
December 01, 2022, 06:48:00 PM

FPP 6.2 Playlist/FPP Command/Run Script vs. Playlist/Script by richardln2
December 01, 2022, 06:16:19 PM

Help--Can't Get Sequence to Output by Oxytousc
December 01, 2022, 05:07:12 PM

Set Time/Date by breese
December 01, 2022, 04:07:57 PM

Differential Receiver Board Ports w/ F48 corrupted data by tkelba
December 01, 2022, 02:58:25 PM

Powered by EzPortal
Powered by SMFPacks Menu Editor Mod