Door monitor challenge- flip flops?

A recent discussion about monitoring traffic through a door set me thinking.

I hope someone can propose a circuit to accomplish the following....

Imagine a doorway between two rooms. One room is north of the other.

Now imagine two IR beams across the doorway, the beams running east to west, parallel to each other, one about 4" north of the other. Each shines on the sort of detector used for IR remote controls... which provides a "high" when illuminated.

If someone passes through the doorway, both beams will be broken, one before the other. And which beam is broken first will tell you which direction the person moved.

Thus, the external electronics which I hope someone can design will have two inputs, call them "N" and "S", for the "north" and "south" IR beam.

There will also be an output, which will go to an Arduino. Call it "P" for "person passed through doorway." It will be low until someone has passed through the door. It will then go high, and stay high.

There's one other I/O line on the external hardware. It is another input, driven high or low by the Arduino. Call it "A" for "acknowledge". It will normally be low. When the Arduino "sees" that P was high. When the Arduino is ready to process the fact that someone when through the doorway, it will make A high, and hold it high for a little bit. The external hardware will then do one of two things. If the person went through the doorway north to south, the external hardware will return P to low as soon as A goes high. If the person went through the doorway south to north, P will only go low when A goes low again.

Thus, with one input, one output to/from the Arduino, you can...

  1. tell someone went through the doorway, without countinually directly monitoring of the state of the outputs of the IR beam sensors, and...

  2. tell which way the person went through the door.

Thank you, if you can design such a circuit!

Add another edge-triggered flip flop for holding the direction state (clocked when the Arduino asserts the Acknowledge). Acknoledge can then also asynchronously reset the two cross-coupled flip-flops)...

I've a nagging feeling that there might be a left-field implementation involving a PLL / phase comparator chip or a rotary encoder chip though - too tired to research it now :wink:

Indeed, I believe it is exactly the same basic function as detecting direction of a rotary encoder.

Give the man a cigar, he is a winner.

And the circuit used below using two FFs is called the "Up Down detection circuit" (but in your case just call it the In and Out detector) and is the third circuit drawn and explaned here:

http://www.piclist.com/images/www/hobby_elec/e_ckt10_3.htm

Lefty

Well the circuit I Referenced requires two inputs rather then what the OP wanted to use:

Thus, with one input, one output to/from the Arduino, you can...

But the pin count is the same, and other then that I don't see how it doesn't fill the operational requirements of:

  1. tell someone went through the doorway, without countinually directly monitoring of the state of the outputs of the IR beam sensors, and...

  2. tell which way the person went through the door.

Just wire the two signals X & Y to user interrupt pins 2 and 3 and have both the ISR functions triggered on falling signal, so a interrupt via X signal falling would trigger user interrupt zero ISR and would indicate someone passed out of the passage and a falling signal on Y would trigger user interrupt one and indicate that some passed into the passage.

I see no flaw in using that circuit as is for the stated goals?

Lefty

The problem is that once someone goes through the portal in one direction, there is no way to detect whether or how many additional passages in the same direction (or in the other direction, for that matter). Thus, the need for resetting both FFs between scans.

I don't see that? The up/down detection ( or if you like in-and-out) circuit in my link is both self-resetting and continous in operation. All other tasks would just be counting total passages and if wanted compairing total in passages Vc total out passages in the isr and loop codes.

Lefty

Try it. Then you will see.

That would require real work on my part. I say it would work fine as drawn and used with proper interrupt set-up. ;D

Lefty

but you couldn't tell how many or when (which is a fundamental requirement of the original project.)

The OP stated:

There will also be an output, which will go to an Arduino.

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. The detector circuit provides all the raw information required to perform those goals. What am I missing here. :wink:

Lefty

Your right we should shut it down. I too am confident of what I have stated. The FFs will generate one complete pulse for each completed passage no matter if it's a repeat from last direction used or a new one from the opposite.

Lefty

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!!!

How about just connecting the two northern-sensors together trough two diodes into an interrupt, and while in the interrupt-routine you just check which of the two sensors thats still high/low.
This will indicate direction in the north-region, and you could do the same in the southern-region.

After reading a pass in either region, you could compare that to the other region.
If someone passed the northern sensors going south, you would expect the southern sensors to registrer the same in a couple of seconds.

Though in case of high traffic, there could be people passing eachother, this is something you have to think about..
Maybe adding some SW debouncing here too...

Just an idea =)

Andreas

edit:
Didnt see that you had only one free pin available for each region
-bygons-

I would have to see your overall I/O pin allocation (recall that analog inputs pins can also be used as regular digital pins) , but I think you may be making the system way more complicated then it really has to be. Bare with me here.

If you just allocated two digital inputs for each station, wired directly from the photodetector outputs, no output pin required from arduino to stations, I think you could then perform all your stated needs by just treating each station as a standard two channel quadrature encoder input. Therefore there is not even a need for even the simple dual flip-flop circuitry.

No need for interrupts as unless your doing a lot of other stuff in your main loop or using delay() functions, the arduino can scan input pins very fast in relationship of how fast people can be passing through stations. But a common interrupt could be included via external diode ORing circuit, if needed for raw speed, just to trigger that there has been some change at some station, and then the input pins should be scanned to determine what has changed.

All the latching, direction determination, and other data needs do not really require external circuitry, just lots of software status flags, counters, etc.

The bottom line, I believe, is if you can design the application on paper using real digital circuitry to meet the requirements, then you can also design the same application using just the raw photodetector inputs and do all the rest in software at lower cost and probably better reliability. I would be very surprised if that was not the case.

Your thoughts?

Lefty

Dear Andpe and Retro...

Thank you for the idea of diodes ORing the signals from the various stations... that had not occured to me, and would be useful in some circumstances.

And yes, the job CAN be done without external hardware.

But I always like to "offload" as much as I can to external hardware so that MORE can be done in the Arduino than can be done if it is busy doing things that could be done other ways. And anyway, it was a challenge. I thought getting the monitoring of traffic in two directions, without constant "attention" from the host processor, down to just two digital lines was quite "neat". A bit like climbing mountains.... because it was there.

(I've already addressed the subject of my wish to avoid using interrupts.)

Ah well. It was a fun idea, at least I had some fun along the way; I hope others did too. Thanks again for all of the contributions, and one final apology for not noticing sooner that the thread was being extended.