View Single Post
  #170   Report Post  
Posted to alt.home.repair
Don Y[_3_] Don Y[_3_] is offline
external usenet poster
 
Posts: 2,879
Default OT Idiot lights-out drivers

On 2/13/2016 8:38 AM, wrote:
On 2/12/2016 10:06 AM, KenK wrote:
Just about pulled out in front of a car with lights out early this morning.
Not even parking lights. A few seconds earlier...

Why do these people drive with lights out? Save gas - engine runs easier
without generating electricity for lights? Seems I've seen many more of
them in the past year for some reason.

What about defective head/tail/signal lamps? I consciously notice which
lamps are lit (headlamp/running lamp/turn signal) each time I pull up
behind a vehicle with some of mine lit. Likewise, notice in the
rear view mirror if one side of the car behind me is "less red"
(from my brake lights) while we're sitting at a stop light.

Periodically will "linger" behind the car as we are exiting the
house and ask SWMBO (driving) to tap brakes, turn signals, etc.
so I can verify their operation.

How could you *not* "notice" that the light in front of your vehicle
is uneven" Or, that there is no "yellow glow" apparent alongside your
vehicle from your turn signal?

[Ans: because you're simply not noticing MOST of the things that you
SHOULD be noticing while driving!]
Virtually all vehicles will let you know if a signal is out by
changing the flash rate - either faster or no flash, depending on the
flasher used.

Perhaps in the days of thermoelectric flashers. Nowadays, when the
flasher is a few lines of code, I don't think that is likely to be the case!

Actually it is MORE likely to be the case - as bulb failure detection
becomes also just an extra line of code.


No.


What is the "no" in reply to??


That it's not just an extra line of code. The bimetal strip's elegance is
that it gave you these characteristics "for free". An alternative
implementation has to include them as "line items" in its design
specification. E.g., I can make an electronic flasher that does NOT
sense load characteristics (and convey this to the ECU) a lot easier
than I can make one that *does* -- both in terms of the hardware
AND software required.

The bimetal strip form of flasher provides the indication as
a "pleasant side-effect" of its NORMAL operation.

- The bimetal strip must be sized to carry the load of the lamps.
- The current through the strip causes it to heat and, thus deflect
(opening the circuit, allowing it to cool and the cycle to repeat).
Less current (failed light) causes it to heat more slowly and
"blink longer".
- The dashboard indicator is "just another turn signal" as far as the
wiring is concerned -- nothing "special" to convey the normal
operation of the turn signals to the user *or* the "altered"
indication.


Pretty obvious so far.

With an electronic drive, the normal "user" indication can be anything
you can create with your available "user interface"

When I said electronic I meant the electronic flasher unit that takes
the place of the bimetalic thermal flasher.


Yes. I'm not caring whether the electronic flasher is a freestanding
entity (with or without its own processor) *or* integrated in the
normal functions of the ECU.

. Many cars now
synthesize a "click-clack" sound to *simulate* the sound of the old
flasher unit (opening and closing that bimetal strip). This in
addition to any visual displays, tie-in's to other warning systems
(e.g., blind spot detector, lane deviation warning, etc.)

I.e., the "normal" indication isn't a natural consequence of the
wiring -- as it was with "dash indicator lamps" wired in parallel
with the actual front/rear turn signal indicators.

While the bimetal strip inherently sensed the amount of current
flowing through it as part of its design and reacted differently
based on that current (thus changing when the load changed), an
electronic drive has to explicitly sense *sense* that current is
being drawn (to know that ANY lamps are illuminated) and sense how
*much* if you want to be able to differentiate between "one lamp
load" and "two lamp loads".


And that is a simple extra line of code in integrated systems (like
CanBus) where the lights are controlled directly by the BCM.


No, it isn't.

if
(the_load_doesn't_appear_to_be_correct)
then
somehow_convey_this_to_the_driver

Where do you *get* the information *from*?

How do you convey it to the driver?

Remember, you've already used up your "one line of code" -- it's
written here, above!

Then, you have to convey this information to your "user interface"
where it must be presented to the user in a manner that makes it
apparent that you are indicating a "load change" (bulb failure).
Whether that is done by altering the numeric value used to specify
the "on time" and "off time" for the indicators (visual and audible)
or an "error message" displayed in the "information console"
(which has to be prioritized with any other competing messages)
is up to the designer. Do you adopt a common means of communicating
this information regardless of make/model vehicle? Do you *augment*
that "display" for vehicles that have more "verbose" display
media? etc.

It's not "free". Someone has to decide it is important to convey this
information and then figure out how to *get* it (sensing current,
sensing an open load, etc.).

E.g., you can sense the actual current flowing through a particular
load (LED/lamp). You can quantify this to any level of precision
that you deem is important (i.e., you can conceivably tell if a
5W lamp is installed instead of a 10W -- or 6W). Or, you can just
say: "A load of at least X is present, or not"

In a degenerate case, you can simply notice the OFF voltage at
the load while introducing a high impedance bias. I.e., shunt a
tiny amount of current AROUND your "switch" into the load at
all times. When "off", an intact load will look like a low impedance
overwhelming that high impedance shunt (voltage divider where
the load is so much lower impedance than the bias that *it*
governs the "measured voltage" at the divider). OTOH, an OPEN
load looks like an infinite impedance! So, the high impedance *shunt*
governs (voltage divider where the load is now infinite impedance
and the bias governs the measured voltage).

Or, you can sense the current flowing to/from the battery (to some
degree of precision) and try to correlate that with actions that
*you* are taking ("OK, I'm turning the light on... NOW! So, that
increase in current draw is PROBABLY a reflection of the current
being consumed in the lamp. If I'm right, it should decrease
when I turn the lamp off... NOW!"). But, this can be confused
if other "uncontrolled loads" are present (e.g., someone plugs
something into a "cigarette lighter" and you don't have an
explicit way of knowing this to compensate your other observations)

[I use this approach in my home automation system to infer what
users (occupants) are doing -- just by looking at the instantaneous
demands placed on the "utilities". E.g., water flowing at a certain
rate for a certain time while a user is located in a bathroom
suggests a toilet flush, not a shower! OTOH, I have no PROOF that
the water really was flushed and not just a "hand washing" that
happened to use the same amount of water flowing at the same
rate for the same length of time as a toilet flush!]

Thermoelectrics stop flashing or slow down. Electronics speed up when
a bulb goes out. And a very large number of new vehicles still depend
on a "flasher unit"


I suspect that is an obsolescent implementation. Our current vehicle
uses LED front and incandescent rear indicators. I've seen other
vehicles with far more elaborate (Tbird style) indicators and imagine
even higher levels of integration in the future.


Note I was talking "flasher units"


The flasher unit still has to take extra design steps to *sense* the
change in load current from "nominal"; then, report this (e.g., via CAN
bus).

Remember, your budget is *one* line of code. You can't cheat and hide
50 lines of code in a flasher unit! :

I've not yet purchased a workshop manual for current vehicle so I haven't
had a chance to examine wiring diagrams, etc.

So, at the very least, it requires extra code, a flasher unit designed to
explicitly note the load change (as it is no longer relying on a
bimetal strip) *and* a path BACK to the electronic instrument cluster
that lets the vehicle KNOW that this has happened (to alter the
"A/V user display").


Not necessarily - it can use "either" a flasher unit "or" an
intelligent interface "or" both.


Are you claiming that the indications on the dash are NOT processed by the
ECU? "Hardwired" turn signal indicators like in days of old?

Moving to an electronic implementation (esp one that involves a computer)
ALWAYS is more complex! The advantage, however, is that one can do other
(extra) things that are impractical, otherwise.

Imagine how you'd SPEAK a bulb failure warning message to the driver
if you were using a bimetal flasher.

Or, how you'd disable the vehicle in that event (if this was considered
essential safety equipment).

Etc.

Much more "involved" and requiring explicit addition of that "feature"
than the "free side-effect" of a bimetallic flasher!