The timings required by the NeoPixels are kind of difficult to hit… so we use the SPI bus to “fake” the data - at 15MHz the clock cycles are granular enough to mostly hit the timings (they fall within the allowable range).
Since it the timings aren’t perfect, on long chains of NeoPixels you’ll get some unexpected behaviour. This might actually be a power issue - I’m going to investigate later today and will report back
All in all, it mostly works… and is a good first step
time() on Imp drifts about 4ms/min. That’s not good. millis() can be made much more accurate by multiplying by a constant. I’ve gotten 10ms/day. You can sync with NIST to get an absolute accuracy of about 10ms. 1/100th of a second. Depending on your internet connection. You can keep this accuracy by syncing again every day. No hardware is needed. Interested?
If you disconnect and reconnect from the server, it will resync time. We’ll look at adding a less severe way of doing this, though it’s usually only a couple of seconds.
You’d have to do this every hour, or it will be off by 1/2 additional second. Plus up to 1 second to begin with when you sync time() by reconnecting. Great for some applications, but much greater than 1/100th second if you need that.
It was not a power supply issue - it turned out to be another issue with the imp’s clock. Right now I’m solving it by setting enableblinkup(true).
I ran the code on a strip of 120 NeoPixels and it mostly worked - it still occasionally jitters, but that seems to happen mostly when you’re updating around 20+ times per second.
