BI-DIRECTIONAL COUNTER USING 2 IR SENSORS (IN & OUT)

[stefanoggizzler]

Hi All,

I am building a directional people sensor and counter in a room using two infrared sensors (S1 and S2) which have a quadrature output such as the rotary encoder.What I want is the first sequence on breaking S1 and S2 the change should signal entry by incrementing a counter whilst breaking the beam in the second sequence S2 first and S1 will signal exit and decrement a counter.

Does anyone have an idea if this is the right way to code this on a 8bit Microcontroller? Or which is the right way to go??

Code attached.

Thanks

[tonyp · Accepted solution]

I have already done this project several years ago (and several versions of it).   We used various detection methods to accommodate all possible passage points (however, always for one person at a time).  From overhead dual-PIR, IR LEDs on both sides, LEDs on one side, etc.  Each method had its pluses and minuses.  In the case of LEDs (where we had the best results), they were positioned so far apart so that a person passing would certainly block both LEDs at some time.

It then came down to a simple state table of binary states for "LED1" and "LED2".  For example,

00-10-11-01-00

(Free [both LEDs off], person entering, person in front of LEDs [both LEDs on], person exiting, free).

The table is bidirectional (with the 00 states on both ends being the same ONE state).  It also allows for a person standing  in the middle (and possibly going back instead of through) to be detected correctly.

Since even the fastest moving person cannot move fast enough to remain undetected by the system, the use of interrupts was unnecessary.  A simple detection software loop was running (as a background task) checking the two detector states, converting them to binary (0 or 1 indicating e.g., free/blocked), and moving to the next table state depending on current state and input.  (Again, you can move both directions in the table, and there is only one 00 state.)

Very simple, very accurate.  We had zero false positives, and practically zero false negative percentage rates.  Whatever errors we had were not related to the software method but to the hardware (e.g., IR LEDs) not giving the correct signal at all times (e.g., certain clothing had a reflection that fooled them in some cases under certain lighting conditions).

(The actual state table was a little more involved to 'grab' error states, but you get the idea.)

Hope this helps.