See Also: intro, part 1, part 2, part 3 and part 4. (Github project.)

WARNING: I am not a hardware person. I’m just a programmer that knows “enough to be dangerous.” I have not measured the voltage/signals coming out of the Control Box to see if they are safe to connect to an Arduino UNO like this. What I am doing could fry the Arduino and/or the Control Box. I don’t know. Consult someone who knows hardware to find out what I am possibly doing wrong…

This article series is a “stream of consciousness” post. I describe the steps as I am working through them. There will be dead-ends, where I learn something new, so try not to scream at your screen when you see me doing something dumb. ;-)

Control Box, meet Arduino UNO…

I used some header/jumper cables (male to female) to go from the four-pin connector’s green wire to an Arudino digital pin (I chose pin 13 since it is next to a ground pin), and the four-pin connector’s black wire to an Arduino ground pin.

Control Box  Arduino UNO
===========  ===========
Blue ------- PIN 13
Black ------ GND
Red          not connected
Green        not connected

In the above photo you will see I also have the blue wire also connected, but it is currently not hooked to the Arduino. You only need the green and black Control Box wires going to Arduino I/O and GND pins.

Here is my code, which uses SoftwareSerial to turn PIN 13 (picked only because it was next to the ground pin) in to an RX (receive) serial port pin. The code then loops waiting for a byte to be written by the Control Box. Since I now see that the pattern is four-bits/four-bits-inverted, I even added a bit of code that ANDs each of those four bits together. The result should be zero if it is a valid byte from the Control Box. (This could be done a bit better since now I know the acceptable values are only 1-8, but this is good for a quick test.)

I then print out the byte value in HEX and as binary, and if it’s value is not 8, I print “PLAYING#” and parse out the 3-bit number (1-7). If it is 8, then I print “STOPPED” since that marks the end.

Lather, rinse, repeat… Here is my code:

#include <SoftwareSerial.h>

// RX pin connected to GREEN wire.
// TX pin not used.
SoftwareSerial mySerial(13, 3); // RX, TX


void setup() {
    // Arduino console port.
    Serial.begin(9600);
    while (!Serial);

    // Control box sends at 550baud.
    mySerial.begin(550);
  
    Serial.println("Running...");
}

void loop()
{
    unsigned char ch;

    // put your main code here, to run repeatedly:
    while (mySerial.available())
    {
        // Read byte from Control Box.
        ch = mySerial.read();

        Serial.print ("[");
        Serial.print (ch, HEX);
        Serial.print (" - ");
        Serial.print (ch, BIN);
        Serial.print ("] ");

        // Validate. Left nibble AND with right nibble should be zero.
        if ( ((ch & 0xf0 >> 8) & (ch & 0x0f)) != 0)
        {
            Serial.println ("INVALID.");
        }
        else
        {
            if (ch & 0b1000)
            {
                Serial.println ("STOPPED.");
            }
            else
            {
                Serial.print ("PLAYING #");
                Serial.print (ch & 0x0f);
                Serial.print (" ... ");
            }

        }
    }
}

// End of file.

Running that, then triggering the sensor, produces the following output:

Running...
[92 - 10010010] PLAYING #2 ... [F8 - 11111000] STOPPED.
[83 - 10000011] PLAYING #3 ... [F8 - 11111000] STOPPED.
[74 - 1110100] PLAYING #4 ... [F8 - 11111000] STOPPED.
[65 - 1100101] PLAYING #5 ... [F8 - 11111000] STOPPED.
[16 - 10110] PLAYING #6 ... [F8 - 11111000] STOPPED.
[7 - 111] PLAYING #7 ... [F8 - 11111000] STOPPED.
[E1 - 11100001] PLAYING #1 ... [F8 - 11111000] STOPPED.
[92 - 10010010] PLAYING #2 ... [F8 - 11111000] STOPPED.

If we can read those bytes, we should be able to send them to the head :)

And now on to the hard part… that blue wire and the pulses that control the servos (or so I suspect at this point).

To be continued…

See Also: intro, part 1, part 2, part 3 and part 4. (Github project.)

IMPORTANT NOTE: This series follows my typical “document as I discover” format, and will be speculating about something that turned out to be incorrect. Rest assured, I do end up showing how things actually work…

Lethal Lily Swamp Witch is (was?) an animated Halloween prop sold by Home Depot in 2023. Although it looks like you cannot currently buy a full Lethal Lily, replacement parts can be ordered from Seasonal Visions International:

Home | Seasonal Visions International – SVI Service

To see if the animated head could be controlled by an Arduino, I ordered a replacement HEAD, SENSOR, ADAPTER 3AMP and CONTROL BOX.

CONTROL BOX

The control box has the following:

• Three-position slide switch to select modes: Sensor, OFF – Try Me, and Lights Only.
• Barrel connector input jack for the 5.9V DC 3 amp power supply.
• Volume knob.
• Speaker.
• Four cables that go to the sensor, head, and (I assume) lights.

The cables are as follows:

• Three-pin (green-blue-white) connector that goes to the SENSOR.
• Four-pin (blue-black-red-green) goes to the HEAD.
• Two-pin (black-red) that goes to … ? (probably lights)
• Two-pin (blue-red) that goes to … ? (probably lights)

Inside the box is a small circuit board. I have not removed it to see what is on the bottom, but I suspect the processor is under the black blob.

POWER ADAPTER

The power adapter is odd — 5.9V DC, 3 amps.

SENSOR

The SENSOR uses three wires, and I assume it is just a normal motion sensor. A PIR (passive infrared) motion sensor has three wires (voltage, ground, and the output).

HEAD

The head has a four-pin cable coming out of it near the metal shaft that is used to connect it to the frame.

How does it work?

I had hoped to find a bunch of different cables that would run to the head, each operating independent servos. Seeing only a four-wire connector made me wonder if they were sending commands (like I2C messages or something) or doing something else to address all eight (?) servos in the head.

The first thing I did was connect the power adapter and sensor, then hook the head cable up to a Saleae Logic Analyzer. I assumed the black wire to be ground, and the red wire to be power, so I looked at what was going on with the blue and green wires on the ends of the connector.

I triggered the sensor seven times (since my understanding is there are seven different patterns Lily can play). What I saw looked promising:

The Green Wire

Above, Channel 0 was hooked to the green wire. This appears to be high except for a few pulses low at the start and end of the sequence, and another set of pulses low at the end.

As I checked the start and stop pulses for each sequence, I saw that they were different. The pulses would vary is width, making it look like it might be I2C or some similar protocol where LOW represents a 0 and HIGH represents a 1 (or vise versa). There are no clock pulses, so if this is encoding a number, it must be doing it based on predefined time, starting to count when it sees the pulse drop. That makes me think it could be normal serial data at some baud rate.

If that is the case, I can work out a sequence of numbers being sent by the green wire at the start and end of each sequence. The signal would drop to indicate the start of data (a “start bit”). Below, “D” is a down pulse, and “U” is back up. I can easily “see” eight in each of the start/end sequences:

1. UDDDDUUU / DDDUUUUD
2. DUDDUDUU / DDDUUUUD
3. UUDDDDUU / DDDUUUUD
4. DDUDUUDU / DDDUUUUD
5. UDUDDUDU / DDDUUUUD
6. DUUDUDDU / DDDUUUUD
7. UUUDDDDU / DDDUUUUD

Looking at the pulses this way shows a pattern. The end pulses are the same for each sequence. Using a serial decoder and and playing around with the baud rate until the bits decoded match where the pulses are, gives me something like this:

That is using a value of 550 baud. I have no idea if this is correct, but if so, it gives the following values for the start of each sequence. Note that the bits are being written least bit first (so, right to left) so UDDDDUUU becomes 11100001 in binary.

E1 - 11100001
D2 - 11010010
C3 - 11000011
B4 - 10110100
A5 - 10100101
96 - 10010110
87 - 10000111

And at the end of each pattern, there is a 0x78 sent (as shown in the screen shot above):

78 - 11100001

I see a pattern! Each set of eight pulses is a 4-bit value, then the value with the bits inverted!

E1 - 11100001 - 1110 and 0001 (1)
D2 - 11010010 - 1101 and 0010 (2)
C3 - 11000011 - 1100 and 0011 (3)
B4 - 10110100 - 1011 and 0100 (4)
A5 - 10100101 - 1010 and 0101 (5)
96 - 10010110 - 1001 and 0110 (6)
87 - 10000111 - 1000 and 0111 (7)

The values go from 1 to 7 — matching the number of patterns the control box can perform. It looks like 0 is not used.

As for the end sequence of 78, that is the same pattern:

78 - 01111000 - 0111 and 1000 (8)

I do not know what these values instruct the head to do, but at least now I should be able to recreate sending those pulses out via an Arduino or something just by writing out a byte at 550 baud.

The Blue Wire

The data on the blue wire looks like pulses of different widths. My understanding is a servo position is set based on how wide of a pulse is sent. The head must be receiving these pulses and passing them to the different servos somehow. Speculation: Perhaps it sends eight pulses that go to servo 1, 2, 3, etc. and then restarts back at servo 1. (Me from the future: It does not…)

To figure out how many pulses there are for each of the seven sequences, I used the Saleae Logic Analyzer and highlighted a range of pulses. It showed me that each sequence has this many “rising edges” (where the pulse goes up):

1. 85 pulses
2. 87
3. 75
4. 87
5. 100
6. 96
7. 79
8. (back to pattern 1) 84 … ?

Speculation: Seeing that the first pattern 1 reported 85 pulses in the Saleae Logic Analyzer, then the second one reported 84, tells me I may not have things set up properly with my Saleae.

This what not what I hoped to see. I expected. If there are eight servos, each number should be a multiple of eight. This clearly does not be the case. Perhaps the pulses can stop at any time (say, updating 8 servos, 8 servos, 8 servos, then just 3 for a total of 27 pulses)? I would still expect every pattern to end with pulses that set the head back to a default “off” state. Perhaps the head does that on its own when it receives the 0x78 “end” byte? Since the start bytes are different for each pattern, I suspect the head must need to know that for some purpose, as well. (Me from the future: This is foreshadowing…)

Also, I only think there are eight servos because of a reference in this Home Depot press release. There is an unofficial wiki that says there are nine servos.

I also do not assume all servos are independently controlled. If each eye has it’s own left/right servo, one pulse could be sent to each eye so the move together. At some point I may have to take this thing apart and look inside.

Until then, let’s see what eight servos might control:

1. Head tilt forward and backwards.
2. Head tilt left and right.
3. Head turn left and right.
4. Left eye looks left and right.
5. Left eye looks up and down.
6. Right eye looks like and right.
7. Right eye looks up and down.
8. Eyelids blink.
9. Mouth open and close…if this is a servo?

Maybe this is why the wiki says nine?

And, if it is nine, but they tied the eyes together, it might really look like this to the control box signals:

1. Head tilt forward and backwards.
2. Head tilt left and right.
3. Head turn left and right.
4. Both eyes looks left and right.
5. Both eyes looks up and down.
6. Both eyelids blink.
7. Mouth open and close…if this is a servo?

That could mean that only seven pulses are needed in the sequence.

Before I can proceed, I need to hook up the head and see what all motions it does.

To be continued…