Teensy with APA102 for many strips

Status
Not open for further replies.

Tejkaran

Well-known member
Hi

I am trying to connect 100m+ of APA102 strips together to create a continuous strip whilst running at at least 12Mhz. I can get it to run at lower speeds(~6-8Mhz), however as I approach faster speeds the LED's flicker to the extent the pattern/code does not work and all that is seen is a flicker/blue of strobing lights

I am using:
Teensy 3.2,
APA102 addressable LED strip from iPixel LED(China/Hong Kong)
12V 30A 360W power supply with a step down buck regulator at the point of power attachment which is 5V 5A
FastLEd Library

Power is attached every 5m, so at the beginning and end of every strip.

So it would be like this: (see image)
https://s31.postimg.org/ib6aocqpn/layout.png

My understanding is that it should be able to run at 12Mhz no problem, however this is not the case with me, and I really do not understand why, any ideas?

Thanks

Tej
 
Check the forums for FastLED but there appears to be issues with APA102 where the clock reshapping distorts the wave as it propegates down the strip. If you have access to an osciliscope suggest trying to send RGB of 1,1,1 down the strip and looking at the wave form as it propagates. Certainly the 5 meter length I was working with had rounder and rounder slopes going down the strip. There may be some form of wave shaping that could be applied periodically down the strip to neaten things up again but unsure what that would look like.
 
Check the forums for FastLED but there appears to be issues with APA102 where the clock reshapping distorts the wave as it propegates down the strip.
If that's the issue, you may be able to periodically insert a (schmitt trigger) buffer in-between two APA102s to clean up the signal. I would have expected the APA102 to properly regenerate the signal edges.

You should also experiment with more frequent power converters (e.g. every 2.5m). The spec sheet says 0.2W max power consumption, so your power supplies may be marginal if you take potential cable losses into account (you are pushing pretty high currents).
 
From what I understand, and what I see from my LED's, Gremlin sounds right. I do not have access to an oscilloscope so I cannot verify myself but I am willing to try some things. Regarding a Schmitt Trigger buffer, where would I be looking for one of those? I just read up on them and it sounds like they cap noise levels which are too low or too high? Is that right?
And would it be easy for me to use? The ones that I see on the internet look like surface mounted devices which I do not think are right for me.
 
You should also experiment with more frequent power converters (e.g. every 2.5m). The spec sheet says 0.2W max power consumption, so your power supplies may be marginal if you take potential cable losses into account (you are pushing pretty high currents).
+1, but make sure the Voltages match closely, as you are paralleling voltage sources in this configuration.

Edit: Schmitt Buffer: http://eu.mouser.com/ProductDetail/NXP-Semiconductors/74HC7014N112/
I skipped through the data sheet and it seems to be ok for your application, but you might want to get a second opnion on that. It has 6 buffers per package where you only need two (data and clock), but I couldn't find any ICs with less buffers that were non-SMD.
 
Last edited:
I would like to apply the voltage more regularly, however the strips I am using are waterproof and the only access is every 5m, hence adding it every 5m.
Is it a reasonable possibility that having the power 5m apart is causing my problem?
 
I would like to apply the voltage more regularly, however the strips I am using are waterproof and the only access is every 5m, hence adding it every 5m.
Is it a reasonable possibility that having the power 5m apart is causing my problem?
You likely have several issues all adding up. Beefier supplies that can supply more current may also help (maybe yours work fine in parallel).
You don't want an inverter. A standard buffer (non schmitt) should do fine, e.g.:
http://uk.rs-online.com/web/p/buffers/0308231/

Make sure to buffer both data and clock, so that they have the same delay. These through-hole parts seem to be fairly slow, so use a single chip for both data and clock so that the delay is reasonably well matched.

BTW, SMD soldering isn't all that difficult if you have a decent board. E.g., SOT23-6:
https://www.sparkfun.com/products/717

SOT23-6 Dual Schmitt-Trigger Buffer:
https://www.digikey.com/product-detail/en/texas-instruments/SN74LVC2G17DBVR/296-13012-1-ND/479734
 
I will try to work with the first link you posted and tell you how that goes (http://uk.rs-online.com/web/p/buffers/0308231/)

My issue with SMD devices is basically that they are incredibly small. Is it normal practice to work with SMD by hand? I assumed they were for robots only....In the past I accidentally ordered some and I felt you would need some serious dexterity plus workmanship to solder them to anything.

What is the third link you posted, is that in case I want to try with SMD? (https://www.digikey.com/product-deta...12-1-ND/479734)

Thanks for the help so far, ordering the parts now, so will hopefulyl get them tomorrow
 
My issue with SMD devices is basically that they are incredibly small. Is it normal practice to work with SMD by hand? I assumed they were for robots only....In the past I accidentally ordered some and I felt you would need some serious dexterity plus workmanship to solder them to anything.
It's much easier than it appears at first. There are quite a few SMD soldering videos on Youtube. You don't even need a particularly fine soldering tip - if you you use plenty of flux and have a board with soldering mask, the solder will magically go where it's supposed to. I actually prefer SMD stuff to through hole for hand soldering.
What is the third link you posted, is that in case I want to try with SMD? (https://www.digikey.com/product-deta...12-1-ND/479734)
My original post has the correct URL if you click on it (the part is SN74LVC2G17).
 
Re surface mount, agree that it's not the dexterity so much as making physics work for you. Which does mean having the right tools for the job. Can be quite magic watching parts pull themselves into place when it all works, but for a one off mounting an SMD part onto a break out board the brute force solution of carefully fluxing the bits you want solder to stick to, glueing it down and then applying heat to the track as close as shaky hands can get and running the solder along it to the pin can work.

Note there is nothing right about the above method since it over heats the track and pretty much guarantees a dry joint but it'll get a prototype built with what you probably already have. Better tools will help but are a decision about options they give vs cost (and time spent learning to use them).
 
I will have a go at surface mount some time, but for the moment i will stick to what I know
however thank for giving me the confidence to try it, would not have even considered approaching it before

regarding the buffer, I have got them now, but they don't seem to be working, or I am overlooking something.
What I have done is visible in this image (https://s32.postimg.org/thviwkuwl/IMG_0715.jpg)
So that is showing what my connections are for the chip, however whenever I do that it seems like the chip is blocking any data going through. My wires are as such
bread board row 15 / chip pin 1 - data input
bread board row 13 / chip pin 3 - data output
bread board row 12 / chip pin 4 - clock input
bread board row 10 / chip pin 5 - clock output
bread board row 45 / chip pin Vcc - +ve (5v)
bread board row 9 / chip pin GND - GND
Datasheet:http://www.ti.com/lit/ds/symlink/sn54126.pdf

Am i doing something wrong?
i tried this in two different scenarios:
I attached the chip buffer before the data&clock line even got to the APA102, so it was Teensy==>Buffer==>APA102(1)
I attached the chip after the first 5m strip, so it was Teensy==>APA102(1)==Buffer==>APA102(2)
 
I will have a go at surface mount some time, but for the moment i will stick to what I know
however thank for giving me the confidence to try it, would not have even considered approaching it before

regarding the buffer, I have got them now, but they don't seem to be working, or I am overlooking something.
What I have done is visible in this image (https://s32.postimg.org/thviwkuwl/IMG_0715.jpg)
So that is showing what my connections are for the chip, however whenever I do that it seems like the chip is blocking any data going through. My wires are as such
bread board row 15 / chip pin 1 - data input
bread board row 13 / chip pin 3 - data output
bread board row 12 / chip pin 4 - clock input
bread board row 10 / chip pin 5 - clock output
bread board row 45 / chip pin Vcc - +ve (5v)
bread board row 9 / chip pin GND - GND
Datasheet:http://www.ti.com/lit/ds/symlink/sn54126.pdf

Am i doing something wrong?
Yes. ~G is output enable. So you want something like:
pin 1 = ~G : ground
pin 2 = A : in
pin 3 = Y : out

(similar thing for clock pins)
 
hey tni

At the moment what I have is this, as you suggested in a previous post
Teensy-->Normal wire-->buffer-->Normal wire-->APA102
In addition, at the end of every 5m strip, I have put in a buffer.
Unfortunately the red flickering persists. If I run the rainbow sequence it all works fine, however if I only have a few LED's lit up, such as lighting one up at a time, then the flickering remains.
Given that the rainbow works fine, or at least appears to, it got me thinking, could there be something wrong with my code which could be causing the flickering? I say this as the rainbow works, but mine doesn't and it seems a somewhat logical step for me. My code is below:

Code:
#include "FastLED.h"
#include <SPI.h>

#define NumPixelsZero 450       // number of LEDs in strip - count starts at 0, not 1
#define DatapinZero 11          // DatapinZero - green on apa102
#define ClockpinZero 13         // ClockpinZero - blue on apa102
#define DataRate_Mhz 12
CRGB leds[NumPixelsZero];

int g, r, b;
int head=-1, tail=(head-6);

float Speed;
float previousmicros;

void setup()
{
 FastLED.addLeds<APA102,DatapinZero,ClockpinZero,BGR,DATA_RATE_MHZ(DataRate_Mhz)>(leds,NumPixelsZero);
 Serial.begin(115200);       // set the speed at which serial monitor will write at
 fill_solid(leds, NumPixelsZero, CRGB(0,0,0));
 FastLED.show();
 delay(3000);
}

void loop() 
{
  Speed = 2.00*1000000, g=255, r=0, b=255;
  {
   while(head<=NumPixelsZero-1)
   {
    float currentmicros = micros();
    float LEDInterval = (Speed/NumPixelsZero); 
    if(currentmicros-previousmicros>= LEDInterval)
    {
     Serial.print("Head Equals "); Serial.println(head);
     Serial.print("Interval Should be "); Serial.println(LEDInterval);
     Serial.print("Interval Equals "); Serial.println(currentmicros-previousmicros);
     Serial.print("Time Equals "); Serial.println(micros()); 
     Serial.println("");
     previousmicros = currentmicros;
     leds[head] = CRGB(g,r,b);         // head
     leds[tail] = CRGB(0,0,0);         // tail
     FastLED.show();                      // show
     ++head;                              // further the lights
     if(tail==NumPixelsZero-1) tail=0;
     else(++tail);
    }
  }
 }
 head=0;
}

This aside, at this point do you think it is better to try using a Teensy every 'x' metres and get a stronger signal that way?
Or I can show you what I am doing in detail if you think that would be beneficial and you think that it can definitely work with just 1 Teensy..

Tej
 
Status
Not open for further replies.
Back
Top