Author Topic: Neopixel Issues  (Read 16153 times)

crambo

  • Jr. Member
  • **
  • Posts: 52
Re: Neopixel Issues
« Reply #15 on: November 22, 2016, 02:16:22 pm »
Ok, so forgive my noobness. But, I clearly must have got the wrong library installed. Is there any documentation someone could point me to that would help me get the right library installed? I have looked in the traditional locations and can only find the adafruit 1.0.6 version of the neopixel lib. Where can I find the "oak" version? I still have to declare to GPIO pin mapping...

Thanks in advance for all your wonderful assistance so far!

-Cam

crambo

  • Jr. Member
  • **
  • Posts: 52
Re: Neopixel Issues
« Reply #16 on: November 22, 2016, 03:20:04 pm »
Ok, so I must have a common ground issue. I am powering the neopixel off of 5v out of my laptop, and powering oak off a wall wart. When I hold the two in my hand, they pixels fire off just as they should. When I let go, they the pixel freezes up. I figure I have some UNcommon ground issue.

How would any of you rec I should provide power 5v to neopixels and power to the Oak? I thought the micro usb provided 5v, but alas, the Oak can only output 3v?

PeterF

  • Hero Member
  • *****
  • Posts: 881
Re: Neopixel Issues
« Reply #17 on: November 22, 2016, 03:25:55 pm »
The Oak can provide 3.3v regulated power, but if you are powering it from the microUSB, you can tap into that from the VIN pin on the Oak. And whenever using multiple power supplies / sources you almost always connect the ground together in some way - you need a common ground. You just don't connect the two positives together as well, especially if they are different voltages. Voltage is only positive or negative in relation to *something*  - with the something being ground.

Regarding your prior question, the Oak version of Adafruit_NeoPixel is bundled with the oak package - so you already have it. Just be aware that that is updated with the board core - so make sure you have the latest version of that (1.0.6 as of 12 Oct, Tools -> Boards -> Board Manager). 

When you compile your code, if you look in the compiler messages, do you get one about multiple libraries, and one being picked over the other? If so, it is probably picking on the that is install in your sketchbook library, rather than the one bundled with the Oak. Only real way to fix that is to remove the copy from the sketchbook, so the Arduino IDE can't see it.

I'll have a look what  the patches are to the library, I'll see if I can put something together that Adafruit would be willing to incorporate into theirs (I'm hoping it's just a conditional pin re-mapping block at the top of the file).
« Last Edit: November 22, 2016, 03:31:34 pm by PeterF »

crambo

  • Jr. Member
  • **
  • Posts: 52
Re: Neopixel Issues
« Reply #18 on: November 22, 2016, 04:30:06 pm »
PeterF,

Thanks! That's the trick. I think I should be good for the time being. Excited to be on my way!

-Cam

exeng

  • Sr. Member
  • ****
  • Posts: 454
Re: Neopixel Issues
« Reply #19 on: November 22, 2016, 05:00:24 pm »
crambo,

What Pete said.

In addition you should know that I have successfully run a small number of Neopixels from the Oak VCC regulated 3.3V, GND and pin 5 for DIN. I was surprized that it worked. Also ran one of my simple animations on an 8X8 pixel matrix but only a few (dozen or so) LEDs are lit at any given time and only briefly.

emardee

  • Full Member
  • ***
  • Posts: 135
Re: Neopixel Issues
« Reply #20 on: November 22, 2016, 06:31:44 pm »
My OAK and 10m of Neopixels are all powered from the same seriously beefy 5v supply: Meanwell LRS 5v 40A PSU Specs

Probably overkill for the job, but I didn't want the PSU overheating in the wall cavity (the de-rating curves of cheaper supplies show they can lose half their max power rating when they get over 50degC).

I think my limitation for current draw is my thin wiring, because when I switch the full length to go to full brightness on a pair of colours, then the far end of the LED string is dimmer or a different colour. (Maximising out at about 50w used). Any single colour on full brightness is fine though. I plan to use thicker wiring to feed the LEDS their power, but also to feed in power further along the string (probably as well as existing feed, but might be instead).

jgueydan

  • Newbie
  • *
  • Posts: 1
Re: Neopixel Issues
« Reply #21 on: December 04, 2016, 07:41:39 pm »
I have an Oak operating 2x 5m strips of RGBW Neo pixels (300 pixels per 5m run).

I've interfaced the sketch to Blynk, so I can pick the subtle mood lighting colour using ZeRGBa or R, G, B, W sliders on my phone.

In a different sketch I was dabbling with animations that worked nicely, like fickering fire, or soothing water reflections, but these aren't in the live sketch I'm currently running yet.

Very much a work in progress at this end... but it works enough for it to be running them as my main lounge lights for the house. Nowhere near the sketch code right now, so can't share them code I'm using right now.
I would very much like to see this when you get a chance to share it!  Thanks

crambo

  • Jr. Member
  • **
  • Posts: 52
Re: Neopixel Issues
« Reply #22 on: December 12, 2016, 06:59:25 pm »
Have they ever crashed on you? Mind sharing your sketch?

crambo

  • Jr. Member
  • **
  • Posts: 52
Re: Neopixel Issues
« Reply #23 on: December 13, 2016, 05:48:39 pm »
Ok, since I am pretty sure this is a conflict between the Neopixels and the Wifi (and possibly the NTP update): Is it possible to pause the pixel animation and only activate WiFi during an NTP update, then redisable Wifi until the next NTP update?

I am not seeing in traditional NTP usage where that is getting kicked off, but this should be possible?

Thanks in advance!

crambo

  • Jr. Member
  • **
  • Posts: 52
Re: Neopixel Issues
« Reply #24 on: December 13, 2016, 06:19:24 pm »
And as another test, I am trying FastLED instead of Neopixel library. I noted that compiling for FastLED, SPI gives an warning. I see that has to do with a clock pin. Does the Oak have a dedicated pin for clock? THat might also be an issue if it is having to bitbang instead of something a bit more elegant... a bit.

PeterF

  • Hero Member
  • *****
  • Posts: 881
Re: Neopixel Issues
« Reply #25 on: December 13, 2016, 09:03:48 pm »
I don't see why not... The simplest would be to shoe-horn the wifi connect and disconnect stuff into the getNtpTime() function. so that when it is called, it enables the wifi, does it's thing, and then shuts down the wifi again... and I do mean the wifi... not just the particle link... so that *should* settle things down if it is indeed a clash. I'll put something together later on tonight.

crambo

  • Jr. Member
  • **
  • Posts: 52
Re: Neopixel Issues
« Reply #26 on: December 14, 2016, 09:58:58 am »
Yes, but I thought Oak takes control of Wifi out of the picture... I don't see a way to control WiFi from within sketch.

emardee

  • Full Member
  • ***
  • Posts: 135
Re: Neopixel Issues
« Reply #27 on: December 14, 2016, 12:16:19 pm »
It does by default. But there is a mode where it doesn't connect to wifi and Particle on boot, but only connects to them if your sketch requests it.

@Peter  is there a wiki page that describes these modes? Just went hunting, but couldn't find it.

I'll be happy to upload my sketch, but it might take me a few weeks, as it is stuck on a computer that isn't setup right now.

Mike

PeterF

  • Hero Member
  • *****
  • Posts: 881
Re: Neopixel Issues
« Reply #28 on: December 14, 2016, 05:39:34 pm »
Yeah, the SYSTEM_MODE flag is documented on the wiki on the API reference page. As are the Oak specific function calls.

The Oak is mean to make it so you don't have to think about the wifi config at all (as is the Photon)... but since that isn't always what the user wants, the SYSTEM_MODE flag exists so that you can specify that it be automatic (default), semi-automatic (user manages particle connect/disconnect, wifi remains automatically connecting, but user manageable also) and manual (user code manages wifi and particle connections). I've done some stuff that does the semi-automatic wifi/particle management, but hadn't needed to do fully manual control yet.

re: SPI clock pin, that would be P9, per the Oak silkscreen. Don't know if it's "dedicated" or merely the default pin...

I'm trialling this code which makes it so the WiFi is enabled only when the NTP time request is called... and runs a single neopixel in the meantime. It seems to be working... the main loop is running at a steady 5120-5121 milliseconds per cycle (i.e. the animation takes around 5120 milliseconds to complete), and then there is a nearly double that (around 9134 millisecond - but will be variable as it is dependent on how quickly the wifi connects and the NTP request processes) loop when the wifi kicks in every five minutes for the time sync. Obviously it doesn't need to be that frequent... and is easily changed by simply updating the time sync interval variable. Just makes it more likely that if the wifi code makes it fail, it should do it a bit quicker ;)

Edit: btw, both the P1 led blink and the 1 neopixel blinker have survived their first 24 hours and are still running fine. So that's two Oaks both doing NTP lookups every 5 minutes with particle and wifi on auto, and no lockups/failures (yet!)

Code: [Select]
/*
   Time_NTP_manageWifi_NeoPixel
   This sketch uses the ESP8266WiFi, WiFiUdp, Time and Adafruit_NeoPixel libraries
   Code examples mashed together 2016 Peter Feerick
*/

SYSTEM_MODE(MANUAL)

// Which pin on the Oak is connected to the NeoPixels?
#define PIN            6

// How many NeoPixels are attached to the Arduino?
#define NUMPIXELS      1

#define DEBUG
#define DEBUG_OI Serial

#ifdef DEBUG
#define   DebugBegin(...) DEBUG_OI.begin(__VA_ARGS__)
#define   DebugPrint(...) DEBUG_OI.print(__VA_ARGS__)
#define   DebugPrintln(...) DEBUG_OI.println(__VA_ARGS__)
#else
// Define the counterparts that cause the compiler to generate no code
#define   DebugBegin(...) (void(0))
#define   DebugPrint(...) (void(0))
#define   DebugPrintln(...) (void(0))
#endif

#include <Adafruit_NeoPixel.h>

#include <TimeLib.h>
#include <ESP8266WiFi.h>
#include <WiFiUdp.h>

// NTP Servers:
IPAddress timeServer(132, 163, 4, 101); // time-a.timefreq.bldrdoc.gov
// IPAddress timeServer(132, 163, 4, 102); // time-b.timefreq.bldrdoc.gov
// IPAddress timeServer(132, 163, 4, 103); // time-c.timefreq.bldrdoc.gov

const int timeZone = 10;     // Australian Eastern Standard Time

WiFiUDP Udp;
unsigned int localPort = 8888;  // local port to listen for UDP packets

long lastUpdate = 0, lastBlink = 0;
long updateInterval = 5 * 60 * 1000; // five minutes
long blinkInterval = 1000; // 1 second
bool firstRun = true;

Adafruit_NeoPixel strip = Adafruit_NeoPixel(NUMPIXELS, PIN, NEO_GRB + NEO_KHZ800);

void startWiFi()
{
  Oak.connect();

  DebugPrint("Connecting to WiFi");

  while (!Oak.connected())
  {
    digitalWrite(LED_BUILTIN, HIGH);

    delay(250);
    DebugPrint(".");

    digitalWrite(LED_BUILTIN, LOW);
  }
  digitalWrite(LED_BUILTIN, LOW);
  DebugPrintln("CONNECTED!");
}

void stopWiFi()
{
  DebugPrintln("Stopping WiFi!");
  WiFi.disconnect();
}

void setup()
{
  pinMode(LED_BUILTIN, OUTPUT);
  digitalWrite(LED_BUILTIN, LOW);

  DebugBegin(115200);
  DebugPrintln("setup()");

  strip.begin();
  strip.show(); // Initialize all pixels to 'off'

  setSyncProvider(getNtpTime);
}

void loop()
{
  unsigned long loopStartTime = millis();
   
  if (millis() - lastUpdate > updateInterval || firstRun)
  {
    firstRun = false;

    if (timeStatus() != timeNotSet)
    {
      digitalClockDisplay();
    }
    else
    {
      DebugPrintln("Haven't gotten time sync???");
    }

    lastUpdate = millis();
  }

  rainbow(20);

  DebugPrint("loop() runtime (ms) = ");
  DebugPrintln(millis() - loopStartTime);
}

void digitalClockDisplay() {
  // digital clock display of the time
  DebugPrint(hour());
  printDigits(minute());
  printDigits(second());
  DebugPrint(" ");
  DebugPrint(day());
  DebugPrint(".");
  DebugPrint(month());
  DebugPrint(".");
  DebugPrint(year());
  DebugPrintln();
}

void printDigits(int digits) {
  // utility for digital clock display: prints preceding colon and leading 0
  DebugPrint(":");
  if (digits < 10)
    DebugPrint('0');
  DebugPrint(digits);
}

/*-------- NTP code ----------*/

const int NTP_PACKET_SIZE = 48; // NTP time is in the first 48 bytes of message
byte packetBuffer[NTP_PACKET_SIZE]; //buffer to hold incoming & outgoing packets

time_t getNtpTime()
{
  //start WiFi
  startWiFi();

  Udp.begin(localPort);

  while (Udp.parsePacket() > 0) ; // discard any previously received packets
  DebugPrintln("Transmit NTP Request");
  sendNTPpacket(timeServer);
  uint32_t beginWait = millis();
  while (millis() - beginWait < 1500) {
    int size = Udp.parsePacket();
    if (size >= NTP_PACKET_SIZE) {
      DebugPrintln("Receive NTP Response");
      Udp.read(packetBuffer, NTP_PACKET_SIZE);  // read packet into the buffer
      unsigned long secsSince1900;
      // convert four bytes starting at location 40 to a long integer
      secsSince1900 =  (unsigned long)packetBuffer[40] << 24;
      secsSince1900 |= (unsigned long)packetBuffer[41] << 16;
      secsSince1900 |= (unsigned long)packetBuffer[42] << 8;
      secsSince1900 |= (unsigned long)packetBuffer[43];

      //finished with WiFi for now...
      Udp.stop();
      stopWiFi();

      return secsSince1900 - 2208988800UL + timeZone * SECS_PER_HOUR;
    }
  }
  DebugPrintln("No NTP Response :-(");

  //finished with WiFi for now...
  Udp.stop();
  stopWiFi();

  return 0; // return 0 if unable to get the time
}

// send an NTP request to the time server at the given address
void sendNTPpacket(IPAddress &address)
{
  // set all bytes in the buffer to 0
  memset(packetBuffer, 0, NTP_PACKET_SIZE);
  // Initialize values needed to form NTP request
  // (see URL above for details on the packets)
  packetBuffer[0] = 0b11100011;   // LI, Version, Mode
  packetBuffer[1] = 0;     // Stratum, or type of clock
  packetBuffer[2] = 6;     // Polling Interval
  packetBuffer[3] = 0xEC;  // Peer Clock Precision
  // 8 bytes of zero for Root Delay & Root Dispersion
  packetBuffer[12]  = 49;
  packetBuffer[13]  = 0x4E;
  packetBuffer[14]  = 49;
  packetBuffer[15]  = 52;
  // all NTP fields have been given values, now
  // you can send a packet requesting a timestamp:
  Udp.beginPacket(address, 123); //NTP requests are to port 123
  Udp.write(packetBuffer, NTP_PACKET_SIZE);
  Udp.endPacket();
}

void rainbow(uint8_t wait) {
  uint16_t j;

  for (j = 0; j < 256; j++)
  {
    strip.setPixelColor(0, Wheel(j));
    strip.show();
    delay(wait);
  }

}

// Input a value 0 to 255 to get a color value.
// The colours are a transition r - g - b - back to r.
uint32_t Wheel(byte WheelPos) {
  WheelPos = 255 - WheelPos;
  if (WheelPos < 85) {
    return strip.Color(255 - WheelPos * 3, 0, WheelPos * 3);
  }
  if (WheelPos < 170) {
    WheelPos -= 85;
    return strip.Color(0, WheelPos * 3, 255 - WheelPos * 3);
  }
  WheelPos -= 170;
  return strip.Color(WheelPos * 3, 255 - WheelPos * 3, 0);
}
« Last Edit: December 14, 2016, 06:29:46 pm by PeterF »

crambo

  • Jr. Member
  • **
  • Posts: 52
Re: Neopixel Issues
« Reply #29 on: December 14, 2016, 08:16:19 pm »
PeterF,

You need to modded up to God Member. You do great stuff in support of this little device. Once I get this all dialed in, I will share a little video of what it all looks like. Having access to a network time source is unbelievably helpful in a fire-and-forget environment that is time dependent(SCHOOLS!), a poorly staffed with support types (ME!). Ultimately, these clocks will be made into kits that students (and teachers who want to build one) can build for a given teachers classroom.

On with the testing!

THANKS!