Contents

Overview

The following information covers some of the challanges when doing power cycle endurance testing where the unit under test (UUT) is connected to the python controlling application using a serial port. Some of the challenges include not letting the extranous data that is often received over serial as the UUT powers off and back on. These characters can trip errors in the python Unicode decoder that need to be ignored.

The only downside I have with X10 is you can't turn it off and back on quickly - something on the order of 3 seconds minimum. I like X10 because I have lots of applicance modules so I can run multiple tests at the same time, I can use it with desktop icons so I don't have to physically power cycle hardware, and because the appliance module can be connected to any outlet, I can set the endurance test hardware out of the way.

python X10 control

There are three subtle host PC configuration steps that I found to be needed to allow X10 power control to work smoothly. Hopefully future Linux distros will do a better job supporting X10 modules.

Unplug CM19a X10 Transceiver

Black list other drivers that attempt to own the X10 USB RF tranceiver

Now you can test by turning a module on and off. My module is set to house code G unit code 3.

./CM19aDriver.py G 3 ON
./CM19aDriver.py G 3 OFF

python expect setup

The good news is the is an expect package for python called pexpect. If you have used any of the other variations of expect, you will find the python version works as you would expect.

I added my Linux user ID to the dialout group so I could send and receive data or the serial ports and also installed the pexpect package.

sudo addgroup $USER dialout
sudo apt-get python-pexpect

Ignoring binary data

The bad news is I found pexpect to assume it was working with a text (not binary) data stream. When binary data was received, the python exception was so low that I couldn't figure out how to easily ignore it while waiting for the expected data. In my case, the binary data was due to powering off and on devices connected over RS-232 serial. Occatiionally I would get a random binary pattern during a power cycle and python said it could decode the Unicode character. Thanks to Open Source code, I could at least work around the issue.

I ended up changing the pexpect 2.5.1 source code to solve this issue. Specifically, I made the following changes to /usr/local/lib/python2.7/dist-packages/pexpect/__init__.py. The changes basically told python to ignore unicode decode error and to strip non-ASCII from strings before logging them.