News:

LATEST RELEASE:  FPP 6.1 - Download from here - https://github.com/FalconChristmas/fpp/releases/tag/6.1

+-+-

+-User

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

+-Site Stats

Members
Total Members: 15527
Latest: Murfdog510
New This Month: 35
New This Week: 23
New Today: 1
Stats
Total Posts: 127426
Total Topics: 15642
Most Online Today: 50
Most Online Ever: 7634
(January 21, 2020, 02:14:03 AM)
Users Online
Members: 0
Guests: 46
Total: 46

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

snmpd interference with FPP by Setarcos
Today at 12:31:26 AM

FPP Connect Limiting Uploads to 16V4 by darylc
Today at 12:07:03 AM

Issues with Falcon Differential Smart Receiver v2.01 (Blue) by Poporacer
December 08, 2022, 10:03:22 PM

FPP 6.2 ColorLight Issues by dennismccreery
December 08, 2022, 08:10:07 PM

Falcon V4 Player by drpiotro
December 08, 2022, 05:29:09 PM

f16v4 wont play in Player or Master Mode by Poporacer
December 08, 2022, 05:07:37 PM

FPP v6.2 Beaglebone Black/Green WiFi at startup by egenoup
December 08, 2022, 03:46:11 PM

I can't get FPP to work with F16v4 by aquinones3
December 08, 2022, 03:08:26 PM

K8-PB does not recognize SB Play 3 by Poporacer
December 08, 2022, 01:58:46 PM

K40D-PB by dkulp
December 08, 2022, 01:04:36 PM

Powered by EzPortal
Powered by SMFPacks Menu Editor Mod