Sequential Taillight using Arduino Pro Mini (Thread Change from 555 Delay Timer)

[Falcon69]

So, I have been reading and trying to understand how a 555 timer properly works.  Now, I still have alot to learn, but I think I am starting to understand it.

Here's a schematic I am working on.

I tried to keep the BOM line count down, that is why I chose 10K trimmer pots for both timers.

Here's how I am hoping the circuit works...

R2 would be adjusted to ~9.62k which should have the ON time of 666ms while R6 would be adjust to ~4.81K which should have an OFF time of 333ms on the first 555 timer.
R4 would be adjusted to ~4.81k which should have the ON time of 333ms while R5 would be adjust to ~9.62K which should have an OFF time of 666ms on the second 555 timer.

Now, I'm hoping it would display the flashes as this...

D9	D10	D11	At Time Interval
ON	OFF	OFF	0 msec
ON	ON	OFF	333 msec
ON	ON	ON	666 msec
OFF	OFF	OFF	1000 msec

At time 1000, the 12V supply to the timer circuits would be cut-off, do to the flashing relay (not shown) and then the circuit would just repeat/reset when the 12V switches back to the ON position at Time of 2000 msec.

The Relays need to stay off until the Timer triggers them.

Are my Values correct? Will this work?

16V, 25V, or 35V Capacitors?
1/2W, 1/4W, or 1/8W resistors?
1A diodes okay? Schottky or regular?

Since the supply voltage for the Timers are switched on and off continuously from a flasher relay......is there anything that should be done to help protect the Timers from any type of possible damage?

I don't have a simulation program, and I've tried using the LTSpice...I just don't understand it.

With my calculations (resistor values), I have duty cycles of 33.3% and 66.6%...from my understanding, the 555 timers don't perform well under 50%.  what can I do about the 33.3% duty cycle from the second 555 timer?  I'd like to try and keep the Trimmer Pots all at 10k, and the Caps at 100uF.  That will keep my BOM Line count down.  The calculation shows also that that both timers will perform at 1Hz.

I also read that the dip packages need to have a socket soldered to the PCB first, then the timer placed into the socket, as the heat from soldering damages the chip. I am guessing this is a stupid question but I am throwing it out there anyway....do the SMD version of the 555 timers have problems with the heat from reflowing?

I appreciate any help you guys can give me on this.  After I am done figuring out this circuit, I'll move onto another 555 Timer circuit, then maybe Ill get into Op-amps or something. I can't believe how many things can be done with 555 timers.

[Falcon69]

Noone has input on this?

This is going to be for my Nephews truck. He built a flatbed and used 3 of those 6inch oval LED tail lights for each side. He wants them to sequential flash. Because there is one wire that operates the Turn Signal, Hazard, And Stop lights, I think I have to use a circuit like this.

I am actually not sure on the Resistor values (potentiometers) because I don't have the flasher relay from his truck. Looking online, the Federal regulations say the turn signals/hazards need to flash at 1-2Hz (1-2 seconds) So I figured if D9 flashes On, stays lit for 1 second, then off for 1 second, that should be okay. But, Again, I am not sure without hooking this up to his vehicle and checking. I may need to decrease the intervals that D10 and D11 flash after the D9, depending on his flashers rate of flashing.  I can't just replace his whole brake switching. The truck goes from power, into flasher relay, then to turn signal and hazard switch, then out to the rear lights. That, plus, It would mess up his trailer brake system and his trailer lights.  I need to tap into the wires (stock wires) at the taillight of his truck to do this.

I was also going to cast this in resin to help protect from the elements, and just leave alittle bit of the potentiometer so a small screw driver can get to it.

I tried this...

http://www.ebay.com/itm/UPI-90656-Sequential-LED-Light-Kit-/321485523191?hash=item4ada07c8f7:g:-QMAAOSwnDZT46Oq&vxp=mtr

But they did not work. When brakes were applied, and turn signal was on, both sides sequential flashed like the hazards were on. Can't do that. The sequential can go through one rotation, but must stay lit at the end of its rotation when brakes are applied, according to the federal regulations. And yes, he knows that he could still get a ticket, because this was not a factory feature originally offered on the vehicle...but it's what he wants. So, please, no flaming on this issue.  Let's just talk about how to make it work, and safely.

EDIT: added wire diagram of those sequential modules. Waste of $60

[TerminalJack505]

I've attached the simulation results of your circuit from the TINA-TI simulator.  As you can see it is about what you expect.  The first pulse is longer than expected, however.  This is due to the fact that the two timing capacitors aren't charged up.

A Johnson counter (4017, for example) and some or-ing diodes is another option.  You could use a 555 to drive the clock pin at 3 Hz.  (Note: The second screenshot is from TINA.  TINA-TI doesn't do digital or mixed mode simulations.)

[Falcon69]

Thank you TerminalJack505

I'm trying to achieve this, and not sure how or what is going on with your simulation. (graph below)

If I have to supply a steady voltage to the timer circuit (and just have the flasher relay on the trigger of the 555), then may need to do that, but not sure how to do it.

There can't be any delay, as your simulation shows, for capacitors to charge up (I thought about that, but thought at 100uF, it wouldn't take long. ....like nano sec's. A delay could cause a rear end accident. I learned from truck driving, that for every second you hesitate stepping on that brake pedal.....the truck travels one football field at 60 mph.  Granted, this is just going on a pick-up truck, but still, the delay could cause an accident.

I'm not sure now how to make the circuit work using trigger as the input using the supplied brake/hazard/turn FACTORY wire already there at the taillights, and keeping the rest of the circuit with a steady +12volts (well, as long as the ignition is on anyway, don't want the circuit to stay on while the truck is parked for the night).  I could run a wire straight to the back for a +12v, but, that would mean I would also need to run a 3rd 555 timer for D9?

I tried using a 4017 before, in conjunction with a 555 timer. It did not work.  In fact, I think that was another circuit I had posted on here many months ago, trying to make this same thing work. I gave up on it, but now my Nephew is hounding me to get this done. He's taking a trip to California to see some offroad/rock crawling competition, and he wants his truck wired up for this, among other things. So I need to get this done for him. It is his Christmas present.

[Falcon69]

oh, now i understand your 4017 drawing. That could work. Very small BOM as well.  Do they make a 4017 that operates on say, 4.5v to 16 volts? 

Another thing I thought of....might need to put in some type of circuit to help with spikes. His truck runs on 12 volts, but because of his cummins diesel, it also runs 2 batteries (24volt). I don't know the wiring of his truck, but those taillight wires to measure ~12volt on a DMM.

[Falcon69]

wait, that 4017 circuit...how would it react when the brake is applied? It will only light up the first LED in sequence? Not all 3?  How would I make it so it will sequential flash to the 3rd, and all stay on...until brakes are released.

I thought about maybe running another wire connected to the brake pedal back to each relay in the circuit so when brakes are applied, it bypasses the 4017 and lights all 3, however...if the turn signal is on..it won't work. Also, the effect of having the sequential for 1 cycle, then all LEDs stay on when brake is applied....won't happen that way.

This is getting technical now. LOL

[Falcon69]

sorry, just realized something else as well with that 4017. I would need to figure out how to 8x the flasher relay's frequency to make that 4017 circuit work. The flasher relay flashing every 1 second, won't work. It would take 4 flashes On, 4 flashes off (8 seconds....ON/OFF) to finish the sequence.....right?

[Falcon69]

This guy....



is using the cheap ebay timer delay switches, wired up as in the second pic. It is working for him....however, I am concerned with the frequency of the flashing relay on my nephews truck.  I made a mock up on perf board of that ebay circuit, and I could not get the second and the 3rd light to activate in sequence. I think the time ran out for the 3rd, and the circuit reset. Of course, my perfboard mock up could have had something wrong with it.

I've included pictures of the perfboard i did. It has both the circuits on one board, and 6 leds. The leds simulated the oval LED's he bought. But I did connect it to the stock wiring for his taillights coming from the front of the truck (switches, flashers, etc.) It did take me awhile to build that thing. Takes awhile to blob all that solder on the back. Pain in da behind!

[cponcsak]

Couldn't you use the same circuit but replace the mechanical relays with solid state ones?

[TerminalJack505]

Sorry, I didn't pay much attention to all of the details so far as the requirements go.

If you want 1 second of off time then (on the 4017 schematic) just move the master reset down a couple of outputs.

The brake signal could be OR-ed in along with the sequence signals using diodes.

[Falcon69]

TerminalJack505,

Maybe I don't understand...

The flashing relay turns off/on every 1 second. That means the 4017 sees a count every 1 second.  So, To complete 1 cycle of the sequential lights, I would need 8 total seconds to do that.

That is WAY to slow. I need to make the counts at least 1/6second to get the second and third led to turn on at interval 333ms and 666ms, then all off at 1second.

The other problem with the 4017, at each off count, the led's will turn off, and the next will light.  That won't work. I need the preceding LED's to stay lit, until the cycle is finished. I don't need a chaser LED set-up, I need a Sequential LED set-up.

[TerminalJack505]

I missed the part where the brake signal and the turn signal are the same.

Here's another thought.  Note that, like the earlier schematic with the 4017, I'm not showing how the 3 Hz clock is generated.  (The input to the CP0 pin.  This isn't the brake/turn signal.)

The diodes take care of keeping the preceding LEDs lit.

Once the 4017 gets power and the clock starts, the three outputs will each go high in order at the speed controlled by the clock signal.  Once Q3 goes high it will bring the clock inhibit pin high and stop the 4017 from counting any further.  All of the outputs will be high at this point and will remain high until power is removed.

[Falcon69]

okay, i get that.

I still don't understand how to boost the frequency.

If the flasher relay is 1 second (1 Hz), how would I boost the frequency to the 3Hz or even 6Hz?  I tried to find a Frequncy Tripler circuit, but all I am finding are doublers.

[TerminalJack505]

The clock signal would just have to be generated by a separate oscillator circuit.  If you're not careful, however, it could have the same problem as the 555s, where the first pulse is stretched out. 

You might be able to take advantage of the fact that the 4017 doesn't need a clock with a perfect 50% duty cycle and minimize the extra time that the first pulse will have by using a lopsided duty cycle.  (Hope that makes sense.)

[Falcon69]

I will try breadboarding this, but, I don't see how it is going to work with a 1Hz pulse signal.  That will just make it too long.  I could pop open the Flashing Relay of the truck and solder on another capacitor in parallel to the existing capacitor to raise the frequency, but, then his Trailer lights will flash way too fast.

So, I need to do this at the lights themselves and leave everything else stock wiring of the truck.

I am having trouble finding a circuit that will triple the frequency coming from the Flasher Relay of the truck, to goto this circuit for the 4017.

I understand what you are saying about the capacitors charging to full first in the 555 timer circuit. By that happening, it will mess everything up for that short period it take for the cap to charge.

[Falcon69]

I need to find a circuit that converts 1Hz to 3 or 4 Hz. I think.

[alsetalokin4017]

This is trivial to implement with a microcontroller, say, an Arduino ProMini or Uno. Initial cost may be a bit more than using TTL/CMOS but it is far more flexible and easier to set up.

It's almost the same code I wrote for another poster on a different thread.

Code: [Select]

/*--------------------------------------------------------------------------------------//
   3-Light Sequential Brake/Turn Signal Actuation
//--------------------------------------------------------------------------------------*/

int delayOn = 333;  // set sequence delay time in ms here

void setup() {
  // connect LEDs, relay drivers or mosfet Gates to Output pins here
  pinMode (10, OUTPUT); 
  pinMode (11, OUTPUT);
  pinMode (12, OUTPUT);
 
  //  connect Brake/Turn signal here (through divider or regulator to give ~4-5V when ON)
  pinMode (7, INPUT);         
}

void loop() {
// Lather:
 
  while (digitalRead(7)==LOW) {
    // do nothing, wait for signal to go HIGH
  }
 
  // when signal goes High, actuate outputs in sequence
  digitalWrite(10, HIGH);
  delay(delayOn);
  digitalWrite(11, HIGH);
  delay (delayOn);
  digitalWrite(12, HIGH); 
   
  while (digitalRead(7)==HIGH) {
    // do nothing, keep outputs ON and wait for signal to go LOW again to reset cycle
  }
 
// Rinse:

  // when signal goes LOW turn OFF all outputs
  digitalWrite(10, LOW);
  digitalWrite(11, LOW);
  digitalWrite(12, LOW);
}
// Repeat:


 

[Falcon69]

I'm trying to do this without Arduino.  Seems a waste to buy two of them (one for each side), and cast them in resin and throw them up underneath the truck. 

[SL4P]

One micro (any micro) - handling both sides...
...is also the way I'd be going with this.

No relays, MOSFETS and a cold beer afterwards.

Easy to add extra 'effects' for hazard lights etc (leave the programming header poking out of the epoxy!
(Why under the truck, why not n the firewall in a diecast box?

[Falcon69]

Hello MC,

The wires are in the back. He ripped off his bed, made a flat bed, and the wires are hanging. He installed 3 LED lights on each side of the flatbed. I need to do this at the termination of the wires in the back. If I do this up front, then it will mess up the stock flashing of when he hooks up his trailer through the trailer hitch jack.  I'm trying to do some very simple (i thought anyway) where all I had to do was build the circuit, go over to his house, and Connect those 3 wires (Ground, Turn/Brake/Hazard Light, Running Light) to it and be good to go.

I am thinking I would also need something to vary the time, in case they are too fast or two slow for the flashing rate for him.  Like a pot to change this.

[SL4P]

OK, I get you.
I still think any way to remove unneeded components that need to be interconnected is a good starting point.  A micro plus MOSFETS.
The vibration and crappy environment in autos is not nice for anything that moves or can move!   Lay everythig low to the board, minimse connectors etc.

Even using a stock arduino module is pushing the boundaries, as these (even cast in epoxy) may not last as long as you expect, due to mechanical considerations of the soldering etc... relays and the spade/QC connectors just add to the multiple 'points of failure'.

Mass of one relay could be as much as the whole micro solution... mass is your enemy in a vibrating environment.

Do you have an arduino nearby?  If yes - Which board?
I can hack up some code against your first diagram, then you can critique, and modify as needed.

Once it's working correctly - build up the final module and enjoy.
Remember to include power protection against charging spikes etc in the vehicle.

[Falcon69]

I have no Arduino.  I'm still trying to learn this Stuff.  I am thinking of buying a few cheap Nanos from Aliexpress and see how they work and try and understand the programming.

The lights draw 240mA each, 240x3=720mA per side total draw.  So I would have to use a relay anyway.  There's plenty of power coming straight off the wiring that the circuit could connect to that currently exists...those 3 wires. But, connecting to them, would mean the circuit turns off at every cycle when blinker or hazards are turned on.

[SL4P]

No relays!  Use logic level MOSFETS

[Falcon69]

okay, good enough, they are probably cheaper also.  But, wouldn't they heat up in the Resin?  I need to cast the circuit in resin to protect from condensation and other fouol stuff.  He 4wheels this truck alot, and these could be sitting in water/mud often.

[SL4P]

Naah - if you seal the controller in a box, or pot it in epoxy (properly), they'll outlast the truck!

[Falcon69]

How will the NANO or Pro MINI react to having it's power constantly disconnected? As in when the Turn signals or hazards are activated?  I'd really rather NOT run a dedicated wire to the back If I don't have to, and also, The Arduino would still see frequent disconnects when he turns on and off his truck.  The dedicated wire would need to be tapped into his ignition wire, so there would be no power draw when truck is off.

[SL4P]

That's what I'd be doing - supply the micro from the ignition +12V (filtered)...
One +V wire - which you would have needed anyway to supply the relays (and a transistor stage to sink the relay coil current).

If you want to have hazards / stop lights etc available when the ignition is turned off, you need to look at using unswitched +12V, and limiting / modifying the flasher behavior when +ignition is 'off'.

In this case the micro can be put into low-power sleep when the ignition is off, and just wake up every second to check if the environment (switches, ignition etc) has changed.  Virtually no load on the battery unless the lights are actually 'on' during their flash cycles.

EDIT: Not worded very well, but you'll get what I meant!
BTW micro with PWM means you could fade the lights in sequence, or dim at night / bright during the day - just like real cars!

[Falcon69]

I understand. Forgot about Hazards needing to be on when Engine is off.  That one wire that is switched for the Brake/Turn/Hazard does supply power with engine off if the Hazards are turned on or brakes are applied. The turn signals only work if the ignition is on.

This may be a good circuit to learn Arduino on. That other circuit we are working on MC is just over my head right now.

I will order a couple NANO's, Logic Level mosFETS, and....what else you think I need to order for this?  Do I need anything to program the Arduino? I am not sure where to even get the software or where to learn up on it yet.

[Falcon69]

And something like this maybe

http://www.ebay.com/itm/Waterproof-Plastic-Electronic-Project-Box-Enclosure-Case-100x68x50mm-L-W-H-SWTP-/331746356647?hash=item4d3d9fada7:g:ja0AAOSwFGNWTlYU

to keep water/dirt/moisture from getting in?  Drill and seal a hole for the wires to come in.

[SL4P]

If you go with Arduino - the software and learning is free - all downloadable and online.  You can program directly from your PC.

You can ask for help almost anywhere on the net (not always good help, but help nonetheless...!  Just like EEVblog!))

As this is a 'mission critical' (safety focused) application - you should test it thoroughly before bolting it into the car.

Other than the basic Arduino and MOSFET drivers - the main concerns will be the power conditioning (over-voltage & spike suppresion etc), and the enclosure.
If it's within the engine bay - heat will cook an Arduino, and any plastic will become brittle in a UV exposed environment within a couple of years.

Grommets are no good in themselves - you'be surprised what can get in!
And epoxy potting only works well if you plan, test and execute it properly.  e.g. multi-core cables will either wick the epoxy internally, or become a superhighway for water and bugs to crawl into the electronics!

ADDED:  LED bulbs will also reduce the power demand for the whole design - but factor in that someone may accidentally replace a LED with a normal bulb in the future - for emergency use etc)

[Falcon69]

ya, I have experienced the wick thing. Made the cable Extremely stiff about 1 inch into it.

The box would be under the truck. Only way UV light would get to it, is if he Rolled the truck and it was upside down. (I expect him to do that at some point.  )

I could put in an over voltage circuit, as well as a reverse polarity one.  However, that will get tricky with the brake/turn/hazard wire.

I was thinking of maybe running the wires through a hole, and either epoxy or hotmelt glue them in. However, hotmelt glue does go bad after awhile.

The main thing I am worried about, is condensation. His LED lights are suppose to be sealed, yet, they have water in them now.

[SL4P]

For the voltage protection - run google across
automotive surge suppression or protection

For the micro - soething simpe like this
https://forum.sparkfun.com/viewtopic.php?f=5&t=36534

For the individual switch / signal inputs a simple zener & resistor should be enough (plus maybe a small value capacitor)
If you use the unswitched +12V, the filter is only needed on that. 
The +ignition will only act as a a signal input - not actually powering the circuit.

[alsetalokin4017]

FWIW.... Arduino sketch for both sides, brakes and turn signals.  Tested on ProMini with LEDs on outputs, pushbuttons emulating Brake/TurnSignal wire inputs.

Code: [Select]

/*--------------------------------------------------------------------------------------//
           3-Light Sequential Brake/Turn Signal Actuation
           (Both Left and Right sides)
//--------------------------------------------------------------------------------------*/

int delayOn = 333;  // set sequence delay time in ms here
boolean Rstate=0, Lstate=0;

void setup() {
  pinMode (10, OUTPUT);   // Right: connect LEDs, relay drivers or mosfet Gates here
  pinMode (11, OUTPUT);
  pinMode (12, OUTPUT);

  pinMode (3, OUTPUT);    // Left: connect LEDs, relay drivers or mosfet Gates here
  pinMode (4, OUTPUT);
  pinMode (5, OUTPUT);

  //  connect Brake/Turn signal here (through divider or regulator to give ~4-5V when ON)
  pinMode (7, INPUT); // Right ts/b
  pinMode (8, INPUT); // Left ts/b       
}

void loop() {
  while (digitalRead(7)==LOW && digitalRead(8)==LOW) {
    // do nothing, wait for signal to go HIGH
    delay(20);     // short pause to allow read/writes to proceed without interference
  }
  if (!Rstate) {   // If lights are already on, skip turning them on again
    delay(20);    // short pause to allow read/writes to proceed without interference
    // when Right signal goes High, actuate R outputs in sequence
    if (digitalRead(7)==HIGH && digitalRead(8)==LOW) {
      Rstate=1;
      digitalWrite(12, HIGH);
      delay(delayOn);
      digitalWrite(11, HIGH);
      delay (delayOn);
      digitalWrite(10, HIGH); 
    }
  }
  if (!Lstate) {   // If lights are already on, skip turning them on again
    delay(20);    // short pause to allow read/writes to proceed without interference
    // when Left signal goes High, actuate L outputs in sequence
    if (digitalRead(7)==LOW && digitalRead(8)==HIGH) {
      Lstate=1;
      digitalWrite(3, HIGH);
      delay(delayOn);
      digitalWrite(4, HIGH);
      delay (delayOn);
      digitalWrite(5, HIGH); 
    }
  }
  if ((!Rstate) || (!Lstate)) {    // If lights are already on, skip turning them on again
    // when Brake (both) signal goes High, actuate R and L outputs in sequence
    if (digitalRead(7)==HIGH && digitalRead(8)==HIGH) {
      Rstate=1;
      Lstate=1;
      digitalWrite(12, HIGH);
      digitalWrite(3, HIGH);
      delay(delayOn);
      digitalWrite(11, HIGH);
      digitalWrite(4, HIGH);
      delay (delayOn);
      digitalWrite(10, HIGH);
      digitalWrite(5, HIGH); 
    }
  }
  delay(20);  // short pause to allow read/writes to proceed without interference

  // when signal goes LOW turn off all outputs
  if (digitalRead(7)==LOW) {
    digitalWrite(12, LOW);
    digitalWrite(11, LOW);
    digitalWrite(10, LOW);
    Rstate=0;
  }
  if (digitalRead(8)==LOW) {
    digitalWrite(3, LOW);
    digitalWrite(4, LOW);
    digitalWrite(5, LOW);
    Lstate=0;
  }
}



 

[Seekonk]

I have a fondness for simple as much as anyone.  Would like to remind everyone that a three lead LM431 makes a dandy RC timer that will drive a small relay.  Just think of it as a op amp, voltage reference and driver.

[SL4P]

FWIW.... Arduino sketch for both sides, brakes and turn signals. 

hehe thanks...
I was going to do something similar if the OP asked!
My only comments would be to 'name' the I/O pins to help the OP understand the logic, and eliminate those delays in favour of a timed state machine...

Blocking delays are bad!  Good to learn and play... bad for almost everything else.

[Falcon69]

well, I spent all morning trying to understand.


Here's my simulation, though, it's not video.

First of all, The simulatyion didn't have a pro mini. But it did have a micro.  I connect to the Dpins as stated in the code.
The 555 timer is just to simulate the 1Hz (as in the flashing relay). That will not actually be there in the circuit design.


The middle tactile switch is bake. That works right. When I press the button, the left and right LED's sequence, overriding the turn signal flashing, then stay on steady. That is what I need done. Good!

However, when the simulation first starts, both left and right LED's sequence. Pressing the left and right tactile buttons do nothing. The lights should be off at start of simulation and then only turn on when a tactile button is pressed.

I am trying to figure it out, but just saw MC post, so thought I'd comment.

Also, I so far like the ease of use. It's easy to change the frequency. Just change the Int Delay = 333 to any number

[Falcon69]

I know you said that a pot is probably a bad idea, but I'm not sure what to do. I think I am going to need one. I need to be able to adjust the timing frequency of this once it's hooked up to the truck.

I would I put in a Potentiometer to change the int delay = value?

[Falcon69]

hmm, just noticed. when i push the left or right tactile switch, it slows down the blinking, but doesn't turn them off (actually, they should be off, only turn on when pressed).  by the way, both sides flash, regardless is button is pushed or not for either one

[SL4P]

That's a good starting point - and great that you're learning to harness the micro.

My comment about the delays was a harsh but important part of learning to 'have control' of your code. 

At the very least, when you take you foot off the brake (or whatever), the micro has to finish a whole flash cycle before it can do anything else - like turn the brake lights on.

If you use a state machine... you simply jump to the idle state, or to the new operating state immediately - e.g. a child runs out and you hit the brakes... no good if the brake lights don't come on for a second and a half!

Good work & good luck!

[SL4P]

p.s.Perhaps an up/down button to step between desired speeds?
Or a DIP switch if they are semi permanent?
Remember these will get shaken around and dirty etc - so must be idiot (and fool) proof!

[Falcon69]

okay, so erase all the "delay(delayOn);" ?

And yes, a couple of waterproof switches for up/down would work. I could cut the mounting holes for them into the box and seal them from the elements. Maybe make it in 1k increments?

[alsetalokin4017]

Well... the code works for me without all those problems. The lights are off until a signal appears on one or both of the input lines.  There is no delay when pressing on the brakes. The only problem is that a very short tap on the brakes produces almost one full cycle before the lights turn back off.

[Falcon69]

that's exactly what I need, but with the ability to control the speed of the lights.

I must have something wired wrong in my simulation.

I see you have a diode going to the gnd pin of the Arduino,I'm assuming it is for reverse polarity protection?

I also see a cap, I'm assuming is a 0.01uF, connecting the GND and RESET pin.

I also see another Cap, Assuming it is 100uF, across the power supply GND +5v?

I will try that, maybe that is what is wrong with mine.

Oh, and I see resistors on the Tactile Switches. 1k?

[SL4P]

@alsetalomin
no ones saying it won't work, just that it's not the 'best' way to code stuff like that.
op
If you go with up/down switches - you can choose as many steps or any frequency you need. The period is generated on the fly in the code.   So for simplicity, you may have slow, medium and fast.
Each time you press the button it steps between the 'modes', and could rapidly flash one of the three turn signal for half a second to indicate which value is 'active' - and saved in eeprom.

The options are endless

[Falcon69]

okay, I can't figure it out.  I tried to wire it like in the video.

The Nano thinks that Pin 7 and 8 or HIGH all the time. Don't know how to fix it. Ideas?

[Falcon69]

Figured it out. I need to add a pulldown resistor to the switches. The Arduino Micro didn't know what to do, so it sent all those pins to high.

Now, to figure out the switch button thing to control the frequency, and what MC was talking about the block delays?

[Falcon69]

i'm tryin to understand that code.  How does arduino know that if only the left button is held high, to cycle once and turn off all led's and stay off, yet, if the brake is applied (high to both sides) then all LEDs cycle and stay lit?

I would think that if the turn signal didn't flash, then the led's on that side would cycle (sequence) then stay lit?  I mean, the code is the way I want it, it works for those LED's, but I'm just trying to understand the code.

[SL4P]

Hi there
I was looking at those drawings, and although I'm not familiar with that particular drawing tool, where do the switches pull down to OV?  Theres seems to be a pull-up to +5, which is not strictly needed with internal pull-ups, but I can't see the push button 'pull down' when pressed...?

Of course this is inverted logic, and in the case of car wiring, pull-up when 'on' is probably more likely in the final software... but nothing else changes.

Is there a schematic anywhere that you can put up, so we can review the actual design, rather than just the breadboard simulation diagram?

added: I just looked at the video... when you press the brake button, the lights come on sequentially...  is that correct (or legal)?  I would have expected the brake lights to come on simultaneously.

[Falcon69]

no schematic yet. The simulator is from 123d

Right now, I'm trying to figure out how to change all those delays to millis()

That's what you were talking about, right MC?

Not sure this link works yet...
https://123d.circuits.io/circuits/1439224-sequential-taillights/edit

[Falcon69]

MC,

It is legal as long as the brakes stay on steady after the first initial Sequence. 

[alsetalokin4017]

that's exactly what I need, but with the ability to control the speed of the lights.

Well, another button could do that as others have suggested, by stepping through some preset values, or a pot could do it really easily on the fly, but might not meet the "durability" requirement of the installation. If I were installing such a thing I'd put it inside a container that could be tightly sealed but still openable, with feedthroughs for the wiring, and use a trimpot to set the sequence delay.

I must have something wired wrong in my simulation.

Probably you already found it: the pulldown resistors on the pushbuttons maybe ?

I see you have a diode going to the gnd pin of the Arduino,I'm assuming it is for reverse polarity protection?

That's right, I'm constantly hooking up power supplies backwards and I just don't want to take the chance of frying anything. I can't remember offhand if the ProMini has a built-in reverse voltage protection diode. The diode is a 1n5817 Schottky.

I also see a cap, I'm assuming is a 0.01uF, connecting the GND and RESET pin.

No, it's connecting "Raw" (voltage in to the ProMini) and GND.  Local decoupling, just a habit, not necessary and certainly not affecting the functioning of the circuit.

I also see another Cap, Assuming it is 100uF, across the power supply GND +5v?

Also more power supply decoupling, just a habit of mine, safely ignored for most purposes.

I will try that, maybe that is what is wrong with mine.

Unlikely to be affecting you especially if you are simulating rather than working with real hardware.

Oh, and I see resistors on the Tactile Switches. 1k?

10K, pulldowns to keep the input pins from floating when the pushbuttons are not pressed.

[SL4P]

millis() is the same as delay()
Both 'block' the processor from doing anything else until the delay period has elapsed...

You need to look at 'state machine' and 'timers' to do it properly, but the low-rent approach seems to be keeping everyone happy so far. 

[Falcon69]

ya. so far I have found delay, millis, and asynchronous,( more difficult). Having trouble getting the millis to work properly. The delay seems to be working just fine however.  But I do see your point. The Arduino can't do anything, until it finishes it's sequences.

However, in this case, I think the delay may work just fine. If the left turn signal is on and brake is pressed, the left finishes its cycle of course, the right starts it's cycle, and when both finish their initial cycle, the brakes stay on steady. That is fine.


I think I might like this later, using this arduino over the 555 timers. The reason...It would take up a lot of space for my car if I used 555 timers/relays like I was originally going to do. My car has like 8-9 LED's per turn signal.  With this set-up, It looks like there's enough pins to do it. I would have to assign the analog pins to do it it, but the micro has enough.

Now, I think what I need to do now, is either use a two push buttons for up and down, or a potentiometer and feed those into the arduino to control the frequency (int delay ()) of pins D3,D4,D5,D10,D11,D12.

I just need to figure out the coding for that.

[alsetalokin4017]

no schematic yet. The simulator is from 123d

Right now, I'm trying to figure out how to change all those delays to millis()

That's what you were talking about, right MC?

Not sure this link works yet...
https://123d.circuits.io/circuits/1439224-sequential-taillights/edit

millis() returns the value in milliseconds since the power was applied to the Arduino, or since last reset. (up to a point, before it rolls over.) I don't know why you'd want to use it in this application.

For the pushbuttons you don't need the 2k resistors from the positive rail. It will probably work but really you just need to connect directly to the pushbuttons from the 5V pin on the Arduino (this assures that you are using the Arduino's own 5v regulator to pull the input pins high rather than the outside raw power source. Safer, IMHO.)
The 10k pulldowns from the Arduino side of the switches, to GND, look correct.

In my video I put in the third button, with diodes, to simultaneously "simulate" pushing both left and right buttons together. But of course if this button is pushed it overrides both left and right buttons, so I just used it to demonstrate "Emergency Flasher" mode.

[Falcon69]

the pushbuttons don't really matter, but the pulldowns do I believe. The pushbuttons represent the incoming signal from the trucks flasher. It is merely on the breadboard to  simulate that so I can see LED's flashing and watch code happening.

[alsetalokin4017]

millis() is the same as delay()
Both 'block' the processor from doing anything else until the delay period has elapsed...

You need to look at 'state machine' and 'timers' to do it properly, but the low-rent approach seems to be keeping everyone happy so far. 

No, millis() is NOT the same as delay(). Delay takes a value and pauses for the length of time in ms that is specified by the value. Millis() _returns_ a value that is the number of milliseconds since the program started running. Millis() does not block anything, it just returns a value.
https://www.arduino.cc/en/Reference/Millis

The whole idea of the delay(20) statements in my code is to block the processor from trying to read and write to digital pins too quickly, which is a known source of error in Arduino program processing. Comment out the delay(20) statements and watch what happens in the code.

Try to explain FSMs to a novice programmer and watch his eyes glaze over. My code may not be the "right" way that a Real Programmer would do it... she'd probably use interrupts, etc. but it is easy to understand and it works.

[alsetalokin4017]

the pushbuttons don't really matter, but the pulldowns do I believe. The pushbuttons represent the incoming signal from the trucks flasher. It is merely on the breadboard to  simulate that so I can see LED's flashing and watch code happening.

That's right. The input pins must be High or Low, or problems will arise. The pulldowns assure that when the pins are not High, they are Low. The pushbuttons are there to make the input pins go High.

But please, use the 5V pin on the Arduino instead of the main power supply to provide the 5V for the pushbutton High state, and you don't need the 2k resistors.

[Falcon69]

yes, I read that on the millis. I was trying to understand what SL4P meant by blocking, and google returned a search on millis for that.  But yes, I'm not using it.

Everyone programs differently, and from what I've learned the past 36 hours or so, is that there are different ways of programming these things. Some better then others, some get the same results, some get different results.

No need to flame or argue here. I appreciate everyones help in this large learning curve for me. I accept any input. 

So, Now my search begins on how to control the 'int delay ()' in the code, without having to type it in. I'm trying to understand this interfacing with a Pot/Trimmer. I have not yet explored the switch idea yet, but at this stage, a pot may be cheaper. But, an up/down switch would be cooler looking. But then again, this thing is going to be buried up below the truck and will never get seen again once it is installed.

So far, when I put in 'int delay arduino with Potentiometer' in google, i'm not finding much help i can understand from a beginners view.

[SL4P]

ya, sorry, I was meaning the end result of maintaining delay by subtracting millis to keep track of time... my poor expression.
I agree that for a newbie to use delay is convenient, but it's like painting yourself into a corner, because eventually, you'll need to develop non blocking async code, and everything you've done in the past becomes irrelevant.
Let's be friends!

P.s.  FALCON69, are you keeping the truck flasher unit in the circuit? as this will create all sorts of issues as far as control and timing.   you're better to let the controller take over all indicator timing and control. Just provide a voltage state for brakes, left, right, reverse and what other lights you need... e.g dim for tail lights, bright for indicator / flash

Remember you could also use dual colour R/G LEDs for tail/turn... all controlled by the micro.  red for stop/tail, and 'yellow' for turn...

[SL4P]

to use a pot with arduino, read about analogread()
Because a pot is mechanical, it is far more prone to dirt, temperature and other variations than a digital selection.

[alsetalokin4017]

ya. so far I have found delay, millis, and asynchronous,( more difficult). Having trouble getting the millis to work properly. The delay seems to be working just fine however.  But I do see your point. The Arduino can't do anything, until it finishes it's sequences.

However, in this case, I think the delay may work just fine. If the left turn signal is on and brake is pressed, the left finishes its cycle of course, the right starts it's cycle, and when both finish their initial cycle, the brakes stay on steady. That is fine.


I think I might like this later, using this arduino over the 555 timers. The reason...It would take up a lot of space for my car if I used 555 timers/relays like I was originally going to do. My car has like 8-9 LED's per turn signal.  With this set-up, It looks like there's enough pins to do it. I would have to assign the analog pins to do it it, but the micro has enough.

Now, I think what I need to do now, is either use a two push buttons for up and down, or a potentiometer and feed those into the arduino to control the frequency (int delay ()) of pins D3,D4,D5,D10,D11,D12.

I just need to figure out the coding for that.

You are having trouble with millis() because someone told you wrong information about what it does, probably.

To implement a potentiometer to control the delay in the flash sequence, you connect a pot (doesn't matter what value but use something over 10k) from +5V (the Arduino pin not the power supply) to GND, and the wiper to an analog input pin,, say A0. In setup() include the statement

pinMode (A0, INPUT);

and then in each of the "for" loops before the first delay(delayOn) statement, read that pin, and map the raw value to some delay value, like this:

delayOn = map (analogRead(A0),0,1023,0,500);

This will change the delayOn value to something between 0 and 500 milliseconds, according to the pot setting (which is going to be from 0 to 1023 at the A0 pin).

[Falcon69]

Yes MC,

I have to. I am not running new wires back from the truck.

The truck goes from Power > Flasher Relay > Turn Switch/Hazard Switch > Brake > Rear Taillights and Trailer Hitch.

Because of this, tapping into the turn signal switch, or the brake switch, will do nothing. If I eliminate the flasher and then tap into the turn signal switch, then the trucks trailer lights won't function, or function improperly.

So, I can run a steady voltage back via an LDO regulator or something to get 5v, but for the brake and turn signal, it has to be with that existing wire already in the back of the truck.

[SL4P]

ok, keep in mind that you will have to account the 'aliasing' between the duty cycles of the truck flasher, and the micro flash rate -- that the 'next' micro flash sequence will only begin upon the next truck flash event...  so your slow/medium/fast flash rate will still be dependent on the truck flasher to 'start' each new sequence.

you may need to consider 'loading' the truck flasher so that it runs at the correct flash rate - as the thermal flashers will run slow if no 'bulbs' are connected....  this is well documented on their web.

[Falcon69]

i don't think there are thermal flashers.

When I was under it, trying to hook up the other...we had one side disconnected and the left side still flashed normally, or so it seemed.

I think his is just a standard mechanical flasher.

Alse...

I can't get that working. Do I need to do all that analogread/serial baude rate stuff as well in the first part of the coding?

I replaced all the "delay (delayON)" with "delayOn = map (analogRead(A5),0,1023,0,500);"

[SL4P]

Since you are going this way,
up the top, put int delayOn to 'declare' the variable

Using delay(delayOn) is fine, but you need to update the delayOn value from the pot  frequently
So in the main loop, put your delayOn = map(...) statement

[alsetalokin4017]

i don't think there are thermal flashers.

When I was under it, trying to hook up the other...we had one side disconnected and the left side still flashed normally, or so it seemed.

I think his is just a standard mechanical flasher.

Alse...

I can't get that working. Do I need to do all that analogread/serial baude rate stuff as well in the first part of the coding?

No.

I replaced all the "delay (delayON)" with "delayOn = map (analogRead(A5),0,1023,0,500);"

No, don't touch the "delay(delayON) statements! They delay for the number of ms that is in "delayON" variable.
The line "delayOn = map(analogRead(A5), 0, 1023, 0, 500);" loads a number into the delayOn variable, so that the delay() statement has something to eat.



I'd run a single "hot" wire back to the Arduino location (or maybe a twisted pair or zipcord, to assure a good ground) , and include a 7809 regulator and a couple of capacitors to make a local filtered and regulated 9v power supply for the Arduino itself. Then I'd use the brake/ts wires (which will be carrying +12 to +14 V when "on" ) to switch a couple of mosfets to switch 5V from the Arduino's own regulated +5 output pin to the two "button" input pins.  This way you only need to run a single extra wire (or pair) to provide the power to the Arduino itself.

[alsetalokin4017]

Since you are going this way,
up the top, put int delayOn to 'declare' the variable

Using delay(delayOn) is fine, but you need to update the delayOn value from the pot  frequently
So in the main loop, put your delayOn = map(...) statement

The delayOn variable is already initialized in my code, as you can see in the link to his simulation.

As I said in my post, the "delayOn =  map() " statement should be in _each_ "for" loop, before the first "delay(delayOn);" statement in the for loops.

(Sorry, I meant the "if" statement segments, not "for" loops. I forgot how I had coded it!)

[Falcon69]

okay, so where it say 'int delayOn = 175" change that to just "int delayOn" ? or to "int delayOn = ()"

oh, don't replace the delayOn in each loop, merely post the new code above each FIRST one in the loop?

[SL4P]

I'd run a single "hot" wire back to the Arduino location (or maybe a twisted pair or zipcord, to assure a good ground) , and include a 7809 regulator and a couple of capacitors to make a local filtered and regulated 9v power supply for the Arduino itself. Then I'd use the brake/ts wires (which will be carrying +12 to +14 V when "on" ) to switch a couple of mosfets to switch 5V from the Arduino's own regulated +5 output pin to the two "button" input pins.  This way you only need to run a single extra wire (or pair) to provide the power to the Arduino itself.

About now would be a good time to draw up a proper schematic of how it's going to be installed and wired - then you can plan and code to fit the actual as-built model of the system.

[SL4P]

Code: [Select]

/*--------------------------------------------------------------------------------------//
   3-Light Sequential Brake/Turn Signal Actuation
//--------------------------------------------------------------------------------------*/

int delayOn;  // declare delay time variable

void setup() {

   ::: as before       
}

void loop() {

  delayOn = map(analogRead(A5), 0, 1023, 0, 500);

   :::  everything else as before
}


[Falcon69]

yes, I will work on that now. this simulation program really sucks for it's schematic portion. I'll have to open up dip trace and draw it out.

I got the pot work, Thank you. 

However, in simulation, it looks like the LED's quickly fade out as they turn off. Anyway to stop that from happening? Not sure if it will be seen in the real world, or is it just simulation?

[alsetalokin4017]

okay, so where it say 'int delayOn = 175" change that to just "int delayOn" ? or to "int delayOn = ()"

No, leave it alone. The variable is declared as an "int" or integer and is set initially to 333, or as you have it, 175. Leave this alone!

oh, don't replace the delayOn in each loop, merely post the new code above each FIRST one in the loop?

That's right. I mistakenly said "for" loops, but it is actually in the "if" statement functions. Sorry about the confusion.

You could also try just the one statement _after_ the "while" loop at the top of the sketch, but I would do it in each "if" statement personally. If you do it at the very top of the loop(), nothing will happen until the "while" statement sees one of the input pins go High.

[SL4P]

Can you post your latest code as it has changed...
We'll take a look and see if there are any tips we can add. (probably clarification of variables etc)

[Falcon69]

Code: [Select]

/*--------------------------------------------------------------------------------------//
           3-Light Sequential Brake/Turn Signal Actuation
           (Both Left and Right sides)
//--------------------------------------------------------------------------------------*/

const int LeftInnerLED = 10;
const int LeftCenterLED = 11;
const int LeftOuterLED = 12;
const int RightInnerLED = 5;
const int RightCenterLED = 4;
const int RightOuterLED = 3;
const int LeftTurnSwitch = 8;
const int RightTurnSwitch = 7;

int delayOn;  // declare delay time variable from Potentiometer

boolean Rstate=0, Lstate=0;

void setup() {
  pinMode (RightInnerLED, OUTPUT);   // Right: connect LEDs, relay drivers or mosfet Gates here
  pinMode (RightCenterLED, OUTPUT);
  pinMode (RightOuterLED, OUTPUT);

  pinMode (LeftInnerLED, OUTPUT);    // Left: connect LEDs, relay drivers or mosfet Gates here
  pinMode (LeftCenterLED, OUTPUT);
  pinMode (LeftOuterLED, OUTPUT);
 
  pinMode (A5, INPUT);
 
  //  connect Brake/Turn signal here (through divider or regulator to give ~4-5V when ON)
  pinMode (RightTurnSwitch, INPUT); // Right ts/b
  pinMode (LeftTurnSwitch, INPUT); // Left ts/b       
}

void loop() {
 
  delayOn = map(analogRead(A5),0,1023,0,500); {
  }
 
  while (digitalRead(RightTurnSwitch)==LOW && digitalRead(LeftTurnSwitch)==LOW) {
    // do nothing, wait for signal to go HIGH
    delay(20);     // short pause to allow read/writes to proceed without interference
  }
  if (!Rstate) {   // If lights are already on, skip turning them on again
    delay(20);    // short pause to allow read/writes to proceed without interference
    // when Right signal goes High, actuate R outputs in sequence
    if (digitalRead(RightTurnSwitch)==HIGH && digitalRead(LeftTurnSwitch)==LOW) {
      Rstate=1;
      digitalWrite(RightInnerLED, HIGH);
      delay(delayOn);
      digitalWrite(RightCenterLED, HIGH);
      delay(delayOn);
      digitalWrite(RightOuterLED, HIGH);
      delay(delayOn);
    }
  }
  if (!Lstate) {   // If lights are already on, skip turning them on again
    delay(20);    // short pause to allow read/writes to proceed without interference
    // when Left signal goes High, actuate L outputs in sequence
    if (digitalRead(RightTurnSwitch)==LOW && digitalRead(LeftTurnSwitch)==HIGH) {
      Lstate=1;
      digitalWrite(LeftInnerLED, HIGH);
      delay(delayOn);
      digitalWrite(LeftCenterLED, HIGH);
      delay(delayOn);
      digitalWrite(LeftOuterLED, HIGH);
      delay(delayOn);
    }
  }
  if ((!Rstate) || (!Lstate)) {    // If lights are already on, skip turning them on again
    // when Brake (both) signal goes High, actuate R and L outputs in sequence
    if (digitalRead(RightTurnSwitch)==HIGH && digitalRead(LeftTurnSwitch)==HIGH) {
      Rstate=1;
      Lstate=1;
      digitalWrite(LeftInnerLED, HIGH);
      digitalWrite(RightInnerLED, HIGH);
      delay(delayOn);
      digitalWrite(LeftCenterLED, HIGH);
      digitalWrite(RightCenterLED, HIGH);
      delay(delayOn);
      digitalWrite(LeftOuterLED, HIGH);
      digitalWrite(RightOuterLED, HIGH);
      delay(delayOn);
    }
  }
  delay(20);  // short pause to allow read/writes to proceed without interference

  // when signal goes LOW turn off all outputs
  if (digitalRead(RightTurnSwitch)==LOW) {
    digitalWrite(LeftInnerLED, LOW);
    digitalWrite(LeftCenterLED, LOW);
    digitalWrite(LeftOuterLED, LOW);
    Rstate=0;
  }
  if (digitalRead(LeftTurnSwitch)==LOW) {
    digitalWrite(RightInnerLED, LOW);
    digitalWrite(RightCenterLED, LOW);
    digitalWrite(RightOuterLED, LOW);
    Lstate=0;
  }
  }

[Falcon69]

what about make the 1st LED fade once the 3rd LED is lit? then 2nd led fade when the 4th (not there of course, just imaginary) hits, and so on.  Like a chaser LED

[alsetalokin4017]

what about make the 1st LED fade once the 3rd LED is lit? then 2nd led fade when the 4th (not there of course, just imaginary) hits, and so on.  Like a chaser LED

That's happening in your simulation for some reason, probably. It doesn't happen in real life (for me anyhow). The LEDs are turned on by digitalWrite statements and these can only be "low" (ground) or "high" (+5V), so there is no way that the code itself could be fading the LEDs.



(I put the potentiometer reading "delayOn=map()"  statements in each "if" function but it should work as you have it just as well, as long as the rest of the code doesn't change much.)

[alsetalokin4017]

As far as using a button-press to do the rate variation... I can't figure out how to keep the set value constant between power-cycles, using a momentary pushbutton. It would reset to some initial value each time the unit is powered on or restarted, and you'd have to reset it to your desired rate each time. A DIP switch/resistor array would keep the desired value between cycles, or of course a trimpot would do the same; once it's set it will "remember" the setting.

Maybe someone else knows how to maintain a non-volatile variable setting across power-cycles, without using some external storage medium like a flash memory (and its associated overhead).

[alsetalokin4017]

I have a question about the breadboard in the Simulation. Many "real" breadboards, and also in simulations, have the power rails split into left and right halves. Is your breadboard connected internally across the middle gap? I guess it must be, if your potentiometer control is working.

[Falcon69]

yes, it is

[alsetalokin4017]

OK, I just read up on the EEPROM in the Arduino. It turns out that you can use this memory space to store variables that will persist across power cycles.

So with some clever coding you could set your desired delay by pushbutton presses, then write the variable to the EEPROM for "permanent" storage. Then read it from the EEPROM when the power is on again.

https://www.arduino.cc/en/Reference/EEPROM
https://www.arduino.cc/en/Tutorial/EEPROMWrite
https://www.arduino.cc/en/Tutorial/EEPROMRead

I've obviously never done this myself, but it seems to be a handy answer to the problem.

[SL4P]

For the non-volatile storage - look at the Arduino EEPROM library
Easy to use and saves across power cycles.

Keep in mind - try to minimise the number of write cycles - as FLASH EEPROM has a finite number of cycles (a lot, but a micro can blitz through them pretty quickly)...  so for example, only save the value 5 seconds after the last change (another example of async programming), thus when you are stepping through delay perriods, it doesn't write every time.

I'm looking at the existing code, and trying to simplify it a bit - without going to a full state machine.

[Falcon69]

i'm drawing up schematic now.  only schematics i found were rom eagle. i had to download free version. trying to convert the file to diptrace now. i'm more familiar with it.

[SL4P]

Here's some code...
Derived from your original example
Not tested, but it compiles without errors

Code: [Select]

/*--------------------------------------------------------------------------------------//
           3-Light Sequential Brake/Turn Signal Actuation
           (Both Left and Right sides)
//--------------------------------------------------------------------------------------*/

#define PotInput A5
#define BRAKE_SWITCH (digitalRead(RightTurnSwitch)==HIGH && digitalRead(LeftTurnSwitch)==HIGH)

const int LeftLED[] = {10, 11, 12};
const int RightLED[] = {5, 4, 3};
const int LeftTurnSwitch = 8;
const int RightTurnSwitch = 7;

int delayPeriodMS = 250;  // declare delay time (default 250mS)
// this can be stored in EEPROM if needed

boolean Rstate=0, Lstate=0;

// *********************************************************************************
void setup() {
  for (int counter = 0; counter <= 2; counter++) {
    pinMode (RightLED[counter], OUTPUT);   // Right: connect LEDs, relay drivers or mosfet Gates here
    pinMode (LeftLED[counter], OUTPUT);   // Left: connect LEDs, relay drivers or mosfet Gates here
  }
 
  pinMode (PotInput, INPUT);
 
  //  connect Brake/Turn signal here (through divider or regulator to give ~4-5V when ON)
  pinMode (RightTurnSwitch, INPUT); // Right ts/b
  pinMode (LeftTurnSwitch, INPUT); // Left ts/b       
}

// *********************************************************************************
void loop() {
 
  delayPeriodMS = map(analogRead(PotInput ),0,1023,0,500);

  // the following block is a bit shady, and works by coincidence - as there are nested conditions
  // testing for true and false on the *same* variables - it should be rewritten if possible.
  // ideally as a state machine - but this works with blocking delays
  // ----------------------------------------------------------------------------
  if (digitalRead(RightTurnSwitch) || digitalRead(LeftTurnSwitch)) { // a switch is 'on'
    // ----------------------------------------------------------------------------
    // LEFT-RIGHT TURN INDICATORS
    // ----------------------------------------------------------------------------
    if (!Rstate) {   // If lights are already on, skip turning them on again
      delay(20);    // short pause to allow read/writes to proceed without interference
      // when Right signal goes High, actuate R outputs in sequence
      if (digitalRead(RightTurnSwitch)==HIGH && digitalRead(LeftTurnSwitch)==LOW) {
        Rstate=1;
        for (int counter = 0; counter <= 2; counter++) {
          digitalWrite(RightLED[counter], HIGH);
          delay(delayPeriodMS);
        }
      }
    }
    // ----------------------------------------------------------------------------
    if (!Lstate) {   // If lights are already on, skip turning them on again
      delay(20);    // short pause to allow read/writes to proceed without interference
      // when Left signal goes High, actuate L outputs in sequence
      if (digitalRead(RightTurnSwitch)==LOW && digitalRead(LeftTurnSwitch)==HIGH) {
        Lstate=1;
        for (int counter = 0; counter <= 2; counter++) {
          digitalWrite(LeftLED[counter], HIGH);
          delay(delayPeriodMS);
        }
      }
    }
    // ----------------------------------------------------------------------------
    // BRAKE LIGHTS 
    // ----------------------------------------------------------------------------
    if ((!Rstate) || (!Lstate)) {    // If lights are already on, skip turning them on again
      // when Brake (both) signal goes High, actuate R and L outputs in sequence
      if (BRAKE_SWITCH) {
        Rstate=1;   Lstate=1;
        for (int counter = 0; counter <= 2; counter++) {
          digitalWrite(RightLED[counter], HIGH);
          digitalWrite(LeftLED[counter], HIGH);
          delay(delayPeriodMS);
        }
      }
    }
  } else {  // no switches are on
    // ----------------------------------------------------------------------------
    // turn OFF ALL LIGHTS
    // ----------------------------------------------------------------------------
    // when signal goes LOW turn off all outputs
    for (int counter = 0; counter <= 2; counter++) {
      digitalWrite(RightLED[counter], HIGH);   Rstate=0;
      digitalWrite(LeftLED[counter], HIGH);    Lstate=0;
    }
  }
}
// *********************************************************************************
// end

MODIFIED PotInput within the analogRead() call. 
Only done for completeness

[Falcon69]

since the LED's will be drawing power off a wire I'll bring to the back of the truck....I need to splice off that wire and supply 9 volts to run the Arduino, as well as the mosFETS for switching.  WOuld a Small 100mA LDO Voltage regulator work for that?

Like one of these...

http://www.mouser.com/ds/2/405/ua78l09a-407362.pdf
http://www.mouser.com/ds/2/389/CD00000446-355303.pdf
http://www.mouser.com/ds/2/149/KA78L09A-185607.pdf
http://www.mouser.com/ds/2/308/MC7800-D-94905.pdf

there's even more, and I may decide to do Surface Mount. Depends on how much I can get cheap PCB's made up.

Anyway, back to the Designing.

[SL4P]

Worst case SIX LEDs on at a time - plus any other indicators and the arduino board.
If they are single 20mA LEDs (even running at 10mA), but somewhere I recall that the actual indicators had more than one LED per 'window'...

You need to figure out what's being drawn - and tot that up with a minimum 20% headroom, as the regulator and other parts may de-rate with higher temperatures... (datasheets are your friend!)  Also ensure the regulator is adequately heat-sinked.

Remember our earlier reference to noisy & spiky automotive power sources...  high voltage that may cook your regulator - so check input range, and add protection in front of that !

[Falcon69]

yes, Data sheet on LED's say 243mA per LED.

But, those will be run through the mosFETs.  Not going through the Voltage Regulator at all.

[SL4P]

Yep - good point - so they are on the dirty side of the regulator - excellent.

[Falcon69]

ya. I thought that would be the best.

Now, you mentioned something about dimming the lights during the night...but that would require tapping into headlight switch and running another wire back.

But, what if we tapped into the Taillight (running Lights)?  That wire is one of the three going to the back. on each side.  Also, if the lights are on during the day, how would we detect that? Some people drive with lights on during day, I do sometimes. When that happens, we don't want lights to dim. I don't think a Photoresistor would work, as this unit will be under the truck and sealed in a box.

[SL4P]

First requirement for PWM, is to use output pins that are compatible with analogWrite()...

Then to answer your other question... hmm can't think of the best idea there.
Some euro and jap cars already have light sensors built in for this, but not sure how we'd retrofit in your case.

Just BTW, are your turn indicators yellow, or they same lens/red with the tail/stop...
If the tail lamps are not controlled in this project.l are they different bulbs?
Also combined stop/tail bulbs are often dual filament 25/5watt (bright/normal)

If this is all designed in it can be included with the Arduino...  (writing the requirements doc on the fly!)

[SL4P]

Di d you try my modified code ?  just interested...

[Falcon69]

Not yet. Have not entered your code yet. Still working on the schematic.

Yes, the LED's are red for the running lights as well, enclosed into the same LED package. I'm not sure how they work, but I believe there is separate LEDs inside for that operation.  If not, they are on resistors or something to make them not so bright, and when the brakes are applied or turn signals, it overrides them.

It's all internal in the light.

When I hooked up the 555 timer, it was just with the turn/brake input, and then the running was just wired direct from the truck. It still worked as it should. Dim LED's for running light, but got brighter when blinker or brakes applied.

[SL4P]

ok, as long as you're happy with the result!

[Falcon69]

Here's the schematic. I'm not sure I need the Resistors with the mosFETS?  Q1 and Q2 can be regular, while the others will need to be Logic Level.

The Voltage Regular will be a small 100mA model.

C3 need to be electrolytic?

Anything else you see that should be addressed in the schematic?

Hmm, just thought of something......

If it's at night time (daytime too if lights are on), the LED's won't turn completely off during the sequencing because of the running lights. So, Looks like may need to implement that into this.  There's JUST enough pins to do this, but will have to change 3 of the analog pins into digital. I would need 6 out for the LED's, and one in for the trigger.

If I need more, I'll need to upgrade to a Nano or Micro

[Falcon69]

just noticed, it actually has 14 pins.  Can the trigger for the running lights be used with one of the analog inputs? Or must it be one of the digital?

[SL4P]

trigger inputs can be any of the Arduino io pins nominated as pinmode input.
I didn't see the schematic link...?

[Falcon69]

it's up, and yes, I know, I need to work on my schematic Layout skills.

So RXD and TXD are the other two digital input/outputs?

So That would leave one more needed, unless the trigger input can use an Analog input/output

Tired now, 3:30am here. I'll work on this some more tomorrow. I'll try and figure out the Running Light Input.  Should be much easier, since there is no sequential to them.

[SL4P]

ok, I saw the pdf ... just wasn't looking in the right place!
the input FETs may be better served by optocouplers with resistor+zener input protection, and series current limiting resistors on the input pins.
I need to look closer at the whole thing, but as mentioned, you CAN use an analog input for your extra digital input.

Physically breadboard it all up and check it does what you need.
The 100R gate resistors are probably a good idea anyway.

The solution is looking good !

[Falcon69]

thought I'd try your code before bed MC.

It doesn't work. It compiles successfully into simulation, but when it runs, All LED's turn on steady, and pressing buttons do nothing.

[SL4P]

I suppose if I was really keen, I can build up the circuit to test the cide...!
just a note - my code was taken from page 2 of the comments... not the later code that was posted... I wasn't thinking.

if the tail(running) lights are not 'controlled', they can be wired normally - straight off the car loom... or you can also toggle them to be the inverse of the sequencing if needed.  I'm not sure of the legalities.

[SL4P]

I think the error is in the if() code for the BRAKE_LIGHT
I'll think about it in my morning...

When I moved all the bits around, I think the brake lights are now always on!

The structure is ok, just the form of the if() terms need to be checked && not || or something like thatM

[alsetalokin4017]

Nice job --- breaking tested, demonstrated working code and posting non-working, non-tested code as a replacement !!   

[SL4P]

you tested it -thanks

[Falcon69]

The cost of the Optocouplers are fairly expensive.

Are the N-Channel MosFETs okay, the way they are in the schematic?  Will they turn fully off/on? It appears they do in the simulation.  I've just been reading and it seems the consensus is that you want to use a P-Channel for a high side switch, however, that would require more components (a NBJT or NMOS) to make it so that it inverses the signal coming from the uC to turn off the P-Channel when the lights are not switched on.

I'd rather keep the footprint as small as possible for this.

[SL4P]

Opto's are cheap <$1 ea, and they provide complete electrical isolation of the input pins.
They can be driven on either pole - hence high-side or low-side signalling.
Most opto's are NPN, so they are normally wired to 'pull-down' the output when triggered - fairly standard method - uses the internal pull-ups in the micro..

I'm not sure that I can contribute much more, as another poster is concerned the code I posted is not up to his spec.   I agree that I would write it differently if starting from scratch, but I tried to keep it the way it was -- with minor internal tidying - seemed to be the best starting point for you to explore without wondering what / why I did things...

I'd rather have late code that was reliable, than rushed code that had race conditions etc.

[Falcon69]

hmm, just noticed something in simulation.

If I hook power directly to the trigger going into Arduino for pin 8 (left side), then turn it to full on, it cycles once and then off. Power still applied.  Then, leaving power on the left applied, i click the right toggle switch to on. Both sides sequence, then stay lit.

Then, if i turn on and off the right side, the left side sequences, right side stays on steady. If I leave the right side in Off position, left lights then stay off, right side on steady. If I leave right side in On Position,  Both Sides stay on steady. This is true for operating switches on both sides. Same result is happening, just switched sides.

So, something weird is happening.

If I leave both switches in off position, I turn on the left, left side sequences and stays on steady. If I toggle it on and off, it sequences over and over again, as long as I keep toggle the switch.

There may be something wrong with the simulation, but, if there is not....when brakes are applied, this could screw everything up.

For example, if I have on Left turn signal, I then applied the brakes, the flashing will switch to steady on, and the right side will sequence.  That's bad.

If the simulation is right, then something is going on in coding. Or maybe another line needs to be added?

And MC, I appreciate your input, as well as the other posters. Everyone who has replied to this thread, I am thankful for.  Don't let others upset you. Post your opinions, I welcome all. I'm a newb.  Besides, arguments are good, helps me understand the differences. Just do it without flaming each other

[Falcon69]

I'm going to order these.... Which one to get? They don't look the same.

The one with the holes on both edges (12 and 6) looks like it has 6 more outputs for something.

http://www.ebay.com/itm/Arduino-Pro-Mini-ATMEGA328P-16MHz-5V-ATMEGA328-/201389987587?hash=item2ee3c75703:g:BzEAAOSwjVVVqJxa
http://www.ebay.com/itm/16M-ATMEAG328-3-3V-8Mhz-Replace-ATmega128-Module-For-Arduino-Pro-Mini-Compatible-/272081659240?hash=item3f5954a568:g:oZMAAOSwPcVVrNFs

[Falcon69]

well, I've messed with it for several hours. I even tried many different combinations of Logic Gates (NOR, AND, XOR, 3-input XOR, etc.) and I can't figure out what is happening in the simulation.

It appears to work in your video, but I can't get it to work in simulation.

I will try and search for a program that records screenshot and post it up of what the simulation is doing.

One thing I see, that may be causing it....When a switch (slide switch, not tactile) is switched on, the lights sequence once, then go off. Shouldn't they STAY on?  That would simulate the brakes being ON on that one side the switch has been toggled. 

But, when Both switches are on, the lights sequence once and stay ON.  I don't understand. I look at the code for BOTH switches on, and The code for if a Left (or right) is ON, the code looks the same.  I don't see anything that tells the Arduino to turn off the LED's at end of cycle (or leave them on).

Here's a Link to the online simulator and the file I was using, not sure if it will work for you, may have to sign up to use it.

https://123d.circuits.io/circuits/1439224-sequential-taillights/edit

[wguibas]

Hi I built this for my camaro,  It is based on arduino and TLC5940 chips.  It utilizes 17 vertical banks per side and can run up to 24 per side.  In your case you could combine outputs from the TLC's to drive the 240mA for each of the 6 LED's.  It takes inputs for Brake, Parking  Lights, and Turns Signals and outputs PWM for dimming and stuff.

Here is the original board I made along with the updated surface mount version:




and for all the engine fanboys, there is also a supercharger hidden under there.



I also used it in  an old Thunderbird with relays driven from the TLC's to drive the Bulbs.

[alsetalokin4017]

I'm going to order these.... Which one to get? They don't look the same.

The one with the holes on both edges (12 and 6) looks like it has 6 more outputs for something.

http://www.ebay.com/itm/Arduino-Pro-Mini-ATMEGA328P-16MHz-5V-ATMEGA328-/201389987587?hash=item2ee3c75703:g:BzEAAOSwjVVVqJxa
http://www.ebay.com/itm/16M-ATMEAG328-3-3V-8Mhz-Replace-ATmega128-Module-For-Arduino-Pro-Mini-Compatible-/272081659240?hash=item3f5954a568:g:oZMAAOSwPcVVrNFs

Don't try to save too much money here! The cheapest Chinese clones may be "buyer beware" kinds of items.
Look for ProMinis that have the holes labelled on top (the first one has labels on the bottom not the top), that come with header pins, either separate or pre-installed. I would suggest that you look for 5V versions rather than 3.3 volt versions for your application.

The extra holes on the first one are the 4 analog pins A4-A7 and headers for the serial communication. The second one has the 4 extra analog holes (not on the edges) but no serial comm pins. (When the ProMini is connected to its programming module it can do serial communication through it.)

To program the ProMinis you will also need the programming module (only one) :  something like this:
http://www.ebay.com/itm/3-Pack-Arduino-Pro-Mini-USB-Programmer-Newest-Design-USA-Seller-FAST-Ship-/231348215568?hash=item35dd6d9f10:g:6rEAAMXQ1d1TJ~JV

[Falcon69]

this is the one i ended up buying...

http://www.ebay.com/itm/281788992457

I haven't bought the other components yet. I'm still not sure on the mosFETs or Optocouplers to get. If I go with mosFETs, I'll need 6 of them to handle at least 243mA per. Since it is on a vehicle, do I need to look for an N-Channel logic level one with vds >12v and and vgs >12v?  I'm guessing ALWAYS keep rds very low.

For Optocoupler, I can't find anything on mouser's site that does more then the 243mA, They only have a couple, and those are >$1 each. If I go SSR, those are about $.075.  Thats more then double the cost of the mosfets. 

Also, the mosfets for the turn/brake input coming from the truck to the arduino....can that be the same as the other 6? (logic level)....I know it will have a ~12v input to the gate, but switching 5 volts.

Here's one of the mosfets I was looking at...
http://www.mouser.com/ds/2/149/FDN359BN-80801.pdf  It's cheap too, .165 when ordered in 100

[alsetalokin4017]

well, I've messed with it for several hours. I even tried many different combinations of Logic Gates (NOR, AND, XOR, 3-input XOR, etc.) and I can't figure out what is happening in the simulation.

It appears to work in your video, but I can't get it to work in simulation.

I will try and search for a program that records screenshot and post it up of what the simulation is doing.

One thing I see, that may be causing it....When a switch (slide switch, not tactile) is switched on, the lights sequence once, then go off. Shouldn't they STAY on?  That would simulate the brakes being ON on that one side the switch has been toggled. 

Yes, they should stay on, according to my understanding of your original requirements and the code I wrote. Is your switch working right? No loose contacts? Did you modify the code I wrote too much?

But, when Both switches are on, the lights sequence once and stay ON.  I don't understand. I look at the code for BOTH switches on, and The code for if a Left (or right) is ON, the code looks the same.  I don't see anything that tells the Arduino to turn off the LED's at end of cycle (or leave them on).

Did you change the logic that checks the Rstate and Lstate flags or something?

Here's a Link to the online simulator and the file I was using, not sure if it will work for you, may have to sign up to use it.

https://123d.circuits.io/circuits/1439224-sequential-taillights/edit

That simulator sort of works for me but seems to be glacially slow, slower than I'm willing to wait. All I can tell you is that the code I wrote does work on my breadboard.  I've added a two-stage brightness control using a simple CdS photoresistor (that I scavenged from a dollar "garden light" thing).

  (sequence rate control)
  (brightness level control)

I've taken out the first delay() statement at the top of the loop(), it was not needed. I also moved the LED pin assignments to the PWM-capable pins so that dimming would work. 

I checked the timing with my oscilloscope and the remaining delay(20) statements result in about a 40 millisecond delay between pressing the Brake switch and the first LED coming on. At 60 mph this translates into about 4 feet of travel.  The delay(20) statements need to be there because if read and write statements are too close together in time weird things can happen; this is a known quirk of the Arduino/Atmel system. I'd love to see if a Finite State Machine solution could overcome this problem...

Here's the code again, that I'm using in the video demonstrations above. It works.

Code: [Select]

/*--------------------------------------------------------------------------------------//
 3-Light Sequential Brake/Turn Signal Actuation
 (Both Left and Right sides)
 
 With Variable sequence rate and Brightness Control
 //--------------------------------------------------------------------------------------*/

int Bright = 0;  // variable to hold brightness level
int delayOn = 333;  // set sequence delay time in ms here
boolean Rstate=0, Lstate=0;

void setup() {
  pinMode (9, OUTPUT);   // Right: connect LEDs, relay drivers or mosfet Gates here
  pinMode (11, OUTPUT);
  pinMode (12, OUTPUT);

  pinMode (3, OUTPUT);    // Left: connect LEDs, relay drivers or mosfet Gates here
  pinMode (5, OUTPUT);
  pinMode (6, OUTPUT);

  //  connect Brake/Turn signal here (through divider or regulator to give ~4-5V when ON)
  pinMode (7, INPUT); // Right ts/b
  pinMode (8, INPUT); // Left ts/b   

  pinMode(A0, INPUT);  // potentiometer to control sequence delay
  pinMode(A1, INPUT);  // CdS photoresistor to control brightness level
}

void loop() {
  while (digitalRead(7)==LOW && digitalRead(8)==LOW) {
    // do nothing, wait for signal to go HIGH
  }

  //  Bright = map(analogRead(A1),0,1023,0,255);  // continuous brightness control
  if (analogRead(A1)<=512) Bright = 8;
  else Bright = 255;  // 2-level brightness

  if (!Rstate) {
    delay(20);
    // when Right signal goes High, actuate R outputs in sequence
    if (digitalRead(7)==HIGH && digitalRead(8)==LOW) {
      Rstate=1;
      delayOn = map(analogRead(A0),0,1023,0,500);
      analogWrite(9,Bright);
      delay(delayOn);
      analogWrite(11,Bright);
      delay (delayOn);
      analogWrite(10, Bright); 
    }
  }
  if (!Lstate) {
    delay(20);
    // when Left signal goes High, actuate L outputs in sequence
    if (digitalRead(7)==LOW && digitalRead(8)==HIGH) {
      Lstate=1;
      delayOn = map(analogRead(A0),0,1023,0,500);
      analogWrite(3, Bright);
      delay(delayOn);
      analogWrite(5,Bright);
      delay (delayOn);
      analogWrite(6, Bright); 
    }
  }
  if ((!Rstate) || (!Lstate)) {
    // when Brake (both) signal goes High, actuate R and L outputs in sequence
    if (digitalRead(7)==HIGH && digitalRead(8)==HIGH) {
      Rstate=1;
      Lstate=1;
      delayOn = map(analogRead(A0),0,1023,0,500);
      analogWrite(9, Bright);
      analogWrite(3, Bright);
      delay(delayOn);
      analogWrite(11, Bright);
      analogWrite(5, Bright);
      delay (delayOn);
      analogWrite(10, Bright);
      analogWrite(6, Bright); 
    }
  }
  delay(20);

  // when signal goes LOW turn off all outputs
  if (digitalRead(7)==LOW) {
    digitalWrite(9, LOW);
    digitalWrite(11, LOW);
    digitalWrite(10, LOW);
    Rstate=0;
  }
  if (digitalRead(8)==LOW) {
    digitalWrite(3, LOW);
    digitalWrite(5, LOW);
    digitalWrite(6, LOW);
    Lstate=0;
  }
}



[alsetalokin4017]

this is the one i ended up buying...

http://www.ebay.com/itm/281788992457

I haven't bought the other components yet. I'm still not sure on the mosFETs or Optocouplers to get. If I go with mosFETs, I'll need 6 of them to handle at least 243mA per. Since it is on a vehicle, do I need to look for an N-Channel logic level one with vds >12v and and vgs >12v?  I'm guessing ALWAYS keep rds very low.

For Optocoupler, I can't find anything on mouser's site that does more then the 243mA, They only have a couple, and those are >$1 each. If I go SSR, those are about $.075.  Thats more then double the cost of the mosfets. 

Also, the mosfets for the turn/brake input coming from the truck to the arduino....can that be the same as the other 6? (logic level)....I know it will have a ~12v input to the gate, but switching 5 volts.

Here's one of the mosfets I was looking at...
http://www.mouser.com/ds/2/149/FDN359BN-80801.pdf  It's cheap too, .165 when ordered in 100

That particular ProMini is not the one I would have recommended, personally, since it has the pin labels on the bottom (maybe, if you are lucky) rather than the top, and it takes at least ten days to get to the USA from Hong-Kong. You will still need to get the programmer module too.

The optocouplers only have to handle the Gate signals to the switching mosfets, right? Not the full current to the LEDs.

You do realize that an SOT-23 mosfet package is about the size of half a grain of rice, right? Are you able to handle printed circuit board design and construction with surface-mount components?
 

[Falcon69]

circuit boards are not a problem. I can place 0402 if I have to. I made a manual pick & place machine with vaccuum pick up tool  that indexes at 45 degree increments, and also with a double mounted Microscope.  And I made a toaster reflow oven.  My 3D printer came in handy for making it.

Ya, But I had already bought the ProMini before you said anything :/

Ones from the US are like 5x the cost for the same item.  I can wait

No, the LED's will have the full current going through the Source and Drain to switch on the LED's which at full brightness draw 243mA each.  The gate will be activated via Arduino ~5v.

[Falcon69]

i noticed in that new code, all the digital write were changed to analogwrite?

EDIT:  Oh, now I see why you did that. Because it now sees what the photo resistor is, before sending signal to the LED

[alsetalokin4017]

circuit boards are not a problem. I can place 0402 if I have to. I made a manual pick & place machine with vaccuum pick up tool  that indexes at 45 degree increments, and also with a double mounted Microscope.  And I made a toaster reflow oven.  My 3D printer came in handy for making it.

Excellent!

Ya, But I had already bought the ProMini before you said anything :/

Ones from the US are like 5x the cost for the same item.  I can wait

Often... you get what you pay for. I hope the units you bought from Hong-Kong work properly, don't get lost in the mail, etc.
A genuine SparkFun ProMini is about 10 dollars. Three clones, plus the programmer, for 18 dollars post-paid from a USA seller is still a pretty good deal IMHO.

No, the LED's will have the full current going through the Source and Drain to switch on the LED's which at full brightness draw 243mA each.  The gate will be activated via Arduino ~5v.

Yes, I understand that part. So what do you intend to use the optocoupler for? The "logical" way to use it would be to isolate the mosfet Gate from the Arduino, I thought. In that case you don't need some high-current rated device, at the slow frequencies we are talking about here.

[Falcon69]

oh, i was thinking of using it on the gate of the mosFET.

[alsetalokin4017]

oh, i was thinking of using it on the gate of the mosFET.

Right. So it doesn't need to carry the ~250 mA that the LED will draw, just the current necessary to turn the mosfet ON. Maybe something like VOM618A-4 would work.

[Falcon69]

so you are saying to do this.....

Arduino > NPN Optocoupler/Photo Transistor > P-Channel Logic Level mosFET > LED's

Instead of....

Arduino > N-Channel Logic Level Mosfet > LED's


What About the Turn/brake Wire> Arduino Trigger Pins 7 and 8? 

Do...
 12V (Brake/Turn Wire)> 78L09 > Pins 7 & 8

Or...
  12V (Brake/Turn Wire)> N-Channel Logic Level mosFET (same as other ones, too keep BOM Lower) > Pins 7&8

Or...
 12V (Brake/Turn Wire)> NPN Optocoupler/PhotoTransistor > P-Channel Logic Level mosFET (same as other ones to keep BOM Lower) > Pins 7&8

[alsetalokin4017]

so you are saying to do this.....

Arduino > NPN Optocoupler/Photo Transistor > P-Channel Logic Level mosFET > LED's

Instead of....

Arduino > N-Channel Logic Level Mosfet > LED's

No, I'd still use N-ch mosfets. Arduino>opto>Nch Mosfet, and logic level isn't needed because you can use the 12-14 V vehicle supply to drive the mosfet Gate through the optocoupler. If you need to invert the signal you can do that very easily in the software.

What About the Turn/brake Wire> Arduino Trigger Pins 7 and 8? 

Do...
 12V (Brake/Turn Wire)> 78L09 > Pins 7 & 8

78L05, not 09. This is the first thing I'd try, myself, since I have a bunch of 78L05s in my parts stash.
 

Or...
  12V (Brake/Turn Wire)> N-Channel Logic Level mosFET (same as other ones, too keep BOM Lower) > Pins 7&8

Or...
 12V (Brake/Turn Wire)> NPN Optocoupler/PhotoTransistor > P-Channel Logic Level mosFET (same as other ones to keep BOM Lower) > Pins 7&8

You should be able to do this part without a mosfet, just the optocoupler. Again, if inverting is needed it's easily done in the software. This is probably a better solution than using the 78L05 regulator; you'll be using the Arduino's 5 V regulated output through the opto to provide the "HIGH" signal to the input pins.

[wguibas]

To do the inputs all you need is a voltage divider.  Put the 12V/14V wire from the car through a 22K resistor.  Take a 10K resistor attach it to ground.  Join the 2 resistors together opposite their connections and connect the node of these 2 resistors to the arduino input.  It will see about 4.2V when the car is sending a signal. 

[alsetalokin4017]

I keep forgetting to ask... do your LED modules need a current-limiting resistor or are they designed to connect directly to the vehicle's 12-14 VDC without an external resistor? I'm asking because if a resistor is needed, it will probably need to be something like 50-56 ohms, 5 watts.....
(14 volt supply, ~250 mA.....) 

To do the inputs all you need is a voltage divider.  Put the 12V/14V wire from the car through a 22K resistor.  Take a 10K resistor attach it to ground.  Join the 2 resistors together opposite their connections and connect the node of these 2 resistors to the arduino input.  It will see about 4.2V when the car is sending a signal. 

Yes, that's good too. Probably still better to use an optoisolator just to be safe.

[Falcon69]

NO, I don't need to invert the signal...I just suggested the P-Channel because the Power needs to go INTO the LED's.I just heard it was better to use P-Channel for high side switch.  But that would mean I'd have to invert the signal, hence why an NPN photo transistor.

As I have the schematic now..it goes like....
Vehicle 12v > Drain N-Channel mosFET through Source of mosFET > LED's > Ground

Since the LED's share a Common ground for the Turn/Brake and for the Tail Light (running Light).....I have to run it as a High Side. Switching the common ground is not acceptable, as it would make the running lights flash when turn signals are on...Don't want that happening. Running lights need to STAY on (separate LED's not connected to the turn/brake LEDs within the LED modules themselves)

If the N-Channel still works for that configuration, I'd rather use it. I never liked using P-Channels as switches. But, I'm a newb, what do I know.

The LED's are connected directly to the vehicles factory Turn/Brake, Ground, and Taill Light wires that are already in the back of the truck.  Basically, we cut the wires going to the existing factory taillights, and wired the LED's in.

Voltage Divider would work, however, What if there is a spike voltage? Wouldn't that damage the arduino? a mosfet or optocoupler would provide protection, wouldn't it from that?

[wguibas]

The divider would handle greater than 16V and still not blow the arduino.  Other electronics in the car  would blow up before the atmel.
I've had this in my car for years now and it works fine.   Unless a 10K ground resistor goes bad the atmel is safe.

[Falcon69]

okay, that would svae some money too.  Are you using 1/2w fort those?

[wguibas]

1/8w is fine, it draws no real current, its just signal.

[Falcon69]

okay, thank you

[wguibas]

Something you might want to consider.  If your gonna run a constant lead to the back of the car to power the arduino 24/7 it's gonna put a draw on the car battery when the car is parked.  I found with mine I could power the arduino through diodes from the input wires before the divider circuit and the arduino booted up so fast, instantaneous, that the brakes would work if pressed with the car off and the parking lights would flash with my car alarm etc.    I then ran ignition source to power the board when the car was on.   You can see this on the board jpg in the previous post.

Also when you have it together let it run and feel the temperature of your regulator.  Mine was a 7805 to power the atmel and TLC's and when it got hot the program/operation got wonky, dissipating 9V in heat was too much even with only a few hundred mA.  I changed it to a switching RECOM regulator and other than the price hit ($5-$7), all has been great.   You seem to be going down to only 9V and don't have the TLC's chips, so it might not be a problem.

[Falcon69]

no, the 12v constant wire would be hooked up to a relay, via the ignition and battery. ALL power should be off

Oh, wait, that won't work, the Flashers won't be on, hmmm.

Maybe I can run two relays, one to power on if the flashers are activated.. keep the relays up front, then run the wire back.

[wguibas]

But you not only want the flashers to work with the car off, but the brake lights too.  Also if you end up putting the parking lights thru your circuit then them also.  The power feeding the bulbs now from the truck is more than enough.  In my car if I push my brake with the car off, 12V goes to the back and flows thru a diode and powers my regulator to power the arduino and the brakes light up. Same thing with my parking lights and hazzards.  The diodes keep the juice from the brake circuit flowing into the parking lights and hazzards and vice versa.  It ended up being a very simple solution that works great.   


By the way what type and year of truck does your nephew have?

[Falcon69]

I'm worried about this.

hooking up to the Barke/Turn/Hazard wire to run the arduino.

#1...
The Arduino would turn on and off during flashing
#2...
The Arduino would Reset half way through left/right turn signal, because the flashing state of ON/OFF

If I put a big capacitor on that wire to ground, then, the sequencing wont work, nor flashing, as the arduino needs that wire to sense the flashing.

I thought about maybe running a wire back connected to the ignition to power the arduino as well, but then that comes back to the same problem as #2

[wguibas]

The turn signals would be covered by the ignition source with a diode also.

[Falcon69]

i don't understand.

Let me try and draw this, maybe I can figure it out.

Can't figure it out.
If I use a Relay/Mosfet to turn of the i....................
hmm, nm, I don't understand how to do it.

[wguibas]

12V comes in on the input pins  travels to the diodes for each input and feeds the regulator to power the board.  If the ignition is on it also is on the input harness and has a diode so it powers the board if the car is on.  Once one of the inputs provides power the board comes alive.  If the ignition is on and the turn signal is activated the board is already on from the ignition so the power from the turn signal input has no change in the power to the board, it's already on.    You can't see it on the picture but the inputs also feed the voltage divider resistors to trigger the arduino inputs.



The traces that feed the voltage divider cant be seen because they are on a layer disabled.

Here you can see their traces:

[Falcon69]

okay, but isnt having the arduino turn off/and on many times over and over again (as in ignition off, arduino powered from turn signal/hazard) bad for it? It doesn't have a lifespan on it based on how many cycles of off/onn....like batteries do?

I know when I was doing car stereos, that the constant draining to zero and recharging, only lasts for about 1-3 times on a conventional car battery, unless you had an optima Deep Cycle.

I'm not sure if the Arduino works the same or electronics in general.

The other thing....that would be there would be a delay in charging/discharging the capacitors, which couold result in delay of lights turning on...I guess with ignition off, that doesn't matter much, unless towing the vehicle.

[wguibas]

The arduino is not a battery, it's a computer.  It has no problem turning on and off.  On the old thunderbird I did, I did have to up the capacitors and add a relay in line with a capacitor to clean up the noisy 50 year old brake pedal switch output.

What year and model truck does your nephew have?

[Falcon69]

FYI, just so you all know....

And, I hate that it is the fact....I am a visual person. I have trouble understanding things, until I see it drawn or a picture of it or see it working. This is why I have so much trouble in college. I can't see and understand much, unless I see a schematic or drawing of it, then the wheels in my head start working and then I understand what is happening.

Just be patient with me, I'll figure it out.

I'm like a grenade with some things. Gotta pull the pin and wait a minute! 

The truck is a 1997 Dodge 2500 Cummins Diesel

Okay, I was just concerned with the Arduino cycling alot through On/Off.  I'll redraw my schematic, and post up.

[wguibas]

Not a problem, I'll look up the schematic for the truck and see what your best options are.   

[alsetalokin4017]

NO, I don't need to invert the signal...I just suggested the P-Channel because the Power needs to go INTO the LED's.I just heard it was better to use P-Channel for high side switch.  But that would mean I'd have to invert the signal, hence why an NPN photo transistor.

As I have the schematic now..it goes like....
Vehicle 12v > Drain N-Channel mosFET through Source of mosFET > LED's > Ground

Since the LED's share a Common ground for the Turn/Brake and for the Tail Light (running Light).....I have to run it as a High Side. Switching the common ground is not acceptable, as it would make the running lights flash when turn signals are on...Don't want that happening. Running lights need to STAY on (separate LED's not connected to the turn/brake LEDs within the LED modules themselves)

If the N-Channel still works for that configuration, I'd rather use it. I never liked using P-Channels as switches. But, I'm a newb, what do I know.

The LED's are connected directly to the vehicles factory Turn/Brake, Ground, and Taill Light wires that are already in the back of the truck.  Basically, we cut the wires going to the existing factory taillights, and wired the LED's in.

Voltage Divider would work, however, What if there is a spike voltage? Wouldn't that damage the arduino? a mosfet or optocoupler would provide protection, wouldn't it from that?

Ah... I see. Common cathode for running lights and brake/ts. I missed that bit of info somehow, sorry.

OK, so it looks like you will have to use P-ch mosfets in high-side switch configuration. So the NPN optoisolators will do the necessary inverting for you. Simples.

Except for a P-ch mosfet the Source goes to the +12 rail and the Drain goes to the LED Anode.
So +12V > Source > Drain > LED > Ground. (If this is confusing, consider the polarity of the body diode in the mosfet. If you connect Drain to +12 v as with N-ch mosfets, this diode will be forward-biased and will conduct.)
And LED will be ON when Gate signal is LOW, so the inverting optocoupler circuit for the Gate will provide correct performance with no change in the software, I think.


As far as powering the Arduino directly from the signal lines.... well, it does take a while for the Arduino to boot up and start working. From applying power to first light flash takes 1.5 seconds, in the setup I'm using.

[wguibas]

If it's taking 1 and 1/2 seconds to light,   do you have any delays in the setup? The other possibility is mine was designed on and Arduino UNO R3, maybe they have different bootloader delays?  My finished board has the bootloader removed.

Here is mine on the bench:

https://youtu.be/ZQPOCtNm95Y

Just to test, I took a regular UNO CHIP with bootloader and uploaded the sketch via USB and dropped it in my board.  Still quick startup

[Falcon69]

video is private, can't see it.

[wguibas]

fixed, forgot to push publish

[alsetalokin4017]

That's amazing. I know I've never seen an Arduino boot that fast. To test, I just wrote this simple sketch:

Code: [Select]


setup(){
pinMode(8, OUTPUT);
}
void loop(){
digitalWrite(8, HIGH);
}


... and on my genuine Italian made Uno R3, it still takes over a second and a half for the LED to light up after power is applied to the Uno's power-in jack.

So I can only conclude that you are some kind of magician or something.....   

[alsetalokin4017]

Meanwhile, back at the ranch....

Here's a demonstration of using a High-Side Switch P-channel mosfet, with Gate isolated using an inverting optoisolator topology, to switch one of the LEDs on my breadboard test system:

[wguibas]

i appreciate your sarcasm, I guess maybe your not a magician.  The video doesn't lie.  Good luck on your ranch.  I am from NY things move faster here.  I'll see if I can figure out why yours is going slow, maybe it's all the optoisolators.

[alsetalokin4017]

i appreciate your sarcasm, I guess maybe your not a magician.  The video doesn't lie.  Good luck on your ranch.  I am from NY things move faster here.  I'll see if I can figure out why yours is going slow, maybe it's the all the optoisolators.

There is no optoisolator or any delay in my Uno test, just one single LED directly connected to the Pin 8 by a 220R resistor. Nothing else. And as you can see the boot-test sketch is about as minimal as it gets.

No, I'm not a magician, I just build and test, build and test. Maybe Falcon69 should just buy one of your boards, instead of messing about with all this other stuff.

[wguibas]

Your slow boot is your bootloader.  Update it to the optiboot one which I just did on a nano and the delay is gone.  Apparently some boards probably the chinese clones come with the optiboot one already.

the optocoupler comment was sarcasm, kinda like the magician comment.

If he wants one of my boards, he just has to ask, it would still need to be adapted to his task. 

Arduino Nano with optiboot
https://youtu.be/tdtlqz64KmM

[Falcon69]

Thank you guys for the videos, and good advice on the bootloader. I will check that once my boards get in.

Thank you Alse..
I can see how the mosFET P-CH is working now. Good.

I think something is wrong with that simulation program I posted.  The lights are still acting weird when brakes are pressed.

I am enjoying, with your guys help, figuring this out. It's one thing to buy the board from someone, then to figure it out, see how it works, do some of the programming and actually understand it.....then it is to just buy one already made.

I like the features of yours wguibas, however, for this truck, it's not feasible, as I cannot break open the LEDs and connect them individually to each of the 10 leds inside each module to get the cool fade/chaser effect while sequencing.  These lights just represent a big 6inch oval LED. Besides, the way he has them mounted, it just wouldn't look right. He has each of the three LED's mounted sloping upward...not in a line like the old 66 mustangs.

However, for my car, a Mazda 6s with aftermarket LED taillights, I plan on doing something like your Camaro, once I learn all this.  I will need to break open the taillights with a Dremel, rewire, then glue it back up. Sounds fun.

Anyway, I redid the schematic, let me know what you think. I think I got it all correct. Correct me if I am wrong.  The Optos will probably be a cheap 4 pin SMD, if I can find one cheap.

[Falcon69]

I was just thinking....

If there was some sort of delay...that wouldn't be god if flashers are on without ignition.  It would not sequence correctly, because of the delay.

So, Is there somehow a way of having a cap to store the energy during the delay of the sequential....that would draw power from the brake/hazard/turn wire to charge it, and supply it to the 78L09 chip...keeping that on continuously until the cap drains without interrupting the sequencing flash rate of the wire?

[wguibas]

Just quick looking at the schematic, You have to add a diode on the ignition line to keep the inputs power from backfeeding to the front of the truck.  Q9 and Q10 are unnecessary.   As far as the hazards working with the ignition off, it could be addressed as a timing thing in programming to have the sequence be as long as the hazard flasher has the wire at 12V.  Then it would cycle all 3 LED's and lose power.

   The problem I see with the setup is the whole 3 step sequence on the brake for the first sequence and the turn signal being on and hitting the brake.  The other side would do a sequence the opposite way for the first sequence.  There is no way to know if the hazards are on or the brake is being pressed in the program? I really think you need to add another input for the brake separate and isolated from the turn signals.  If you grabbed the wires from the front of the truck under the dash at the brake pedal and by the turn signal switch, then you could have true brakes lights and sequential signals and program the logic to know what to display in the back better.

[Falcon69]

yes, thats exactly what the simulation is doing....

hmm, so that would be two additional wires coming back. One for ignition, one for brake pedal. I was trying to not do that.

so have the last LED pin that after it lights, have a small delay, then code to turn off ALL LED's?  Then Arduino resets and starts over?

But, that would mess up the Brake Lights.....unless I do run another wire back. I was hoping NOT to do that. One wire for ignition was more then I wanted, but if it has to be done, it has to be done I guess.

[wguibas]

You really need 4 wires to the back.  Left, Right and Brake and Ignition.  The Left and Right at the back of the truck already have the brake signal mixed in.  You need to get them all from the front under the dash to really do it right.  Your logic in the arduino can then put all 3 lights on simultaneously for the brake, see when a turn signal is on  change accordingly,  and if it sees both left and right with 12V interpret that as hazards and display your hazard routine.  If the brakes come on with the hazards on it can immediately change to brake lights until the brake is released. 

[Falcon69]

grn/yellow, tan/blk are the ones going to the front turn signals, i am guessing, since those do NOT have the brake mixed in.  Ya, I see your point.

Sounds like I need another input into the Arduino for brake wire, and then modify the code just alittle bit for that new input.

Damn, I was really hoping NOT to do it this way.

[wguibas]

It's more work, but the output and the control will be so much better.    Good night I'm going to bed.

[alsetalokin4017]

Your slow boot is your bootloader.  Update it to the optiboot one which I just did on a nano and the delay is gone.  Apparently some boards probably the chinese clones come with the optiboot one already.

the optocoupler comment was sarcasm, kinda like the magician comment.

If he wants one of my boards, he just has to ask, it would still need to be adapted to his task. 

Well.... what do you know. These ProMinis I have are from SparkFun, just got them a  month or so ago, and they do _not_ have the Optiboot bootloader. The Uno I have is a year or more old and it also does not have the Optiboot bootloader. I see that SparkFun is now including the Optiboot bootloader with new Unos, but apparently not with ProMinis.

So I dug around, and found out how to install the Optiboot loader onto my ProMini using the Uno as programmer. And sure enough, it made a big difference. Now the delay from power on to first LED lit up, using the full code I wrote for the Sequential Signals, is a bit over 110 ms, instead of the 1500+ ms it had before.
And with the minimal sketch just lighting one LED, the delay from power-on to light is a hair over 70 ms. This is a huge improvement in boot-up time.   

So thanks, now I'm a magician too !!

(The only catch is that now I have to select "uno" instead of the Pro Mini as the board when uploading sketches.)

I have a couple more Chinese Pro Mini clones coming in a few days, it will be interesting to see which bootloader they contain.  The Green LED on Pin 13 flashes once on reset for the old bootloader, and three times very fast on reset with the Optiboot bootloader.

110 ms is about 10 feet at 60 mph, if I did the math right.

[alsetalokin4017]

Ah... a little further experimentation reveals that my Pro Mini with Optiboot doesn't "reset" each time power is applied, so it's not really rebooting. When the "reset" button is pressed, it still takes about a second and a half before the sketch starts running and the LED comes on. The clue to this is that the Green Pin 13 LED doesn't flash each time power is applied, it only flashes (3 times quickly) when the reset button is pressed. Before, with the old bootloader, it reset automatically when power was applied (green LED flashed once), hence the delay before the sketch ran.

[alsetalokin4017]

Thank you guys for the videos, and good advice on the bootloader. I will check that once my boards get in.

Thank you Alse..
I can see how the mosFET P-CH is working now. Good.

I think something is wrong with that simulation program I posted.  The lights are still acting weird when brakes are pressed.

I am enjoying, with your guys help, figuring this out. It's one thing to buy the board from someone, then to figure it out, see how it works, do some of the programming and actually understand it.....then it is to just buy one already made.

I like the features of yours wguibas, however, for this truck, it's not feasible, as I cannot break open the LEDs and connect them individually to each of the 10 leds inside each module to get the cool fade/chaser effect while sequencing.  These lights just represent a big 6inch oval LED. Besides, the way he has them mounted, it just wouldn't look right. He has each of the three LED's mounted sloping upward...not in a line like the old 66 mustangs.

However, for my car, a Mazda 6s with aftermarket LED taillights, I plan on doing something like your Camaro, once I learn all this.  I will need to break open the taillights with a Dremel, rewire, then glue it back up. Sounds fun.

Anyway, I redid the schematic, let me know what you think. I think I got it all correct. Correct me if I am wrong.  The Optos will probably be a cheap 4 pin SMD, if I can find one cheap.

You're welcome. Re your schematic: If you want the variable brightness, you need to connect the output optos to the PWM-capable pins which are 3,5,6 and 9,10,11 only. You have connected to 3,4,5 and 10,11,12. This may be why your simulation is giving you strange results if you are using the sketch I posted. Only 3,5,6,9,10,11 are dimmable using the analogWrite statement, the rest of the pins can only go High or Low.
I agree that Q9 and Q10 aren't needed on the input side, you could just use the voltage dividers ... but optoisolators in these places might be a good idea.
The value of R27 will probably need to be adjusted depending on the particular CdS photoresistor you use for PH1, there are a wide range of resistances for those things and you'll just have to measure yours to see what the appropriate value for R27 should be.

[wguibas]

Glad the optiboot is working faster for you.  The chip is still resetting/rebooting when it's powered up, it's just the optiboot loader doesn't waste time flashing the LED. When you press reset and it takes longer that must be part of the optiboot  bootloaders program so the user can confirm they pressed reset.  The bootloader is a sketch itself with logic.  The LED flashing every time on the regular bootloader is part of it's program.  If you remove the bootloader all together and load the chip with ICSP then there is ~no delay at all pressing the reset button.  The LED stops blinking as long as you hold the reset button then starts blinking immediately when released.
If you want to further test this, you could write a sketch that blinks 1 led in the main loop, after a delay or number of times have it blink a different LED or rate change of the same LED in an endless loop subroutine.  then remove power and reapply power.  If the main loop routine reruns, then the chip is resetting.

Update:
Upon further thought, It would probably work like this.  The atmel chip has a power up from reset register.  The bootloader  reads this register and determines what to do.  If it powers up with no reset set then the optiboot proceeds directly to the program,  If the reset flag is set then it waits 1.5 seconds for data on the RX/TX for a new sketch to be downloaded. If no data starts showing up then it proceeds to your program.  When you send a new sketch from the arduino software, the usb loader chip pulls reset on the atmel low and then releases it and starts sending the new sketch.

This is from the datasheet about the External RESET register.

• Bit 1 – EXTRF: External Reset Flag
This bit is set if an External Reset occurs. The bit is reset by a Power-on Reset, or by writing a logic zero to the
flag.

110 ms is about 10 feet at 60 mph, if I did the math right.

Does it take 110ms for the light to light up when the chip is already running?   The board would be powered from ignition if the car was going 60mph. 

[alsetalokin4017]

No, if the ProMini is already running it takes a bit over 40 ms from input signal going HIGH to first LED lighting up, using my sketch. This is too short to perceive visually but is equivalent to a bit under 4 feet of travel at 60 mph.

Somebody said using a FSM could get rid of the delays (there are two delay(20) statements involved which improve reliability by separating reads and writes a little in time) .  But really, my sketch is a state machine in disguise anyway. I'd like to see if a formal FSM using case and switch statements could in fact get rid of these delays and operate faster, but I'm not willing to write one at this time.

Re the reset issue (OT, I suppose) :
I have another ProMini that I also flashed to Optiboot last night. It's sitting in a breadboard to test an optical encoder routine. Now, when power is applied to it, sometimes it looks like it does not restart the sketch, so twirling the encoder or pressing its shaft-button doesn't do anything. The power led on the board is on normally but nothing is happening. I have to press the board's reset button to reset the board and get the sketch running again. This happens about half the time on applying power, and it didn't do this before the Optiboot. I haven't been able to get the Sequential Taillight board to act this way, it looks like it restarts normally every time power is applied. Got any thoughts about what might be going on here?

[Falcon69]

Isn't there something I can do to the code to make it so I don't have to run those extra wires?

Like take out the Brakes on statement where both wires have to be on.....and make it like if left blinker is on for more then 666ms, then it stays on till it goes low....same with the left side.  If the brakes are applied, then both sides would stay on.  Treat both sides as individual.

So when the turn signal flashes on for 1/2 second, then it goes off, the sequence will reset once it flashes to on again, however, it would sense that the ON state of that turn signal has passed the 1/2 second mark, and thus all led's for that side stay on until the signal goes low again.

Put in a potentiometer to control this, just in case the vehicle's flasher relay isn't 1/2 second, but is 0.6 seconds instead, or something.

Because, in simulation, wguibas is right, it does change to left turn signal LEDs when the physical right turn signal goes high, if brakes are already applied.  So, I would think the Arduino would no longer do that if the brake statement

Code: [Select]

  if ((!Rstate) || (!Lstate)) {    // If lights are already on, skip turning them on again
    // when Brake (both) signal goes High, actuate R and L outputs in sequence
    if (digitalRead(RightTurnSwitch)==HIGH && digitalRead(LeftTurnSwitch)==HIGH) {
      Rstate=1;
      Lstate=1;
      delayOn = map(analogRead(A5),0,1023,0,500);
      analogWrite(LeftInnerLED, Bright);
      analogWrite(RightInnerLED, Bright);
      delay(delayOn);
      analogWrite(LeftCenterLED, Bright);
      analogWrite(RightCenterLED, Bright);
      delay(delayOn);
      analogWrite(LeftOuterLED, Bright);
      analogWrite(RightOuterLED, Bright);
is no longer in the code

And thank you alsetalokin4017....the code for the dimmer works correctly in simulation now. I didn't know about the PWM thing on the pins. I fixed it in simulation.

On a side note...the 'const int' statement to define a pin number is nice. You verify what each pin is named, then in all the code you write in the name. When you need to change a pin, simply change it in the 'const int' statement, and it changes everything else. I like that feature, saved some time. 

[wguibas]

Re the reset issue (OT, I suppose) :
I have another ProMini that I also flashed to Optiboot last night. It's sitting in a breadboard to test an optical encoder routine. Now, when power is applied to it, sometimes it looks like it does not restart the sketch, so twirling the encoder or pressing its shaft-button doesn't do anything. The power led on the board is on normally but nothing is happening. I have to press the board's reset button to reset the board and get the sketch running again. This happens about half the time on applying power, and it didn't do this before the Optiboot. I haven't been able to get the Sequential Taillight board to act this way, it looks like it restarts normally every time power is applied. Got any thoughts about what might be going on here?

If you could take a picture of your breadboard setup and also list what pins you have hooked up for I/O maybe we could get to the bottom of this.

[wguibas]

Falcon69

What your asking could work, but the problem is your gonna have a lot of extra sequential activity when it's not really desired.  I need to look at more of your code, one problem I see in the snippet posted is while that routine is running with the sweep, nothing is being monitored for change.  whats the value of the delayon variable approximately? 

Just curious where are you located?

[Falcon69]

I am in Vancouver, WA

The delayOn variable depends on the Potentiometer. The delay between the sequence is adjusted by that.

[wguibas]

  The reason I'm asking is if the rest of your code is written like this routine then when you put a turn signal on and push the brake, the brake won't come on for up to a second while the routine is finishing.

[Falcon69]

interrupts then?

[alsetalokin4017]

I don't understand.  Did I not demonstrate all possible states, with correct operation?  If brakes are on (both inputs HIGH) and then the turn signal is actuated (one input goes LOW when vehicle's flasher tells it to, then goes high, low, etc.) only that side flashes and sequences, the other side stays on steadily. As it should, right?

Or if a turn signal is flashing, and brakes are applied, the non-turnsignal side sequences once and stays on until the brake is released, while the turn signal side continues to blink as told to by the vehicle's flasher, and sequences each time. If the turn signal stops blinking while brakes are on, both sides stay on until the brake is released.

Isn't this the way it's supposed to work?

If your simulation is doing something else, then there may be something wrong with the simulation or the code you entered into it. The code as I posted it works as shown on my breadboard in the demonstration videos.

The code snippet up above only runs once per both inputs going high then exits with all lights on, and they stay on until they are turned off by the input signal(s) going low by another part of the sketch. True, during that one sequence lasting under a second, if something else happens the sketch doesn't detect it. But as soon as the one sequence is done and the state exits with lights on, whatever happened will be detected and acted upon.

I've made another video showing the possible states. They seem to be working properly with no untoward delays, no undetected states, no false side-switching, as far as I can tell.

http://youtu.be/pHKLdWdgrxs

  The reason I'm asking is if the rest of your code is written like this routine then when you put a turn signal on and push the brake, the brake won't come on for up to a second while the routine is finishing.

This is only true for unreasonably long delayOn() times.

[Falcon69]

Yes, Video is correct.

but simulation isn't working that way.  it may just be the simulation program being weird.

when i get parts in, i'll wire it on breadboard and hook up to truck.

wguibas said something earlier that may happen with the cicuit, and exact thing happens in simulation.

when brakes are on, turn on left turn switch and right side blinks. 

[wguibas]

Looks good to me.   

[Falcon69]

alsetalokin4017,

I redid the simulation, erased the code, copy/pasted your code again.

I then deleted the mosFETS and just ran LED's with Arduino Pinout > Resistor > LED

It works as in your video now.

So Either I did something with the code, or the HighSide N-Channel mosFET I had on there was messing something up.

I will try now, without touching the code, apply a P-Channel mosfet via a 4n35 Optocoupler, and see if I still have it operating correctly.

[Falcon69]

okay, that works.

The only thing I really had changed in the code was you had Pot and photo resistor on pins A0 and A1.  I HAD those at A4 and A5.

So If tat was okay, then maybe having the high side mosFET n-channels were creating some kind of a feedback that was messing up the Arduino?

Hell, I don't know, it works now.

[Falcon69]

little lost

I am looking for a logic level P-Channel mosFET (or do I need logic level now that I'm using a 4n35/4N25 Optocoupler?) but all the logic level ones all have negative values for the vsd, ld, and Vgs th.  I don't understand the negative thing.

Just trying to get these parts ordered.

I need a mosfet that can be triggered by the 4N35/4N25 and handle at least 234mA, as that is the current throuogh those LEDs (each one)

Is there a cheaper Optocoupler i can do as well? They are about 17 cents each at Mouser for the 4N25. That's not bad, Im sure they are cheaper from eBay.  I prefer to find all these components needed in through hole to test on the breadboard, but ultimately, I want to make a very small package (PCB no bigger then the Pro Mini itself) that I can fit into a small project box for this...as small as I can.  So I want all these components to be available in SMD as well, without changing much of the specifications on them vs their through hole version.

[Falcon69]

Think I found something that works...

I found a picture from another forum.  I modified it just alittle bit. It was using a standard NPN bjt (instead of optocoupler). It did have a pull down resistor on the base (so that pin on arduino is forced low, though, as an output pin, does it matter?).

It had values changed for the pullup for the p-channel mosfet, so it would turn off faster. Which may not be a bad idea in a LED flashing circuit.

It used a ZXMP6A17GTA mosFET
http://www.mouser.com/ds/2/115/ZXMP6A17G-77699.pdf

Looking at the stats of that mosFET, I found a cheaper one that I think will work?

By specifications, I looked for negative values for ld -continuous drain current, Vds - drain-source Resistance, and positive value (±) for the Vgs - Gate-Source Breakdown Voltage.

Both chips have a Vgsth of -1v

So I was thinking of this chip, just 9.3cents each (100)
http://www.mouser.com/ds/2/115/DMP3099L-266220.pdf

It has a large ld (-3.8A) so it should never get hot having only a current draw of 243mA on it.

Will this work?


Someday I'll try and understand what all the specifications mean. I thought I had it (when I was looking at NPN/n-Channel stuff, but with PNP/P-Channel....those negative values throw me off)

[Falcon69]

Got an update to the Schematic.

Now, on the schematic, I'm guessing that R13-R18 should be 1/2W? Or more?  Is 10K too much?  I don't want the mosFETs turning off too slowly.

Also, 16V be okay on all the caps? Or should I go 25 or 35v?  And C1 0.33uF....the data sheet did not specify for the 78L09. Is that one an electrolytic while the C2 0.1uF is a Cermic?

C3 100uF is electrolytic.

C4 can be ceramic?

For the diodes, I have a bunch (like 500 of them) that are 500mw 150mA, will those be okay?

R5 okay to be 1/4W or even 1/2W Trimmer?

For the mosFETs, i was thinking these:
http://www.mouser.com/ds/2/115/DMP3099L-266220.pdf <---- those be okay for this project?

Is there anything that you would change? Values, etc.?

The Photocell I bought says it is
   - Light Resistance: 30-50Kohm
   - Dark Resistance: 3Mohm

Also, I was thinking, for those.  I would solder each leg, shrink wrap it, then cast it in resin to help protect it. Then I would drill a hole in the bumper and mount it.  That way, while the rest of the circuit is buried in a box under the truck, this would still see light.  Will the clear resin interfere with its operation?

Thanks for your input. I'm looking forward to ordering the parts and gettin this thing assembled.

Just need a second opinion on the components, before a waste the money on them.

Thanks in advance

[wguibas]

You still need to add the diode on the ignition wire.

[Falcon69]

OKay, but other then that, will all the stuff (i have and what i need to order still) will work? I'm alittle worried about the 500mw Diodes, but, there's not much power going through those, i Don't think

[wguibas]

I used 1 amp diodes because that what I had around and they are cheap.   You need to see how much the chip draws and the LED side of the optocouplers thru their 220R resistors.    My chip and TLC chips draw a little under 200mA when driving the Lights.  150mA probably wont be enough with the chip and the six optocouplers.

[Falcon69]

okay. i will get 1A ones. thank you

[wguibas]

all you need is ones like these

SMT  .43/1  or $2.40 for 10

http://www.mouser.com/Search/ProductDetail.aspx?R=CGRM4004-Gvirtualkey59960000virtualkey750-CGRM4004-G

thru hole
http://www.mouser.com/ProductDetail/Fairchild-Semiconductor/1N4004/?qs=sGAEpiMZZMuQUXCJI7Y4lnwnhMohE%2fNv

[Falcon69]

great, thank you. I have some 1N4001 in do-214 package, Alittle big, but I got like 200 of them.  The voltage dropped across them is high.  But the ones you linked are smaller in size. I'll order some up.

All the other components are okay? Caps/resistors/optos/mosfets?

[wguibas]

Sorry for the delay, had to look at the datasheets for your components.  You only need 1/4 watt resistors for all in the project.  R13-R18 are just pull-up resistors 1/4W is fine.   The 220R resistors would flow about 16mA current to drive the LED side of the optocoupler which translates to about .054 watts, less than half of an 1/8th Watt resistor.  The optocouplers look fine, should be more than fast enough, 2us switch time.  The P-channel Mosfets looks fine for the task.

[SL4P]

@wguibas - I admire your patience on this project!

[wguibas]

I did nothing, probably muddied the water if anything,  alsetalokin4017 gets all the credit on this one. 

[Falcon69]

Well, making progress.

There's still lots to do, but I was able to get all the components and traces routed on a pcb size 27.94mm x 43.18mm .

The Arduino Pro Mini would sit about 12mm above the board on Headers. You can see about where it would be by the square box silk screen.

The potentiometer is actually sitting wrong in the video. It actually lays flat with the adjuster facing north (north as in up in the picture). I'm hoping to cast the whole thing in resin, leaving just the turn thing for a screwdriver to get to the potentiometer. Once under the truck and adjusted, A dab of epoxy should keep water from getting in and keep it safe.  That's the theory anyway.

The Photo-sensor is not on there, but you can see the squiggly silk screen line...those are the pins it is connected to.

There's still lots to do, lots of fine touches to the traces and pouring of the copper on bottom side.  Not too mention the correct naming of the reference designators to match the schematic and adjust the lettering so they can all be seen.

Whatcha think so far?

[Falcon69]

Well, got the Mini's in today. I ordered 5, cost me less than $10 total.

Upon first initial inspection...man these things are small!  I didn't think they were this small.

The quality of the boards are pretty good (I'm comparing them to boards I have ordered for myself from china fab shops). The traces are clear, and the silkscreen is sharp.  I'd like to find out the manufacturer of the PCB's. I'd have them do my stuff.

Anyway, the soldering job looks pretty good too.

I have not tested them yet, as I am still awaiting further components, i.e. FT232 UART thingy.

Upon further inspection, they are using 0603 components.  I wonder if I can make this thing smaller using 0402 components, and switch around the header pins.

[Falcon69]

I just now thought of something else.

The tailight (or running lights which turn on when headlights turn on).....will those automatically dim as well?  I think they will, since that part of the circuit won't be touched at all. It's still connected to the truck...not going through Micro-Controller.  If so, I guess more code needs to be written with another mosFET/optocoupler/photosensor?

[wguibas]

You said the running/park lights have their own wire on the lights, which light up separate LED's that are dimmer than the brake/turn signal ones.  Is that not the case?  If it is the case then they are completely independent from the circuit.  I thought the dimming you were looking for was for the night time dimming from your photo sensor for the Brake lights and turn signals.   I guess your gonna have to put it all together and see how it all looks and then decide if it's good or not. I really don't see the point of dimming the Brake lights at night, they should be as bright as they can be.  I don't think production cars do that. 

[Falcon69]

ya, my car does it, when i turn on my headlights...but I agree, maybe they should be as bright as possible, alot of people, drive during the day with the headlights on.

Yes, that is correct, the running light is separate.

Can I ad a jumper, so that if I don't like the lights dimming at night, it won't. Will placing the jumper in line between the arduino and the photo sensor work? or will it be all messed up if it does not receive a signal from it. ?

[Falcon69]

oh, i see (from simulation), I will need to put the jumper between the photo resistor and the ground. Jumper is out, the arduino doesn't see the photoresistor.

[wguibas]

what kind of car do you have?  Your saying if you push and HOLD the brake, then turn on your headlights, that the brightness of your Brake Lights gets dimmer?   If that's true then on your nephews car you could have just hooked up the running light wire  on the arduino and used that to dim the brake lights instead of a photo sensor.

[Falcon69]

his truck doesn't do that.. i have a mazda 6s, but it's been modified.  i think maybe the after market led kit is causing the dimming when headlights are on. 

[wguibas]

The point is instead of a photosensor, the positive signal from the parking light wire could have been input into the arduino and that would be the determining logic for day/night instead of a photosensor.

his truck doesn't do that.

Isn't this whole thread about changing his lights to something completely new?

[Falcon69]

yp, it is.

I will need to head back over there, and see if his running lights DIM when the lights are put on.  I don't think they actually do. I'll see though and let you know.

The only thing I have found so far on the internet regarding brake lights illumination is 'Adaptive Braking Lights' which as far as I can tell, only flashes the brake lights rapidly for high speed breaking (i.e. quick stop on freeways).  The new Mercedes and BMW's seems to have it already.

But, I couldn't find anything, so far, on actually dimming them for night time, to stop other drivers from being blinded.  I would think there would be some time of dimming. Isn't red light, rather the frequency/brightness of red light, is what can trigger seizures in people who have that problem?  I would think that dimming the brakes at night time to a more realistic level, would help reduce the risk of that happening.  I will need to do some more search, see if I can find something on the law books about it.  I mean, these LED's are really BRIGHT at night.

[wguibas]

running lights don't get dim when you turn the head lights on, they light up when you turn the head lights at a dimmer brightness then brake lights.  The bulbs still get 12V for parking/running lights, it's just lighting a dimmer filament in the bulb.  In the case of LED's, there is usually a resistor in series with the LED's to make them dimmer.  The car isn't doing anything special as far as power goes.  The new lights you bought have a separate wire for the the park/running lights I thought you said? 

Test this:

Connect ground to the ground wire on the lights, then put 12V on to the wire on the lights labeled park/running.  The lights should light up dim.  Then touch the brake wire of the lights to the same 12V, they should be bright then.

[Falcon69]

yes. 3 separate wires on the leds and coming from the truck.  Turn/Brake/Hazard, Ground, and Taillight(running)

I'll see if they dim with head lights on when I get time to go over there and check.

[wguibas]

forget the truck, the truck has nothing to do with this.  When you move the headlight switch 1 or 2 clicks, it puts 12V on a Black/Yellow wire to the back. done. 

The lights you are putting in if they were meant to be lights in a car and they have a wire labeled park/running putting 12V on that wire and ground to the wire labeled ground should make them light up dim.

[Falcon69]

UPDATE:

So, I had ordered some of these timers:

http://www.ebay.com/itm/DC-12V-Delay-relay-shield-NE555-Timer-Switch-Adjustable-Module-0-to-10-Second-/400985412556?hash=item5d5c97d3cc:g:ANwAAOSwY45UPoBa

And tested them tonight on the truck. They work!  However, the adjustment of them is very touchy to get them to sequence. It's like the Lights don't stay in the ON state (before they turn off when using turn signal or hazard lights) long enough to get the 3rd LED to flash, but, with a little slow turns of the pots, I got them to just work.

I'm still waiting on components to test the Arduino, but at least now I can get his lights working right. I just need to order a project box, slip these into it, pour some resin to keep moisture from getting on the circuit, seal up the box, wire them back onto the truck, and call it a day.

Here's the diagram used for these to wire up 3 LED's if anyone is interested.

I know that I can pop open his Flasher Relay (the stock one in the truck) and solder on another capacitor on top of the stock one inside the flasher relay to get a longer ON state, but then the front turn signals, as well as the turn signals on a trailer when he pulls one, will flash too slow. For now, they work.


The second pic is just a modified version of using the 1st schematic, and the circuit of the relays from that eBay page. 

[wguibas]

cool, would have loved to see a video of them.

[wguibas]

And tested them tonight on the truck. They work!  However, the adjustment of them is very touchy to get them to sequence. It's like the Lights don't stay in the ON state (before they turn off when using turn signal or hazard lights) long enough to get the 3rd LED to flash, but, with a little slow turns of the pots, I got them to just work.

I eliminated this problem by removing the flashers for turn signals and hazards, and replacing them with a jumper wire.  Then my board see's a latched signal and not a blinking one. 
edit:
I don't think that would work in your design because the brakes and turn signals are combined. 

The front lights I drove from a separate flasher board which was easier to implement at the time, but could have been driven from the taillight board with a little extra thought.

[Falcon69]

If it becomes a problem, I will look into that. Might be a little difficult though to separate the front turn and the trailer turn/brakes though. But for now, I think it is working (or will once I cast in resin and hook it back up on the truck).

I will try and get a video up soon.  This coming week, I need to bury my grandmother, and then the week after I need to move in to take care of my other grandmother. She has gone downhill.  So I'll be pretty busy the next couple of weeks.