Here are the photos
You’re weired to AGND instead of GND - try wiring to GND. I’ve had weird stuff happen when wiring ground to AGND instead of GND.
Thanks, I’ll try that, though I thought they were mostly equivalent.
OK, so I may have been wrong about ALL of the LEDs being blue. It looks like the first LED is off and the rest are blue. Rewiring ground to GND from AGND did not make a difference
More information: Even if I try to control more than one LED, only the first is off with the rest bright blue. I’ve also tried changing the setup to use the WS2812B initialization with the same result. Here is the entire code that I’m trying to run:
#include “FastLED.h”
// How many leds in your strip?
#define NUM_LEDS 96
// For led chips like Neopixels, which have a data line, ground, and power, you just
// need to define DATA_PIN. For led chipsets that are SPI based (four wires - data, clock,
// ground, and power), like the LPD8806 define both DATA_PIN and CLOCK_PIN
#define DATA_PIN 11
#define CLOCK_PIN 12
// Define the array of leds
CRGB leds[NUM_LEDS];
void setup() {
// Uncomment/edit one of the following lines for your leds arrangement.
// FastLED.addLeds<TM1803, DATA_PIN, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<TM1804, DATA_PIN, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<TM1809, DATA_PIN, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<WS2811, DATA_PIN, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<WS2812, DATA_PIN, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<WS2812B, DATA_PIN, RGB>(leds, NUM_LEDS);
FastLED.addLeds<NEOPIXEL, DATA_PIN>(leds, NUM_LEDS);
// FastLED.addLeds<UCS1903, DATA_PIN, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<UCS1903B, DATA_PIN, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<GW6205, DATA_PIN, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<GW6205_400, DATA_PIN, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<WS2801, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<SM16716, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<LPD8806, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<WS2801, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<SM16716, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<LPD8806, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);
}
void loop() {
// Turn the LED on, then pause
leds[0] = CRGB::Blue;
leds[1] = CRGB::Green;
leds[2] = CRGB::Red;
FastLED.show();
delay(500);
// Now turn the LED off, then pause
leds[0] = CRGB::Black;
leds[1] = CRGB::Black;
leds[2] = CRGB::Black;
FastLED.show();
delay(500);
}
Oh! Important question - what version of the library are you using, the teensy 3.1 is only supported on the 2.1 branch, not master.
FastLED2_1. Yeah, I saw that before I ever started down this path. I do appreciate the help. I’m sure I’m missing something here, just can’t figure out what. A bit more information. If I don’t use the FastLED2.1 library, and just run a simple program that doesn’t try to light any LEDs, I still get the same result - all Blue LEDs except for the 1st. I’m hoping that the first LED isn’t bad, but I can probably deal with that if it is. It just means cutting it off and resoldering the leads.
Thanks again Daniel. Let me know if you can think of anything to test the setup out. I do hope that I haven’t chosen a bad LED strip (i.e. one that just won’t work with this setup).
I’m not entirely sure what you’re seeing. I’d think if the first led was bad, none of the other leds would light up. Also - I quite often use a teensy 3.1 and WS2812 strips without issue.
One possible idea - you’re currently running at somewhere along 300-400 fps. For laughs, what happens if you change the delay to be 5000 (e.g. 5s). There is such a thing as running the WS2812’s too fast.
Though, that doesn’t explain the coloring on the rest of the leds, they should all be off.
Tried it - no change. I’m really confused at this point. 
So am I. Out of curiosity - can you try running off of a pin that is not pin 11? Also - i’m finally digging all of my led stuff back out after burning myself out on a project for Priceless - and will be poking at the teensy 3.1 again this weekend. It’s possible something horked got in there
Sure Daniel. What pin would you suggest. I chose 11 because it is listed as DOUT. I’m willing and anxious to try anything to make this worlk.
Wait a minute. I think I’m an idiot. I may have wired to the back end of the strip instead of the front end. Let me try to correct that first.
Yep - that was the problem! Woot! Thanks for the help Daniel. It’s functioning properly now!.
So now I have the system working “properly”. One annoying artifact is that I can detect a flicker, even if I’m writing the same values to the LEDs. This, of course, is dependent upon the update rate, and faster update rates make the problem more apparent. In order to do smooth motion with the LEDs, I need to keep the delay time small for the loop. Are there any tricks for dealing with this flickering? It starts to get annoying at a delay of about 100.
Thanks in advance.
= Ed =
You’re seeing the dithering - if you’re going to be running below a certain fps (I don’t remember the exact range) then it is going to be visible for you - and at a delay of 100, well, that’s only 10fps, so you’re asking for it 
See https://github.com/FastLED/FastLED/wiki/FastLED-Temporal-Dithering for more information. Specifically:
_ To disable temporal dithering, for POV or light painting projects, use “FastLED.setDither( 0 );”. If you turn off dithering, the library reverts back to ‘flooring’ integer values, instead of dithering them._
At some point we’ll have code that detects the frame rate you’re running at and scales/disables the dithering accordingly, but alas, we are still enslaved to day jobs.
Of course you can also change “delay(100)” to “FastLED.delay(100)” and you should see much better visual quality. Basically, it uses the “delay time” to actively refresh the pixels and smooth them out as best it can.
Sweet! I wanted to run it faster than 10 FPS. The FastLED.delay() seemed to do the trick. Thanks!!!
= Ed =
Just a quick test of some generalized code I wrote to have a base color for the string with various, arbitrarily sized & colored sections move or pulse at variable speeds. You’ll notice that there is a section in the middle of the string that pulses gently with the underlying base Color.
OK, to those of you that may still be watching this, I’m now having a problem where cycling power often causes the teensy3.1 board to hang after executing both the setup and the loop at least once. I posted about this in thread I found on the subject in the PJRC forum here: http://forum.pjrc.com/threads/25493-Teensy-3-1-only-runs-code-on-upload?p=51940#post51940
If anyone here has any insight on this problem, I’d appreciate the info.
= Ed =
Ed - i’d need to see the code your running in that video to a) see what’s going on or b) try to reproduce it here.