Answered Diff Receiver Issue

JulianLights

Apprentice elf
Joined
Jan 5, 2019
Messages
78
Hi everyone
I have been playing around with a couple of my diff receivers the last couple of nights and have encountered an issue I can’t seem to wrap my head around.
As soon as I power up the receiver the first 8 pixels light up. It is always the first 8 and they are always in the same order and colour, 1 blue, 6 white and 1 yellow. I am not running any sequence, it happens as soon as I power it up. I have tested this across a couple of receivers and have the same issue. I have also tried a couple of different Ethernet cables with no change.
When I do run a sequence on the tree it runs but those first 8 pixels remain the same and the rest of the sequence runs as though the channels are starting after the eighth pixel (if that makes sense).
What I have found is that if I power it down, disconnect the Ethernet cable and power it back up the issue is not there, it is only once I connect the Ethernet cable that the issue comes back so I suspect the issue is with the Ethernet connection.
A brief background on my setup, running a f16v3 with diff expansion board running to ‘dumb’ diff receivers (I also have smart receivers but haven’t tested them yet). The f16v3 and receivers are being powered from separate psu’s in separate enclosures.
Wondering if anyone has encountered similar issues?
 

AAH

I love blinky lights :)
Community project designer
Joined
Dec 27, 2010
Messages
4,188
Location
Eaglehawk
Can you pop up screenshots of the Falcon setup showing that port in particular. If it's that consistent then there may be a config issue causing the problem,
 

TerryK

Retired Elf
Joined
Feb 9, 2020
Messages
655
Location
West Central Ohio
If you have not already, separate the F16V3 from any programming source; xLights, FPP, etc. and using the Falcon's Test capability check to see if the lights can be driven correctly that way.

Ethernet cables usually either work or don't. If the lights illuminate incorrectly as soon as the enet cable is connected then the illumination is being commanded from the controller or the controller via program source. 'Hot plugging' the enet cable may induce random pixel illumination but the first string refresh from the controller should correct all that.
 

JohnsRdChristmas

Full time elf
Joined
Dec 12, 2016
Messages
131
Location
Central Coast
I had a similar issue, but in my case it was with smart receivers, and iv seen a few others have the issue aswell, i beleive it was with the termination dip switches on them not set correctly,

However in my case i was using ZCPP, and simply converting to e131 fixed my issue,

On facebook there is a thread, you will likely need to be a member of the official xlights support page,
View: https://www.facebook.com/groups/xLights/permalink/2644006842301721/
 

prof

Apprentice elf
Joined
May 26, 2010
Messages
93
Location
Bundanoon
Had same issue with dumb receivers. In my case it occured when i expanded the falcon port config to show i was using receivers. When i collapsed the config back to just show the ports 17-32 it worked normally. Seen a post somewhere that described same issue - the dumb receiver is getting the added smart receiver overhead in the data stream which manifests itself as the odd patern at the start of the light string.
 

JulianLights

Apprentice elf
Joined
Jan 5, 2019
Messages
78
Thanks for the help everyone.
Prof, your idea worked! I had expanded the ports as smart receivers and now having switched them back to standard ports the issue has gone. Thanks again!
 
  • Like
Reactions: AAH
Top