Addressable RGB LED

grim_reaper

Senior Member
Hello all. I've found a relatively cheap RGB LED, which is labelled as either 'addressable' or 'intelligent' depending on which search results you follow. My preferred supplier has a datasheet which can be found here (PDF).
Now, hopefully most of you will agree with me that this datasheet is somewhat lacking in critical detail, hence the following questions!

If I've interpreted it correctly, the output should be held at half the (LED) supply voltage (we'll use 5V for examples here), and raised/lowered to create the binary data stream. It sounded like a simple method of time-independent driving (or edge-driven I suppose it should be called?) - there don't appear to be any timing requirements aside from keeping the output at 2.5V steady when you want to latch the data. Or do you interpret it differently?
The issue I have now, at the prototype design stage, is how to generate a 2.5V output which can be pulled high and low.

Is it as simple as using a potential divider across the supply to obtain 2.5V, then using a PICAXE pin to drag the line high and low? I'm thinking set the pin as an input for 2.5V, output high for 5V and output low for 0V - but that smells like it needs a diode somewhere (the basics are not my strong point - too many years of using other people's pre-built equipment at work!).

Has anyone seen this kind of driving method somewhere else? I.E. can anyone identify the IC family used inside the LED?

Thanks for any insights - or even better - experience with this very LED :D
 

fernando_g

Senior Member
The easy part is generating the tri-state output.

A Picaxe bidirectional port attached to a 1k + 1k resistor divider.
To send a zero, make the port low.
To send a one, make the port high.
To idle, make that port an input.

Other than that, the datasheet is confusing. In particular, this statement:
Directly connect to electronic power without transformer

Which would mean that you have to daisy chain enough devices in series to withstand the rectified AC line?
And do I assume that as each device starts to go farther and farther away from powerline common, will the DO pin level shift the data for the following DI pin?

One thing is for sure: individual devices are not addressable. Every single device in the string will display the same color.

EDIT: to avoid having a "shocking" experience, I would get a 12 V transformer, and purchase just enough LEDs to consume the aprox 16 volts DC.
That way, you and your Picaxe will be safer in case something goes wrong.
 

AllyCat

Senior Member
Hi,

Sorry, I've never used those particular LEDs and the interface does seem a little "unusual", but I do agree with your interpretation of the rather limited data sheet.

The "easy" way to drive it would be to use two PICaxe pins, each connected to the data input via a resistor of the same value (I'd guess at around 10k). Then you would create the High and Low levels by driving both pins to High or to Low, and for the "middle" level, drive one pin to each polarity. Then the pins can remain as outputs all the time (or switch to input mode to save power).

But to use a single pin, connect the data/pin to the centre of a voltage divider chain across the supply/ground; I can't see any need for a diode. Then use the PICaxe in "Tri-State Mode", i.e. as you say, output either High or Low, or select a High Impedance with an INPUT or REVERSE command. If you were driving lots of LEDs then you'd probably create a "half Vdd supply" to bias each pin/LED via a single resistor.

Cheers, Alan.

EDIT/PS: I'd be cautious about the meaning/translation of the word "transformer". They seem to be using the word "Pressure" for "Voltage", so transformer might mean transistor, or driver or regulator or .....?

EDIT2: Reading the data sheet again, I think "transformer" probably just means "Resistor", i.e. something that "transforms" a voltage into a current. Or it might mean that there is no need for a "step down converter" (from a higher dc voltage) such as a buck SMPS (which would indeed contain a choke or transformer) because the LEDs can be connected in series.

The Data I and O pins are presumably coupled by an internal "shift register" so that multiple LED/chips can be "daisy chained" with individual control. But the respective supply-grounds can be connected in series which makes the interface data levels rather "interesting". I would guess that there is ac (capacitor) coupling with some form of "dc restoration" associated with the Tri-level interface. That might mean that there are more critical timing restrictions on the widths of the pulses and "middle" voltage levels than the data sheet implies (or rather, doesn't specify).
 
Last edited:

grim_reaper

Senior Member
Thanks AllyCat; your commentary is invaluable, as always. At ~64p each, it's highly likely I will get a few to play with out of morbid curiosity.

The project I have in mind is 'decorating' our rather large kitchen clock (big round analogue jobby) with 12 LEDs around it's hollow metal frame. Consequently, I think only the 'original style' round through-hole LEDs will look OK (as opposed to sticking SMD ones on the outside), and a round drill hole through the metal is as complicated as my mechanical skills will stretch to on one of my wife's prized items of decor. As I'm sure most of you are aware, there are plenty of other round 5mm (+) RGB LEDs to choose from.

Regards the datasheet, I kind of recognise the standard of translation as being from the Far East - and obviously very little care was taken in checking it, since the maximum allowed supply voltage is 6V, whereas the minimum is 35V (!).

If I do build a prototype, I'll probably opt for your 2 pin suggestion (08M2 with nothing but a serial connection and the outputs to the LEDs, so plenty of I/O), as like you say it's the easier option and once I got my head around it, it's just the potential divider, but using the pins instead of the rails!

Fernando_g - why would you wire the power supply in series?! EDIT! I see they did that on the last page - yes - not good!
I didn't even consider that - just drew my prototype plan with all LEDs supplied in parallel.
I don't think any of us are going to argue that the datasheet is confusing!

Thanks both - and I'll let you know how it goes/went in a few weeks!
 

AllyCat

Senior Member
Hi,

Sorry, I did quite a lot of editing "on the fly" as I read through the data sheet again (and again....).

Just one further thought. What happens if you use two LEDs in series as per their diagram on page 3 and then set one to "White" (lots of RGB current) and the other to "Black" (no current)? Does the "off" one have an internal shunt regulator (3.5v ?) to provide current (with a suitable voltage drop) for the other LED? That doesn't seem a very efficient approach (full current even if all LEDs are "off"). In theory the "upstream" LED may "know" what the others should be doing, but the downsteam one may be completely "in the dark" (literally or figuratively). ;)

Also I suspect that they have LEDs #1 and #0 (or the DI-DO pins) exchanged. Wouldn't the first data sent end up in the last LED?

Thanks for introducing us to another "interesting" device. :)

Cheers, Alan.
 

westaust55

Moderator
Also I suspect that they have LEDs #1 and #0 (or the DI-DO pins) exchanged.
The diagram seems right to me.

Wouldn't the first data sent end up in the last LED?
That is how I see it.

The first 3 bytes as Data0 go first into IC #1's DI pin then pass through to IC #0's DI pin as the next 3 data bytes for data1 enter IC #1's DI pin.
 

hippy

Technical Support
Staff member
I suspect that they have LEDs #1 and #0 (or the DI-DO pins) exchanged. Wouldn't the first data sent end up in the last LED?
I suppose it depends on whether they remember the first data they receive after a 'latch period' and only pass subsequent data on after that, or use the last data received when that 'latch period' occurs.

That datasheet is of rather limited utility. I would guess the minimum voltage is 3V5. Given that the 'latch period' is 3ms of mid voltage I would also guess that sets the minimum high-mid-low periods.

To generate the three voltages I would try a 10K pull-up and 10K pull-down with a single I/O pin and tristate it, make it input, to get a mid-voltage.

The part seems to be OST4ML5B32A for anyone wanting to search for any other information on the LED.
 

AllyCat

Senior Member
Hi,

But if the 3. example diagram represents a 'scope waveform with time increasing from left to right, but split over two lines (top to bottom), then isn't the "first" bit sent the LSB of R1 (#1) and the "last" bit (before the 3ms data latch) the MSB of B0 (#0) ?

To me, that would shift the #1 data through to #0 and leave the #0 data in #1 ?

But I am getting on in years. Anybody else ? ;)

Cheers, Alan.

EDIT: It rather depends how you read Figures 1 and 2. I would read them as "right to left" so the fisrst bit would be MSB of B1, but that doesn't seem to agree with the 3. waveform.

And from one of the data sheets based on hippy's discovery ,it seem fernado was correct since it says:

Application circuit
1. Connect to 220V electronic supply, suggest to use 48PCS LED in series. :eek: I think I'll pass on that suggestion.
 
Last edited:

hippy

Technical Support
Staff member
But if the 3. example diagram represents a 'scope waveform with time increasing from left to right, but split over two lines (top to bottom), then isn't the "first" bit sent the LSB of R1 (#1) and the "last" bit (before the 3ms data latch) the MSB of B0 (#0) ?
If we call the first 24 bits of data LED#1 and the next 24 bits LED#0. The R1 which it goes into will read LED#1 first, latch it, all the while keeping its data out at Vmid, then, having latched its own data, pass on the rest. R0 will see LED#0 first, latch that, pass the rest on.
 
Last edited:

AllyCat

Senior Member
Hi,

Yes that could work if an exact multiple of 24 bits is always transmitted. But suppose that an extra (error) bit gets introduced after the latch period. Then all the the LEDs will have stored the wrong value and most won't know what to do when an extra bit appears before the next latch cycle.

But we really need somebody to "play" with several of them (but preferably not 48 plugged into a UK mains socket). ;)

Cheers, Alan
 

hippy

Technical Support
Staff member
Yes that could work if an exact multiple of 24 bits is always transmitted. But suppose that an extra (error) bit gets introduced after the latch period.
Then you are potentially up that infamous creek without a paddle. As used to be said more often than it is these days; garbage in, garbage out.

The protocol requires multiples of 24 bits to be sent. If you don't send in multiples of 24 bits then all bets are off, and it's not reasonable to expect anything else unless specific steps have been taken to make something fault tolerant.

Unless there is defined behaviour for unexpected situations then one has to take whatever arrives. In the extra bit situation it may well be that the extra bit just 'falls off the end' and has no impact. It could well be that nothing is latched if too few bits are sent. It could be fault tolerant even if not by design. But perhaps not.

Most datasheets will only detail what will happen when things are done properly, not what happens when they aren't, and, as here, many datasheets can often be light on detail anyway.

But we really need somebody to "play" with several of them
Though only to confirm that what the datasheet says needs to be sent does what the datasheet says will happen. Anything more than that is information the majority will not need to know. "It won't work properly if you don't send the data it needs to receive" will be good enough for most people, and is rather implicit anyway. How it doesn't work will mostly be of interest to those dealing with safety critical situations where they have to be concerned with fault conditions.
 

AllyCat

Senior Member
Hi,

Yes, fair points. But bear in mind that one "application" is a string of LEDs hanging almost directly across the mains supply with very little filtering. There almost certainly will be "spikes" on some occasions and IMHO one should always try to design a system to be as fault-tolerant as practical.

Certainly we can't read too much into that data sheet, but to me a "Latch" event occurs after a string of data has been transmitted, whilst a "Sync" (or Start) pulse/event occurs before the data.

Cheers, Alan.
 

hippy

Technical Support
Staff member
But bear in mind that one "application" is a string of LEDs hanging almost directly across the mains supply with very little filtering.
I am not convinced that its use in such an application can be inferred from the datasheet given.

That seems to be reading quite a lot into one sentence of the datasheet where it has already been recognised that it is not exactly clear what that one sentence actually means.


I have found another datasheet which suggests it can be used in a transformerless design with 48 LED's for 220V and 24 LED's for 110V. It is a bit more complicated than hanging them across a mains supply.

We do not recommend anyone attempting any projects which utilise mains supplies in their circuit or uses a transformerless design.
 
Last edited:

Flenser

Senior Member
Hippy, I found a data sheet that describes using 48 LED's for 220V and 24 LED's for 110V and it occurred to me that while the datasheet describes how you _an use these LEDs wired in series at 110V or 220V does that necessarily mean that you _must_ use them in series.

Surely we should be able drive these LEDs with V+ and V- wired in parallel across a 5V power supply? (which is how the WS23xx LEDs are wired)

The more LEDs in the string the higher current your power supply will need to be able to source. The datasheet lists 15mA for the individual RGB LED currents so at max 45mA per RGB LED we should be able to drive 11 of these LEDS off a 500mA USB 5V supply.

The other bit of useful info in the other datasheet was this timing spec for the data pulse width:
TruOpto OST4ML5B32A Data Format.jpg
 

AllyCat

Senior Member
Hi,

It is a bit more complicated than hanging them across a mains supply.
Well yes, it has a bridge rectifier, a series capacitor (very efficient at coupling spikes and general garbage into a circuit) and a large high voltage electrolytic capacitor across the supply (which probably has too much inductance to "shunt away" most of the garbage that does get in). The circuit also shows a "variable resistor" directly across the mains input, which I hope is intended to be a surge / spike protector or TVS (Transient Voltage Suppressor). Also note that it's notionally a "positive earth" design, but of course one of the "gotchas" with a transformerless bridge circuit is that the positive and the negative supply rails are both "live" (at some time during the mains cycle).

I'm still puzzled exactly how these LEDs can be connected in series. I remember when "fairly lights" were connected directly in series across the mains (e.g. 12 x 20 volt bulbs) and if one filiament "blew", all the lights would go out. Then you'd have to replace each bulb in turn until you found the faulty one and they all started working gain. Later, the bulbs were "improved" with an internal switch, such that when the tension in the filiament broke, then the switch closed and shorted out that particular bulb. Thus it was easy to find and replace a faulty bulb, but if you didn't do that quickly, then the increased voltage on all the other bulbs would cause another to fail, and soon there was the possibility of a nice big bang. ;)

So presumably these LEDs have an internal shunt regulator so that any that are "off" or "dim" still pass sufficient current for the "bright" ones to work. But there is always the issue of "spreads" or "tolerances"; what happens if one LED want to pass 15 mA (or drop 5 volts) and another wants to pass 14 mA (or drop 5.5 volts). I guess they must have a resistive characteristic, so that they can reach some "consensus" on the overall voltage or current.

Thanks flenser for that additional timing information, which I was sure had to be "necessary". It looks a little fast for a PICaxe, but should be possible at the higher or highest clock frequencies.

Cheers, Alan.
 

grim_reaper

Senior Member
Wow! I didn't expect that conversation to carry on into the weekend with such vigour! Curiosity has beaten my reluctance to release the moths from my wallet, so 5 of the LEDs will be arriving here on Monday :D

I shall of course be experimenting with caution, at 5V, with a meter and oscilloscope on every component before, during and after it's added!
 

AllyCat

Senior Member
Hi,

Ah, that will be interesting. I think that I now understand the Data Sheet:

The first "Data Format" diagram is like a "scope" waveform, i.e. the transmission sequence is 1 0 0 1 ...etc.. (but the binary representation has acquired a spurious 1 in the data sheet). However, section 2 and the "waveform" in 3 are NOT like a 'scope, but read from right to left, i.e. the "signal" is considered to "move" from left to right (in the direction of the "arrow") and we should "read" the signal as it passes under an imaginary "cursor" on the right hand side. Thus the first bit transmitted is the MSB of Blue 0 and finally it's the LSB of Red for whatever is the last LED number. Then, the LED numbers, DI and DO, the binary representation (MSB...LSB) and Latching the data after it is received, all make sense. :)

Personally, I haven't managed to find any data sheet which includes that vital tiiming data from Flenser. It will be quite tricky if the 100 us bit period is an absolute maximum limit, but we don't know what timing ratio between the "logic" (pulse) level and the "bias" (mid) level is acceptable (the diagram appears to show it as 1:1). I think the following "linear" code will just achieve the 100us bit period (with the "two pin" method):

Code:
#picaxe 08m2
#no_data
setfreq m32

low c.1
high c.2
pause 10000
do
 high c.1    ; Logic 1
 low c.2
 low c.1     ; Logic 0
 high c.2
; etc...  for a total of 24 bits per LED
 pause 3000      ; Latch period (or could prepare data for the next frame)
loop
Provided that the "bit pulse duty cycle" doesn't need to be 1:1 then a PULSOUT ... can be a little faster than a high : low (or high : input) but it's going to be quite difficult to create a tight looping program and/or to read and send varying bits or bytes within that 100 us bit period. So one of the necessary tests will be to see how critical is that 100 us period.

Cheers, Alan.
 

grim_reaper

Senior Member
Just a quick update while I get over the excitement of getting it all working and start documenting it properly. Did I already mention it works?!
Basically, what Alan said in post #17 in his first paragraph is correct, along with Westy's bulk of knowledge on the subject earlier - the data goes in one end and comes out the other - i.e. they're just shift registers. I've yet to determine whether it's MSB or LSB first, but it's in the BGR order, so MSB first is probably right.

I started off at 32MHz (code to follow soon) and struggled to get anything to happen. Then I put my finger on it - literally - I touched one of the resistors and the LED lit up! It turns out that it's more fussy about the 'mid-voltage' being exact than anything else. I put a variable resistance into the circuit so I could tune it to exactly 2.5V and voila, it started sequencing as per my test code. Being curious about the data Flenser found, I then dropped the clock speed. I'm back down to 4MHz now, and it's still running, so seems to care not a jot about the timing.

Attached is an image of the waveform put out for green. You can see the width of each set of pulses takes about 13ms to 16ms - and there just happen to be 16 lines of code, which seems more than coincidence! So we're talking about 2ms per pulse, waaaay over the previously discussed 100us! I guess it's as simple as the clock on a shift register; still works even if you clock it slowly.

RGB Test (G).png

Grim
 

newplumber

Senior Member
@ grim_reaper yes me too is looking forward to your set up and code
so would be sweet to post a setup pic/schematic and code unless of course your patenting it
 

hippy

Technical Support
Staff member
@ grim_reaper : It would be useful to see your code and your exact circuit used.

I tried controlling one of these OST4ML5B32A but I am getting all sorts of odd behaviour; flashes of wrong colours when changing colour, sometimes wrong colour completely, and horrendous flickering when fading a colour.
 

AllyCat

Senior Member
Hi,

I am getting all sorts of odd behaviour;
I'm not surprised, particularly with that data sheet. ;)

It's basically a "self-clocking" SPI-type system, which is very common for example in "Wireless" links. But normally the '0' and '1' values would be signalled by "long" and "short" pulses (typically 0.5 and 1.5 ms in a 433 MHz system). It is easily decoded with a (software) counter or a (hardware) monostable: The leading edge acts as a "clock" and the falling edge reads or latches the time delay "data" that occurred.

The problem here is that the interface appears to be designed to work over an enormous (undefined) range of pulse widths, so it instead uses a "three level" interface protocol*, However, the (relative) durations of the "pulse" and "centre" periods are not defined (in any data sheet that I've seen), which creates major "issues" in its behaviour if there are long sequences of '1's or '0's.

Generally, I still consider my "specialist" experience to be in analogue hardware design, but I'm not sure how I would design a circuit to reliably detect that data format, at least from the specifications I've seen so far. :(

* Actually a two-level protocol is still possible over large time ranges; for example it can be done with an up/down counter (in hardware or software) to determine the mark-space ratio.

Cheers, Alan.
 

hippy

Technical Support
Staff member
The problem I am experiencing is not so much that it doesn't work but that the behaviour of the silicon is not as one would expect. They are shift registers, and the first set of 24 bit data is latched and output as expected.

What happens next is odd; I am seeing colour changes while the next set of data is being output. After that it is then held static as set, though there do seem to be occasional glitches in data which leave the wrong colour set.

It seems to be that once the 3ms latch signal is detected, the latched data is output - and then always output - so, as the next data arrives, the shift register changes, and that affects the LEDs themselves. A rough model of behaviour is -

Code:
            .-------------------.
            |       Buffer   OE |<--.
            `-.....-.....-.....-'   |
              ||||| ||||| |||||     |
            .-^^^^^-^^^^^-^^^^^-.   |
Data ---.-->| DIN           DOUT|---|--->
        |   `-------------------'   |
        |                           |
        |   .------------.   .---.  |
        `---| 3mS Detect |-->|S Q|--'
            `------------'   |   |
            .------------.   |  _|
VIN --------|  Power On  |-->|R Q|
            `------------'   `---'
This means one cannot change from $FF,$00,$00 to $FF,$00,$00 without a LED also seeing and outputting $7F,$80,$00, $3F,$C0,$00, $1F,$E0,$00 etc. There's a blast of 23 colours until it's back to what it should be.

My theory is that this is how they are meant to work and would work in mains-powered Christmas tree lights. In that case mains cross-over will kill power, clear the OE latch, and then they can be updated to the right colour before that data is latched. There's a short off time but that won't be noticed as such.

To update without the blast of colour changes doesn't seem possible unless the power to the LEDs were being switched to force the reset, to mute the stream data affecting things until the first latch.

But no one else ( here or elsewhere ) seems to have mentioned this issue so am not sure if this is correct or not. Hence it would be nice to see other people's code to see how that performs.
 

hippy

Technical Support
Staff member
I'm wondering if that "3ms latch time" at the end of the bit stream is actually 3ms, or a typo ?

The reason I say that is because a longish mid-voltage time after a high or low could be causing a latching after each 1 or 0 bit sent, after every shift register shift. Which is what I believe I am observing.

It certainly seems plausible. If the PICAXE is "wound up to 11" ( 64MHz on a 20X2 ) and the mid-voltage time between bits is reduced there are fewer wrong colour flashes as the data is transferred.

If the pulses are supposedly meant to be 100us as was suggested earlier, then 300us, 0.3ms, could make sense. It could even be less than that.

I am also wondering if they aren't some 'WSxxxx' type clone with a different input interface but with similar tight timing. It may be working as well as it is despite the design rather than because of it.
 

grim_reaper

Senior Member
Still sitting on a breadboard with very basic code I'm afraid... work, family and being sick have absorbed all my time this week!

There is a slight issue with the LEDs, which I'm not sure of the source of, where they appear to be set to a random colour for a split second before the chosen colour is displayed. Might need some help with debugging that - it's next on the project list, but please be patient.

EDIT: Sorry, didn't even notice the comments on this page! Yes Hippy, that's the same problems I'm having - the transitions between colours.
 
Last edited:

Flenser

Senior Member
I'm wondering if that "3ms latch time" at the end of the bit stream is actually 3ms
Hippy, you could have hit the nail on the head here.

This blog post https://cpldcpu.com/2014/01/14/light_ws2812-library-v2-0-part-i-understanding-the-ws2812/ describes exactly this same issue for WS2812 LEDS. i.e. the datasheet describes the "low voltage time" for latching the last set of values as "Above 50uS" but when the time required to latch was measured the minimum value was actually 8.95 µs, way below the 50uS specification.
 

hippy

Technical Support
Staff member
There is a slight issue with the LEDs, which I'm not sure of the source of, where they appear to be set to a random colour for a split second before the chosen colour is displayed.

Yes Hippy, that's the same problems I'm having - the transitions between colours.
That is good news - at least in it meaning it's more likely a systemic problem, not just an isolated issue which I was having.

It's a pain but at least a static colour can be set. So as long as the LED is being used as an infrequently changing status LED or similar, and when any flash is not too inconvenient, it may be usable, especially as it offers more colours than one can get out of a traditional two colour LED.

I'm wondering if that "3ms latch time" at the end of the bit stream is actually 3ms
Hippy, you could have hit the nail on the head here.

This blog post https://cpldcpu.com/2014/01/14/light_ws2812-library-v2-0-part-i-understanding-the-ws2812/ describes exactly this same issue for WS2812 LEDS.
I am coming to the conclusion that may well be the issue. Everything else would then work as expected and as described by the datasheet. My mains-crossing reset theory may have been a red herring.

I think the 3ms may describe how long it can be before the LEDs are updated, but it could be sooner. Hence; that's how long one should leave between updates, not how long one should idle before it is latched. What's the betting that's actually 2.56ms, tied into the PWM'ing of LED brightness, plus some manufacturing tolerance ?

I think what happens is the LEDs are updated from the shift register whenever the PWM counter hits zero providing there has been a short period of data idle. For the PICAXE that period is shorter than the bit idle time but an actual update doesn't necessarily occur after every bit. The 'blast of colour' isn't every 24 bits but less frequent than that. This would explain why there aren't always flashes; if an update falls between the PWM hitting zero cycles; no flash.

This would also fit with people using the LED with other micros which have higher output rates not seeing the issue.
 

hippy

Technical Support
Staff member
I think what happens is the LEDs are updated from the shift register whenever the PWM counter hits zero providing there has been a short period of data idle.
I now have a more refined theory.

I think data is being latched after each data bit as it passes through the shift register. PWM counters are running for each colour; 255 down to 0 and lighting the LED while the brightness set is above the counter value.

So, as data passes through the shift register, it is latched on every shift, that changes the latched brightness which the PWM counter is compared with. This will turn a LED on or off or leave it set as it was, may flash it on and off as the bits shift. A shift moving one LED brightness from %0xxxxxxx to %1xxxxxxx can cause that LED to instantly turn on, that could lead to a predominantly white flash when done at high speed which is what is being observed.
 
Top