Author Topic: Inconsistent Blinky Flashy  (Read 26653 times)

Offline David Pitts

  • Administrator
  • *****
  • Join Date: Mar 2013
  • Location: Falcon, CO
  • Posts: 3,929
  • Kudos: 76
Re: Inconsistent Blinky Flashy
« Reply #15 on: August 21, 2015, 01:54:44 PM »
Can you try not using the same channels for every port. You could be getting memory bus collisions since DMA needs to access same memory locations. Also can you try using the test mode (test jumoer on) to prove it is not a timing issue. If test works than controller can drive the pixels.
PixelController, LLC
PixelController.com

Offline JonB256

  • Supporting Member
  • ******
  • Join Date: Mar 2013
  • Location: Granbury, Texas
  • Posts: 5,163
  • Kudos: 122
    • Granbury Christmas Lights
Re: Inconsistent Blinky Flashy
« Reply #16 on: August 21, 2015, 10:11:45 PM »
Can you try not using the same channels for every port. You could be getting memory bus collisions since DMA needs to access same memory locations. Also can you try using the test mode (test jumper on) to prove it is not a timing issue. If test works than controller can drive the pixels.

David, does setting the Pixel Count to 0 for a Port # on the F16V2 eliminate it from CPU cycles?

If not, what is the best way to turn OFF unused Ports so they don't consume CPU time?

Offline David Pitts

  • Administrator
  • *****
  • Join Date: Mar 2013
  • Location: Falcon, CO
  • Posts: 3,929
  • Kudos: 76
Re: Inconsistent Blinky Flashy
« Reply #17 on: August 21, 2015, 10:17:26 PM »
Can you try not using the same channels for every port. You could be getting memory bus collisions since DMA needs to access same memory locations. Also can you try using the test mode (test jumper on) to prove it is not a timing issue. If test works than controller can drive the pixels.

David, does setting the Pixel Count to 0 for a Port # on the F16V2 eliminate it from CPU cycles?

If not, what is the best way to turn OFF unused Ports so they don't consume CPU time?

The F16V2 is a completely different animal compared to F16V1. The F16V2 will reduce cpu load if the count is lowered though. But will have enough power if they all were 680. The F17V1 uses SPI dma to send all 16 ports and it is that DMA that may be having memory collisions.

Offline Gary

  • Supporting Member
  • ******
  • Join Date: Jan 2015
  • Location: Chilliwack, BC Canada
  • Posts: 380
  • Kudos: 3
    • Diamond Crescent Musical Christmas Lights
Re: Inconsistent Blinky Flashy
« Reply #18 on: August 22, 2015, 12:15:50 AM »
Can you try not using the same channels for every port. You could be getting memory bus collisions since DMA needs to access same memory locations. Also can you try using the test mode (test jumoer on) to prove it is not a timing issue. If test works than controller can drive the pixels.

I did try unchecking the Enable field for each port, but I thought I'd try what you suggested as well Port 1 is Channel 1-300, Port 2 is 301-600, etc.), but the problematic red remains at the end of the string.

The Test jumper isn't able to reproduce the problem as it cycles between Red, Green, Blue, White, Red, Green, Blue, White, etc. with no black pauses. To  reiterate, the bright red pixel problem only happens when the R, G, and B values are the same before going to 0,0,0. If the values are 1,1,1 I always get the red flicker and occasionally the bright red full on when it's supposed to be black. If the values are 255,255,255 I don't get the red flicker, but occasionally get the bright red full on when it's supposed to be black.

Offline David Pitts

  • Administrator
  • *****
  • Join Date: Mar 2013
  • Location: Falcon, CO
  • Posts: 3,929
  • Kudos: 76
Re: Inconsistent Blinky Flashy
« Reply #19 on: August 22, 2015, 02:15:01 AM »
So do you see this when playing a sequence or only in xlights test screen.

Sent from my LGLS990 using Tapatalk


Offline Gary

  • Supporting Member
  • ******
  • Join Date: Jan 2015
  • Location: Chilliwack, BC Canada
  • Posts: 380
  • Kudos: 3
    • Diamond Crescent Musical Christmas Lights
Re: Inconsistent Blinky Flashy
« Reply #20 on: August 23, 2015, 01:30:47 AM »
I've only seen it in the xLights test screen. To be honest, I haven't looked at any of the tutorials on how to sequence anything yet.

I'm experimenting on a string of 50 again, and the last 3 pixels are problematic. I should perhaps clarify the flickering red is more like a flickering pink... perhaps the equivalent of RGB (10,1,1). I should re-iterate that my dim (1,1,1) test values have nothing to do with the pixels randomly and occasionally turning bright red when they are supposed to be at a 0,0,0 value; it's just that the pink flickering pixels are the only ones that turn red. When they are at 255,255,255 and then go to 0,0,0 the last three ones at the end of the string occasionally turn bright red as well.

Looking and analyzing this more, the pixels before the problematic ones are primarily "dark grey" (RGB 1,1,1), but they do flicker a tiny amount of red, but it happens so infrequently I can't call them pink. The pixels closest to the end of the string tend to flicker more, and there is less and less flicker until there isn't any halfway through the string.

I also noticed that If I turn off channels 145-147 (for the second last pixel), and I turn the others on at intensity 1, the second last pixel flickers a very faint amount when it's supposed to be black. Is this normal? As I turn the brightness up, the second last pixel dims to black.




Offline JonB256

  • Supporting Member
  • ******
  • Join Date: Mar 2013
  • Location: Granbury, Texas
  • Posts: 5,163
  • Kudos: 122
    • Granbury Christmas Lights
Re: Inconsistent Blinky Flashy
« Reply #21 on: August 23, 2015, 04:58:17 AM »
Red will always come on first (lowest setting) because it is the most efficient.

This is purely my opinion, but I think you are worrying about something that will not be visible during a show. Move into actual sequencing. Only 90 days until showtime.

Offline Gary

  • Supporting Member
  • ******
  • Join Date: Jan 2015
  • Location: Chilliwack, BC Canada
  • Posts: 380
  • Kudos: 3
    • Diamond Crescent Musical Christmas Lights
Re: Inconsistent Blinky Flashy
« Reply #22 on: August 23, 2015, 08:44:51 AM »
I'm not too concerned about flickering pixels at low brightnesses (since I won't be running pixels dimly--but I thought I'd share the symptom to help troubleshoot), but when I have bright red pixels scattered throughout my display when its supposed to be black... Well, that's lame.

Between the time crunch and having a toddler (and also composing this on my phone with my free hand as I'm holding a baby in my arm that woke up early this morning), plus not having my Falcon-16B received or soldered yet, not even having a chance to plug in my BeagleBone black to learn the ropes on it, I would say that I probably won't be having a show outdoors this year anyways. I think I will just be wrapping a bunch of strings around my living room Christmas tree and learning some hardware skills and software sequencing so I can bone up on my skills for Christmas 2016.

Sent from my Nexus 6 using Tapatalk


Offline JonB256

  • Supporting Member
  • ******
  • Join Date: Mar 2013
  • Location: Granbury, Texas
  • Posts: 5,163
  • Kudos: 122
    • Granbury Christmas Lights
Re: Inconsistent Blinky Flashy
« Reply #23 on: August 23, 2015, 02:04:38 PM »
Gary, it never sounded like you had bright red, just dim flickers.

Offline Gary

  • Supporting Member
  • ******
  • Join Date: Jan 2015
  • Location: Chilliwack, BC Canada
  • Posts: 380
  • Kudos: 3
    • Diamond Crescent Musical Christmas Lights
Re: Inconsistent Blinky Flashy
« Reply #24 on: August 23, 2015, 11:52:01 PM »
Gary, it never sounded like you had bright red, just dim flickers.

Yeah, when I started the thread, I was running the xLights Flicker test pattern to turn the lights on and off at full 255,255,255 and noticed the red randomly turning "full on" when the string was supposed to be black.

As I started troubleshooting more and did some playing with the brightness slider controls on the Test screen, I noticed the flickering issue on some of the pixels when I turned the brightness way down, and as it turns out, those are the only ones with the "random full on" red problem.

Offline zwiller

  • Falcon Beta Team
  • **
  • Join Date: Mar 2013
  • Location: Sandusky, OH
  • Posts: 994
  • Kudos: 13
Re: Inconsistent Blinky Flashy
« Reply #25 on: August 24, 2015, 08:37:49 AM »
Might finally have a chance to jump in and test with the back to school drama mostly over.  Do you have access to some 1804 nodes?  Curious if they would act up too.  I started to type that I ran 2811 flex and had no issues BUT then I did remember occasional pink weirdness/stuck on low on the ends of the flex strip (arches) in the morning.  Son of a gun.  Forgot about that.  In all honesty, at the time I thought it was moisture or something.  OK.  I will drag out them out and try and replicate.  That said, I agree with Jon not to OCD about it...  Case in point.  There's at least 8-10 leds out/off in my show here but you really can't pick them out. https://vimeo.com/115857387  "The show must go on"  ;D
Sam
 Last year's video: https://vimeo.com/150560653

Offline corey872

  • Supporting Member
  • ******
  • Join Date: Oct 2013
  • Location:
  • Posts: 490
  • Kudos: 16
    • Link to the sale...
Re: Inconsistent Blinky Flashy
« Reply #26 on: August 24, 2015, 12:02:38 PM »
Scanned through the responses and didn't see the following info/suggestions, so thought I would point them out...if you've already tried them, then disregard.

1)  It is interesting you mention these being some of the last pixels in the string...that can sometimes signify power or ground issues...though it's equally curious the string is only 50pix long.  That should have no troubles at all.  One thing you might try is to loop the power and ground coming out after the last pixel back to the power/ground terminals going into the first pixel.  This is obviously just a test configuration, but it provides solid power/ground connections to both ends of the string.  Does the red go away then?

2) "Back in the day" - (mainly running SSC's) people would cut their node strings into confetti searching for "bad nodes" when it was really "bad data".  Seems like here we've been looking at it almost completely opposite.  So is there a chance you have a bad node or two?   Test #1 above should help rule out anything on the power side, but a node might be worth consideration.  Is there any way you can splice two known 'working' strings to make one well over 50 nodes?  Does the red pattern persist when additional 'known good' nodes are added after the first 50?
Corey
 2018 uSC, Afterburner, uAmp co-op - pending May-June 2018.  Remaining boards are now FOR SALE

Offline Gary

  • Supporting Member
  • ******
  • Join Date: Jan 2015
  • Location: Chilliwack, BC Canada
  • Posts: 380
  • Kudos: 3
    • Diamond Crescent Musical Christmas Lights
Re: Inconsistent Blinky Flashy
« Reply #27 on: August 24, 2015, 01:27:09 PM »
Might finally have a chance to jump in and test with the back to school drama mostly over.  Do you have access to some 1804 nodes?  Curious if they would act up too.  I started to type that I ran 2811 flex and had no issues BUT then I did remember occasional pink weirdness/stuck on low on the ends of the flex strip (arches) in the morning.  Son of a gun.  Forgot about that.  In all honesty, at the time I thought it was moisture or something.  OK.  I will drag out them out and try and replicate.  That said, I agree with Jon not to OCD about it...  Case in point.  There's at least 8-10 leds out/off in my show here but you really can't pick them out. https://vimeo.com/115857387  "The show must go on"  ;D

I don't have any 1804 nodes, but I do have some rectangle modules that use the WS2811 chip. Perhaps I can try that then.

P.S. I just had to watch that video link. Your sequencing is amongst my favourite. What sequencing software do you use again? Was it LightShow Pro?
« Last Edit: August 24, 2015, 01:50:50 PM by Gary »

Offline Gary

  • Supporting Member
  • ******
  • Join Date: Jan 2015
  • Location: Chilliwack, BC Canada
  • Posts: 380
  • Kudos: 3
    • Diamond Crescent Musical Christmas Lights
Re: Inconsistent Blinky Flashy
« Reply #28 on: August 24, 2015, 01:50:06 PM »
1)  It is interesting you mention these being some of the last pixels in the string...that can sometimes signify power or ground issues...though it's equally curious the string is only 50pix long.  That should have no troubles at all.  One thing you might try is to loop the power and ground coming out after the last pixel back to the power/ground terminals going into the first pixel.  This is obviously just a test configuration, but it provides solid power/ground connections to both ends of the string.  Does the red go away then?

Ugh. I was hoping to avoid power injection at all costs but I guess I can tolerate it for troubleshooting.   ::)


2) "Back in the day" - (mainly running SSC's) people would cut their node strings into confetti searching for "bad nodes" when it was really "bad data".  Seems like here we've been looking at it almost completely opposite.  So is there a chance you have a bad node or two?   Test #1 above should help rule out anything on the power side, but a node might be worth consideration.  Is there any way you can splice two known 'working' strings to make one well over 50 nodes?  Does the red pattern persist when additional 'known good' nodes are added after the first 50?

I don't think it's an issue with the nodes as all (or pretty well all) my light strings have the problem. I didn't check each string individually, but I have 3 Falcon-16 v1 controllers, each with 16 bundled light strings and see red lights all over. Each string that I unbundled has the problem at the end.

When I spliced two strings of 50 together a week or so back, the problem moved to the the last pixels in the second string (i.e. nodes 98, 99, 100). Pixels 48, 49, and 50 didn't have the problem anymore. I tried a string of 50 on a SSC that I'm borrowing, and didn't have any problems at all. I may not know what I'm talking about here, but is there the possibility of data reflection going on? I remember reading in the past that people who use Lynx Express Controllers should set the Terminate jumper on the last controller because of data reflection potentially causing problems. The past few years, I think some of the jumpers weren't set properly, but I didn't see any problems.

Offline corey872

  • Supporting Member
  • ******
  • Join Date: Oct 2013
  • Location:
  • Posts: 490
  • Kudos: 16
    • Link to the sale...
Re: Inconsistent Blinky Flashy
« Reply #29 on: August 24, 2015, 07:11:47 PM »
...

When I spliced two strings of 50 together a week or so back, the problem moved to the the last pixels in the second string (i.e. nodes 98, 99, 100). Pixels 48, 49, and 50 didn't have the problem anymore.

Now that is the most bizarre point yet!  That would seem to rule out any issue with power or ground.  Adding more pixels wouldn't make conditions better!

Quote
I tried a string of 50 on a SSC that I'm borrowing, and didn't have any problems at all. I may not know what I'm talking about here, but is there the possibility of data reflection going on? I remember reading in the past that people who use Lynx Express Controllers should set the Terminate jumper on the last controller because of data reflection potentially causing problems. The past few years, I think some of the jumpers weren't set properly, but I didn't see any problems.

I don't guess I have heard of this 'data reflection' issue.  The pixels have a 'data input' side and a 'data output' side... if there were some abnormal signal at the output side, I don't know how (or even if) it could transfer back to the input side.  Plus, any controller is really only sending data to the first pixel.  Once it gets there, it's up to the pixels to repeat the signal down the chain.  Though conversely, you say the strings work fine with the (likely weaker) data output of the SSC and have issues with the stronger F16...so maybe something here.

I guess this does bring up two additional questions:

1) What is your 'F16 to first node' distance?  Is it possible this distance is unnaturally short for testing purposes?  Maybe the strong signal output of the F16 is somehow corrupting nearby nodes where the weaker signal from the SSC is OK for such a short distance.  If it is crazy short, you might try running out a dozen feet or so.

2) How long is the 'pigtail' coming out of your last node?  Seems like normally there is 18-20 inches of wire after the last node.  I've never known that to be a problem, but possibly in a test situation with a bunch of hardware in a small space, it is enough wire to be picking up some spurious signals. ... or possibly your nodes have an even longer 'tail' which might be an even better antenna.

To test this, you might first try to coil any length of excess wire up in a ball, that should help cut down on its 'antenna' nature.  Or if you plan to anyway, go ahead and crop it down to something minimal...like a few inches.

If none of this works, we may just have to chalk it up to gremlins!

 

Back to top