Apologies to everyone for not noticing (!) all the hard work above on my behalf. (And all the people who will, I believe, eventually benefit from this most excellent, and actually USEFUL circuit!)
Retrolefty correctly read my mind when he said...
So keeping count of how many have come in, gone out, total traffic count, how many left in the room, when (using millis() or RTC info), last direction used, etc , is just simple code written in the arduino.
In exchange for a simple circuit, and interface to Arduino, I am prepared to sacrifice a sensor which can count "how many", or log "each way".... in other words, my supervising Arduino will be tasked with polling the device often enough to catch the passage of person "A", before person "B" goes through the door (or "A" going back, the other way.)
To pick up another point in the above: I won't be using an interrupt to service the detector. For one thing, I anticipate having several monitored by one Arduino, and I want to know which sensor "saw" something. And secondly, I like to avoid interrupts because they are hard for some users to use without messing up other things, or depriving themselves of a resource which may be needed for something which can ONLY be done with an interrupt.
So, again... apologies and thank you!
Ummm.... but....
Having spent time studying the answer to date, a few questions arise. Apologies for not noticing this discussion was going on, and interjecting this stuff earlier. But I very much hope that what's been discussed already is a useful start toward the ultimate goal...
I should probably have used the term "latch" in my attempt to explain what I'm looking for. I want the sensor to latch the first event, and ignore subsequent events until serviced. Perhaps that's already clear from earlier parts of THIS post.... as I said, sorry it arrives late.
As for "One output not enough"....
Well... it isn't for some of the variants discussed above, but for what I wanted, it is... as follows....
If the output is low when the supervising Arduino checks it, it means "no one has been through the door since you last reset this latching detector".
If the output is high, it means someone has been through the door.
The Arduino then takes the INPUT to the sensor high. Holds it there. Waits "a moment". Then re-reads the output from the latching sensor. I'm going to call the sensor's input "ACK/RST" to emphasise that this input is for acknowledgeing the data held in the latch, and reseting it, ready to detect another person's passage through the doorway. (That line was called "A" in the original post.)
If the person went through the doorway north to south, the sensor will return its output to low (almost) as soon as the sensor's ACK/RST line goes high.
Here come's the tricky thing, the thing that lets a single bit convey more than two messages....
If the person went through the doorway south to north, the sensor will only return its output to low after as the sensor's ACK/RST line goes low again.
So, pseudo-code for the Arduino, which will, at the start of execution, initialize the output to sensor from Arduino to LOW.)
Check output from sensor.
If low, do nothing, go on, eventually come back to the top of this.
If high...
{
Bring output from Arduino high to tell sensor, "Ok, saw that. Now tell me
which way person travelled."
Wait a short time, to allow electronics in sensor to... maybe... change
state of output from sensor
{
If output from sensor now low...
interpret it as "Person went north to south"
Else
interpret as "Person went south to north"
}
Bring output from Arduino low again. Sensor should now, if it hasn't already
done so, bring its output low again. In any case, it now begins "watching"
the door again for another person passing through.
Wait a short time, to allow the output from the sensor to become low, so
that a quick cycle to the top of this code doesn't erroneously pick up
a false "new" event from the final throes of the current event.
} //end of "if high"
===
One "little" thing... easily solved by inverters, by which I mean "NOT gates", if necessary....
In a perfect world, the circuit would expect the output from the IR beam sensors (the inputs from sensors to the latching sensor-monitoring circuit) to be high when the beams are NOT blocked, as this is how the sensors I already know and love work!
===
Thanks for any new ideas!!!