WS2812B LED, wrong baud rate?

Trying to connect single individual WS2812B, and control using this code:

SPI2.setup({
  baud: 3200000,
  mosi: B15
});

var rgb = new Uint8Array(3);

setInterval(function() {
  // get milliseconds
  var ms = Math.floor(getTime() * 1000);
  // make 0..255 value based on time
  var r = Math.floor((Math.sin(ms / 1000) / 2 + 0.5) * 255);
  // send data
  SPI2.send4bit([ r, 0, 0 ], 0b0001, 0b0011);
}, 1000 / 60);

So it suppose to fade one color from 0 to 255, from dark to bright.
But what it does it kinda starts from blue (0-16) and then starts blinking and shifts to red and blinking there as well.
So looks like something wrong with bits, is it baud rate, or is it different format of data?

Any assist would be great.
Wiring is simple, B15 goes to data, power to power, and ground to ground. Nothing more or less.
Is capacitor here essential, or it is not related?

EDIT:
When connecting using battery (without USB) then it's OK!
So what am I missing here?

SOLUTION [ DrAzzy ]:
Put 0.1uf capacitor between ground and power right next to each LED.
Or consider already soldered solutions.

When using naked WS2812Bs, you need the 0.1uf capacitor between ground and power right next to the LED. This capacitor (acting as a so-called filter capacitor) serves to prevent the brief voltage drop when the LED is turned on from resetting the controller inside the WS2812B.

So that will help it to be OK through USB?
I will try, thanks a lot!

Yeah. Without the caps, it likely won't work on battery either once you start stringing more of them together

Thanks a lot. This is awesome, enjoying how easy is to put them together and here we go.
Another question:
If I want to have 8x8=64 LEDs and one Espruino, with 60 frames a seconds, it will be about ~10kbps (64leds * 60fps * 24bits), which as I understand is fine capacity for one board right?

Thanks for helping out :)

Depends what else you're doing besides updating the leds, but you don't need to refresh that often. The ws2812 remembers what you told it until you tell it otherwise.

Yes - you should be fine for sending the data out...

The issue is creating the patterns at that speed - but you could move between a set of pre-made patterns at 60fps if you needed to.

My idea is to create a remotely controlled controllers. So the idea that espruino will only get binary data from wireless or through some other wired method from laptop, and will render it on led arrays.
While visuals will be all product of software I'm writing. There are few ideas but generally it will be OpenGL (for prototype I'm using WebGL), that renders some 3D stuff, then I get pixel buffers, send them using WebSockets to node.js, and then from there I will have more ways to send to espruino board, as node.js has some cool low enough level of networking solutions. If will be able to get wireless working without big delays - that will be mind blowing.
I got wireless module as I had backed it on kickstarter, where got 4 boards, 1 wifi and few others (RS, Bluetooth).
Targeting to less than 30ms delay between renderer in software, and render on LEDs.

Then after this base is done, will look into Web Audio API in Chrome of FF, so I can extract frequency spectrum data, and them do some real-time rendering based on ranges of frequencies.
I did software very similar thing previously in .Net and Blitz3D before that (long time ago though) using BASS (library) and FMOD.
It's exciting project doing with my friend.

But for real-time renderer from software, and pretty visualisation, is what we want to achieve, is new buffer every ~16 ms (60Hz). Just for the beauty and experience of the picture.

Well, it shouldn't be too hard.

The main thing is to be able to push data buffers around, rather than explicitly setting every element in Espruino. For example, if you send data as a base64 encoded string, then converted it with atob, and sent it directly out, I think you could get 60fps very easily.

For atob and btoa thanks a lot!
Mainly it is an idea. I were looking into networking solutions, atm there is http, but of course overhead due to http, as well as the fact that for each request it open/close of a socket - is waste of performance.
So looking into more low-level communications. WebSockets - is a great alternative, but there is no support for them so far.
http over ethernet? Maybe.

We will have many of panels, each 16x16 (256) leds.
Each will have own board, and most likely ethernet connection, wifi would be great, if we will have WS that might work! Need to figure out how to get rid of problems I have when connect LEDs at same time as WiFi, looks like some capacitors are required (just a guess, as I am newbie in electronics).

Then software on laptop will do rendering and send data. WS - would be the best of course. Idea is to make modular node-webkit app, so people will be able to write own WebGL renderers and UI plugins to control panels.

We already have some soldered and tested, some tests on boards, and already printed parts to match them properly.
Here is WIP prototype model of a panel. We targeting to around 18 (6x3) of them with 30mm distance between each LED. That is amazing 4608 of individually addressable LEDs! :)

To be honest, websockets are a bit heavyweight. I guess ideally there would be support for simple UDP sockets, and then you could send a packet of data over UDP (which would be nice and efficient).

Honestly if you're going that far I'd consider using the WIZnet wired ethernet - trying to do everything over WiFi could be painful!

Also you could consider having a raspberry pi to handle ethernet, and then connecting Espruino boards via USB and using them to drive the WS2811s. It's probably significantly cheaper than buying multiple WiFi/Ethernet interfaces as well.

WebSockets has extra framing around each message, on top of pure TCP sockets including handshaking - which is string based message (HTTP headers).
Framing contain some data about type of message, its length and masking. That pretty much it.
I have implemented this protocol in C# .Net long time ago (when there was no SignalR and .Net 4.5).
Those guys have it, but their implementation is a bit surplus: https://github.com/einaros/ws
Here is some code for send/receive in .Net with dataframing I've made some time ago: http://moka.me.uk/files/wsreadwrite.txt

UDP is unreliable especially on embedded systems. What about just streamed TCP? Pure binary TCP stream? As starting point I believe is a good thing, will allow other developers to implement their data protocols on top of it.

Yes, pure TCP would be a good idea.

I don't think there's any reason for UDP to be unreliable though - on a wired network you could expect almost no packet loss I imagine. It's not like it matters though, because if it's lost, it's just a single frame at 60fps - I doubt anyone's eyes would notice.

Yes, Yes, Yes, i know that this is a repeat ;-)

Pure tcp socket support, mybe a subset or something like

http://nodejs.org/api/net.html

Sacha

Yes - IMO it's probably more important than WebSockets...

Indeed!

Sorry but "Put 0.1uf capacitor between ground and power right next to each LED." isn't overly clear to me but I am a complete newbie so I am a little afraid to 'wing it' without checking with someone who knows what they are on about first :-) By "Each LED" we are talking about LED Strip rather than individual LED right?

I've got Ground (White) and Data (Green) from the Espruino to the WS2812B (waterproof), and Power (Red) and Ground (Black) from a 5V power supply. The espruino is going into the JST socket (Green > Green, White > White) which then meets up with Ground (Black) and Power (Red) in a sealed section at the end of the WS2812B but turns 4 wires into 3 connections: GND (Black), Din (Resistor but then white), 5V (Red)

I would have guessed the proposed solution it to stick a 0.1uf between the 5V and GND lines on the end of the WS2812B but a)I can't it's sealed b)given I can't do it at the LED end, if I did it at the end of the wires where the power supply came in, that would create a short circuit, no? Obviously given these are sensitive components I don't want to blow anything up

I've actually got the WS2811 LEDs that came with the espruino kit and they are working fine without this, I did try to plug these WS2812Bs into the end of the WS2811s but nothing happened other than the initial flicker that happens when the LED strips get a bit of power but they are powered from the wall rather than battery so it'll be the same issue no doubt!

I'm a little confused about how you are hooking it up.

So the WS2812B strip has... 4 wires coming out of the input end of it? Red/Black/Green/White?

As I read your post, you have it connected like:
Black - GND of PSU
Red - +5 of PSU
Green - B15/A7/B5 of Espruino (depending on which SPI you're using)
White - GND of Espruino

And Red and Black are +5v and GND (I would agree with this assumption) - and the others would thus be ground and data. Barring documentation to the contrary, I would assume that the white wire would be data, and green ground - it sounds like you're doing it the other way around.

You can, of course, check with a multimeter - either the white or the green should be connected to the black wire if it's wired the way we think it is.

(it sounds from your description like there's no chance there could be a fourth wire in the strip. If there was, it's conceivable that, particularly in a waterproof strand, they might run Dout from the end of the strip back to the start of it, to aid in chaining them. In this case, you would need to connect GND on espruino to GND of the power supply for the LEDs, and whichever wire was Din to the espruino)

Your issue is unrelated to the caps. The caps need to be next to every individual led (per datasheet), so the led strips and arrays already have the caps in them. You just need to think about the cap if you're working with naked 2812s.

Right, sorted! Thanks DrAzzy!

I incorrectly labelled my JST connector above "Green > Green, White > White" was in fact "Green > Black, White to White" as apparently the JST connector on the WS2811 is different than the JST connector on the WS2812B

When I had the WS2811 working, I had Green out of B15, White out of GND which then correctly went into Green and White wires.

When I picked up the WS2812B I thought the only difference needed to be unhooking the JST connector and changing the power input.

I was wrong!

I've now swapped GND and B15's Green and White wires around and they are working as expected.

Looking at the LEDs in detail I can also see the tiny caps between them.

My LiPo battery arrived as mentioned in the other thread and works perfectly by the way, so now I've got my PIR, LED strip and battery powered espruino all working as I expect, the next step is to make it efficient so it can run on batteries for most of the year, hurrah! :-)

Those little caps - are capacitors. Your problem is different.
All LED strips already have individual capacitor nearby Each LED.

I've got slightly other problem now.
Got 256 RGB LEDs soldered, in 16x16 array.
My problem is that at the end of chain, LEDs start looking dimmed (they become orange, like loose blue and some green), like not much power left, especially if they all white.

It is plugged to espruino (power, data, ground).
As I understand I should move power and ground to external source?

You should definitely be powering it off of an external source if you want to drive that many LEDs! If running it on an external power supply, you need to tie the ground of the LED power supply to that of the Espruino.

The fact that it's getting dim at the end (it's expected that as voltage sags, blue and green would go first), though, implies that the voltage drop is not happening at the source (that would dim everything) but rather along the string.

If the issue persists after switching to an external power supply (I have no idea how you're making it work without one now, quite frankly!), your power and ground connections within the array are insufficient for the current involved. At full blast on 5v, WS2812's are spec'ed to pull 60ma each, so 256 of them will pull a whopping 15A! It sounds like you have power and ground running alongside data (so power to the one on the end is going back and forth along the whole array, rather than taking a more direct route) - tying supply power and ground to the power and ground of the string at multiple points along the string should help.

That is a great explanation!

I've looked into external power supply options, they look rather serious :) But If I want to have 18 in total of those panels, then it will be up to 600W (5v 270A), that is like a good PC with next-get GPU card.

I will go for an external power supply option. Will let you know how it will perform.

15A/panel * 18 panel = 270A

That is not 600W, that's... 5*270=1350W....

You can't use a computer supply for that even one rated at 1350W - computer power supplies are a whole bunch of supplies sharing a common ground, sized in the appropriate ratios for a desktop computer. The wattage on the box being the wattage of all these supplies summed together. If you look at detailed specs, you will find that the +5V output is rated much lower than you expect. Most of that power is only on the 12V side.

You are going to need to get more creative with your power source if you're going to run a 1.35 KW LED array

Ouch :D
What about if every panel (16x16) which is 15A or 75W would run from individial power supply (for each panel own one)? It obviously a bit more expensive, but easy solution here?
Something like this: http://www.ebay.co.uk/itm/UK-Stock-DC-5V­-12V-Universal-Regulated-Switching-Power­-Supply-for-LED-Strip-CCTV-/400671565030­?pt=UK_BOI_Electrical_Test_Measurement_E­quipment_ET&var=&hash=item5d49e2e4e6
Which is £12, not that bad imho. There is 200W option as well, which is enough for 2 panels. Throwing more Amps on panels - is not bad, right? As I would plug Espruino it self to same power source, and board needs very little energy (Espruino + WiFi/Ethernet).
It just have to be 5V and enough of Amps?

1.35 KW LED array, lol, that will cost a bit of energy :)