A Homebrew Versatile X10 Signal Analyzer (Data Logger) using a Lego RCX
While investigating ways to improve X10 reliability (eventually hitting upon the X10RfConfiguration), I considered different approaches to see if any of the (often time-consuming and expensive) changes I was making in my X10 configuration were helping at all.
What I was looking for was a way to tell exactly how many X10 pulses reliably made their way to their destination socket as initiated by the CM11A and CM17A over a given interval. I was hoping to make a series of changes, e.g. moving/adding filters, moving my boosterlinc, alternative dryer coupler/repeater placement, turning on and off breakers, etc and then systemically logging whether my changes made things better or worse.
I had the X10 ESM1 signal analyzer. While this is a good unit, it's hard to tell from the moving LED bar graph whether systematic changes are getting better or worse over time. You'd have to read the graph and make a subjective judgement as to whether it seemed stronger. There are more elaborate X10 signal analyzers out there, but it seemed to me that I had most of the parts needed already.
Basically, what I did is make a little program for the Lego RCX that counts and logs the pulses it receives as triggered by contact closure on the UM506. Then I use a program to trigger N pulses over M minutes. As I make changes, I compare the logs and see which changes are beneficial.
That's probably enough info for most hackers build it, but in case you want a little more detail, I've described below.
Here's how I made a better X10 signal analyzer using parts I'm guessing that most folks have around:
The RCX, UM506, and RCX software are collectively referred to as the X10RcxSignalAnalyzer (XRSA).
Instructions
* Cut the Lego electric connector plate wire, one side should longer than other
* Separate the split the ends of the wires and connect to the UM506 and the Lego RCX on sensor one (not the motor outputs)
* Set the UM506 to momentary contact and sounder & relay
* connect the UM506 and RCX together with some rubber bands or velcro.
* Download and install NQC (although you could easily make the same program in any of the other programming languages available for the RCX - even the 'stock' LegoMindstorms RCX language would probably be fine).
* Compile and and download X10RcxSignalAnalyzerCode or equivalent program.
* Download and install a client X10 communication program to your client machine (such as BottleRocket, MisterHouse, or Heyu)
* Write an X10RcxSignalAnalyzerCode client program to trigger N pulses (make sure house and unit code match UM506 code)
It should like something like this:
Testing
* The UM506 must be plugged into the wall for this test to work.
* By pressing ON on the UM506 you should see a tiny triangle in the upper left hand corner of the RCX display that indicates you've closed the sensor contact.
* If this doesn't work, you may have the connector plate installed improperly (check the orientation and ensure it's conrrected tto the RCX motor control, not the sensor controls.)
Operating Instructions
* Install the XRSA in a socket for which you want to measure accuracy.
* Start the program on the RCX by clicking the run button.
* Start the client-side X10RcxSignalAnalyzerCode and let it complete its cycle.
* Retrieve the XRSA and upload its datalog using the command "nqc -datalog"
* Examine the intervals claimed by the log. Missing pulses should be obvious as the time delayed indicated will be multiples of the "correct" length. Even the number of lines is a good first pass hint, if you've generated fifty pulses, ideally you'll have fifty lines. Anything less represents pulses lost in transit.
* Make changes in your X10 system and repeat logging/analysis, until you're satisfied. Instead of just eyeballing a display to judge the quality of the signal, you have some hard data about how your changes affect the system.
Notes
* Something similar could certainly be made with a CM11A and a laptop, however, as I was convinced the CM11A was part of the problem, not the solution, I wanted to 'take that out of the equation'. Plus I only had one. Also the portability of the XRSA is attractive.
* Another alternative implementation is a digital counter circuit and the UM506. An AVR Butterfly or any other embedded processor would probably work nicely.
* I was able to get my reliability to nearly 100% by moving to an X10RfConfiguration.
* Send me an email to newsaccount.h at gmail.com if this was handy for you!
Sponsored Links
escape programming hell...
Comments (0)
You don't have permission to comment on this page.