0
\$\begingroup\$

I'll be using an Arduino to "read" the parking light wire on a car.

I was wondering if debounce is necessary here? I want to think that the factory bulb will act as a debounce to smoothen out the signal...

I will be using the interrupt function to read the state change of the parking light wire. In particular, I will enable some function if the state changes twice in a particular time frame, so therefore I can't have false reading from switch bounce.

The diagram shows how I tie into the factory wire.

Schematic showing the factory part and the modifications using an opto isolator

\$\endgroup\$
  • \$\begingroup\$ Adding a small capacitor parallel to R2 will help with debouncing electrically, rather than doing it in software. \$\endgroup\$ – JvO Dec 14 '16 at 0:58
  • \$\begingroup\$ Thanks for the suggestion. What would you suggest as a good value? For small values, I have on hand a 0.33uF and a 0.01uF. Would any of them do? If it matters R2 is 10k ohms. Thanks again. \$\endgroup\$ – Ivan K Dec 14 '16 at 1:34
  • \$\begingroup\$ The RC time of 10k & 0.01 uF is only 0.1 milliseconds, which I think is too short. So go for the 0.33 uF. \$\endgroup\$ – JvO Dec 14 '16 at 1:41
  • \$\begingroup\$ Adding a cap between the input pins of the optocoupler will create a small time delay with R1. \$\endgroup\$ – Ciredigital Dec 14 '16 at 3:55
1
\$\begingroup\$

The lamp will not act as a capacitor, to aid in debouncing the relay contact. Although the lamp (assuming incandescent) doesn't switch on and off immediately, those are thermal effects, not electrical ones. It is a fairly easy matter to add debouncing in software; there are tone of resources on the web for doing so. Search the forum for arduino debounce and arduino debouncing to get started.

\$\endgroup\$
  • \$\begingroup\$ Thank you for the helpful explanation. I realize now it was kind of a silly assumption. I've been working on a software debounce but I keep running into a bug that I can't seem to solve. JvO has suggested a small capacitor in parallel with R2. I think that will be the simplest option for me. \$\endgroup\$ – Ivan K Dec 14 '16 at 1:32
0
\$\begingroup\$

For your application, detecting several changes in a short time, you, as programmer, have to make a decision about the time threshholds. Changes in too short a time => 'switch bounce', changes in a longer time => 'changing behaviour', changes in a yet longer time => 'unchangeing behaviour'.

What you are talking about is putting the decision between 'bounce' and change into analogue hardware, and the change to unchanging into software. It would surely be far more flexible, lower parts count, easier to tune, to put both threshhold decisions into software, and simply poll the brake light.

The easiest way to simply debounce, is to work out how slowly you can read that output, and if it's >50mS or so, then poll the output that often. Most debounce events will be over in this time.

With a relatively slow poll, even if you read the switch while it's bouncing, the previous read will have been 0, the next read will be 1, and this read will either be 0 or 1, so you still have a clean transition, just uncertain as to the timing.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.