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

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

View
 

X10RcxSignalAnalyzer

This version was saved 18 years, 11 months ago View current version     Page history
Saved by PBworks
on August 1, 2005 at 6:24:23 pm
 

A Homebrew Versatile X10 Signal Analyzer 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 (sometimes 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 reliability 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 any of you to build it, but in case you want a little more detail.

 

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

 

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.

* Test you've connected it properly by

* Set the UM506 to "momentary" contact and "relay/sound"

* Download and install NotQuiteC (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.

* Download and install a client program to your PC or Linux machine (such as BottleRocket, MisterHouse, or Heyu)

* Write an X10RcxSignalAnalyzerClient program to trigger N pulses (make sure house and unit code match UM506 code)

 

Testing

 

* 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've got the connector plate installed improperly, a damaged UM506, etc.

 

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.

* Make changes in your X10 system until you're satisfied with the relability.

 

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.

* I was able to get my reliability to nearly 100% by moving to an RF based solution.

Comments (0)

You don't have permission to comment on this page.