Strange NeoPixel Issue

[goto10]

Hi, all–

I'm working on a project– it's basically wireless wearable LEDs for dancers– and I'm having a strange issue. My moteinos run the NeoPixel test programs just fine, but as soon as I try to add any serial or radio communication, the pixels freeze. I'm only controlling two individual pixels, and it's currently being powered off the USB port. Is it a RAM thing? A power thing?

Any advice would be appreciated. Thanks!

: jesse

[TomWS]

Hi, all–

I'm working on a project– it's basically wireless wearable LEDs for dancers– and I'm having a strange issue. My moteinos run the NeoPixel test programs just fine, but as soon as I try to add any serial or radio communication, the pixels freeze. I'm only controlling two individual pixels, and it's currently being powered off the USB port. Is it a RAM thing? A power thing?

Any advice would be appreciated. Thanks!

: jesse

Might be a power or timing thing. 

Neopixel transfers require precise timing at 800KHz clock rate (Correction) bit rate, the timing resolution needs to be something in the order of 2.5MHz or better.  The existing library uses a very exact sequence to control the clocking and shifting of data with interrupts turned off during the entire sequence.  In theory, once the transfer has begun, then the sequence shouldn't be interrupt-able, but, as Jan la van de Snepscheut said, "In theory, there is no difference between theory and practice.  In practice there is." 
Neopixels also draw a lot of power if you have them on max brightness - I don't have the datasheet handy, but that might be an issue.

To isolate the problem, try powering the Neopixels from 3 AA batteries but signal from your Moteino.  If it fails, then it's timing, if not, it's power.

Given the strict timing requirement for Neopixels, I've considered making a PIC driver.  Send the data using SPI, I2C, or serial from the Mote to the PIC, and then the PIC handles the critical Neopixel timing, something it can do fairly easily @32MHz and an 8 pin device.

Tom
UPDATE: I missed your comment about RAM thing - how much memory IS remaining after you compile your Sketch?  If you have a lot of text, you can move that to PROGMEM using the F() macro.

[goto10]

Thanks for the quick response!

I tried running separate power to the NeoPixels and got no change. Only the first one lights up. How would I go about running it through the I2C?

The compiled sketch is only ~9kb/32kb, so I'm guessing it's not RAM.

Thanks again!

: j

[TomWS]

My question was about RAM usage.  This is also reported when you compile your program and this is where you might have problems, especially with NeoPixels since I think that library grabs a bunch of RAM for each pixel used.

In my comment regarding SPI, I2C, etc, I was talking specifically about adding a new piece of hardware, a PIC processor, which would offload the critical timing of the shifting out to the NeoPixels.  The link between the PIC and the Moteino could be any of the ones I mentioned, but it would require a new processor.  Sorry to add this confusion, but it may be the only way to reliably drive Neopixels AND operate a wireless communication link. 

Tom

[goto10]

Ok- thanks! How do I determine RAM usage? I got the 9kb figure in the console when I compiled the app. Is that different?

Can you point me at how to get started with a PIC? It seems like a whole area of micro controllers I haven't begun to explore.

Also, is it weird that I get the same issue when I try to start a serial connection?

Ps. Do you think it'd be easier just to run dumb RGB LEDs instead? I'm just using two.

[TomWS]

Ok- thanks! How do I determine RAM usage? I got the 9kb figure in the console when I compiled the app. Is that different?

Unlikely since a Moteino only has 2K of RAM total.  Unfortunately the Arduino IDE behaves differently depending on the version and OS.  On my Windows and Linux systems, with IDE 1.6.0, the amount of RAM used is listed at the end of compilation.  There are ways to control this but you'll have to research.

You can put this in the beginning of your file.

Code Select Expand

#include <MemoryFree.h>
#define QMEM          {Serial.print("freeMemory()="); Serial.println(freeMemory());}

And then you can pepper your code with "QMEM" to get a state at that point in the program.that will tell you what's remaining after everything gets loaded.

Can you point me at how to get started with a PIC? It seems like a whole area of micro controllers I haven't begun to explore.

Try Microchip.com and I'll wager that there are plenty of tutorials floating around the web.  One warning, I don't think that they have a free development system.  The timing code is simple enough that it could be done in assembly language without too much difficulty but it's a whole lot of learning to go that route.  If I had nothing to do I might take a stab at it (since I have a NeoPixel project for next Christmas - it was supposed to be done this past Christmas    But I've got plenty to do right now.

Also, is it weird that I get the same issue when I try to start a serial connection?

In my experience, everything is 'weird' when using NeoPixels.  But, trying not to be a wise guy, I'd say that Serial dynamically allocates memory and, if you don't have enough, that would be a problem.  The NeoPixel library disables interrupts at time critical points so you shouldn't have a problem with the Pixels.  Everything else will break, but you should get pixels.

Ps. Do you think it'd be easier just to run dumb RGB LEDs instead? I'm just using two.

The ONLY reasons that I can think of for using NeoPixels are,

• you don't have enough signal pins available and want to do complex color schemes OR
• your LEDs are in a strip mounted several inches/feet from your processor.

Two RGB LEDs will require 6 pins and I don't know if you have 6 PWM pins on the Moteino (I doubt it).  However, if the LEDs are the same color, not a problem. And even easier if they are the same color and intensity.

Tom

[goto10]

Ok- i think I isolated it to a call to Serial.available(). Looks like there's plenty of memory free, though. ~1300 - ~1400

I think the easiest solution is to go with some basic RGB LEDs.

Thanks again for your help!

: j

[TomWS]

Ok- i think I isolated it to a call to Serial.available(). Looks like there's plenty of memory free, though. ~1300 - ~1400

I think the easiest solution is to go with some basic RGB LEDs.

Thanks again for your help!

: j

Hmmm, that would be plenty of memory.  It's when you get down below 400 bytes that you'll have a real problem.  Overall, I'd say going to basic LEDs might be a good decision.
Good luck, let us know how you make out.

Tom