The technical details for Halloween 2002

Note: This article assumes you've read my 2001 technical details. I don't describe in detail here some of the hardware when it is already described there.

This year, I decided to dispense with the use of PCs entirely. Instead, I only used microcontrollers (MCUs) to control everything. In addition to using Microchip's PIC16F84A/04s that I used last year, I also used a couple of PIC16F628/20s. The variation I picked up can be 5 times as fast, has twice as much program memory, three times as much data memory, and has a number of other built-in features (like a USART), yet they are almost half the price of the '84A. I also dispensed with using PicBasic to program the MCUs, and instead went right to assembly language, using Microchip's MPLAB environment to do all my programming.

Since I was losing the sound cards from the PCs, I picked up two more CD players from Walmart to provide the additional sound sources I needed. This brought the total of controllable CD players to 4. And, I made sure the play and stop buttons worked on *these* CD players (unlike last year's). As I was determining the layout of the sound sources, however, I ended up only using the two new CD players. In my experience with doing this the last couple years, I have come to the determination that people don't distinguish much between the various sound sources in such a small area. In the past, I have put a speaker and some prop directly above where people would stand to receive their candy. I played a sound through that speaker while they were standing in that spot, thinking that they would look up at the prop. Not one person looked up. As a result, I have determined that there is not a lot of point in making many different sound sources. Thus, this year, I combined all of my sound into just the two CD players.

One CD player was just the background sounds. Since I had a spare controllable CD player, I decided to make the background sounds stop when they weren't needed, unlike last year when they just played constantly in a loop. When the master switch on the main control panel was off, the background sounds stopped. When it was switched on, they started up. The other set of sounds was for the trash-can dummy's laugh and the prisoner's chains rattling. This set of sounds was home-made. I used software called CoolEdit to record the sounds and then alter them as needed. For instance, the trash-can dummy's voice is my voice after the pitch has been raised and some echo effects have been added.

I used the laser again this year to activate the main sequence. There were a number of signals I needed to exchange between the master MCU and the MCU controlling the laser. To simplify the wiring required between the two of them and to reduce the number of pins needed for communication, I decided to use a serial communications protocol between them, which meant that I only needed 4 wires between them -- 2 for each direction of communication. When I originally started implementing this, I was only using the PIC16F84A, which doesn't have a UART in it, so I had to implement the protocol in software. That was challenging. I don't have an oscilliscope, so it was very difficult to tell what was going on when things weren't working correctly. Eventually, though, I got it working. I could now pass 8-bit messages back and forth to relay status fairly easily.

Last year, a co-worker had suggested pulsing the laser instead of leaving it on all the time as a way to extend the life of the laser. I followed his advice last year. While it didn't cause me any problems, I re-thought it this year. Since I have another 5 or so of these lasers, I saw no reason to be conservative with them, especially since, in 5 years, I'll probably be using a different technology to detect people arriving anyway (assuming I'm still doing this in 5 years), so this year, I did not pulse the laser. It was on any time the master switch was on and there were no guests in the garage. This allowed me to poll more frequently, so it was even less likely that someone would be able to enter the garage without the laser/light sensor detecting it. The laser worked perfectly this year. I didn't even have the problem I had last year where the light sensor shifted a couple times on me. No adjustments were necessary.

None of the other MCUs needed to send anything to the master. For that matter, there were only two signals the master needed to send to the other MCU:

  1. Wake up and go into standby mode.
  2. Run the sequence.

When an MCU was in sleep mode, all sources of power consumption were turned off, and the MCU itself went into sleep mode, in which its current consumption is measured in microamps instead of milliamps. Before going to sleep, though, the MCU enabled the interrupt that gets triggered by the rising edge on RB0.

Rather than use separate pins for each MCU (which means I would have run out of pins), I used only two pins to send these signals to all the other MCUs (not counting the laser). The individual MCUs were then responsible for running their own sequence at the appropriate time based on when the master signal arrived.

In addition to the master MCU and the laser MCU, there were three other MCUs.

  1. This PIC16F628 used 11 of 13 available I/O pins. It controlled:
  2. This PIC16F84A used 5 of 13 available I/O pins. It controlled:
  3. This PIC16F628 used 7 of 13 available I/O pins. It controlled:

Details about the witch can be found here.

Party City was our best friend this year. When we went in, all their masks were 50% off, so we went to town. We picked up the masks for Big Guy, the prisoner, the vampire, and the witch there. We also picked up the coffin for the vampire there.

Back to the Halloween 2002 pictures

Page last modified on 02/04/2003