Can oak get time from the cloud?

[PeterF]

Same here... I didn't bother disabling the particle connection, and used the strandtest code, and the oak crashed/froze somewhere between 10 mintues and 30 minutes later.... So I think some yields() are needed to kick the wifi / particle tasks.

I think it could be an interaction of two things... (bear in mind that I haven't looked at this bit of code yet so what I say now could be complete rubbish!)

From fiddling with the pure ESP8266 Arduino core (and seeing forum/github stuff), there used to be (still is?) a problem where you didn't call yield() often enough, and the wifi link would drop or the ESP8266 would crash 'n burn. yield() does essentially what it says it does... it yields (to the background periodic processes that need to run). Then with the Oak I think you add the Particle integration on top, meaning not only could the wifi get b0rked, but also the Particle link. Hence yield() has to be run periodically. Now, every time the main loop() function runs it should trigger, as well as any background particle stuff. IIRC, the particle stuff is also triggered whenever a long enough delay() is used (hence why there is no longer a special Particle.delay() call). So if you have code (like standtest) that doesn't let the loop() run frequently enough, either or both the wifi and Particle code get cranky, and the Oak locks up (is that a  technical enough description?).

Moral of the story... be generous with your yields(). I don't know if Particle.process() is needed - it might be called in the yield() function also meaning it's not needed - although I know it is needed if you are in full manual Particle mode.

[crambo]

Nope. Sprinkled with yield() and it still crashes. Starting to think this platform was a mistake...

There are no Particle references in the code I shared...Is there something else you need to do to get Particle out of the way? I just need NTP access. Trying to make what I thought would be a simple clock....

[exeng]

crambo, Wish I could help but ran your Neopixel chase code on both UNO and Oak without a crash (unless it takes some time to occur).

Initially I thought these lines might be a problem...

Code: [Select]

   for (uint16_t i = 0; i < strip.numPixels() + 4; i++) {
    strip.setPixelColor(i  , c); // Draw new pixel
    strip.setPixelColor(i - 4, 0); // Erase pixel a few steps back
    strip.show();
    delay(5);
When i=0 you are referencing pixel -4. At i=1, pixel -3, but it doesn't seem to matter. Perhaps Neopixel lib has some bounds checking built in.
In any case I'm running you code on the Oak. No crash.

EDIT:
Also (not related to the crash question) your chasedown routine...

Code: [Select]

static void chasedown(uint32_t c) {
  for (uint16_t i = strip.numPixels(); i > 0 + 4; i--) {
    strip.setPixelColor(i  , c); // Draw new pixel
    strip.setPixelColor(i + 4, 0); // Erase pixel a few steps back
    strip.show();
    delay(5);
  }
}... does not make it all the way back since you stop at i > 0 + 4 which is 5 and leaves out pixels 4 through 0. If you slow the chase down you'll see it.

Again... running it now with no crash.

[crambo]

The program will run anywhere from minutes to hours....But alas, it always crashes. Same code on plain old vanilla Uno, runs for days plus now... small bugs in program aside, which don't seem to impact the uno negatively.

[crambo]

Yup, even with changes in code. Still crashing on two different Oak's.

[crambo]

Can anyone explain how to get Particle out of the picture? For this project, it is unnecessary...

[PeterF]

Just particle, or wifi? You will get the most stability with both disabled, but it should be more stable (time-sensitive-code wise) without Particle.

If you put SYSTEM_MODE(SEMI_AUTOMATIC) at the top of the your sketch (not in setup() - it goes outside of any functions - the Oak will still try to establish a wifi connection, but not Particle - you need to do that manually. SYSTEM_MODE(MANUAL) also prevents automatic particle connection, and requires that you use regular Particle.process() calls to maintain the Particle connection. I can't remember if the manual mode still connects to the wifi, or if that becomes a manual connect also. There is some documentation on this API / Particle stuff on the wiki.

Just a word of warning - as soon as you do either the SEMI_AUTOMATIC or MANUAL system modes, unless you have some code that establishes a particle connection in response to some condition (i.e. button attached to a pin), the only way you can do Particle over-the-air programming will be through the P1 - GND config/safe mode.

Something like this might be a starting point. I made one or two minor changes... I'm using a 24 pixel ring as a test subject and I haven't renamed the Oak neopixel library so Adafruit_NeoPixel_Oak didn't work for me (but these shouldn't change anything that would break stuff).  I added the strip.show() call after strip.begin() as that ensures all the pixels are off. Then there is the very dumb time-out to allow for OTA programming - you could also use config mode, or test for a pin being pulled high or low to halt startup and wait for programming. I'll leave that running for a few hours... but so far it is no longer randomly & periodically halting every 20-30 seconds whilst the particle processing happens.

Code: [Select]

SYSTEM_MODE(SEMI_AUTOMATIC)
#include <Adafruit_NeoPixel.h>

#define PIN      1
#define N_LEDS  24

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

void setup()
{
  strip.begin();
  strip.show();

  Particle.connect();
  Particle.publish("oak4/connect", "Giving Particle time to catch me for programming", PRIVATE);

  delay(15000);

  Particle.publish("oak4/disconnect", "I ain't no IoT device... I quit!", PRIVATE);
  Particle.disconnect();
}

void loop()
{
  chaseup(strip.Color(255, 0, 0)); // Red
  chasedown(strip.Color(255, 0, 0)); // Red
  chaseup(strip.Color(0, 255, 0)); // Green
  chasedown(strip.Color(0, 255, 0)); // Green
  chaseup(strip.Color(0, 0, 255)); // Blue
  chasedown(strip.Color(0, 0, 255)); // Blue
}

static void chaseup(uint32_t c)
{
  for (uint16_t i = 0; i < strip.numPixels() + 4; i++)
  {
    strip.setPixelColor(i  , c); // Draw new pixel
    strip.setPixelColor(i - 4, 0); // Erase pixel a few steps back
    strip.show();
    delay(5);
  }
}
static void chasedown(uint32_t c)
{
  for (uint16_t i = strip.numPixels(); i > 0 + 4; i--)
  {
    strip.setPixelColor(i  , c); // Draw new pixel
    strip.setPixelColor(i + 4, 0); // Erase pixel a few steps back
    strip.show();
    delay(5);
  }
}

[crambo]

PeterF,

I appreciate your both validating what I am seeing (thought I was crazy) and your input and expertise. I too will try these changes. I assume Wifi will still work, as ultimately, I will need it for the NTP example you contributed early in this thread.

THANK YOU!!!!

Cameron

[crambo]

PeterF,

I too am running code you posted. I am now hoping that this will work, and that by doing so, NTP/Wifi will keep working, as that will be necessary for the clock code.

Best,
Cameron

[PeterF]

No worries Cameron. This 'lil sucker has been running for more than two hours now and hasn't even hickup'd once so far... which is starting to get annoying as it's a bit bright on the desk in front of me!   

Anyway, the wifi backend stuff should still be working, just not doing much since Particle isn't needing to establish a connection. I suspect what you'll need to do is do your NTP time sync, and just live with the fact that while that is happening the pixels can't be controlled - this is strictly a one task at a time affair. The easiest way to cheat that is to use non-blocking delays to do stuff. But that is the topic for a another thread ;0

Pete

[crambo]

Oh no! It froze on me! Arrrrggghhh!!! Is it still running for you? I ran for more than an hour!

[crambo]

Ugh. I give up. I'm gonna just use an Uno with a shield. Would have been col tho!

Pete, thanks for all your help. I imagine the Oak will eventually be a great little platform and I will hold on to my five for that moment!

[PeterF]

It ran for about five hours then the battery went flat... so I'll get it off the hook on that point! Edit: It looks like I may have spoken too soon... about 3.5 hours later, and running from USB power this time... and it froze! So something doesn't want to co-operate. :-(

hm... I dunno what's going on here... when it locks up... is the P1 led doing a triple blink pattern (indicating it is in safe mode)? And how are you powering the oak... maybe it's not getting quite enough power? The only other thing is which version of the board package you are using... the latest (1.0.6)?

[crambo]

I have now run this on a plain old ESP8266 for multiple days. Clearly there is some inefficiency (bug) deep in the particle support. That is the only thing I can identify as different....

Is there any way for me to convert my Oaks to plain old 8266 units? At least I won't be out $50.

[PeterF]

It's also possible that there is a bug that was kept over from an earlier version of the ESP8266 core, as the Oak one is a bit behind... but I would be more inclined to point the finger at something to do with the particle integration.

AFAIK, all you need to do is a) save your device ID once you've claimed your Oaks on Particle so that you can re-Oakify them later if you wish; and then b) just serial flash them with a compiled ESP8266 sketch when they are in serial programming mode (P2 to GND)... that should be all there is to it. Then have a look at the Oak to ESP8266 pin mapping so you can work out what pin is now which in ESP8266 Arduino parlance. And they also have enough on-board memory that you should be able to play with OTA programming ESP8266 Arduino style.