making LEDs strobe in pattern with other leds

Projects Programming
1

okay I'm sure by now most will recognize my name here and I hope I'm not annoying anyone with my repetition, but I have time now again to work on my design.

I need to make a string of "X" led "UNITS" to blink in a pattern such as inside to outside (and vice versa), left to right chase(and vice versa), 1/2 and 1/2 alternating (Just to name a few)

X = 1-10

My problem is the "blink" with digital delay is not effective for 10 individual units blinking in different sequences blah blah blah, I know there are other options to code it but I'm not in full understanding of how they work and how to package it so I don't have massive amounts of code to sort though when making changes.... yes in know these are newbie questions but I'm trying to work on this while taking care of my newborn, working full-time and training for my firefighting future.

I have a technical/ programming requirement however,

the first "UNIT" will be connected to a main CPU
each unit will be attached to each-other but needs to communicate back to the CPU to tell it another unit has been plugged in and in turn add that unit to the pattern

example.
if I have two units connected to each-other, unit one is connect to unit two and the main controller and unit two is only connected to unit one.
if i add 2 units and connect them to unit two the pattern changes to incorporate the new units.

I've attached a picture to show what I mean

nova 1.png
nova 1.png992×237 1.16 KB

2

I don't think you've really thought this through. Geometrically defined linear sequences can't really be defined by their boundary (or edge, if you like) conditions. In other words, a module can not guess what the inner LEDs in a neighbor module is doing by only looking at the end point LED's.

3

so there's no way to have a module understand when another is connected to it? then relay that information down the line building until it reached the main unit?

in other words- in a sting of 4 the end unit that's only connected to another unit tell unit 3 to add+1 and have unit 3 relay to unit 2 to add +2 and unit 2 relay +3 to unit one which would tell the CPU a total of 4 units in the chain.

nova 1.png
nova 1.png992×237 3.55 KB

i don't see why this couldn't be possible.
each unit would have a 8 pin comm port (8P8C modular connector) so if that helps the ability to do so?

nova 1.png
nova 1.png992×237 3.55 KB

4

nova 1.png
nova 1.png992×237 1.16 KB

I can think of a way that might work with up to 8 units. It might be possible to extend this to 16 units.

Each unit would contain an i2c i/o extender chip, such as pcf8574. Each one wired so that it has a unique address on the i2c bus. Each chip would dedicate 2 of its pins to establishing the sequence that the units have been connected in. One pin acts as an input and is connected to a certain wire from the "in" connector. The second pin acts as an output and is connected to that same wire but on the "out" connector. At startup, the Arduino detects how many units are connected to the i2c bus and each unit's address, using the "i2c scanner sketch" technique. The Arduino then outputs a HIGH to the sequence wire to the first unit. It then reads data from each unit to find out which unit has picked up the HIGH signal. This unit is the first in the chain. It then writes data to that unit, so that that unit outputs a HIGH on its sequence output. The Arduino then reads the remaining units to find out which of them is now receiving the HIGH signal. This is the second in the chain. And so on until the position of each unit has been established. The Arduino then records the sequence in its memory and begins the display.

5

There are ways to do this, but it is a steep learning curve if you haven't don it before.

Basically at power on, the host has a map of the clients, then interrogates the client buss.
The first unit responds, and if it's the same as the mapped ID, it's confirmed by the host.
Then the next interrogate 'message' is sent.... passed by the first client on up to the next client, and so on.
This requires using a non-volatile static map in the host, as well as using EEPROM in the clients to store their unique local ID and personality - as well as a token (a unique ID like a MAC address) that matches the mapped host expectation.

If any of the interrogations fail, the clients are told to release their known position in the host map, then the acquisition is restarted from that client.

This allows devices to be arbitrarily added or replaced on a single daisy-chain control bus, while letting the host remain aware of where each device sits on the chain.

We used this system on chains of up to 255 devices connected by RS422 in a telco headend.

There are several distinct management processes involved for different circumstances.
INITIALISE
ACQUIRE
VERIFY
and SEND/RECEIVE from a particular node in the chain.

This strategy could be applied to any daisy-chained topology with intelligence and EEPROM at the client nodes.

6

This sounds sort of like the patterns running on the LEDs that Daft Punk uses on their helmets. I wrote an example for someone a while back which blinks several sets of LEDs in sequences. It only lights one LED per group but maybe it will provide a useful example. It was for an Arduino UNO so there can only be 19 channels. On a MEGA you would have many more channels. Alternatively you could use addressable LEDs and use addresses instead of pin numbers.

const int CheekPins[] = {
  3,4,5,6,7,8,9,8,7,6,5,4};  // gives forward and back
const int CHEEK_COUNT = sizeof CheekPins / sizeof (int);
const int CheekIntervals[] = 
{
  300, 300, 300, 300, 300, 300, 
  300, 300, 300, 300, 300, 300} 
;  // Milliseconds
unsigned long CheekTime = millis();
int CheekStep = 0;

const int ChinPins[] = {
  10,11,12,13};
const int CHIN_COUNT = sizeof ChinPins / sizeof (int);
const int ChinIntervals[] = {
  300, 300, 300, 300} 
;  // Milliseconds
unsigned long ChinTime = millis();
int ChinStep = 0;

void setup() 
{
  int i;
  /* Cheek LED's */
  for (i=0; i< CHEEK_COUNT; i++)
    pinMode(CheekPins[i], OUTPUT);  // Yes, it's OK to set the pinMode twice on some pins

  /* Chin LED's */
  for (i=0; i< CHIN_COUNT; i++)
    pinMode(ChinPins[i], OUTPUT);
}

void loop()
{
  // Do the cheek animation
  if ((millis() - CheekTime) > CheekIntervals[CheekStep])
  {
    CheekTime = millis();
    digitalWrite(CheekPins[CheekStep], LOW);
    CheekStep = (CheekStep+1) % CHEEK_COUNT;
    digitalWrite(CheekPins[CheekStep], HIGH);
  }

  // Do the chin animation
  if ((millis() - ChinTime) > ChinIntervals[ChinStep])
  {
    ChinTime = millis();
    digitalWrite(ChinPins[ChinStep], LOW);
    ChinStep = (ChinStep+1) % CHIN_COUNT;
    digitalWrite(ChinPins[ChinStep], HIGH);
  }
}
7

@lastchancename that sounds much more complicated than my suggested solution. Can you see some flaws in my approach?

8

It IS more complicated... but shows what can be done with smart daisy-chained serial devices. Your requirements don't need different types of interchangeable devices or reading back data values...

For a simpler example - look at how the WS28xx RGB LEDs & drivers work.
You don't have to use a 1-wire interface if the timing is tricky to maintain, but if you understand the idea of 'take a message and pass the rest along' - it may help develop your solution.

9

lastchancename:
There are ways to do this, but it is a steep learning curve if you haven't don it before.

Basically at power on, the host has a map of the clients, then interrogates the client buss.
The first unit responds, and if it's the same as the mapped ID, it's confirmed by the host.
Then the next interrogate 'message' is sent.... passed by the first client on up to the next client, and so on.
This requires using a non-volatile static map in the host, as well as using EEPROM in the clients to store their unique local ID and personality - as well as a token (a unique ID like a MAC address) that matches the mapped host expectation.

If any of the interrogations fail, the clients are told to release their known position in the host map, then the acquisition is restarted from that client.

This allows devices to be arbitrarily added or replaced on a single daisy-chain control bus, while letting the host remain aware of where each device sits on the chain.

THIS IS EXACTLY what I need, the ability to use a single module identical to another communicating its position to a CPU . if that unit is removed the cpu would read that its not there and adjust accordingly !

A couple questions!

  1. would would i need to have on each end to read and communicate this "daisy chain" effect?

  2. how many pinouts would I need to dedicate to this feature or would I be able to send other information such as colour data and flash pattern data?

  3. would this allow for all modules to sync or unify its timing so that they maintain pattern with each other. In my experience running to pre-progamed units side by side they may be off by a couple milliseconds each. the problem is when you are doing a ton of flashing (200-1000 mills each) it will start to compile and make them flash off-timed. im guessing they should work perfectly fine . i have made a diagram to explain exactly what im trying to achieve as an end goal

nova 2.png
nova 2.png845×231 4.3 KB

nova 2.png
nova 2.png845×231 4.3 KB

10

I must admit over recent months, I've been thinking of writing this code for Arduinos - but never had the application.
You do need a comms and application processor at each client node (could be combined in a single chip) - the type depends on what each node is required to do.

For what you're trying to achieve, an AVR/MEGA type chip is probably enough (make sure it has two hardware UARTs - one upstream & one downstream).

The host could be anything fast enough to send and receive the commands & NV RAM to maintain the client map. It could be Windows, but, probably easier to develop with another AVR/MEGA sized chip.

The easiest wiring scheme would be ground, a tx/rx pair (RS485/422 for longer distances), and DC power (which should be injected at each client node if the load is significant). Three wires, or 5 wires if power is also bussed around.

I would do this today with a MEGA-128 or 256 (to get the UARTS). SoftSerial wold be a hassle if you hit reliability & timing problems. The board could be home-brew or an Arduino MEGA - with lots of I/O as a bonus.

Aside - all the comms node are effectively identical - except that during assembly - the client would be flashed with the unique 'MAC address' and the specific functionality 'ID' if there are different types of client. (e.g. RGB LEDs, display, servos, beeper/buzzer/audio player etc.)

11

lastchancename:
I must admit over recent months, I've been thinking of writing this code for Arduinos - but never had the application.
You do need a comms and application processor at each client node (could be combined in a single chip) - the type depends on what each node is required to do.

For what you're trying to achieve, an AVR/MEGA type chip is probably enough (make sure it has two hardware UARTs - one upstream & one downstream).

The host could be anything fast enough to send and receive the commands & NV RAM to maintain the client map. It could be Windows, but, probably easier to develop with another AVR/MEGA sized chip.

The easiest wiring scheme would be ground, a tx/rx pair (RS485/422 for longer distances), and DC power (which should be injected at each client node if the load is significant). Three wires, or 5 wires if power is also bussed around.

I would do this today with a MEGA-128 or 256 (to get the UARTS). SoftSerial wold be a hassle if you hit reliability & timing problems. The board could be home-brew or an Arduino MEGA - with lots of I/O as a bonus.

Aside - all the comms node are effectively identical - except that during assembly - the client would be flashed with the unique 'MAC address' and the specific functionality 'ID' if there are different types of client. (e.g. RGB LEDs, display, servos, beeper/buzzer/audio player etc.)

**each "node" or unit i refer them to, is going to need to have a pattern memory to use without an serial input thjat would be read once power is applied, to use with or without a CPU unit (or "host" as you refer to it), would be for standalone units and would be a simple flash then a quick flash. nothing complex. **
The "nodes" would be R,G,B,W leds only flashing with a total Amp draw of about 3 A @ ~12 V, only white would be steady at full power and the rest would be able to do a steady on at 1/2 power using a PWM.
Other then that just the ability to "map" its position and use that against a "flash pattern model" from the CPU "host"unit. as shown with the red blue diagram where the left 1 is red and the right 1 is blue,,, adding 2 more would make the left 2 blue and the right 2 red
the "host" was planning on being something like the mega board, it need to have a touch screen ability to program the physical buttons on the host unit to do different commands such as change pattern, colour and assign a group (one string of leds that use the same pattern and colour there will be a max of 10 "groups" of leds)
i have the main lay out of the board in mind and the slave units but i still need to know what chips to use to allow the positioning and communication of colour, pattern, location and brightness level.
ADDITIONALLY this is going to be made for VOLUNTEER emergency services so any help is supporting your local emergency services!

12

You are probably going to suffer a lot less by simply using addressable RGB LEDs like the WS28xx family.

Take some care with the signal wiring and power lines - then you dont have to reinvent the wheel.

If you have different types of device on the chain, then hard-wired addresses, or something like that described above - which seems like overkill for a semi-permanent small-scale application like you have described

13

lastchancename:
You are probably going to suffer a lot less by simply using addressable RGB LEDs like the WS28xx family.

Take some care with the signal wiring and power lines - then you dont have to reinvent the wheel.

If you have different types of device on the chain, then hard-wired addresses, or something like that described above - which seems like overkill for a semi-permanent small-scale application like you have described

i would suffer alot less BUT i already have the led choice and the leds you have mentioned do not create enough Cd and Lux for my application and NO i WILL NOT suffice with using an array of them to increase their outputted light

appreciate the ideas but the intended purpose for these is very regulated and controlled and i cant dieter away from my design as i already have the preliminary approval biased on the overall theatrical output

14

You know that WorldSemi also make a chip only driver - without the LEDs...
You can tack on your own MOSFET and drive whatvere LEDs you want.

Take a look here

15

i would suffer alot less BUT i already have the led choice and the leds you have mentioned do not create enough Cd and Lux for my application and NO i WILL NOT suffice with using an array of them to increase their outputted light

In that case, you can use the bare neopixel controller chips.

WS2811 NeoPixel LED Driver Chip - 10 Pack : ID 1378 : $4.95 : Adafruit Industries, Unique & fun DIY electronics and kits . $5 for a 10-pack .

Each WS2811 has three output channels and will drive a smallish common-anode rgb led. If you need more power, run each output into a logic-level MOSFET and drive anything you like. If your lights are just single-colour, you could hook three lights to a single chip, and individually control them.

The point being - you'd use the adafruit library, programming is relatively simple, and you can chain these suckers out to any length you want.

each "node" or unit i refer them to, is going to need to have a pattern memory to use without an serial input thjat would be read once power is applied, to use with or without a CPU unit (or "host" as you refer to it), would be for standalone units and would be a simple flash then a quick flash. nothing complex.

Oh. Well, in that case you are looking at supplying a microcontroller for each node. Several options:

Use an ATTINY and WS2811s.
If you are only interested in on/off and don't need the full 8-bits to control brightness, an ATTINY and some shift registers will do.
If you need brighness control AND you don't want to have external electronics, you will need something with enough analog outputs to drive everything. But even so, you are going to need external electronics to supply the power you want, so meh.

As to the whole daisy-chaining thing to program the items, i2c does seem to be the way to go. Maybe. But you'd have to make up some weird protocol. And what are you doing for a user interface? I mean, ok - you plug these submodules in and the master becomes aware that they are present. Then what? You have a button on your console that says "Tell every module that is currently connected that it needs to flash in pattern A"? I suppose that's do-able.

16

In that case, you can use the bare neopixel controller chips.

WS2811 NeoPixel LED Driver Chip - 10 Pack : ID 1378 : $4.95 : Adafruit Industries, Unique & fun DIY electronics and kits . $5 for a 10-pack .

Each WS2811 has three output channels and will drive a smallish common-anode rgb led. If you need more power, run each output into a logic-level MOSFET and drive anything you like. If your lights are just single-colour, you could hook three lights to a single chip, and individually control them.

The point being - you'd use the adafruit library, programming is relatively simple, and you can chain these suckers out to any length you want.

**The problem is my leds are 4 input, RGBW and would need to be able to produce a combined amber/yellow color using red/green **
would using a PIC12FF157X work? its used here for a RGB chip similar to what im using
**Three Watt Individually Addressable RGB LEDs | Hackaday **

Use an ATTINY and WS2811s.
If you are only interested in on/off and don't need the full 8-bits to control brightness, an ATTINY and some shift registers will do.

I will need to control brightnes at a 25% 50% and 100% level not like a full wave 100-0%

If you need brighness control AND you don't want to have external electronics, you will need something with enough analog outputs to drive everything. But even so, you are going to need external electronics to supply the power you want, so meh.

Each individual will take a 12V in and internally drive the leds, the power will come right from the control unit or a 12V power supply.

As to the whole daisy-chaining thing to program the items, i2c does seem to be the way to go. Maybe. But you'd have to make up some weird protocol. And what are you doing for a user interface? I mean, ok - you plug these submodules in and the master becomes aware that they are present. Then what? You have a button on your console that says "Tell every module that is currently connected that it needs to flash in pattern A"? I suppose that's do-able.

the interface is a touchscreen to on the fly program/change light colour output and other "groupings". to explain a little further, the control box will have several outputs for data, each one is a "group" which you would assign its own pattern, colours and settings.
ie. outputOne is a left to right chase while outputTwo is a 25% steady on.
the main user interaction will be a set of physical buttons which will be programmed by the touch screen interface.
i.e. buttonOne will change the pattern of group 1,3,4 , buttonTwo will turn everything off buttonThree will turn groupOne off while leaving groupTwo on

17

BTW for synchronous function in diverse nodes, it is common to 'pre-load' the nodes with their unique pattern/logic - then use a common heartbeat on the comms line - so they all trigger at the same time.

A variation on this is deferred commands - using a future time programmed in each node (ahead of time) to trigger the event when that time arrives over the heartbeat/sync-clock.

These methods are often used to eliminate delays caused by propagation or processing in the nodes.

18

that is the plan, basically each node gets its information on what to do, then the comms line will supply a timing or "heartbeat" for the nodes to sync to

19

I will need to control brightnes at a 25% 50% and 100% level not like a full wave 100-0%

Ok, so you need something smarter than just a shift register.

If you want four lights in a module, then you need 16 analog outputs (which operate some mosfets or something to supply 12v power).

(let's just delete the stuff I wrote while googling :slight_smile:

You know - a few WS2811s will still do the job you want. They are only three channels each, but the channels are just chained together in sequence R-G-B. If you get 6 of them, that will provide your 16 analog outputs fro one module. The adafruit library contains support for RGBW led strips, so just wire them up

Chip: R G B R G B R G B R G B R G B R G B 
LED : R G B W R G B W R G B W R G B W

and explain to the neopixel library that it is operating an RGBW strip. The library provides every combination of sequences as constants (NEO_WBRG , NEO_WBGR, NEO_RWGB, NEO_RWBG, etc) so one of them will certainly match however you have wired your lights up.

The pinout is dead simple: https://cdn-shop.adafruit.com/product-files/1378/WS2811.pdf. You will have to solder SMD chips for your prototype, but meh: watch a youtube tutorial on how to do that.

I'm moving away from i2c as your data bus. It would probably be easier to use serial - define a pair of SoftwareSerial objects (upstream and downstream). Read from upstream, copy everything to downstream. Simple, assuming that if you plug multiple modules into your programmer, you are just wanting for all of them to be the same.

So in total, you need 5 pins - four serial, and one for the LEDs. A $20 Teensy will be ample to drive a module. Add $3 for the six WS2811s, and a few cents for the mosfets and drain resistors. The controll stuff will cost less than your no-doubt expensive LEDs.

To connect your modules together while you are programming them, I'd suggest RJ45 four-conductor modular connectors. Telephone wire. It's easy to get, its standard, its cheap, tooling is not a proble, it's not going to weird people out, and there are enough conductors for ground, power, Rx and Tx. Job done.

20

PaulMurrayCbr:

I will need to control brightnes at a 25% 50% and 100% level not like a full wave 100-0%

Ok, so you need something smarter than just a shift register.

If you want four lights in a module, then you need 16 analog outputs (which operate some mosfets or something to supply 12v power).

In one "slave unit" there will be 1 set of leds doing the same thing acting in unison as ONE unit,
however you can connect up to 10 units together in a line
each unit can flash on its own getting information from the master controler in a pattern with the other units.
example units 1,3,5,7,9 are flashing red then blue every 1 second, while units 2,4,6,8,10 are flashing yellow and green every 2 seconds (just one example of many) each unit will both be provided 12VDC and send it forward to the next unit(if applicable)

(let's just delete the stuff I wrote while googling :slight_smile:

You know - a few WS2811s will still do the job you want. They are only three channels each, but the channels are just chained together in sequence R-G-B. If you get 6 of them, that will provide your 16 analog outputs fro one module. The adafruit library contains support for RGBW led strips, so just wire them up

Chip: R G B R G B R G B R G B R G B R G B

LED : R G B W R G B W R G B W R G B W




and explain to the neopixel library that it is operating an RGBW strip. The library provides every combination of sequences as constants (NEO_WBRG , NEO_WBGR, NEO_RWGB, NEO_RWBG, etc) so one of them will certainly match however you have wired your lights up.

The pinout is dead simple: https://cdn-shop.adafruit.com/product-files/1378/WS2811.pdf. You will have to solder SMD chips for your prototype, but meh: watch a youtube tutorial on how to do that.


I'm moving away from i2c as your data bus. It would probably be easier to use serial - define a pair of SoftwareSerial objects (upstream and downstream). Read from upstream, copy everything to downstream. Simple, assuming that if you plug multiple modules into your programmer, you are just wanting for all of them to be the same.

So in total, you need 5 pins - four serial, and one for the LEDs. A $20 Teensy will be ample to drive a module. Add $3 for the six WS2811s, and a few cents for the mosfets and drain resistors. The control stuff will cost less than your no-doubt expensive LEDs.


To connect your modules together while you are programming them, I'd suggest RJ45 four-conductor modular connectors. Telephone wire. It's easy to get, its standard, its cheap, tooling is not a proble, it's not going to weird people out, and there are enough conductors for ground, power, Rx and Tx. Job done.


**I already have the connector of choice which is an 8 pin Ethernet plug due to the locking connection and the readily availablity of them. if i can use this in a 5 pin config with chip reading that i can work with that(im not sure what standard chips will read with)**
**im also planning on using an FQP35xx mosfet for the power handling which would be switched by the chips receiving the serial input unless there is a better alternative.** 
__*does anyone know if the FQP series FETs will produce much EMI?*__
**power usage explained - 3A@~12VDC (0.7-1A@3.4v/led x3 in parallel and x3 in series)**
**the power is provided by 12VDC power supply (automotive battery with max 14.4v into the control and distributed from the control box to each "string" of led units) ** 
**im planning on using 22-18 awg power wire into the units** 
**would it be better to wire all 9 led/ unit differently so the amperage along the line stays down?**

thanks again for all the ideas and comments, im excited to have the first prototype done in the next week or so.