Here is a cut at a "Flickerless" state diagram. The delay is started when the switch goes from "on" to "off". Neither light should "flicker" when the switch is changed. There probably is an error somewhere but I wanted to show an example of how a state diagram can help discussion about behavior and nail down what is wanted. Please note there is no reason yet to discuss technology or how to implement the design. Just a disciplined way to specify what is needed. Also, there can be redundant states at this point. Redundant states can be eliminated later.

OUTPUTS
A - Main Light "on" when "1"
B - Aux Light "on" when "1"

INPUTS
S - Switch "on" when "1"
D - Delay ""on" when "1"

Delay is triggered when Switch goes from "on" to "off". One question: Is it retriggerable? This may change the diagram.

STATE DESCRIPTIONS

A - Idle, no lights on, waiting for Switch on
B - Main light on, waiting for switch off
C - Main light on, waiting for Delay to start
D - Main light on, waiting for Delay to end
E - Both lights on, waiting for Switch off

 

That is a change from my previous circuit. Hmmm ...

No, I'm talking about the relay. Your schematic shows a relay controlling load B, and the circuit driving the relay coil. How much current does the relay coil need?

Also, the logic can be CMOS devices, which run on 12 V directly. No need for a 5 V regulator.

Yup.

ak

Regarding the relay coil, this is what I was referring to before (albeit clumsily). The trigger on the relay. The input on the relay that makes the switch in the relay "go." I don't know how much current is required because I haven't specified the part yet. I believe the approach here would be to say, "Ok, we can pass 12v through the 555, the logic gates and the flip-flop. So let's specify some possible components for those and see what kind of current we might be able to handle. Then we can look at relays see what current might also be required. Where there's overlap, we know we're looking at potential solutions."

Does this sound right?

 

Here is a cut at a "Flickerless" state diagram. The delay is started when the switch goes from "on" to "off". Neither light should "flicker" when the switch is changed. There probably is an error somewhere but I wanted to show an example of how a state diagram can help discussion about behavior and nail down what is wanted. Please note there is no reason yet to discuss technology or how to implement the design. Just a disciplined way to specify what is needed. Also, there can be redundant states at this point. Redundant states can be eliminated later.

OUTPUTS
A - Main Light "on" when "1"
B - Aux Light "on" when "1"

INPUTS
S - Switch "on" when "1"
D - Delay ""on" when "1"

Delay is triggered when Switch goes from "on" to "off". One question: Is it retriggerable? This may change the diagram.

STATE DESCRIPTIONS

A - Idle, no lights on, waiting for Switch on
B - Main light on, waiting for switch off
C - Main light on, waiting for Delay to start
D - Main light on, waiting for Delay to end
E - Both lights on, waiting for Switch off


View attachment 176639

Thank you for doing this. You'll notice that I'm trying to keep up with multiple conversations here, one of which does include questions of hardware. Please don't take this as any indication that I'm not interested in following your line of reasoning — "design first, avoid mistakes" is a major part of my philosophy and I will do so.

I started reading the link you sent, but this weekend is very busy for me and I haven't made my way through it. Without the benefit of having read the article on finite state machines completely, I can't comment on the diagram, other than to say that I have a vague understanding of what's going on with it. I will give it a closer look and respond after I'm done with some errands, but this may not be until tomorrow. Again, thank you for taking the time to show me how to do this!

 

Regarding the relay coil, this is what I was referring to before (albeit clumsily). The trigger on the relay.
Does this sound right?

Not really. A relay does not have a "trigger". Without getting into the more exotic flavors, a relay is a coil of wire that electromechanically opens and closes switch contacts. usually the action is that pf a pushbutton switch - the contacts stay closed only as long as energy is being applied. It the case of a relay, the energy is current through the coil. Switching high current loads reliably requires more contact pressure than for low current loads, which is why the relay coil power (watts) is sorta kinda related to the contact rating (amps). many automotive relays have contacts rated for 20-30 A for things like seat and window motors, lights, etc. Years ago, Bosch invented a very popular style that everyone now copies. You switch (with a physical switch or a transistor) current into the relay coil, and the coil activates a separate (mechanical) switch that controls the load.

There are latching relays that hold their state even when power is removed from the coil. That might be the way to go here based on your last description. But what about this - When the car is turned off (overnight) and then started, do you want load B to retain its previous state (as you want it to do when the lights are dimmed for oncoming traffic), or should the system reset itself if it is off for a long time?

ak

 

Not really. A relay does not have a "trigger". Without getting into the more exotic flavors, a relay is a coil of wire that electromechanically opens and closes switch contacts. usually the action is that pf a pushbutton switch - the contacts stay closed only as long as energy is being applied. It the case of a relay, the energy is current through the coil. Switching high current loads reliably requires more contact pressure than for low current loads, which is why the relay coil power (watts) is sorta kinda related to the contact rating (amps). many automotive relays have contacts rated for 20-30 A for things like seat and window motors, lights, etc. Years ago, Bosch invented a very popular style that everyone now copies. You switch (with a physical switch or a transistor) current into the relay coil, and the coil activates a separate (mechanical) switch that controls the load.

There are latching relays that hold their state even when power is removed from the coil. That might be the way to go here based on your last description. But what about this - When the car is turned off (overnight) and then started, do you want load B to retain its previous state (as you want it to do when the lights are dimmed for oncoming traffic), or should the system reset itself if it is off for a long time?

ak

So we should start with the load that will be passing across the mechanical switch in the relay, which will drive the design of the coil. The aux lights I have in mind are the Rigid Industries D-Series Pro in the "spot" configuration. They can be found here:

https://www.rigidindustries.com/d-series-pro-d-series.html

According to the specs table, these draw 2.14 amps each, but the max voltage is shown as 36. I'm not sure if the 2.14 amps is at that voltage or at the regular 12. To be on the safe side, let's use 6 amps for the circuit (2 lights, plus a buffer [sufficient?]).

Regarding the latching relay, this may an interesting option to explore for the "memory" component. In response to your question about having the aux lights remain in their same "latched or unlatched" state after the vehicle has been power cycled, I am fine with either behavior (latch preserved or latch reset at power off).

 

Thank you for doing this. You'll notice that I'm trying to keep up with multiple conversations here, one of which does include questions of hardware. Please don't take this as any indication that I'm not interested in following your line of reasoning — "design first, avoid mistakes" is a major part of my philosophy and I will do so.

I started reading the link you sent, but this weekend is very busy for me and I haven't made my way through it. Without the benefit of having read the article on finite state machines completely, I can't comment on the diagram, other than to say that I have a vague understanding of what's going on with it. I will give it a closer look and respond after I'm done with some errands, but this may not be until tomorrow. Again, thank you for taking the time to show me how to do this!

Thanks for checking in on my posts. This is great practice for me. It has been a long time since I did a "discrete" state machine. For the last couple of decades, they have all been buried in programmable logic and designed with a high level language. So, my contribution is selfish, in a way.

It is entirely appropriate to be thinking about components. A couple of thoughts. 1) The delay is more accurately a "one shot" function. It may or may not want to be "re-triggerable". This means when the switch goes off, the "one shot" fires again even if it has not finished from the previous trigger and stretches the output time. This is a detail to be faced at some time. See

https://electronics.stackexchange.c...a-nonretriggerable-and-retriggerable-one-shot

2) If not going with mechanical relays for a "vintage" design to match a vintage cycle, check out "solid state relays" as the switches which connect the lights to the battery power. Modern, simple and reliable.

 

Follow up question - does all power for the circuit, including for the control electronics, come through the one switch? Or, will the circuit have 12 V power all the time, no matter which state the control switch is in? This is important because a solid state latch (CD4013) cannot remember its state without power. The issue here is what happens when you turn off the lights for oncoming traffic and want them to return to their previous state. 2 seconds is easy; 2 minutes (lotsa traffic, stupid football game) is hard.

ak

 

I could give it constant power.

 

Thanks for checking in on my posts. This is great practice for me. It has been a long time since I did a "discrete" state machine. For the last couple of decades, they have all been buried in programmable logic and designed with a high level language. So, my contribution is selfish, in a way.

It is entirely appropriate to be thinking about components. A couple of thoughts. 1) The delay is more accurately a "one shot" function. It may or may not want to be "re-triggerable". This means when the switch goes off, the "one shot" fires again even if it has not finished from the previous trigger and stretches the output time. This is a detail to be faced at some time. See

https://electronics.stackexchange.c...a-nonretriggerable-and-retriggerable-one-shot

2) If not going with mechanical relays for a "vintage" design to match a vintage cycle, check out "solid state relays" as the switches which connect the lights to the battery power. Modern, simple and reliable.

The bike is a late model Kawasaki KLR 650 — old technology but not qualifying as vintage. I doubt there is code or equivalent involved, for example, in the ignition module but surely there is a custom IC or two. The beast has no "input" plug for diagnostics or anything like that. It's carbureted, so no brain in the fuel system either. And aside from a few updates to suspension and fairings, the bike the same from the mid-90s until 2018 (the last model year… rumor has it they're bringing it back next year or so, probably in contradiction with the above). I like the idea of the solid state relays; would these be MOSFETs or something similar?

When I was making the truth table, this isue of "retrigger" occurred to me as well. The condition would be one of "missing" the second toggle signal, like the rightmost box in this diagram:

I was thinking this would be solved by making the timer output go low when the highbeam switch (S.A) is turned ON. My thinking was that this would allow the timer to be retriggered when S.A is turned OFF again… The change to the above timeline would be that 5.55's pulse ends whenever S.A is turned ON. However, this would invalidate the logic for using the AND between S.A and 5.55 to drive the toggle , So that's a no-go.

I haven't read your link about the one-shot because I'm wiped out tonight, but I'll dig in tomorrow. I'm sure we can resolve this dilemma. From a purely functional point of view, I can see where this is not that big of a deal — it's something I could work around ergonomically. From a "quality work" point of view, though. it's definitely got to be resolved

 

ps _ I read that stackexchange page… I thought it was going to be a long article about one-shots

 

https://www.allaboutcircuits.com/te...f-ssr-solid-state-relay-the-switching-device/

A MOSFET solid state relay (SSR) is the "MOS-Based SSR" in the linked article. So, yes to your question. Probably the most common type and suitable for your DC load.

Your timing diagram is excellent. Very often, a timing diagram is produced first and the state diagram falls out from it. It is the best way to communicate the requirements. One suggestion is to expand it (horizontally) and include every possible sequence you can think of. For example, add the high beam going off. In my state diagram, the high beam (output A) does not go off when the switch is pressed ("flicker"). But then, it does not go off until the one shot is done. Up to you....

Maybe you can find a Japanese SSR?

 

Here's the expanded version of the diagram, also with the states I identified in the truth table called out again. I did this last bit of effort mainly as a means of cross-checking my work so far before setting in on the state machine diagram (it checked out). Note that red is used differently here than in the state table. Here it shows the "miss."

 

And here is the promised state machine diagram. Please look this over and feel free to make suggestions and/or corrections. Red is again used to identify the "toggle" states, the same as it is used in the state tables.

 

Now that I put this diagram together, I'm comparing it to yours and I have some questions. I'm not sure I did mine correctly.

The procedure described in the article is quite a bit different from what I've done, and it's probably more similar to yours. I'd like to get on the same page, functionality-wise, and then update my diagram as necessary.

You mention before that you were thinking the main light (highbeam) would not turn off immediately with the switch, but would wait for the timer to run out. Thinking about it now, I'm understanding this is probably what you meant by "flickerless:" the main light doesn't get turned off in order to bring the aux light on. But I think I should stick with the version that lets me cut my lights in real time.

I notice in your diagram that you have listed some inputs that "could not exist" in connection with the states they're attached to, and I'm wondering if this is part of the method for these diagrams. For example, between State C (Main light ON, waiting for delay to start) and State D (Main light ON, waiting for delay to end), there is an input of 11 (Switch ON, Delay ON). My thinking here is that if the main light were already on, then the switch would already be on, and thus there would be no way to "apply" this input to change the state. And so the other input you have between these two states, 01 (Switch OFF, Delay ON), would be the only one truly possible.

I feel a similar idea in connection with the 01 (Switch OFF, Delay ON) input between states B (Main light ON, waiting for switch off) and C (Main light ON, waiting for delay to start): If we're going to a state where we're waiting for the delay to start, how come the delay is already ON in the input? It would seem like this arrow would go straight from B to D (Main light ON, waiting for delay to end). Again, I suspect the explanation may lie in the routine for translating these diagrams into circuit designs…

 

@AnalogKid If we're ready to talk about hardware, that will bring us immedately to several questions that have been rolling around my mind these past few days:

1. What alternatives are there to the 555 for generating a timed voltage?
2. What component needs to sit between S.A and the 555 to generate a pulse instead of a constant voltage? I understand that when the 555's trigger goes low the timed pulse begins and the output goes high, but if the trigger is still low when the timed pulse ends, the output never goes low.
   
3. If we have a way of giving the 555 a pulse of limited duration in response to S.A, why wouldn't we just use a longer version of this pulse instead of the 555 itself? (i.e., question 1 all over again…)