Re: Need some antenna advice (for my CM15A, of course)

I see. Sort of like a VU meter on an AGC tape recorder always showing a strong signal as long as the source is within a certain range.

As long as the distance tests are rigorous enough, they're what really counts to the end user. It's just that in so many posts I see less than optimal testing procedures. I would assume you'd have to take a least four different readings (one from each compass point) to make even a marginally useful range map.

Yes, thanks. That's very "Closely spaced pulses affect the AGC and the capacitor on the comparator input differently than widely spaced pulses."

What do UPB pulses, which (IIRC) are variably spaced, look like to an X-10 transceiver? It's alleged that UPB works with everything except the Lutron Homeworx product lines. I wonder why? There's some interesting reading at:

where they say: "Case Study: Web Mountain has installed UPB devices in approximately 15 homes. With the exception of one outlet in one large house, we installed the devices, powered them up and they worked. The one outlet that didn?t work was fixed by adding a phase coupler. No noise filters were needed and no troubleshooting was required. Only one of the 15 homes (>6500 sq feet) required the UPB phase coupler."

Your test setup seems quite rigorous so I'm assuming yours are real-world estimates, unlike the overly optimistic figures given by X-10 and some X-10 enthusiasts.

Have you ever looked at Leviton's HCPRF All-housecode transceiver with the built-in lamp control module? It's got a little wire pigtail antenna that's not very effective. It's a unit that can certainly stand a "hearing aid" of some sort but I believe it's based on the older, AC hot = ground principle because the insulated pigtail has no shield - just a single wire connected to the PCB.

I took it off line a month ago in an effort to stop a collision problem I was having. Unplugging the transceiver stopped the problem, but it reappeared a month later. More detective work required. I am frustrated because I have reached the limit of what my trusty ESM1 can tell me about the powerline signal. Today, I saw a 1.4V good signal followed by 1.4v noise followed by a .40 good signal after using a credit card RF X-20 transmitter. Very repeatable. Very weird.

I'm wondering if I should buy a used o'scope or pony up for one of the signal analyzers. Any suggestions? Both Lynx and Monterey look like they'll give me at lot more useful information about the boogie men in my X-10 setup. I bought a dozen new filters and am determined to clear the lines of all the noisemakers and signal suckers. It just seems that it *is* possible to have a fairly reliable X-10 system because enough people manage to do it. If a better meter or o'scope doesn't work, it will be time for Zigbee!

Thanks for all the work in putting those pages together with screen shots, etc. It really helps explain what's been a pretty amorphous concept. Do you think you might ever do a similar analysis for UPB? I'd really like to know whether their "Pulse Position Modulation" scheme is as robust as they claim.

-- Bobby G.

This has drifted rather far afield from the original thread.

I have one of the Leviton HCPRF transceivers but don't recall that it has a built-in lamp module. At least not a dimmer - mine has a solid state relay. It's RF range seems comparable to standard X-10 transceivers. Unfortunately, there's no room within the case to add a connector for an external antenna so I did not try to trace the circuit to see whether they are using the hot side as electronic ground. Without knowing that I cannot make any antenna recommendation. There should be no collisions as the Leviton will back off and wait for a clean line before it sends PLC. You will get duplicates of all signals. If you have marginal coupling between phases you might see different results at different times. If the Leviton can't "hear" the other transceiver, there will be collisions.

Don't confuse the UPB PLC pulses with RF. They're different species.

IMO, AGC doesn't do much for PLC. AGC was invented for AM radio as a way to maintain a steady volume. It does this by reducing gain as signal strenth increases.

Automatic Threshold Control is slightly different. It raises the threshold so that only stronger pulses are effective. If the signal is stronger than the noise, the output is clean. The page I referenced illustrates this. The comparator circuit is called a "data-slicer" because, in effect, it slices off the bottom half of the pulses, omitting most of the noise and passing only the cleaner top half along.

I'm not at all sure what UPB pulses are composed of. PCS specs say they are capicitor discharges or, in other words, noise. The page you cited implies they are something else entirely. The page you cited also spews a lot of male bovine excrement about PLC noise. A bigger problem is the line filters added to AV equipment, to meet FCC requirements, that attenuate PLC signals.

The data on the UPB tests by PCS would seem to indicate that they get most of their reliability from having a much stronger pulse and from having a two-way protocol so that any mangled signals are repeated. However, I question the validity of a test that did not use actual dimmers, etc. Triac noise looks a lot like their pulses.

Your ESM1 tests sound like collisions.

I think the Monterey is vastly overpriced. It falsely reports every 1110 sequence not followed by a valid X-10 sequence as a "bad start code" when they are usually the results of collisions between signals offset by 1/2 cycle. The TesterLinc is cheaper. I think Bruce Robin posted comparisons of all of the available testers.

This is a good choice for a "scope"...

You should also get ACT's Scope-Test2 if you want to look at X-10 PLC signals.

I doubt I'll do anyth>>>BX24-AHT wasn't really useful for making definitive comparisons

Indeed, we have sure veered far from the original thread -- but it sure is interesting.

I don't know how to explain this (sorry to go back to my amateurish discussion), but my eggbeater antenna is working better than ever!

I threw it over an old exercise bike in one my closets here in my basement -- 100 feet of cox cable in a knot.

The antenna is hanging upside down, with the eggbeaters resembling 85 year old breasts (I'm a paramedic -- I see them regularly).

One of the leads actually ripped off, so it's actually more like one breast.

Lo and behold, my slimline remotes are working 3 floors up. ...there is no method to this madness!

I did order an old fashioned transceiver today, anyhow. $20.00 with a chiming module and an Active Eye PIR sensor... what the heck!

Okay, sorry for my update... back to the more interesting stuff.

David, I'm sorry to hear that health reasons have prohibited you from helping with my assembly. One day I'll get someone over here, and we'll put in the amplifier, too.

Thanks!

Mike

Agreed. And I am going to break it out into two messages because the thread splits again!

Correct. Although the one I have says "300W max., 60W min. Incandescent load" and responds to the ALL LIGHTS ON command - it does not respond to DIM or BRIGHT commands. I assumed that made it more of a lamp module than an appliance module. They confuse the issue pretty solidly by stating, in one part of the documentation:

NOTE: If a power interruption should occur while the device in ON, the light load will return to its previous light level when power is restored.

That's a neat trick for a module that doesn't seem to respond to DIM commands sent by Palmpad, Sticka Switch, Credit Card/Keychain type controllers and Mini-controllers. The HCPRF PDF file goes on to say: "It can also be programmed to respond to scene commands from scene controllers." Perhaps if it dims, only Leviton controllers can activate that function.

However, further on down when they discuss testing, they seem to contradict themselves by saying:

"3. Transmit DIM and BRIGHT commands. The device will not react, but will transmit the DIM or BRIGHT command through the house wiring; all units set to the same code will respond."

So, I'm not quite sure *what* it is. I'd consider it a "non-dimmable" lamp module, but it's definitely a weird duck. It *always* collides with the TM751s that are set to matching housecodes and it doesn't accept commands from the older-style transmitters that came with the RR501s (which had the somewhat useful 4 position unit slide switch).

The HCPRF got retired because of the interactions with other transceivers but I'd sure like to know what it's putting on the line. The Decora unit makes the ESM1 do a weird little dance whenever it's activated on a housecode with dedicated TM751 around.

Unfortunately,

Yes, it's quite crowded in there. I suspect that if the HCPRF ever DID dim, they disabled that function to limit heat build-up inside such a small unit. I'd spring for the CM15A with its far roomier cabinet. It might be possible to remount the HCPRF in an old RR501 case, but it hardly seems worth the effort since it doesn't play nice with the TM751's I use.

I suspect this is what's going on with the ESM1 showing a definite second signal at a lower voltage after it reports a good signal and then a strong noise block. This is what I'd like to be able to "see" in some sort of detailed display.

I've read through comments by you and others about the Monterey and decided to pass on it. While it stores captured PLC data, there's NO WAY to output it to a PC for analysis. I ordered the LynX-TOOLS Power Line Analyzer.

We'll soon see what it says about the Decora's dawdling. Interestingly enough, the ESM1's strength LEDs seem to follow the Decora's status light blinks by about 1/2 a second. I'm determined to figure out why the ESM1 shows 1.4 volts or the first series of blinks and only .4 volts for the second "good" signal.

I got the strong sense that were a traditional "scope" to appear, I would find myself in the doghouse with SWMBO. The Stingray looks awfully sweet and if the Lynx doesn't do what I hope it will do, I'll seriously consider it. I'm really looking forward to seeing what's really on the line, not just whether the signal's strong or not.

Thanks again for your comments, Dave

-- Bobby G.

I have the Lynx which shows a lot of interesting detail but hasn't really helped me do much troubleshooting. I spent an hour with the engineer who designed it at an EHXpo 2 years ago and he showed me how to read it. He talked about updating the software to make it a little more useful for field work but nothing came of it. The ESM is handy for a quick test particularly when you want to look across a room and see if a signal is getting through. I like the Monterey but it is somewhat error prone as Dave mentioned. It is still useful and was my favorite UNTIL I got my hands on the ACT 004 tester. Not cheap, it is, (saw StarWars the other night) but for the money it's a better unit than the Monterey and is my current favorite. I still have my old Leviton tester too, now about 20 years old, and it still does the job in a primitive sort of way. If I could only have one, it would be the ACT 004. (Home Controls had the best price on it at the time).

From:Robert Green ROBERT snipped-for-privacy@YAH00.COM

Reading the docs, are we? Geesh - no wonder things are so confused. ;)

I did not do extensive testing with the HCPRF. Once I saw there was no room to add an external antenna jack, I lost interest.

What unit codes are you seeing the strange behavior on?

gives a very brief summary of what you'll see with multiple transceivers.

While some have collision avoidance, there are still collisions as there must be a collision in order for them to detect it and back off. This is one reason for there being two copies of the X-10 PLC code. If the first gets corrupted, the second will be OK (assuming that one of the transmitters backs off). The price is duplicate commands - if the unit that backed off then resumes transmitting once the line is clear. I consider units that do automatic retransmission as brain dead. It's easy to envision duel-to-death powerline storms from two such units. When I design something I limit the number of times it will try to retransmit before throwing in the towel.

If there's no collision, the codes coincide and all's well.

The TM751 does not have collision detection or avoidance. Since it does not "listen" to the powerline, it is oblivious to what's coming from other PLC transmitters. When it receives an RF code for its housecode, its action depends on the unit code. If it's for units 1 or 9, it has to wait for a rising edge on the 60Hz in order to trigger the SCR that drives the relay, before it relays the command to the powerline. For all other units, it just sends the code at the next ZC regardless of whether it's a rising or falling edge. If there are two transmitters on different phases, the signals will be

1/2 cycle off for units 1 & 9 but will coincide for all others.

Before ELK bought the design, I was in communication with Paul Beam, the designer of the ESM1. We were discussing turning it in to a more sophisticated device with an RS-232 connection and I offered to write a Windows interface for it. Once ELK bought it, those discussions ended but I did learn some of the details of the ESM1. It does not do any sophisticated anaysis of the signal but if it sees a 1110 followed by an appropriate number of 10 and 01 sequences, it turns on the "X10 Good" LED. If it does not see a legal sequence, it does not illuminate the LED. So, you will always see the signal in the LED bar for one full sequence before the "X10 Good" LED lights as the ESM1 has to see a full signal before it can make a judgement.

Now, even with something that will show you the PLC signal, it's difficult to identify where a specific burst of 120kHz originated. If we're looking at two TM751s or a mix of TM751 and some other transmitter, about the only clue is the amplitude of the signal and that's not always definitive especially when all of the signal strength meters fail to show the true amplitude for strong signals. All of them (including the newer ACT) top out below 5Vpp while most of the older X-10 devices transmit 10Vpp. I have a pre-ELK ESM1 which was calibrated to show 10Vpp as fullscale. The ELK models are calibrated using a Monterey so fullscale is something less than 5Vpp.

As you can see from the page I cited, I did not do much testing with the HCPRF. Specifically, I did not test it with other transceivers on opposite phases which is where most of the interesting things happen. I tested it using the CM15A as my tarot card. With the Cypress MCU moved to a breadboard and a ribbon cable from the breadboard to the CM15A MCU socket I could monitor PLC receptions while disabling the the CM15A's PLC transmissions.

As an aside, the TW523 does not report all powerl>

Leviton's web page says, "...incorporates a built-in outlet suitable for "ON"/"OFF" switching of incandescent lamps rated up to 300W"

The TM751 label says it can handle 500W incandescent and has other ratings for other types of loads.

Yes, I'm going to go offline a bit to read up some more. There's a lot of homework involved in (me) trying to understand what you're saying. Your ..mbx site is informative and well-presented but my brain has become highly insulated so it takes a while to soak through.

I've been rummaging around X-10 sites so I can hope to ask the right questions to help me hunt down the X-10 weirdness that's been plaguing me. I have to install the Lynx gizmo (on an old Armada without a CD drive or a USB port or network card from a CD) and "take a look around" to figure out what's happening. Hopefully I can capture readings that make sense and not just flashes from my Elk meter.

The quick answer to one of your questions is: "The haunted lamp lives at B13" and when I was recording from the line via (in)ActiveHome I recall seeing a lot of M13's and status requests.

I can't believe how much hope I have imbued in the Lynx analyzer, sort of like getting a electronic X-10 Rosetta stone.

Thanks for your help, again, Dave. Now back to Reading The (many) Fine Manual(s) . . .

-- Bobby G.

I had to go through a bit of a search to get them, too. I lost the little paper insert and then realized that the house and unit code are set via the programming button. I didn't remember how to do that. (old age, I guess). Leviton never replied to support emails but I finally found the PDF imbedded in one of their catalogs (had to DL 60MB by modem to do it!). The funny part is that I had finally found a use for HCPRF, but that was based on the mistaken assumption that it was a old-fashioned relay module like the TM751 and RR501 and not a solid state relay for incandescent loads. I was going to use it to control some fluorescent lights! :-( No such luck! The one thing the module has going for it, as opposed to the TM751 is that it's silent. My MIL finds the TM751's relay clacking objectionable.

Too bad. I can afford to experiment on mine and might have taken a whack at modifying it just out of curiosity. It's definitely not happy within my current setup.

On a number of different codes. B13 is the most popular inadvertent turn on (and off) but others do it as well. I should add that these units are controlled by the infamous Hawkeye PIRs. As I wrote that, I realize I may have blown a couple of 100 bucks on the Lynx. The collisions may be occurring in the RF portion of the "control sequence." :-( I used to keep the CM11A active, just logging the weird signals but I stopped using it when it started showing signs of overheating.

Yes, I've been spending a lot of time there, sifting through the diagrams and data.

Am I right in assuming that there's no error checking like a CRC check of the *complete* X-10 signal? I see it as a series of 120KHz tones synchronized to the zero crossing. When a receiver sees 3 or more tone-free AC cycles it is then "primed" to look for a "start code" of "1110" which, for a standard X-10 transmitter, is a series of 9 pulses, total. Six of those pulses are ignored, as they are for split phase systems zero crossings. The Powerlinc appears to differ in that it only sends pulses on one phase, so the scope trace looks a lot like the actual binary string transmitted.

My understanding is that whatever error checking occurs, it's in representing a 4 bit binary number like 1001 in 8 bits using a bit's complement to guard against errors. So 1001 would become 10010110. The only place this does NOT occur is in the start code, which is just 1110 that follows at least three signal-free AC cycles.

FWIW, I can't seem to reach the Power Line Communication Bibliography referenced on

don't know whether it's me or they've disappeared. I searched the Wayback machine for it:

otherwise known as and I can retrieve the bibliography list, but the URLs they refer to are gone, too. I've tried to pull them one at a time out of the Wayback and then tried using Google to see if the site's simply been relocated but I can't seem to find a new version of the site. :-(

-- Bobby G.

The only error checking is the Manchester encoding wherein each 1 bit is 10 on the powerline and each 0 bit is 01 on the powerline. If you analyze it, after the start code (1110) there's no way you can have a "legal" run of more than 11 or 00 within the code. That's fairly robust. The probability that a ~120kHz "noise" source will create such a pattern out of whole cloth is nil.

I don't think there is a requirement that a 3 cycle silence precede a start code. The second copy of the code follows without such a gap.

The likelihood of RF collisions that create valid codes is very, very, very low. The RF codes also incorporate error checking. If two motion sensors see the same motion, the transceiver will likely see a corrupted RF code and will ignore it. The transceiver receives the RF, decodes it and then (if it's OK) sends it to the powerline. There is no one-to-one correspondence between the RF code bits and the PLC bits. Some transceivers will relay certain commands that others do not - All Units On, All Lights On, All Lights Off are not universal.

However, if you have multiple transceivers and multiple motion detectors you might see some really complex behavior where one transceiver "hears" from one motion sensor and another transceiver "hears" from another a few ms later. That could cause PLC collisions. It all depends on the strength of the RF signals (as seen at the transceivers) and the timing between when the motion is detected by the sensors. The AGC/ATC in the RF receiver circuits will pick out a stronger signal that overlays a weaker signal. The RF code is about 105ms long. Once a valid code is being sent to the powerline, a transceiver is deaf to RF until the PLC cycle completes but a stronger RF code can override a weaker one if it starts before the first RF code competes.

It's a shame that the Power L>I had to go through a bit of a search to get them, too. I lost the little

Should have been "completes".

I agree that it's unlikely a valid code would come from random noise burst. I suspect that in cases where oddball codes appear to come from nowhere people are actually seeing interactions between various modules. I have a couple of power strips that make the ESM1 meter light up ever so faintly when I plug them into or unplug them from a nearby power outlet. It's one of the things I hope LynxTools will help me analyze. I also note that the LM14A module makes the ESM1 show a strong signal when I first plug it into the wall.

This makes me wonder if the weirdness people see isn't related to small powerline interruptions that often occur late at night when the power companies do maintenance. If units that transmit upon activation all fire together there could be an awful lot of powerline traffic generated from a very short interruption. I'm assuming I can simulate this with a quick flick of the main breaker switch. In any event, I'm trying to figure out an "experiment design" that can replicate the oddball behavior consistently.

As you said in an early message, though, it may be very difficult to determine which unit in a collison sent which bit other than by amplitude, which is unreliable. From what I saw at your site, a collision between a CM11A and a TM751 might be distinguishable because the bit "signature" of each unit is different. The CM11A shows a distinct "fall off" - I'm not sure the Lynx can detect that although I suspect an oscilloscope should. I'm hoping that the Lynx will read out signal strength precisely enough to "get a fix" on the source at the bit level. The more I read, the more I wish I had purchased the scope and interface you recommended. If the Lynx doesn't lead to answers, I may well yet purchase the scope.

Yes, sorry. I see that now. I was confused by the line from the X-10 site says: "This complete block, (Start Code, House Code, Key Code) should always be transmitted in groups of 2 with 3 power line cycles between each group of

2 codes." I confess that I didn't clearly understand the implication of the Manchester coding until you explained it in this very message, at least in terms of how unique it would make the '1110' pattern of the start code. Thanks for revealing that particular mystery! I'm still a little hazy about the "Bad Start Codes" that the Monterey analyzer reports. Does that mean they detected a valid '1110' sequence but that the data that follows is NOT legitimate X-10 data?

I really think the behavior above describes the process that creates the unusual junk people see in their Activehome logs. I'm pretty sure I can recreate the situation by going into my box of Hawkeyes and putting some old RR501's, the Decora HCPRF, my CM11A and a few TW523's on-line responding to a dozen or PIRs.

I remember the day I was determined to put all the gear I had inherited to use. I put a number of lights on modules geared to respond to Hawkeyes so that anyone walking around at night wouldn't have to fumble for lightswitches. Things worked fairly well if only one person was moving about. As soon as two people were triggering different PIR's at the same time, the fun began. A person walking from the kitchen toward the LR and a person walking from the bedroom area to the LR at the same time could and would turn the porch lights on. Those lights were on an entirely different housecode than the rest of the house.

I've found a number of the originals, but it's very slowly going. It's too bad. The bibliography I got from Wayback looked very interesting.

-- Bobby G.

Wayback

The LM14A transmits its ID (as an extended code which is longer than standard codes) when it powers up. The LM14A only sends this if it has been without power for some length of time so brief power glitches will not trigger it.

However, the recent thread from 'AZ Woody' about phantom codes being logged when he ran his paper shredder, is probably a precursor of more such reports. The shredder motor was causing his two-way switchlinc to 'think' its load had cycled and it was sending the codes. This may also explain the reports of phantom codes from a noisy PC power suppy. (However, the details of that one changed considerably over time so I think that poster was just confused.)

The Monterey just applies the label "Bad Start Code" to any sequence of 1110 that is not followed by a valid code. As a result, you'll see messages posted here from Monterey users saying things like "tons of BSCs" from a collision like the one I describe in the "Multiple Transceivers" app note. I've color coded the sequence seen at the receiver to highlight all the 1110 sequences that result from a collision between codes that are identical but

1/2 a powerline cycle out of sync.

The terms "valid 1110" and "Bad Start Code" are really a bit meaningless. From the receiver point of view, whether a 1110 sequence is a start code depends on whether it starts something (i.e. whether a valid code follows) and not all 1110 sequences are start codes (good, bad or ethically neutral).

Multiple transceivers with multiple motion sensors will likely lead to cacophony. I still think the approach I took with the BX24-AHT was the best solution. One central RF receiver with a good antenna gives adequate range. With a CM11A as its X10 interface, it avoided collisions because the CM11A stops sending PLC whenever it sees a 1 when it sent a 0. It did not retransmit (probability is very high that any collisions are with a second transceiver) so it can coexist with one other transceiver. Initially, I planned to support two CM11As (one on each phase) but it's software UART wasn't capable of that. I still hope to design a brain transplant for the CM15A that will incorporate most of the BX24-AHT features but my health now makes it tougher to handle lengthy projects like this. The Powerline Communications papers were mostly pitched towards BPL but several did give excellent descriptions of the types of noise encountered. It was also a little more European oriented and their electrical grid is quite different with 100s of residences sharing a stepdown transformer. You can find some of the same data from companies like Intellon who are building the BPL chipsets. There are also several academic theses that cover the same ground.

I don't recall whether the LynX-10 PLC can measure signal strength. Even if it does, it may give an average or peak reading so it may not be useful for seeing the CM11A signal degradation. A scope is the easiest way to detect that.

I plan to have a raw diagnostic mode >Dave Houst>

Another point that should be made is that powerline collisions sometimes result in valid codes that differ from either of the originals but can affect other devices in the X-10 address space. In these cases there will be valid signals of unknown origin in the logs. The original Ocelot firmware would detect collisions but did not report them. I convinced ADI that, they needed to report any that resulted in valid X-10 commands. I shudder to think of the phantom event reports we'd be seeing if they had stayed with the original firmware. ;)

It's also possible for power spikes and brownouts to directly affect X-10 modules and switches. In these case there will be no codes in the logs.

Finally, with SmartHome selling the two-way *Linc devices that send their own Address and On/Off codes when the load is cycled, there will be codes logged. As we've seen, these can apparently be fooled by things like motor noise.

SmartHome also uses the old style preset dim codes which can mysteriously affect modules in other housecodes.

I spent a while fretting about how I would load the Lynx program CD onto the old Compaq Armada I had earmarked for it (no CD drive!). Then I looked at the files on the clearly limited-edition paper-labeled CDR disk and saw they were from 1998 and 2002 and would all easily fit on a floppy. It installed nicely, although it took me a while to realize it was "locked" and I had to enter my CD-Key to activate it.

At first I was both overwhelmed by the complexity of the screens and underwhelmed by things like simple signal strength measurement. It can draw all sorts of fancy phase angle graphs and pseudo-oscilloscope output, but I didn't see anything that would really help me get to the bottom of the Phantom Menace that's been haunting my X-10 setup.

Then, just to see how it would react, I decided to press two keychain remotes simultaneously, one set to housecode "B" and the other set to "D." Lo and behold! Now I had a grid the showed the breakout of what the Lynx receiver saw on the powerline, bit by bit, and it showed, embedded in the middle of lots of what it labels "code fragments" was a DIM command for Housecode M, Unit 16. Bingo! There's no M housecode in use in my system anywhere. I'll run a few more tests and even set up a few lamp modules on the M housecode to see if I can't get it to activate by pressing transmitters on D and A codes.

From what I see, in the display that looks a little like what Disk Defragmenter shows, there's one line with the actual powerline bits, another line that shows them mapping into X-10 binary codes and another line that shows the actual X-10 commands. I was hoping that I could read the power level of each bit but I haven't found that function, if it indeed exists. It does seem able to tell me the location of each bit along the AC cycle, which I assume is really just the number of milliseconds past the zero crossing point That could end up being as valuable in figuring out the mechanics of such collisions. Did you take notes at the EHXpo? :-)

I thought that loading the SW on a laptop would make it a useful tool, too but it's too clunky for fieldwork. Actually, when buyer's remorse was at a peak this morning, I came across the Smarthome Monterey clone that's on sale here (no affiliation) for $89

and thought that was what I really needed. I can't see much difference from the Monterey when I compare the specs - except maybe the Testerlinc is 200 bucks cheaper! Well, one thing that's odd is they use a "quality count" rather than display signal voltage. But again, the Testerlinc does not log to a PC.

across a room and see if a signal is getting through. I like the

I'll bet the Testerlinc suffers from similar issues. One thing that freaked me (and Dave, if you are reading, please correct me if I am wrong) is that I think Dave said they used the Monterey to *calibrate* the ESM1. How bad could the Monterey be if they use it to calibrate other meters!!!? :-) FWIW, as soon as I opened the Lynx box, a little voice said "you should have bought the Monterey or the Testerlinc!"

I'd like to figure out how to "broadcast" the output of the ESM1. I'd like to be able to bring it up as a system tray icon so that every time an X-10 command was sent, I could see its strength. Maybe I'll just set up an old CCTV camera and broadcast it via cable TV modulator. Now showing on channel

111! X-10 Signal Strength!

Don't make me spend any more money!!!!!! I've already decided I have to get that little USB scope that Dave mentioned earlier. I just haven't found the cheapest price for it yet.

lists only one dealer which means they can command list price. Still, it's an OK deal for $220 since it includes the software.

What does it do that the Monterey doesn't?

Maybe providence and the spirit that protects wallets and bank accounts has made the ACT 004 impossible to find on Google. No, wait, oh, darn, here it is:

For $250, it might be worth it if I did installs and needed to leave something overnight to log data. But it's got the same damn Achilles' Heel that the Testerlinc and the Monterey have - no way to log to a PC. It's got lots more neat buttons and features, though. Next time I save myself a lot of money buying Minicontrollers for $2 each I'll be able to justify buying the ACT. There's something perverse about spending all the money I save buying cheap X-10 gear on expensive X-10 test equipment.

-- Bobby G.

I'm beginning to notice that!

I'll probably end up with the Testerlinc, too, because it's a lot easier to justify than the Monterey and seems to be remarkably similar as well. The Lynx is not practical for moving around much. In fact, my plans to run it on an old laptop were not well-reasoned. The software looks as if it would run best on a very large display. Also, when I went to check it just now, it was flashing the screen on and off, with a WIN32 message about a parameter problem. Not a good sign. I'm going to try it on another machine.

That's something I've needed on several occasions I can fake it with a neat pair of spring clips that can keep a transmit button on a minicontroller mashed down and a surge protector that's known to attenuate the signal by

1volt. But the ACT looks far classier.

It shouldn't really be part of mine, but I'd like to be able to port the information I discover to a format that's postable on the web. I'm not sure what I am doing will come to anything, but I can't help wondering if some housecodes are more prone to colliding than others. There have been so many strange reports here over the years it's almost like CHA's own version of UFO sightings. Having the ability to transfer readings to messages will make it easier to get feedback from the CHA brain trust. I lost a lot of banked SAF with the "Hawkeyes in every room" experiment. It was pretty nightmarish having the wrong lights turn on while the right lights wouldn't.

Thanks for the citations. Well, there's a website selling Leviton DHC rocker switches 5 for $100. That's a savings of $250!! Just enough to buy the meter!!!

The ACT004's a nice unit, but the Testerlinc might satisfy my tester needs better if used along with the Lynx unit (if I ever get it working correctly - time to RTFM).

Thanks for your input, Bruce

-- Bobby G.

-- Bobby G.

You are correct, again. My testing procedure was faulty. I plugged in the ESM1 and then the LM14A and saw the transmission. Then I tried again and did NOT see it so I took another LM14A out of the box and tried that, and it, of course worked. Then I fiddled around for a few minutes and by the time I got back to the first one, enough time had passed for it to transmit again. Proof positive that it takes more than one or two observations to form a valid conclusion!

I may just have to fish through Google to see what phantom codes these people were reporting. I'm wondering whether certain housecodes are more prone to collision issues than others both as sources and unintended output.

From what little I can tell of my first series of Lynx tests using two key chain transmitters and two TM-751's on housecodes B and D transmitting simultaneously, B and D seem to readily create M house code fragments and even entire commands. I should be able to do exactly what you've done with your illustration. Display Code 1 on line one, Code 2 on line two and the result of the combination on the third line. Lynx takes the complimentary approach to Monterey's Bad Start Code. They consider any pattern of "1110" as a Start Code and if what follows is nonsense or corrupted, they call it a "command fragment" and try to decipher what those fragments are.

I suppose they had to do it that way for brevity's sake. This sort of data looks a lot more comprehensible in full screen format. Does it make sense to say that their Bad Start Code could really be renamed Good Start Code followed by Code Fragments?

Right again. I hope to have some time this weekend to see if there's any order in the chaos. Based on X-10's fondness for giving away buckets of Hawkeyes and TM-751s for next to nothing, I'll bet a lot of people have multiple PIRs and multiple TM-751s. The secret may be the multiple housecodes. If I remember I'll try tuning them all to the same housecode to see if it's as easy to create a third code from TM-751s all set the same way.

Yes, I agree. It's too bad I caught you too late in the cycle to acquire one.

I'm sorry to hear that. I hope your health improves.

It can measure the time past the zero crossing but not, apparently, signal strength. At least not as far as I can see but I've hardly looked at the manual yet. With all the things on my to-do list this weekend, it may take a while before I really get the hang of the Lynx analysis software.

Half-bits. Sounds like some people I know. :-)

-- Bobby G.