LDR on input pin to capture light strobe

Go To Last Post
23 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi guys,

I want to do the following. My energy usage meter (don't know the exact correct wording) strobes a pulse every single Wh passed through. I already catch that strobe using a LDR connected to an I/O board that has a dedicated counter on that input and it works like a charm.

Now I want to get rid of the I/O board and replace it with an attiny. To be able to experiment with this, I built a simple experimentation-board with a attiny861a (the final version will probably be implemented on an attiny85, but that doesn't matter for the question), with a few leds connected and two push buttons, externally pulled up to Vcc using 22 kOhms resistors, to get some experience.

I also made a very simple program, that catches pin changes on the relevant pins using pcint, counts the numbers of presses and flashes the leds the counts of presses on the button.

Exactly like foreseen, the count increases with 1-5 with each press, yes I know I should apply debouncing with push buttons ;-)

Now the all-important question is, what will happen if I connect the LDR instead of the push button? I would expect no "debounce" issues here actually. I'd like to not do debouncing (according to the texts found here), so I will capture ANY strobe and not miss a single one.

What do you think? Suggestions?

I will test with the LDR, but it's a but difficult because all the kWh meters are taken by the existing stuff ;-) Simply flashing a torch at a LDR won't do I'm afraid ;-)

Thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is the 'strobe' ?
Is it a light ? or a black mark on a rotating wheel ?

An LDR directly connected to the micro might not produce enough of a voltage change to give you a clean digital signal.
It will depend on how much illumination the LDR receives.
An LDR is also temperature sensitive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This seems to be a duplicate post You might delete it before yo get responses in two places.
I my experience only mechanical switches need debouncing, but after 50 years of electronics I still learn things every day contrary to my previous beliefs.
I would think it should work, but the sensitivity of the LDR is fairly low.

Charles Darwin, Lord Kelvin & Murphy are always lurking about!
Lee -.-
Riddle me this...How did the serpent move around before the fall?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
This seems to be a duplicate post You might delete it before yo get responses in two places.
Already deleted.

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

... and if I remember correctly, LDRs have a low frequency response.

Ross McKenzie ValuSoft Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And LDRs are relatively slow. If the pulse is too short, or happens too often, you will not get a good signal.

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How about a data sheet link to the LDR in use?

Is the LDR your addition to the meter?

Does the background lighting vary during the day/night?

One might consider using the LDR in a resistive bridge feeding the Analog comparator as another input option, or pre-processing the signal with an op-amp.

I did not look up the hysteresis on the PCInt, or on the Analog Comparator, but if the LDR happens to be illuminated such that the output happens to be at about the threshold then there is no reason it can't "bounce".

I recall having breadboarded a photo-darlington and I could watch the florescent ceiling light on the O'scope...

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not only fluorescent lights, but high intensity discharge lights (sodium, mercury, and such).

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

LDEVRIES wrote:
This seems to be a duplicate post

Yes that might very well be. I accidently hit "submit" twice, but didn't see the double post, apologies!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay, thank you for your thoughts! I'll give some additional information.

The usage meter has a LED which it flashes, there is no mechanics involved (luckily). The LDR's are completely covered by black tape, so there is almost no chance for any daylight or other unwanted light to disturb the signal, so imho we can rule out the influence of fl etc. lights.

I am afraid I don't know the part number of the specific LDR anymore. I found this one by trial-and-error, in combination with the meter, the ldr and the I/O board, until it worked. Then I ordered an additional 10 and mounted them, and then I lost the part number :-(. The I/O board has similar digital inputs (pulled high to +5), which end up in a PIC uC, so hardware-wise it has proven to work ;-) I know they do some sort of debouncing though (no details known, unfortunately) and if you connect a push switch it does work nicely. Using the LDR is also works nicely, by the way. It's a shame I can't measure the length of the pulse of the LED. I might try making a movie clip and count the frames, but I fear the timespan is too short to have it on more than one frame.

@docjc: this is exactly my worry, that the analog voltage of the LDR in "idle" would sit around the threshold voltage of the input. But that's something I can measure :-)

Thanks guys!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

BTW I've thought of something quite flexible if debouncing appears to be necessary, it may very well be a well-known approach of course. Have one timer continuously run at high rate (low divisor) (maybe 8 bit), on overflow or compare (whatever suits best) increment the software counter (16-32 bits). If a pcint occurs, record the value of the software counter ("timestamp") for that port. If another pcint occurs calculate the current timestamp and compare, if they're too close, ignore the event. That way you don't need to fiddle with interrupts on/off and you can use one timer for all pcints's (I am going to use multiple pcints, so that is important). Of course you need to take care for 16-32 bits wraparounds in this scenario.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is a dutch saying "measuring is knowing" which I practised immediately ;-)

I've made a 50fps progressive recording of the blinking led. It seems the led is reliably on for two frames, which would then calculate to 25 "blinks" per second, 40 ms per blink. To be on the safe side, I think I'd best account for 1 frame (20 ms). This means I can implement a debouncing scheme, can't I, to be sure, with a minimum timespan between events of 20 ms! Now I can start doing the maths for the timer ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

IIRC LDRs become slower with age. So it may work now and not in a few years.

I'd change the sensor to something faster and more stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jayjay1974 wrote:
IIRC LDRs become slower with age. So it may work now and not in a few years.

I'd change the sensor to something faster and more stable.


Okay, thanks, that's a valuable suggestion. Can you make a suggestion as what to use instead then?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jayjay1974 wrote:
IIRC LDRs become slower with age. So it may work now and not in a few years.

I'd change the sensor to something faster and more stable.

Something like this (photo transistor)?

http://www.engr.usask.ca/classes/EE/392/DataSheets/OPTO-SDP8406.pdf

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Something interesting I experimented with today and wanted to share...

I soldered 100 nF capacitors over the push buttons. The push buttons connect (if pressed, of course...) a 22 k resistor (connected to +5) to ground.

Now the bouncing is completely gone, I cannot reproduce any of it. Has anyone ever experimented with this solution? Are there any drawbacks?

I know the "response time" (the time between two events that can be distinguished from each other) will decrease, the question is, how much will it decrease before the required time resolution of 50 ms will become a problem. I am not so good at calculating electronics ;-) Can anyone help me with that?

I can't find the input impedance of the digital inputs, but the analog inputs seem to be 100 MOhm. So besides that, I have a resistor of 22 kOhm connected from +5 to the input, a capacitor of 100 nF from the input to ground and a push button from the input to ground/common.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lets guess your switch bounced 5 times in 5ms. The time const of your 22K and 100nf was about 2ms, so it took it 10ms to charge up after the first press and discharge, and the bouncing was all done by then, so you are golden, I think.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks very much :-)

This also means the capacitor can remain in place for the ldr/phototransistor (required "speed" appears to be 25 ms), so I can make it a generic wiring.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Maybe, maybe not.

You have not shown the schematic for the LDR circuitry.

There could be a rather large resistor in a resistor divider with the LDR, which might give a much slower response with the same capacitor value used above.

If the response is too slow, then the output won't charge to the trigger threshold before the LED pulse is off, and the circuit starts to discharge again.

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am going to be buy a few phototransistors to resolve this issue.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The characteristics for the device will be different, but know that switching from the LDR to the Photo-Transistor won't eliminate the possibility of the signal bouncing if the baseline is very near the switching threshold. 50/60 Hz ripple noise on the power supply could trigger inputs.

With tape covering the LED & LDR / Photo-transistor you should have a large amplitude signal without outside interference, all good things.

The point remains, however, you are triggering your microcontroller with an ANALOG signal. It is NOT guaranteed to be noise free, and to be "monotonic" as it transitions through the trigger threshold level.

I mentioned the input circuit's hysteresis before, this is to help eliminate bounce in the output as the signal switches levels.

Digital outputs from one chip to another chip switch states cleanly, and you need not debounce them.

For analog signals this is not necessarily the case, and you need to know the characteristics of the signal very well, the characteristics of the chip's input, (hysteresis or not), and decide if you need to add either a hardware filter, or a software debounce routine, or both.

If you use the SEARCH option at the top of this page you can do a search on debounce and debouncing and see many threads that have discussed this topic, and some different approaches to handling this issue.

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

BTW. the inputs of the uC should have a schmitt trigger, IIRC. Then there only is a problem when the analog voltage hangs around the threshold voltage, imho. I am going to check that anyway, but IIRC I already did that once and the result is a full sweep from 5V (minus a few mV always lost in the LDR) to almost 0V, so I don't think that will be a problem. I have tried several LDR's for the best response and this one is clearly on the spot. Anyway, I am going to try phototransistors instead. To which I may add an external schmitt trigger if you guys think that helps.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A Schmidt Trigger is a Schmidt Trigger. If the micro's input has one then adding an external one is not needed.

JC