• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Stop wasting time looking for files and revisions. Connect your Gmail, DriveDropbox, and Slack accounts and in less than 2 minutes, Dokkio will automatically organize all your file attachments. Learn more and claim your free account.



Page history last edited by PBworks 15 years ago

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:


* An X10 Universal Module

* One Lego Mindstorms RCX

* One lego connector plate wire (minimimum 6+ inches)

* NQC and a small program...


The RCX, UM506, and RCX software are collectively referred to as the X10RcxSignalAnalyzer (XRSA).




* 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:




* 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.




* 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.