Microcontroller-Based Sentry System

David Penrose’s “Sentry” project comprises an array of passive IR sensors placed throughout a building to track motion. The microcontroller-based system comprises an RF link to a processor along with an Ethernet module to unobtrusively monitor motion and activity levels.

The Sentry system uses commercial IR motion sensors (lower left) together with a customer vibration sensor (lower right) to determine where an individual is within a building. The base unit (top) integrates reports from these sensors to generate alerts to a caregiver.

Photo 1: The Sentry system uses commercial IR motion sensors (lower left) together with a customer vibration sensor (lower right) to determine where an individual is within a building. The base unit (top) integrates reports from these sensors to generate alerts to a caregiver.

Penrose writes:

My Sentry System is designed to assist those folks living alone who desire the peace of mind provided by a caregiver looking after them without the caregiver having to be present. Its implementation was facilitated by the WIZnet WIZ550io Ethernet module, which provides a rich yet simple interface to the Internet. With a simple microprocessor, the system allows the status of a resident to be continuously monitored in a minimally intrusive fashion.

Any abnormal conditions can immediately be alerted to a remote caregiver for action. In this way, a caregiver’s smartphone acts as an alert system by letting them know when a resident’s activity deviates from a normal pattern. The system is designed to be simple to set up yet very flexible in its application so the needs of different residents can be addressed. A resident with minimal needs can be monitored by a set of relaxed rules, while a resident in need of more continuous observation can be assigned a set of strict rules. In all cases, the overarching design approach was to provide a system that augments the caregiver’s capability.

Penrose goes on to describe the system:

The Sentry System integrates motion sensors, a microprocessor, and the WIZ550io Ethernet interface to monitor a resident and report abnormal activity patterns to a remote caregiver (see Photo 1). The relationship of these subsystems is illustrated in Figure 1.

Up to eight sensors transmit activity to a base unit processor, which checks for abnormal behavior of a resident. Alerts to a caregiver are generated and communicated over the Internet.

Figure 1: Up to eight sensors transmit activity to a base unit processor, which checks for abnormal behavior of a resident. Alerts to a caregiver are generated and communicated over the Internet.

The primary sensors are IR motion sensors. These can be augmented by vibration sensors, pressure mats, ultrasonic, and other devices capable of detecting a person’s presence. These sensors are placed at key locations in a resident’s home to monitor movement from room to room or within rooms. The vibration sensors are placed in favorite chairs/couches or in the bed to determine if the furniture is occupied and if there is normal activity. All of these sensors are battery powered and report over an RF link. The RF reports from these devices are received by a base unit which then compares the resident’s location and activity to a set of rules that define normal behavior for different times of day. Any deviation from normal results in an SMS text message or e-mail being sent to the caregiver along with information about how to contact the resident. In most cases, it is expected that the caregiver would respond by phoning the resident to check on them.

The system is designed to be easy to install and operate. The WIZ550io’s Internet interface is used to communicate to a browser allowing the caregiver or resident to configure the system. This configuration consists of identifying sensors and rooms and describing a set of rules for each room for periods in the day. This local interface also allows for a review of all past activity once the system is operational. This history data is valuable for refining the rules to reduce false alarms and ensure security. Since the interface is behind the resident’s firewall, the system is secure from improper modification. The key output from the system is the alert to the caregiver, which relies on the WIZ550io module communicating to a service site such as Exosite. The site generates the alerts sent to the caregiver.

The base unit incorporates the WIZ550io, an 89LPC936 processor, a MCP79401 real-time clock, and a serial EEPROM to process reports received from the 433-MHz receiver.

Photo 2: The base unit incorporates the WIZ550io, an 89LPC936 processor, a MCP79401 real-time clock, and a serial EEPROM to process reports received from the 433-MHz receiver.

The system’s hardware consists of a base unit and multiple sensor/reporting units. The base unit (see Photo 2) comprises a WIZ550io Ethernet interface, an inexpensive microprocessor, an RF receiver, a battery backed-up real-time clock, and a serial EEPROM. All of these pieces are integrated into a small form factor case and powered by a plug-in transformer (see Figure 2).

Figure 2: The microprocessor accomplishes all of its tasks while using only a few of the available port pins.

Figure 2: The microprocessor accomplishes all of its tasks while using only a few of the available port pins.

The remote units can be one of many different sensor/reporting devices depending on the needs of the resident. The basic sensor is the IR motion sensor, which is available from a number of different sources.  I used Bunker Hill Security sensors, which I purchased from Harbor Freight Tools (Item 93068). A sensor plus receiver is very inexpensive. Some cost only $11. The item consists of a sensor/transmitter and a receiver/alarm device. The receiver/alarm device is not used in this project although the RF receiver was lifted from one of these units to provide the receiver for the base unit. These sensor units are powered by 9-V batteries and report on an RF link at 433 MHz with a unique address code.  The code allows multiple sensors to be deployed and recognized by the base unit.

The complete article appears in Circuit Cellar 296 (March 2015).

Microcontroller-Based Control Display Component

Jerry Brown, a California-based aerospace engineer, designed and built (both the hardware and software) an MCU-based computer display component (CDC) for a traffic-monitoring system. The system with the CDC is intended for monitoring and recording the accumulative count, direction of travel, speed, and time of day for vehicles that pass by.

In his November 2014 Circuit Cellar article, “MCU-Based Control Display Component,” Brown explained:

For the past five years, I have been working on an embedded project that you might find interesting. As part of a traffic-monitoring system (TMS) developed by a colleague (a retired aerospace/aeronautical engineer), whereby traffic flow on city streets and boulevards is monitored, I designed and built (both the hardware and software) a dual Microchip Technology PIC18F4520 microcontroller-based control display component (CDC, see Photo 1). My motivation to develop the CDC came about as a result of my chance meeting with my colleague when we were both judges at the local county-wide science fair. He explained the concept of the TMS to me and his motivation for developing it and said he needed an electrical engineer to design and build the CDC. Would I be interested? You bet I was.

Photo 1: Fully functional CDC prototype

Photo 1: Fully functional CDC prototype

Brown went on to describe system.

The TMS comprises a dual laser beam transmitter, a dual sensor receiver, and the CDC (see Figure 1). It is intended for unmanned use on city streets, boulevards, and roadways to monitor and record the cumulative count, direction of travel, speed, and time of day for vehicles that pass by a specific location during a set time period (e.g., 12 to 24 hours).

Figure 1: Traffic Monitoring System showing the Laser Beam Transmitter, the Sensor Receiver and the Control Display Component

Figure 1: Traffic Monitoring System showing the Laser Beam Transmitter, the Sensor Receiver and the Control Display Component

The transmitter, which is placed on one side of the roadway at the selected measurement-monitoring location, has two laser diodes (in the red color spectrum about 640-to-650-nm wavelength) spaced 12″ apart. The receiver has two photo transistor detectors also spaced 12″ apart. The transmitter is positioned directly across the roadway from the receiver as nearly orthogonal as possible. In operation, the two laser diodes in the transmitter continually emit a pair of parallel beams a small distance above the road surface, and the beams are aligned so that they impinge on the two photo sensor arrays in the receiver across the road. When a vehicle passes through the monitoring location, one beam is interrupted and, a short time later, the second beam is interrupted. The CDC electronics and software accurately measures the time differential between the sequential beam interruptions to determine vehicle speed and, depending on which beam is interrupted first, determines the direction of travel. The CDC—which counts the passing vehicles accumulatively and calculates and displays vehicle speed, direction of travel, and time of event on an LCD—is electrically connected to the receiver. All traffic-monitoring data including the time of each interruption event is recorded on a Compact Flash Memory (CFM) card within the CDC for later review and analysis in an Excel spreadsheet or other data  analysis program. In addition, the CDC has an alphanumeric keypad whereby the set-up technician can enter four initial parameters (Date, Location, Map Book Page, and Map Book Coordinates), which are downloaded to the CFM card as the “Header File.”

The TMS system-level requirements established by my colleague drove the CDC level requirements which I documented. Specifically, the CDC had to be of a size and weight so that it could be easily hand carried. Inexpensive off-the-shelf components were to be utilized to the maximum extent possible in the design and fabrication of the CDC. Power consumption needed to be kept to a minimum. Functionally, the CDC had to be capable calculating speed to within ±1 mph of all vehicles passing through (i.e., “interrupting”) the laser beam pair. In addition, the CDC had to be able to determine the direction of travel, the time the valid interruption occurred, and the cumulative count for all vehicles interrupting the laser beam pair during a manned or unmanned test session. A real-time GUI (i.e., the LCD) and a keypad were also required, as was nonvolatile  memory (CFM card) to store all the traffic pattern data obtained during a traffic-monitoring session.

Figure 2 shows the CDC’s functional elements.

The functions of the main co-processor are to display on the LCD input from the User Interface, to drive the status LEDs and to calculate and display traffic pattern data which is sent to the CFM microcontroller. The CFM microcontroller formats the traffic pattern data in a File Allocation Table (FAT) file and writes that file to the CFM card. Both microcontrollers are clocked by a 40-MHz crystal controlled oscillator and both have an in-circuit serial programming port (ICSP), which allows for programming and reprogramming the microcontrollers at the CDC level. During the software development phase of the project, the ICSP ports were definitely utilized. A power on reset (POR) circuit initializes both microcontrollers at system power-up.

Figure 2: CDC Functional Block Diagram showing the two micro-controllers, the User Interface and the Supporting Functionality

Figure 2: CDC Functional Block Diagram
showing the two micro-controllers,
the User Interface and the Supporting
Functionality

Based on the FBD and the established CDC functional requirements, I designed the CDC motherboard circuit using a schematic capture program. Where necessary, I simulated elements of the circuit using a circuit simulation program. I used an online PCB prototype fabrication service and had to re-enter the schematic using their software. I then laid out and routed the two-sided board using the software package provided by the online vendor. After I submitted the file, it only took a few days to receive the two prototype PCBs I ordered. I “populated” one of the boards with components I had purchased and kept the second board as a spare. Preliminary board-level testing of the assembled PCB revealed two layout errors which were easily corrected by an X-ACTO Knife trace cut and by the addition of a jumper wire.

Figure 3: CDC Motherboard Schematic divided into three sections: (1) Data Processor, (2) CFM Formatter and (3) Input/Output. Some circuitry, such as the RS-422 Interface (U2, U4, J6), was included in the design for potential future utilization but was not used in the prototype configuration.

Figure 3: CDC Motherboard Schematic
divided into three sections: (1) Data
Processor, (2) CFM Formatter and (3)
Input/Output. Some circuitry, such as
the RS-422 Interface (U2, U4, J6), was
included in the design for potential
future utilization but was not used in
the prototype configuration.

Figure 3 depicts the CDC main microcontroller circuit on the motherboard. Photo 3 shows the inside of the CDC with the front panel removed.

As indicated above, I designed and assembled the motherboard circuit card. The LCD module, the keyboard module, the RTC module, and the CFM card module were all purchased assemblies. Once all the parts were installed in the case, I completed the interface wiring.

Photo 3: Inside the CDC showing the (1) Main motherboard, (2) The Main Microcontroller, PIC18F4520, (3) the CFM Micro-controller, PIC18F4520 (4) the LCD module, (5) the Keyboard module, (6) the Real Time Clock module and (7) the CFM Card module, only partially visible.

Photo 3: Inside the CDC showing the (1) Main
motherboard, (2) The Main Microcontroller,
PIC18F4520, (3) the CFM
Micro-controller, PIC18F4520 (4) the
LCD module, (5) the Keyboard module,
(6) the Real Time Clock module and (7)
the CFM Card module, only partially
visible.

The complete article appears in Circuit Cellar 292 (November 2014). Additional files are available on the CC FTP site.

Real-Time Trailer Monitoring System

Dean Boman, a retired electrical engineer and spacecraft communications systems designer, noticed a problem during vacations towing the family’s RV trailer—tire blowouts.

“In every case, there were very subtle changes in the trailer handling in the minutes prior to the blowouts, but the changes were subtle enough to go unnoticed,” he says in his article appearing in January’s Circuit Cellar magazine.

So Boman, whose retirement hobbies include embedded system design, built the trailer monitoring system (TMS), which monitors the vibration of each trailer tire, displays the

Figure 1—The Trailer Monitoring System consists of the display unit and a remote data unit (RDU) mounted in the trailer. The top bar graph shows the right rear axle vibration level and the lower bar graph is for left rear axle. Numbers on the right are the axle temperatures. The vertical bar to the right of the bar graph is the driver-selected vibration audio alarm threshold. Placing the toggle switch in the other position  displays the front axle data.

Photo 1 —The Trailer Monitoring System consists of the display unit and a remote data unit (RDU) mounted in the trailer. The top bar graph shows the right rear axle vibration level and the lower bar graph is for left rear axle. Numbers on the right are the axle temperatures. The vertical bar to the right of the bar graph is the driver-selected vibration audio alarm threshold. Placing the toggle switch in the other position displays the front axle data.

information to the driver, and sounds an alarm if tire vibration or heat exceeds a certain threshold. The alarm feature gives the driver time to pull over before a dangerous or damaging blowout occurs.

Boman’s article describes the overall layout and operation of his system.

“The TMS consists of accelerometers mounted on each tire’s axles to convert the gravitational (g) level vibration into an analog voltage. Each axle also contains a temperature sensor to measure the axle temperature, which is used to detect bearing or brake problems. Our trailer uses the Dexter Torflex suspension system with four independent axles supporting four tires. Therefore, a total of four accelerometers and four temperature sensors were required.

“Each tire’s vibration and temperature data is processed by a remote data unit (RDU) that is mounted in the trailer. This unit formats the data into RS-232 packets, which it sends to the display unit, which is mounted in the tow vehicle.”

Photo 1 shows the display unit. Figure 1 is the complete system’s block diagram.

Figure 1—This block diagram shows the remote data unit accepting data from the accelerometers and temperature sensors and sending the data to the display unit, which is located in the tow vehicle for the driver display.

Figure 1—This block diagram shows the remote data unit accepting data from the accelerometers and temperature sensors and sending the data to the display unit, which is located in the tow vehicle for the driver display.

The remote data unit’s (RDU’s) hardware design includes a custom PCB with a Microchip Technology PIC18F2620 processor, a power supply, an RS-232 interface, temperature sensor interfaces, and accelerometers. Photo 2 shows the final board assembly. A 78L05 linear regulator implements the power supply, and the RS-232 interface utilizes a Maxim Integrated MAX232. The RDU’s custom software design is written in C with the Microchip MPLAB integrated development environment (IDE).

The remote data unit’s board assembly is shown.

Photo 2—The remote data unit’s board assembly is shown.

The display unit’s hardware includes a Microchip Technology PIC18F2620 processor, a power supply, a user-control interface, an LCD interface, and an RS-232 data interface (see Figure 1). Boman chose a Hantronix HDM16216H-4 16 × 2 LCD, which is inexpensive and offers a simple parallel interface. Photo 3 shows the full assembly.

The display unit’s completed assembly is shown with the enclosure opened. The board on top is the LCD’s rear view. The board on bottom is the display unit board.

Photo 3—The display unit’s completed assembly is shown with the enclosure opened. The board on top is the LCD’s rear view. The board on bottom is the display unit board.

Boman used the Microchip MPLAB IDE to write the display unit’s software in C.

“To generate the display image, the vibration data is first converted into an 11-element bar graph format and the temperature values are converted from Centigrade to Fahrenheit. Based on the toggle switch’s position, either the front or the rear axle data is written to the LCD screen,” Boman says.

“To implement the audio alarm function, the ADC is read to determine the driver-selected alarm level as provided by the potentiometer setting. If the vibration level for any of the four axles exceeds the driver-set level for more than 5 s, the audio alarm is sounded.

“The 5-s requirement prevents the alarm from sounding for bumps in the road, but enables vibration due to tread separation or tire bubbles to sound the alarm. The audio alarm is also sounded if any of the temperature reads exceed 160°F, which could indicate a possible bearing or brake failure.”

The comprehensive monitoring gives Boman peace of mind behind the wheel. “While the TMS cannot prevent tire problems, it does provide advance warning so the driver can take action to prevent serious damage or even an accident,” he says.

For more details about Boman’s project, including RDU and display unit schematics, check out the January issue.

Linear Regulator with Current and Temperature Monitor Outputs

Linear Technology Corp

Linear Technology Corp

The LT3081 is a rugged 1.5-A wide input voltage range linear regulator with key usability, monitoring, and protection features. The device has an extended safe operating area (SOA) compared to existing regulators, making it well suited for high input-to-output voltage and high output current applications where older regulators limit the output.

The LT3081 uses a current source reference for single-resistor output voltage settings and output adjustability down to ”0.” A single resistor can be used to set the output current limit. This regulator architecture, combined with low-millivolt regulation, enables multiple ICs to be easily paralleled for heat spreading and higher output current. The current from the device’s current monitor can be summed with the set current for line-drop compensation, where the LT3081’s output increases with current to compensate for line drops.

The LT3081 achieves line and load regulation below 2 mV independent of output voltage and features a 1.2-to-40-V input voltage range. The device is well suited for applications requiring multiple rails. The output voltage is programmable with a single resistor from 0 to 38.5 V with a 1.2-V dropout. The on-chip trimmed 50-µA current reference is ±1% accurate. The regulation, transient response, and output noise (30 µVRMS) are independent of output voltage due to the device’s voltage follower architecture.

Two resistors are used to configure the LT3081 as a two-terminal current source. Input or output capacitors for stability are optional in either linear regulator or current-source operation mode. The LT3081 provides several monitoring and protection functions. A single resistor is used to program the current limit, which is accurate to ±10%. Monitor outputs provide a current output proportional to temperature (1 µA/°C) and output current (200 µA/A), enabling easy ground-based measurement. The current monitor can compensate for cable drops. The LT3081’s internal protection circuitry includes reverse-input protection, reverse-current protection, internal current limiting, and thermal shutdown.

A variety of grades/temperature ranges are offered including: the E and  I grades (–40°C to 125°C), the H grade (–40°C to 150°C), and the high-reliability MP grade (–55°C to 50°C). Pricing for the E-grade starts at $2.60 each in 1,000-piece quantities.

Linear Technology Corp.
www.linear.com