Re: Occupancy detection

[Marc_F_Hult <MFHult@xxxxxxxxxxxxxxxxxxxxx>]

On Tue, 7 Aug 2007 07:51:12 -0400, "Robert Green"
<ROBERT_GREEN1963@xxxxxxxxx> wrote in message
<KN2dnXW6jpewwCXbnZ2dnUVZ_u2mnZ2d@xxxxxxx>:

>But before I even begin to think about choosing a HW platform, good coding
>technique dictate I do a requirements analysis that fully describes what I
>want the system to do.  The stairway problem breaks down fairly simply:
>Reliably sense entries and exits and occupancy via multiple sensors as well
>as motion and light output (so that I know if the light's burned out or
>really ON or OFF).

By "HW platform" I think that BobbyG is referring to a central processor or
microcontroller and not the platform of sensor hardware (eg motion
detectors).

An important step in system and sensor design is the decision of whether to
create the Event of "Occupied = YES/NO" at the sensor itself or  in a higher
level processor. Or both.

An actual example of hardwire-based decision-making are dual technology
motion/occupancy detectors that use both Passive Infrared (PIR) and microwave
and only report an Event when both sensors are triggered.

Along the same lines, the outputs of two motion detectors in a room can be
logically OR'd together or logically AND'd. The OR'd arrangement increases
the risk of a false positive but decreases the risk of a missed occupancy.
And vice-versa  for the AND'd configuration. Sending the uninterpreted ON-OFF
Event data from _both_ sensors to a processor for decision-making provides
for better risk and error management.

Event 1 Detector_1 Only
Event 2 Detector_2  only
Event 3 Detectors 1 and 2 Both
raw
Another example is/was the use of what Savoy dubbed "Motion Vectors" in the
CyberHouse software released ca 1998 which used the time relationship between
"ON" events reported by two motion detectors monitoring two different
contiguous locations to create Motion Vector Events (eg: 'Motion to north in
Hallway"; "Motion to south in Hallway"). The latency problems of X-10 made
useful implementation difficult/impossible even with hard-wired motion
detectors.

The hardwired THOL (Temperature, Humidity, Occupancy, Lightlevel) system I
designed and am installing can be used with multiple motion detectors at a
single measurement site so as to be able to create a Motion Vector Event in
hardware in real time as well as pass on the raw, uninterpreted sensor data.

The data and the events are combined into a single 0-10vdc analog level which
in turn can be treated downstream as a single event by defining the event
threshold analog voltage or as a series of readings of the different sensor
or both. More than one downstream processor can receive, interpret, store
and(or) act on the data, so different processors can have different
responsibilities.

Continuing with my THOL example of Occupancy, a single commercial PIR
detector simply toggles the output between two voltages (typically 0 and
10vdc but they could be any two values between 0 and 10vdc) when the contact
of its internal relay closes.

Contact closure of each motion detector in an array of n detectors can short
out a different resistor in a conventional R-2R resistance ladder and so
create a unique 0-10vdc value for each of the possible 2^n outcomes.

Adding a simple PIC or AVR can add interpreted outcomes (= Events) based on
timing, IOW, Motion Vectors. The practical number of different states that
can be reported by an analog signal depends on ADC resolution and precision
and system noise among other factors. Reporting independently the five
different Y/N states requires 2^5 = 32 different values.  This is easily
handled by a 10-bit ADC (1024 possible values) in a system with sufficiently
low noise and stability.

Bit 5 Motion South
Bit 4 Motion North
Bit 3 Motion Detector_1
Bit 2 Motion Detector_2
Bit 1 Motion Detector_3

Note that Bits 1-3 are raw sensor data. Bits 4-5 are interpreted data.

So by logging the analog voltage one is logging both all the raw data and the
Motion Vector events interpreted by the on-site hardware.

These discrete events could be usefully lumped together to create fewer
combinations of possibilities that impose less stringent demands on the
analog hardware and communication. For example by reporting exclusively only
_one_ of these six  Events

Event 1 = Motion South Three Detectors = 8.volts
Event 2 = Motion North Three Detectors = 7 volts
Event 3 = Motion North Two Detectors   = 6 volts
Event 4 = Motion South Two Detectors   = 5 volts
Event 5 = Any Two Detectors            = 4 volt
Event 6 = Only One Detector            = 2 volts
No Event= No motion                    < 1 volt

at the receiving (downstream) end one can more easily  use analog comparators
or TTL/CMOS PICs or AVRs or a simple LM3914 Dot Display driver to physically
create a discrete electrical signal in the form of a contact closure or TTL
signal for the event.

2 volts would imply low certainty with no perceived motion.
4-6 volts moderate certainty
A voltage > 7 volts would imply high certainty, etc.


>Then I need to put the entries in a state table with
>some simple rules and act accordingly.

With flawless event definition, "simple rules" might work well most of the
time for many actions.

>It probably doesn't even need a
>microprocessor as the logic would be simple enough to implement with some
>TTL devices on a perf board once the proper inputs and outputs had been
>established.

This is a classic GIGO situation. A CPU or MCU processor can help to filter
the data in a way that "simple" rules" can't and to create infrequently
enacted rules that might be very important but might not find their way into
a system based entirely on discrete logic ICs.

A fully hardwired TTL approach also mostly forces definition of the event of
"occupied" beforehand and essentially eliminates any stochastic evaluation or
risk analysis and their use in determining actions. Stupid machines make
stupid mistakes.

Also, IIRC, in previous posts wrt temperature and HVAC BobbyG expressed an
interest in data storage. How does one do this efficiently with TTL's  alone?
A hardwired TTL circuit might have a place in the system if (especially)
there are other devices that also translate, use and act on the data.

(FWIW, making one-off PCBs has become relatively easy, fast and inexpensive.
And for non-RF prototypes, solderless breadboards work fine. Perf-boards for
TTL are fragile and error-prone IME.)


... Marc
Marc_F_Hult
www.ECOntrol.org