Lights status reading

Hi all...I'm working on a project that involves lights on-off switching and I must check if the real status of the lights are the same with the command byte I'd issued. It's about a traffic-lights system where I must check the consistency of the commands with the real status of the lights.For that I'm using the classic triac output arrangement (with the corresponding optotriac preceeding it)on the PORTC (all 8 bits) and the information about the status I'm sending back via 8 ac input optocouplers(TLP126) to the PORTF.
I've managed to do this checking, using some additional IC's( single-gate Schmitt-triggers) and capacitors to eliminate the zero-crossing impulse generated by optocouplers, but due the space limitation I have, I must do this checking using only the optocouplers' outputs...The problem is the zero crossing impulse..How can I read the PORTF (PINF) only between those zero-crossing impulses ? No code needed, only a clue for a proper alghorythm..

You just need to take several readings, with a delay of a few milliseconds between them.

If you choose the delay so that you take say 4 readings per mains cycle (20ms if your mains frequency is 50Hz, or 16.7ms if your mains frequency is 60Hz), then you should get at least 2 that indicate the light is on.

Just ignore the 'dark' ones. (Unless they all are, in which case the light is off.)

Hi,
Can you please post a copy of your circuit, in CAD or a picture of a hand drawn circuit in jpg, png or pdf?

Thanks..Tom..... :slight_smile:

Use light sensors to determine that the light is actually shining?

Costin:
the information about the status I’m sending back via 8 ac input optocouplers(TLP126) to the PORTF.

That will only tell you if the lamp is getting power. You should use a light sensor so you can tell if the lamp is actually lit. That sensor will have to be adjusted for ambient light. An LDR connected to an analog input in the usual way can be sampled before the lamp is lit and again after the lamp is lit. The two results should differ significantly or your bulb is likely blown.

Thanks all for your answers…@johnwasser…I’m using a current sensing device (HCPL7510) to read the effective status of the lights, and yes, that’s the thing I need to be simplified :command status reading.So I must ignore the zero crossing impulse, which makes all inputs high for 2-3 ms, then sampling the input port and see if what I send as command is what I get as reading…By the way, how can I upload a pdf schematic, to be better understood ? I saw that I can insert images,links but not a schematic from EagleCad saved as pdf. Could be a solution having a “while” loop keeping an eye on the zero-cross impulse which gives me a 255 read of PINF, then having some samples across the same PORTF ?
Thanks again…

Any suggestion or advice ?

By the way, how can I upload a pdf schematic,

Hit the reply button and then the triangle next to additional options. Then you can upload a file.

Is this an education assignment?

Thanks Mike…I’ll be happy to be again at the educational assignments age ,but this can’t happens :slight_smile: As I said , it’s about a simple traffic lights controller,but with some safety checks. The board it’s intended to be an upgrade for some old traffic controllers which does not meets the actual standards required . Until now, I’d managed to hook up on the same ArduMega board a DS3231 clock, a TFT display(the official one),the GSM shield (using simple AT commands),a GPS module , an WZ5100 Ethernet module. This main board communicates via RS485 with another two boards ( a power control board which do all the checks, including this one which I want to made it with fewer parts and a capacitive keypad board - done with a MPR121 chip).Until now everything seems to work fine, including the little Java gui( my first one ever) I made which makes the bridge between my pc and the Arduino main board.So here’s a simple drawing for a single channel (there are 12 on a board) and i’m not able yet to figure out a proper algorithm to do this port sampling for commands consistency checking…

Control gate.pdf (24 KB)

You talk of the zero crossing impulse given by the optos, this puzzles me as to where it comes from. I would not expect you to get one. Ah, further looking makes me think that this is a drop in the LED signal at the zero crossing not a pulse.

Also the resistor values R4 & R6 look a bit low to me.

Anyway the R & C arrangement before the schimitt buffer look OK and should delay things until it takes over.

i'm not able yet to figure out a proper algorithm to do this port sampling for commands consistency checking.

Can you post what you have tried and say why it fails.

Hi again, Mike…with the schmitt buffer works fine, no problem at all.I have zero output after buffer when the mains is present on the opto input.The zero-crossing impulses are very low, under 0.6 Volts,due the capacitor.But I can’t use this arrangement becose of limited space, so I’m forced to use the simplified variant and do the stuff for bypassing those impulses in the software.There are impulses there, about 2 ms long…When both leds are lighting when the mains are above the illumination threshold, the output from the transistor inside the opto goes low, near zero…But when the voltage across the resistor before the led side is under illumination threshold, transistor output goes high until the zero-crossing period passes.
I didn’t tried any snippet to see how it works, but I’m thinking to a “while” loop which will look to the port reading.If it is a value == 255, that means all the inputs are high, so we have a zero-cossing. The “while” will wait until PINF != 255, meaning the zero-crossing impulse just passed, allowing the Arduino to get some samples until next zero-crossing will arrive… I’m interested only by the logic side of the problem, not for a code, maybe I’m thinking wrong…By the way ,things became very interesting in C++ when you forget somewhere a lost semicolon… :grin: …I was used until some months ago to work in assembler, until a float math was the spark to turn over Arduino stuff… :smiley:

OK, I think I am with you now. What you need on this is a form of debounce. When ever you see the signal at the fault level and want to raise an alarm, simply call a very small delay of 2mS and then test again. If this second test shows a fault then it is real.

Thanks,Mike....Now I'm going to manufacture one test PCB to see the "real life" aspects of what we were talking here..I'll be back here next week to post some results....Thanks again !