I am working towards updating an old ible which uses 12 4 pin common anode RGB LEDs.
My aim is to update the build using WS2821B LEDs. I am programming and prototyping using a UNO R3 while the actual light fitting uses a self built "hackduino"
Due to the current LED Enclosures (glass Oringina bottles) I think I am going to need to put two WS2821B Leds back to back to create each pixel.
Is it possible using the FastLED Lib (ideally) to treat concurrent pairs of LEDs in an array as single pixels for programming effects? In other words to light LED 0&1 together as pixel 1, 2&3 together as pixel 2 etc to create 12 "sudo" pixels out of a strand of 24 LEDs?
An example being to "chase" or sequentially turn on then off each "sudo" pixel pair in turn along the strand.
If this is feasible then any guidance on how to implement this would be greatly appreciated as an older bloke teaching himself Arduino for gits & shiggles.
Ultimately if this does work then it might be fun to have two individually addressable LEDs in each light enclosure for half & half in one one rather than in adjacent enclosures.
My limited knowledge leads me to think that maybe defining some sort of matrix might be a potential solution (2 rows x 12 columns).
If it helps, I have simulated the original build in WOKWI as it supports common anode RGB LEDs (TinkerCAD is common cathode only) to tinker with (setting more usable variables and start commenting the sketch (WIP)).
I realise the original code probably be uber optimised but it is a useful learning experience for me nonetheless.
The current timings are set quite fast compared to the original code to speed up the simulation (I was having issues when looping back to the initial R, G, B fade).
It is very easy to group LEDs programmatically with some relatively simple code. Once you define the essential task, which is to replicate something n times which should be a clue to use a 'for' loop. A simple logic would be:
for all leds in sequence
{
for the size of the led group
{
set group colour
}
}
That can be set up with simple indexing, so start with led 0 and write out the group size number of leds, at the appropriate times incrementing an index to the current led number.
If you are hoping to run existing effects or animations through this mechanism, your first stop would be the documentation for the display library you are using to see if the library already supports grouping.
I presume he means something like a two pixel piece of a LED strand folded over so that each LED shines in the opposite direction. Now to use the six bottles as one strip would mean running the data from the first back along the pendant cable (4 wires) and into the next. This would also mean a 330 Ohm resistor in series with the "DIN" of each two pixel piece.
The original question is whether the FastLED library facilitates treating pairs (or larger groups) of LEDs in the chain as single "pixels". I myself do not know having not used it. The alternative is the Adafruit library and I don't know for that either.
Now if you are totally sure you never want to treat the two "back-to-back" pixels separately, then you simply connect the data in to both "DIN" in parallel and take the "DOUT" from only one of them to the next module.
Thank you for your reply. I shall investigate further.
As mentioned in the OP my aim is to use the FastLED Library.
I do not plan re-working the original effects (designed for 4 pin analogue LED's) from the original ible into some more "modern" effects facilitated by W2821b's
Thank you for your reply. I shall attempt to elucidate further.
Due to the way the light is (currently) dissipated by a single 4 pin RGB LED regardless of a frosted or sandblasted finish to the exterior of the bottles, I think I might (not 100% sure yet) need to use two W2821b's back to back as Paul _B has correctly surmised.
The W2821b strip I have is cuttable and has a self adhesive backing which should allow two LED's/pixesl to be stuck back to back then connected together in series via the solder tabs if folding them causes contact failure/snappage.
You are spot on about the back to back arrangement.
The wiring is not a major issue as i already have the completed and working unit built (a few years ago in fact) based on the original instructable (so each enclosure currently has 4 wires) so we are talking 12 bottles & 24 LED's)).
Your advice for a 330 Ohm resistor for each "sudo" pixel is for reducing noise on the Data line? I thought just one resistor would be needed as per "best practices"?
If I need 12 so be it but where should they be located? at the LED's themselves to scrub noise as it goes in?
I too know not if the FastLED lib facilitates treating groups/pair in discreet pixels hence my OP.
On reflection ultimately being able to treat each "sudo" pair as to individuals would be ideal for potential effects and learning
But to get up and running if I need two LED's per enclosure your suggestion of connecting the Din's and Dout's is Genius and a perfect example of the KISS maxim. So like me to over complicate and miss the simple solution. Thank you!
@ er_name_not_found Thank you also for your reply, I Believe Paul_B Has suggested the same physical solution.
Nope. Mine is a whole lot simpler. 2 strands stuck back to back that just share a single data wire, where as his is awesome but requires you to wire each pixel to its pair.
I have an existing pre-built fixture composing of 12 cables each going to a single enclosure/bottle.
Each cable has 4 cores/wires.
My understanding of Paul_B's solution fits 12 "strands" of 2 physical LED's to create 12 "sudo/pair" pixels. Din at top of each "sudo/pair" Dout at bottom of each pair so the sketch would call LED 0 but light physical LED's 1 & 2 in enclosure/bottle 1 then call LED1 to light physical LED's 2&3 in enclosure/bottle 2 and so on. 12 physically discreet LED pairs compatible with existing cables.
My understanding of yours, now, is 2 "strands" of 12 LED's uncut, stuck back to back with Din at the top of both strands Dout at the bottom. The physical limitation of the build means I need 12 physically discreet pixels. 1 pixel (or pair) going to each enclosure.
I understand visiting external links provided in help requests is frowned upon but in this case the instructables build pictures might help. just visualise 2 ws2821b LED's for every 4 pin RGB common anode LED in the build.
What ever gave you that idea? It is not.
However be aware that instructables has a very very very poor reputation as a source of good electronic design. They seem to be written by people who have an exaggerated view of their own ability.
The thing that is not clear is are you using 5mm WS2812 LEDs or are you using the surface mount strips?
Assume you are using the surface mount strips then you might be best to cut then in small strips of 2 LEDs and then fold them in half. This will give you the three connectors at the same end of the pair but on different sides of the strip. The power and ground could then be wired together, but the in and out would have to be separate. That might prove physically to be a difficult task, I would not trust the adhesive coating to insulate the two sides, I would add a piece of paper between them.
The resistor that @Paul_B recommends would be put on the data out pin before it goes to the next bottle. It is not used to "clean up noise", but to prevent the generation of noise, the two things are very different.
Erm The How to get the best out of this forum General Section - "partly because we feel that if you want our help you should provide everything we need on this site not expect us to go hunting elsewhere for it."
Hence I was reticent to provide a link to the original project but yolo.
To clarify, I am going to be using non weatherproofed, adhesive backed surface mount WS28122B strip rather than loose 5mm LED packages.
I`m still unsure about the suggestion to use 12 noise prevention resistors on what effectively be 1 Data wire. Is it because of the length data wires going down to each bottle as Din then ascending as Dout to become the next Din at the next drop to the next bottle?
What is generating the potential noise and why does it not appear to be a factor on every single strand example I have seen using a single resistor? (just curious, not trying cast doubt)
I think a dimensioned drawing of the lengths involved would be helpful. Or at least a list of measurements. Because, the resistors are mostly added to compensate for longer (further apart) connections. Sometimes everyone feels they are on the same page but no, because of some communicative oversight or assumption not always. If it's an existing strip all the way, with LEDs at regular millimeter to several cm intervals and so on, then resistors are only needed in the wiring between strips.
Disclaimer - I've never tried daisy chaining strips. But I have driven a panel of 256 NeoPixels.
It can make a designer's accountant squirm but you can always leave pixels turned off if you don't need them. Just my $0.02. That can get you out of some mechanical design problems. At least they don't use much power.
@anon57585045 Here is a list of the cable lengths... 8.5" ,10" ,11.5" ,13" ,14.5" ,16" ,17.5" ,19" ,20.5" ,22" ,23.5" ,25"
therefore for each cable the Data wires are going to be at the very least twice that length as there needs to be more on top of the base for the wiring loom.
The existing loom will require modification to bus together the cable cores being re-provisioned for 5v & GND while the Din and Dout cores can be joined between each cable drop. I cannot remember the spacing between each cable drop (not specified on the original template) but they are probably around 4 or 5"
TL DR there is a significant distance between each pixel/LED pair
Are you an native English speaker? I ask because those words from the guide do not lead to the conclusion you reached from them. They mean exactly the opposite of your conclusion.
When it says :-
It means that, for example, you say I am following the tutorial by G. I. Joe, then you should supply a link to that tutorial, and not expect us to search for that tutorial. Mainly because he might have written many on the subject and we don't know which one you are following, but also this takes time and that name might not be unique.
The signals are fast with square edges, therefore this contains lots of high frequencies. This means that the wiring has to be considered as a Transmission Line. When a signal edge is sent along a wire and it reaches the far end of that wire, unless the impedance of the termination, matches exactly the impedance of the transmission line, that edge will be reflected back, and will interfere ( as in constructive / destructive interference ) with the next signal coming along. It will indeed reflect off the the start of the wire again. This effect is used in time domain reflectometry.
The resistor is there to absorb these reflections, the longer the signal wire the more reflections you get, which is why it is not a problem for short distances, but is a problem for the first LED in a strip which is normally some distance away from the source.
Here is a picture of an oscilloscope trace of using / not using a series resistor with a WS2812 LED.
When driving a strip you only need to consider the wire ( transmission line ) between the Arduino and the strip, for all the LEDs on the strip the connection distance is too small to matter.
I have seen projects that (correctly) do this when chaining strips together especially when the strips are some distance apart. A typical project like this might be for Christmas lights covering a house.
There is a lot of crap tutorials and projects on the net written by people who don't know what they are doing and think because what they have thrown together is fine, because "it works". They don't even own an oscilloscope so they don't know anything is wrong, or how close it is to breaking, or attribute problems to other things like power supply issues.
It is less critical at which end of the wire the resistor is put because it acts like an impedance matcher for the whole line.
Yes, I am a native english speaker.. in fact I am English. I have however been around Forums long enough over the years to see plenty of new forum users fall foul of not following advisory protocols.
Maybe i should have quoted the other section of the General Section thus:
"Please try to avoid posting links to other sites where code or photos or schematics are hosted. Most of us will not follow such links, partly due to the risk that they hold malware or other unwanted content"
Anyhoo, none of the above is really pertinent to the topic at hand.
Thank you though for the clarification on the noise prevention - a picture is worth a thousand words as they say.
