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

  • Whenever you search in PBworks or on the Web, Dokkio Sidebar (from the makers of PBworks) will run the same search in your Drive, Dropbox, OneDrive, Gmail, Slack, and browsed web pages. Now you can find what you're looking for wherever it lives. Try Dokkio Sidebar for free.



Page history last edited by PBworks 17 years, 5 months 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.