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: 15473
Latest: vb
New This Month: 95
New This Week: 10
New Today: 9
Stats
Total Posts: 126841
Total Topics: 15549
Most Online Today: 71
Most Online Ever: 7634
(January 21, 2020, 02:14:03 AM)
Users Online
Members: 1
Guests: 44
Total: 45

Strange Smart Receiver Behavior

Started by ric878, November 28, 2021, 09:18:55 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

ric878

Hi Everyone,

First, let me describe my setup
Falcon F16v3 with two expansion boards, firmware v2.59
- F16V3 Expansion Board
- F16V3 Differential Expansion Board
- 4-String Differential SmartReceiver (5 total)

Now on to my issue. I have a series of props/strings connected to my smart receivers. All seems to be okay until I add one additional floodlight to a series of four existing floodlights. When I add that one additional floodlight, two of my flat trees and one of my windows stop working. Here is how they are connected:

Port 35 Smart Reciever A: Floodlight-1, Floodlight-2, Floodlight-3, Floodlight-4, Floodlight-5
Port 35 Smart Reciever B: flat-tree-1, flat-tree-2
Port 35 Smart Reciever C: Window-1

As you can see, the issue essentially affects all the props that run on that port, even though they are connected to different Smart Receivers. If I remove that last floodlight, everything works fine (From Xlights, not physically). Once I add it back in, everything on Port 35 for Receivers A and B stops working, but all the floodlights, including the new one, work fine.

Here are a few additional details and things I have tried:
I let xLights program my F16V3
I have checked all the dip switches on the receivers to ensure they are set to A, B, or C
I have checked the termination switches on the receivers to ensure that B and C are not terminated and that C is terminated. Also, I ensured that all 4 switches were set correctly for termination.
Power cycled.
Deleted the output port configuration in the F16V3 and allowed xLights to re-upload it

Screenshot of controller output:
https://www.awesomescreenshot.com/im...7ef8ca0817d4da

Any help would be appreciated. Thanks.

tbone321

The controller definitions seem to be ok.  I would take a closer look at XLights and specifically at the definition of that new flood light.  Make sure that it is defined with 1 node and that the start and end channel numbers are correct.  Also take a look at the channel numbers of the other props after that last flood light and make sure that they are not changing when the floodlight is added,

ric878

Quote from: tbone321 on November 28, 2021, 11:23:23 PMThe controller definitions seem to be ok.  I would take a closer look at XLights and specifically at the definition of that new flood light.  Make sure that it is defined with 1 node and that the start and end channel numbers are correct.  Also take a look at the channel numbers of the other props after that last flood light and make sure that they are not changing when the floodlight is added,
Thanks for the suggestions. So, I did all that and everything looks good. I also tried something else that seems to have fixed the issue, but I don't know/understand why.


While browsing through the forum trying to find other people with similar behaviour, I came across someone who was having unexpected results with smart receivers. Someone suggested that adding an extra pixel in the chain resolved some issues (they referred to the last pixel being red). I thought I saw one of the pixels red at some point when I was going back and forth with reproducing the issue but I was not certain and could not get it to happen again.

Anyways, I figured, what the heck. Let me give it a shot. I added a single pixel/node string to the end of the chain and bam, everything worked. I remove it, and bam, back to where I started. I'm not sure why adding that one model with only one node resolves the issue.

I also did some other testing. I removed one of the other floods from xLights to ensure that I did not mess up the new flood configuration. That also works. As long as I only have 4 floods, doesn't matter which 4, it works. When I add the 5th back in, it doesn't work.

So my two options, as of now, are to go with only 4 floods on that port/receiver or add the extra unused string with only one pixel/node. I have chosen to go with the extra node for now.

One more note. I believe I have not seen this on any other ports/receivers because I have extra nodes on all of them. All of those props have extra nodes that I added in xLights because I did not cut the strings to be perfectly sized, instead, I opted to add the leftover nodes into their own models. Mostly because I did not want to cut strings in my first year, just in case I wanted to make changes. So in essence, all of my models have 1-6 extra nodes configured in xLights.

Support FPP

+- Recent Topics

Unable to get DHCP after FPP install by Jlwright325
November 27, 2022, 11:31:30 PM

What is the second best way to get rid of pixel gap errors? by k6ccc
November 27, 2022, 10:32:34 PM

FPP connect by LedMutt
November 27, 2022, 09:29:34 PM

FPP Scheduler duplicate by Aaron Maue
November 27, 2022, 09:24:20 PM

Audio Stalls on 8th music sequence by JonD
November 27, 2022, 08:09:16 PM

F48 with Daisy Chained Smart Receivers by JonD
November 27, 2022, 07:55:30 PM

Kulp 32A-B setup by tgeorges
November 27, 2022, 05:54:31 PM

MultiSync copying of Show Files not working in FPP 6.1.1 by jnealand
November 27, 2022, 05:27:32 PM

Pixel strands change color halfway through the string by jnealand
November 27, 2022, 05:18:57 PM

show locks me out of falcon player by torn8o
November 27, 2022, 05:09:31 PM

Powered by EzPortal
Powered by SMFPacks Menu Editor Mod