Electronics Projects

Repairing LitterMaid Self-Cleaning Litter Box

This repair project involves replacing malfunctioning microcontroller chip in LitterMaid Mega self-cleaning litter box with a Microchip PIC microcontroller and redesigning its firmware. It is shown how to embed a new microcontroller onto the original board and a detailed description of the new firmware algorithm is presented.

During the past several years we were using for our cat a self-cleaning litter box manufactured by LitterMaid. Although this device does not provide a perfect cleaning of the box so that you do not need to touch it any more for a manual cleanup, it made our life somewhat simpler. However, one day it stopped working for an unknown reason: the power LED was steady on but the rake refused to move.

Litter box

My litter box model (see above) is pretty old and is probably not manufactured any more. The modern ones come with more features like real-time clock which allows you to disable automatic cleaning at some times (e.g., nights), and air ionizer for reducing the smell. Therefore, the technique described here might not be directly applicable to newer models. I have never opened newer models yet and am not aware of what is inside. However, I hope that my experience could be applicable anyway.

The device is assembled on a single printed circuit board (PCB) shown below. After careful examination of all components I figured out that two transistors TR6 and TR7 of type 2N3904 were burned out and the microcontroller IC3 showed no reaction to signals applied to its pins. These parts are are circled.

Damaged parts

Note that in other cases the set of damaged components can be different. In my case replacing transistors was not a problem, but the device still did not work after this, so a microcontroller replacement was needed. The problem was that I could not identify the microcontroller (MCU). But even if I could, it won't help me much, since any MCU must be programmed with firmware and I have no development tools for this MCU. Moreover, the manufacturer does not provide any firmware for download. So, I decided to replace the original MCU with another one that I can handle (Microchip PIC16F684) and develop a new firmware for it by myself.

Original Circuit Description

By examining the PCB I came up with the schematic shown below (left image). The numbering of components on the schematic matches the one on the PCB.

Original schematic Modified schematic

As you probably know the device is equipped with a rake that moves from the back side of the box towards the front side (from left to right on the above photo). The litter grabbed by the rake is dropped into a plastic container located under the bluish cover at the front. The rake is activated (starts to move) after about 10 minutes as the pet leaves the box.

Checking for pet presence in the box is accomplished by an infrared emitting diode LED1 and IR receiving diode RX. The transmitter is switched by transistor TR1, whose base is driven by a square-shape waveform from pin 7 of MCU IC3. The frequency and duty cycle of this signal is about 10 kHz and 50%, respectively. The receiver's output signal is pretty weak and needs to be amplified, for which transistors TR3 - TR5 are used. The amplified signal is forwarded to the peak level detector on components D6, R19, and C9. In case of no blocking obstacle between IR transmitter and receiver (no pet in the box) the voltage at the peak detector output is about 4.5V. It drops down to 0V by blocking the IR ray.

Transistors TR8 - TR11 form an H-bridge that controls the direction rotation of motor M. Transistors TR6 and TR7 amplify current for driving the H-bridge. When the rake is steady the voltage at MCU pins 13 and 14 is close to 0 and all transistors TR6 - TR11 are closed. To move the rake forwards (for cleaning) pin 13 of MCU turns into a high-impedance state, resulting in opening of TR6 which in turn opens TR9 and TR10. For moving the rake back MCU outputs 0 at pin 13 and drives pin 14 into a high-impedance state. This results in opening of TR7 and as a consequence of TR8 and TR11. The voltage polarity applied to the motor changes to the inverse one resulting in reversing its rotation direction.

The final position of the rake as it moves forwards is registered by a pair of buttons End located inside the device side panels. At the final position the buttons get open and the voltage at MCU pin 4 raises up from 0 to 5V. Similarly, the home position of the rake is registered with another pair of buttons Home. As the rake reaches its home position these buttons get close resulting in dropping the voltage at pin 5 from 4.4V down to 0.

The motor moving the rake is equipped with a gearbox, resulting in a pretty high torque so I can barely stop the rake with my hands. Nevertheless, sometimes even this power becomes insufficient for moving the litter out and the rake jams. If this happens, the current through the motor and H-bridge noticeably increases. To protect them from burning out the designers use voltage regulator LM317 (IC4). Since the adjustment terminal of LM317 is grounded, the voltage at its output is close to the input one. As the current drawing by the motor increases, the one through IC4 and R28 increases too. IC4 limits the current at the level of approx. 1.5A thus protecting the H-bridge and the motor.

At the same time, increasement of motor's current is registered by comparator IC2a which monitors the voltage drop on R29. As the current goes above 0.7A this voltage drop exceeds 0.83V (determined by R21 and R24) the comparator output raises up from 0 to 5V. The low-pass filter R29 - C11 prevents the comparator from reporting short peaks of drawing current (below ca. 70 msec) that can be caused by transporting heavy loads by the rake or by reaching the terminal positions. Furthermore, triggering an overload is also provided by a bumper located at the back of the rake. This way pets incidentally appeared behind the rake moving to the home position get protected from smashing. The bumper closes button S2 (mounted inside the rake), which triggers an overflow signal at the output of IC2a only when the rake moves backwards. This is accomplished by diode D7 which blocks button S2 when the rake is moving forwards.

The device can be powered from a wal-wart power supply or from batteries. The input voltage is rectified by D1 - D5 and stabilized by IC1 of type 7805. The input voltage is monitored by comparator IC2b. If the voltage drops below 8.5V (determined by R19 - R20 and R22 - R23) the output of IC2b raises up from 0 to 5V. This information is used by MCU for controlling the rake. Turning the device on is performed by switch S1. Its lower (on schematic) contacts break the input voltage, while the upper ones probably serve for resetting the MCU.

Modifications in the original schematic

As it is mentioned above I replaced the original MCU with PIC16F684. This part has only 14 pins vs. 16 in the original one and has incompatible pinout. To resolve the last problem I mounted the new MCU on a small home-made PCB shown below. The right image is a detailed view of the PCB traces which are located on its bottom side. The blue jumper connects the filled (ground) areas on PCB.

Auxiliary PCB PCB layout

The board size is about 2x3 cm. It has 16 pads corresponding to the ones of the original MCU. The auxiliary PCB pads are connected by short wires with the corresponding MCU pads on the original PCB (the original MCU has to be removed from PCB, of course). This way the auxiliary PCB is assembled about 1 cm above the main PCB and the constructions is pretty stable. The images below show the original MCU on PCB and its replacement, respectively.

Original MCU MCU replacement

The 5-pin connector on the auxiliary PCB is intended for in-circuit programming of PIC16F684. This was very handy, since the firmware was reloaded into it many times during debugging. By the way, it turns out that my PIC programmer was unable to power the entire circuit during the MCU programming process. I resolved this problem by powering the device from its own power supply during programming.

Since PIC16F684 has pretty stable internal clock oscillator, the elements Q1, C6, C7, and R6 (that served for clocking the original MCU) are not needed and they are not connected to my board. I also did not use the reset circuitry R1 - C5, relying on the one built in PIC16F684. The broken connections are indicated by crosses in the modified schematic.

The last modification concerns resistor R7. It was disconnected from the base of TR1 by cutting off the corresponding trace on the PCB. Instead of it a new current-limiting resistor R0 is added. For this the PCB trace connecting the base of TR1 with MCU was cut off and a small SMD resistor in package 0603 (not shown on photos) was mounted over the cut. It is possible to use a regular resistor with axial leads.

Firmware design

Since I do not have a detailed description of the original algorithm, I cannot guarantee that my one exactly matches it. Anyway, by designing my firmware I tried to mimic the functionality of the original device as much as I remembered it.

The firmware is implemented as a finite state machine (FSM) with 5 states. One of those states in the initial one which the device enters right after powering up. The other state is the terminating one, which is used to indicate problems preventing the device from functioning. Examples of such problems are unavoidable obstacles hit by the rake or dropping of input voltage below 8.5V (when being powered from batteries). Exit from the terminating state is only possible by manually turning the device off and then on again. The remaining three states correspond to waiting for pet, moving the rake forwards for cleaning, and moving it back to the home position.

In general, the functionality of the device mostly consists of waiting for pet and activating the rake (moving it forwards) 10 minutes after the pet leaves the litter box. The rake gets 3 attempts for cleaning the box. After every unsuccessful attempt (rake is stuck by moving forwards) the rake is returned back to the home position and the next attempt is performed after a delay of 1 sec. The delay allows the litter to reconfigure after moving it, which could help to remove it. After 3 failures the rake gives up and stops, and the devices enters the terminating state. In this state the power LED starts blinking indicating a problem (normally this LED is steady on). If an unavoidable obstacle is experienced by moving the rake to the home position (which should normally never happen), the device gives up right away. In each state monitoring of the power supply voltage is performed. If it drops down below 8.5V threshold, the device enters the terminating state. Below I describe each of the states and inter-state transitions in detail.

State 0: Device initialization.
This is a starting state which the device enters right upon turning it on. In this state we initialize the MCU registers, set up timer TMR1 (used for triggering timeout interrupts), and tuning the PWM module (pulse-width modulation) to generate a waveform of frequency 10 kHz with duty cycle 50% for driving the IR emitting LED. After that the program enters state 2, in which it starts test cleaning of the litter box. This way the device functionality can be verified operatively.
State 1: Waiting for pet to enter the litter box.
Experiments with our neighbor's original working LitterMaid litter box showed that the MCU drives infrared LED permanently. This way the voltage stabilizer IC1 dissipates about 0.45W of heat. As no heatsink is mounted on it, the IC becomes so hot that I can barely touch it. I took it as a design flaw and decided to improve the situation by checking for pet only once every two seconds and for a very short time. This is accomplished by driving TR1 from the PWM module of the MCU. The PWM period of 10 kHz is provided by timer TMR2, while 2-second intervals are generated by timer TMR1. Every 2 seconds it requests an interrupt and the corresponding Interrupt Service Routine (ISR) enables PWM at pin 5 of MCU for a duration of 1 msec. This way the IR emitting LED becomes active for a very short time and this completely eliminates useless heating of IC1 and drops the total power consumption in a factor or 5.

During the PWM enabling interval the ISR also checks for a signal at pin 8 of MCU. Once this signal drops down to 0, the pet is detected. Then the program waits for 10 seconds and checks for pet again. If the pet presence is not confirmed, the program invalidates the first checking and returns back to the waiting mode. This is done in order to ignore short IR ray interruptions caused, for example, by manual cleaning of the box. Otherwise, if the pet is still there, the program waits for 10 minutes letting pet complete its job and checks for pet again after this timeout. If the pet is still there, the program makes periodic checks every minute until the pet leaves the litter box. As this finally happened the cleaning starts right away. The counter of cleaning attempts is reset to 0 and the program enters state 2.

State 2: Cleaning the litter box by moving the rake forwards.
In this state the interrupts are disabled, so the IR sensor does not affect the functionality. Once the rake starts to move forwards, the counter of cleaning attempts increments on 1. While rake is moving, the program polls the state of buttons End and outputs of both comparators of IC2 with a period of about 30 μsec. If the low battery voltage event is detected, the program enters the terminating state 4. If the rake is stuck the program enters state 3 to return rake back home after a 1-second delay. As one of the buttons End gets open (cleaning completed), the counter of successful events is reset to 0 and after a 3-seconds delay the program enters state 3. The delay is needed for letting the litter drop into the plastic container.

The tests showed that sometimes the cleaning process was interrupted with rake located somewhere in the middle of its path even if no obstacle is detected. This probably happens because of vibrations caused by moving rake leading to short malfunctioning of buttons (my unit is too old). To resolve this problem, debouncing of switches was added, so the now rake does not take the button states into account before they are confirmed for 128 times.

State 3: Returning rake to the home position.
This state is similar to state 2. The motor direction is reversed and the program monitors the state of buttons Home and the outputs of both comparators of IC2. If one of them goes up (low battery voltage or unavoidable obstacle), the program enters the terminating state 4. As one of buttons Home gets close the program checks the value of the cleaning attempts counter. If this value is non-zero, then the cleaning is not completed and the rake was returned back because of an obstacle. In this case if the counter value does not exceed 3 the program is moved to state 2 again without cleaning the counter and the cleaning process repeats. If the counter value is 3, the rake gives up to move an obstacle and the program enters terminating state 4. Finally, if the counter value is 0 (cleaning is completed successfully), the program enters state 1 for waiting of a new pet visit.
State 4: Terminating state.
This state is used to indicate a problem by blinking the power LED (normally it is steady on). Exit form this state is only possible by a manual reset of the unit by turning the power switch off. Possible reasons for entering this state are restricted to the presence of an unavoidable obstacle in the litter box and low power voltage. It is impossible to distinguish between them just by observing the power LED. However, presence of an obstacle in the litter box is usually easy to detect visually (I have never had problems with it).

Concerning the low input voltage, if the litter box is powered from batteries, the device will most likely detect low battery voltage again right upon reset, so the reason of LED blinking becomes obvious. In case of power outage the program will be restarted from state 0 and perform cleaning as soon as power becomes available.

The program is written in assembly language and intended for compilation with MPLAB IDE, which can be downloaded from microchip.com website.

If I would do it again

My primary goal in this project was to reanimate the broken device as soon as possible rather than to optimize it. Anyway, the first thing I would do is eliminate the pull-up resistors R27 and R28 and insert current-limiting resistors of 2.2K between the bases of TR6 and TR7 and pins 11 and 2 of MCU respectively (similarly as it is done with TR1 and pin 5 now). This way the MCU would not sink the current through R27 and R28 to keep the motor in the stop position. The motor is in this is the state for most of the time, so currently 10 mA of current are sinking my MCU for nothing.

Next, I would reroute the auxiliary PCB so that the buttons and outputs of comparators IC2 would be connected to pins of PORTA of MCU. This way one could use interrupts on change on PORTA and the MCU could be put on sleep for most of the time. To enable this feature, pin 4 should be pulled up to +5V via R31.

Also, the comparators do not need to be on all the time. The battery voltage monitoring could be accomplished ones in a while as the device is in the pet waiting mode. This way CPU can be kept on sleep and awaken for a short time to perform voltage checks, for example every 2 seconds which the pet presence is checking.

Finally, I would power the amplifier on TR3 - TR5 from a CPU pin and turn it on only when it is used (1 millisecond interval every 2 seconds). By implementing all this, the power consumption could be dropped down in another factor of 5 as minimum. Well, this would probably save you at most a couple of bucks on you electricity bill in a year, but why not.

As I mentioned, the device is pretty old. Modern MCU are more beefy and many of them contain built-in comparators. So, IC2 could be eliminated by using a bigger MCU. But for this probably a new PCB must be designed.


Last modified:Wed, Feb 10, 2010.