The strips are in! Packaging will begin this evening and mailing tomorrow if I’m not overrun by a mob of local makers (who also ordered a bunch). For those who ordered less than 5m, it will take a bit longer because I have to cut them to size.
Woo! Hoo! Let the stripping begin! [insert pole dance music here]
@ ransomhall - Crossing my fingers for delivery in time for MADExpo next week…
@ devhammer - I’ll bump you up to the top of the delivery pile. East coast priority mail is 3 days max, so you should get them by Saturday, or Monday at the very latest. What are you planning to do with them at the expo? Unfortunately, I could not convince my boss to sponsor the conference , so be sure to post blinky pics here.
Actually, now that I think of it, EVERYBODY who ordered these should post pics of their LED projects somewhere on this forum.
@ ransomhall - I don’t have a plan yet…I’m madly throwing together every cool demo I can think of. Currently trying to get a simple robot to work, but finding some flakiness with the potentiometer module under 4.2
http://www.tinyclr.com/forum/topic?id=7508
Given the small amount of time available, I’ll probably just breadboard one of the strips and get some simple blinkies working, just because…well, because who DOESN’T like blinkies?
That would be Joe Cocker
Posted my video over here:
http://www.tinyclr.com/forum/topic?id=7562
Thanks again, Eric! These are AWESOME!
Has anybody tried the driver over on http://netduinohelpers.codeplex.com ? After a little homework on Adafruit for optimizations to their Arduino drivers for these strips, I discovered this link. I’ll be taking a look at some point.
Would that driver have any advantages over Dave Durant’s code? The only real issue I’m seeing the current code is the slowdown I see when I drive both reels at the same time, but that may not be an issue of code so much as just limitations when driving that many LEDs at once.
HERETIC!!!
I’ve poked around the code a little but haven’t run it. Trying to be unbiased, I’d say that mine is probably a hair faster but has fewer bells & whistles.
Both reels at once? Nice!
Am I to be burned at the stake just for asking a question?
Truth be told, I was hoping the answer would be “no” as I don’t feel like messing with a working demo less than 48 hours before I’m to show it off. I have enough to deal with trying to get my durn robot(s) working.

Am I to be burned at the stake just for asking a question?
Probably not… More likely to be forced to sit in the comfy chair.

Truth be told, I was hoping the answer would be “no” as I don’t feel like messing with a working demo less than 48 hours before I’m to show it off. I have enough to deal with trying to get my durn robot(s) working.
The big difference is that it seems to have support for laying the LEDs out in a x/y grid so you can do 2D stuff instead of just 1D. There are a few really nice features around that like drawing rectangles and text.
The fading code looks like it’s blocking, not async like mine, but that may not be something you care about.
The performance differences aren’t huge… They do multiple SPI calls to write the LEDs out, I do it all in one send. There are also a few places where they do math multiple times or in a loop and I was pretty careful to avoid that. So… My code probably runs a little faster but it might not be visibly noticable and it’s all stuff that’s fixable fairly easily. If you really like the idea of a 2D display and have a bit of extra time, I’d go for it - always easy enough to reflash back to my stuff if needed.
I also see that they tell SPI to run at 10,000 KHz where I use 2,000 KHz. I used 2000 because (IIRC) I read that rate at adafruit.com but you might want to try 10000 and see if that helps performance any. I’m pretty clueless about how this stuff works internally - it might not help at all.

The big difference is that it seems to have support for laying the LEDs out in a x/y grid so you can do 2D stuff instead of just 1D. There are a few really nice features around that like drawing rectangles and text.
The fading code looks like it’s blocking, not async like mine, but that may not be something you care about.
The performance differences aren’t huge… They do multiple SPI calls to write the LEDs out, I do it all in one send. There are also a few places where they do math multiple times or in a loop and I was pretty careful to avoid that. So… My code probably runs a little faster but it might not be visibly noticable and it’s all stuff that’s fixable fairly easily. If you really like the idea of a 2D display and have a bit of extra time, I’d go for it - always easy enough to reflash back to my stuff if needed.
I also see that they tell SPI to run at 10,000 KHz where I use 2,000 KHz. I used 2000 because (IIRC) I read that rate at adafruit.com but you might want to try 10000 and see if that helps performance any. I’m pretty clueless about how this stuff works internally - it might not help at all.
The 2D stuff would definitely be of interest to me later this year. Part of my plan in getting these was to set them up in a grid (haven’t decided how large yet) and use them to do some kind of display fun. So perhaps once I get back from MADExpo I’ll have a look at the netduino helper code and see how easy it would be to bring it over to Gadgeteer.
I received a nice box of goodies in the mail today! Now I’m going to have to send ransomhall a medical bill… I’m seeing spots It didn’t take long to get going thanks to Dave’s blog post. I don’t see a Codeshare forum post for Dave’s driver. If you’re running it on 4.2, you’ll need to change the LedStripLPD8806 constructor to:
public LedStripLPD8806(GT.Socket socket, int numLeds)
{
SPI.Configuration spiConfig = new SPI.Configuration(Cpu.Pin.GPIO_NONE,
false, // chip select active state
0, // chip select setup time
0, // chip select hold time
false, // clock idle state
true, // clock edge (true = rising)
2000, // 2mhz
SPI.SPI_module.SPI1
);
// the protocol seems to be that we need to write 1 + (1 per 64 LEDs) bytes
// at the end of each update (I've only tested this on a 32-LED strip)
int latchBytes = ((numLeds + 63) / 64) * 3;
mLedByteCount = numLeds * 3;
mData = new byte[mLedByteCount + latchBytes];
mNumLeds = numLeds;
mLedStrip = new SPI(spiConfig);
// start with all the LEDs off
for (int i = 0; i < mLedByteCount; i++)
{
mData[i] = MASK;
}
// give the strip an inital poke of the latch bytes (no idea
// why this is needed)
mLedStrip.Write(new byte[latchBytes]);
// push the initial values (all off) to the strip
SendUpdate();
}
Ransom, thanks for all the extra goodies! What a nice treat!
I now have a couple projects planned using these. Fun stuff!
@ ianlee74 - I overestimated the shipping in your case, so I figured extras were more fun than a refund. I must have forgot to include the user manual about not doing a deer in the headlights with these Project pictures please!

@ ianlee74 - I overestimated the shipping in your case, so I figured extras were more fun than a refund. I must have forgot to include the user manual about not doing a deer in the headlights with these
Project pictures please!
Thanks, again. That works for me. It’s more like a mosquito flying toward a bug zapper. The lights are so beautiful…ZAP!

I don’t see a Codeshare forum post for Dave’s driver.
Is it worth having one?
I haven’t really been paying attention… Is there some automated integration or do people just start a new forum thread?
Codeshare, Submit Code, follow the instructions. A related post gets added to the forum auto-magically. And yes, it is worth having one!

Codeshare, Submit Code, follow the instructions. A related post gets added to the forum auto-magically. And yes, it is worth having one!
I’m not seeing a way to do it for already-submitted code…
Do I just have to resubmit it or is there a trick I’m missing?