XTB-II Enhanced Repeater

So far, I've just tried two transformers. One that puts out 11VAC at 1.2VA and another that puts out 13.5VAC at 12VA. The 11VAC unit causes all the bars on the ESM1 to light up but they never extinguish. Until I tried that I hadn't noticed that even the stock PS causes what appears to a be a boot-up sequence in which all the LEDs flash briefly.

The second transformer, a hefty beastie that once powered a heated massage cushion, produced results that were basically similar to the stock power supply. It's hard to make precise estimates because the bars tend to flicker a bit. The unloaded voltage for the stock PS is about 13.5VAC. I have a power supply that's marked 13.5VAC and actually reads about 16VAC, but I am reluctant to test it on something that provides a higher voltage than the stock transformer because it might cause the magic smoke to escape!

The next test will be to see if 100' of 16 gauge speaker wire will attenuate the signal, and if so, how much. If I can still get adequate signal with that much wire, I'm going to consider the multiple transformer phase of the testing complete, since you've established other transformers work as well. I'll then move on to selecting the components and creating the circuit design to read the ESM1 LEDs via phototransistors and sound an alarm if the meter head detects an X-10 type signal for more than 30 seconds. I don't care if it's noise or valid X-10 commands because anything that "blows a 10" on the ESM1 meter is capable of obliterating valid X-10 commands on the line.

I'd like to create a circuit that's able to differentiate between noise and valid X-10 signals, if only for troubleshooting the source of the broadcast storm. That should be pretty simple. All I need to do is to check whether the "X-10 Good" LED lights up along with the segments of the bar graph. I think it would be a good idea to monitor the very first segment of the LED bargraph, too, because lately I've been seeing the first segment light up and stay lit when the basement shoplites are running. I might decide to have the audio alert play a different tone if the background noise level goes beyond that first segment.

It looks as if the LEDs are close enough to the surface of the meter display window for me to be able to read them without spillover, but I won't know until I actually start trying to read the pulses whether that's going to be an issue. I think the best thing to use to butt up against the EMS1 display would be an 1/8" thick piece of black rubber with holes drilled in it to precisely line up with display LEDS. That should be easy to do. I'll take a piece of tracing paper and place it over the display head so I can mark the positions and then take that paper, tape it over the rubber strip that I'll tack to a piece of thin wood and then I'll drill holes through the paper, rubber and wood. The thin strip of wood will be thick enough to hold the phototransistors securely in place. I can bend the leads at a right angle and mount the circuit board horizontally in the plastic box that forms the mating part of the cradle.

FWIW, I tried to induce reading errors by moving the ESM1 head all around the wall wart. I had remarkably consistent readings. I did notice that the parallax error arising from the clear plastic lens and bargraph interface could easily lead someone to believe they were seeing one less bar when viewing the device from an angle. That parallax error means I may have to shroud the phototransistors carefully to insure they read just the LED they're aimed at. I hope it won't come to removing the clear plastic lens from the front of the meter to assure a tight optical coupling, but it could come to that.

Next thing to do is get some phototransistors and see what sort of output I can get from a flickering LED and then how to turn that output into a a multipoint audio alarm.

-- Bobby G.

Reply to
Robert Green
Loading thread data ...

That branch of the thread has been marked "Broadcast storm detector" for quite some time.

Congratulations!

Don't take this the wrong way but as an owner of the XTB-II that's not going to be upgradeable to the XTB-IIR the subject of the world's best repeater is primarily an academic one for me now. On the other hand, my interest in house-wide, real-time X-10 signal strength readings and broadcast storm detection are quite high on my list, hence my discussion of the details of that project in the "broadcast storm" thread.

-- Bobby G.

Reply to
Robert Green

While there are certainly some features that cannot be ported over to the

8-pin PIC, things like enhanced error detection, abort transmit on collision, and command storm shutdown can be. It may also be possible to add the smart bright/dim repeat for sequential commands. The real question is whether it is worth the effort if only a few people are interested in a firmware upgrade.

Jeff

Reply to
Jeff Volp

It depends on a lot of things. The most important, to me at least, is whether the upgrade is simple to perform and bulletproof. Even if you volunteered to do it for a fee, the XTB-II is a critical component to be missing from a house for very long. You've got a wide range of customers from those with no electronics experience to whose who could reprogram the PIC without blinking. That's a factor that will determine at least some of the upgrade decisions. Based on my experience with PC firmware, upgrading is often an iffy proposition.

Then there's the issue of whether they'll need those features. Polite mode (abort on collision) is nice, but it could be a liability as well as an asset. If it fixes the rare cases where two transmitters send an X-10 command simultaneously, it's an asset. If it however fixes a problem that shouldn't be happening in the first place, it may be a liability in terms of discovering and fixing the colliders, at least for me. I'd want to know if the repeater was being polite more than a few times a day.

(You've alerted me to the need to add such detection capabilities to the BSD cradle. I need to monitor the "X-10 Good" LED and the two or more segments of the ESM1's bargraph LED for collisions and send a message, light an LED or take some other action to alert me that more than a handful of collisions a day are occurring.)

If you're still looking for features to add to the XTB-IIR, a way to read the incoming signal strength and to alert the user to an unusual number of collisions would be nice to have for most people, although perhaps not for me. I am afraid that the BSD would probably conflict with the XTB-IIR because the IIR might detect and shut down the broadcast storm before the BSD ever had a chance to detect the storm and sound an alarm. It would depend on whose time limit was set shorter. I believe you've allowed for different broadcast storm lengths in your device, so if my timing and yours are both variable, that should be a problem that's easy to work around.

I also realized that detecting a broadcast storm has some interesting issues associated with it, namely making sure that a legitimately long string of X-10 commands doesn't get misinterpreted as a broadcast storm. In my case, I'll have to make assumptions based on the way the ESM1 parses the X-10 command. It's only after the bargraph LEDs go out that the "X-10 Good" detector lights. I'm working on setting up my Sanyo CCTV recorder to film the ESM1 display as it reacts to X-10 traffic. Since it allows for very high speed capture, with frame by frame viewing and millisecond time stamping, I should be able to make very good estimates of how long each LED stays lit and the exact on and off times. It's probably overkill, but I've found that examining reams and reams of raw data can often point out the nasty exception cases that often prove quite troublesome to resolve after the design is complete.

Sorry. I'm hijacking your thread again. (-: It's hard to avoid because discussing the XTB's functions naturally links up in my brain to the sketching out the full spectrum of the BSDs capabilities that I've been contemplating. I want to try to get it right in "wetware" before I go soldering any wires. (While writing this, I had the "ah ha" experience about how I need to set up the TV remotes which I'll describe in another thread.) Even this tiny project has given me a greater respect for all the time and effort that's gone into building the XTBs. There must have been an incredible number of decisions you had to make regarding component size, cost, operation, interactions, etc. The BSD universe is quite tiny by comparison and yet it is still perplexing. Every time I think I'll do X, either some design constraint or unexpected behavior means I have to do Y. Which leads us right back to your quandary: To upgrade or not upgrade the XTB-II?

Since most of the transmitters I use now for extemporaneous commands (ControlLinc Maxi's) have polite modes, it's probably not terribly important to have it in the XTB-II. But it would be nice to have for the few devices that still collide. If I need the IIR, I'll just remove the II and use it as a standalone device. It's not as if the newer IIR obsoletes the original unit into worthlessness. So far, the HAC-8X8 switcher works fine with the TW-523 plugged into the XTB-I outlet so perhaps when I finally get the CPU-XA doing something useful again I will use the II as its powerline interface.

Getting back to original question of who wants the upgrade, you're the only one that's got the XTB customer list, so if you're losing sleep over the upgrade you know who to ask! I realize that it's the kind of question that you might not want to ask because the (legitimate) fear is that everyone will answer "yes I want it" and then never follow through. So I'll quash those expectations here and now by just saying "no." (-:

If I need the better repeater, I'll buy it from you because I know you're not buying a fleet of huge flatscreen TV's based on the profits you've made on this venture. I shudder to think how small a TV fleet you could actually buy with XTB profits. When I look at the cost of switching to Insteon or Z-wave, which I was seriously considering before the XTB arrived, it's still quite a deal even if I have to buy another repeater. I just snagged a whole bunch of X-10 gear from Ebay NIB at 1/4 what I used to pay from Worthington so I'm not unhappy about passing that savings on to you by buying the IIR. If I didn't have the XTB's, I would be paying a lot more per controlled load than $5 and I would have perhaps 1/4 the overall capability and choice of components.

The XTB-II's had their purpose. It's reasonable to make people buy the IIR if they want a super-duper, "handles all cases" repeater. There will be at least a few grumblers out there that won't agree, but if I were you I would consider the cost of porting the IIR code to that of a quiet trade-up program for any extremely noisy and unhappy XTB-II owners. Not sure what you can do with the returned XTB-II's, but I am sure that over the years at least a few will be fried by direct lightning strikes, home fires, etc. I'll bet you could do the trade and sell the used ones cheap on Ebay and still sort of break even. It all depends on the value you place on your own time. You couldn't get me to do much of anything for $1 an hour.

So the bottom line is, no, I don't think it would be worth the effort to port the code. Even though I would like to have it, there are good business reasons not to, mainly because your time is probably better spent perfecting the XTB-IIR. If there were no other uses for the retired XTB-II, I would feel differently, but there are. Also, since you inspired me (and led me to a great vendor, Fruit Ridge Tools*, for the parts) to use a twist-lock

220VAC outlet to mount the XTB-II, there's very little switchover cost involved between the two devices. FWIW:
  • "Fruit Ridge Tools specializes in electrical surplus tools and supplies. Offering a wide variety of switches, dimmers, plugs, wallplates, etc" Also has a store on Ebay.

formatting link

(No commercial interest or kickbacks involved, just a fairly priced and very helpful merchant.)

-- Bobby G.

Reply to
Robert Green

Thank you for the detailed and thoughtful reply. Just a few things to add:

Updating the XTB-II firmware only requires turning off power, wiggling out the 8-pin PIC that is already in there, and plugging in a new device, making sure it is oriented the same way. I believe all early units were updated to

1.10. Two additional mods were made - one to prevent repeater ping-pong, and one to correct a bug in 3-phase transmission. The firmware has been stable at 1.12 since early this year.

I agree with you on the "polite" mode. It will probably be useful in installations with motion detectors and a TM751 transceiver. That unit is not polite, and will transmit whenever it receives a signal from a motion detector. That would cause a collision if the XTB-IIR is repeating at that time. If so enabled, the XTB-IIR would immediately terminate the transmission, and re-transmit the repeat after the line has cleared. A receiving module would not respond to the XTB-IIR command if it also saw the bits from the other transmitter. So, the delayed re-transmit gives a chance to get that module to respond properly. Since it is more likely that an installation will not need the polite mode, I have changed its default to OFF. Both the abort on collision and auto re-transmit can be enabled through mode options.

While it is easy to count error conditions, providing that information in a useful format is not. A whole housecode could be dedicated to diagnostics, and a two digit code issued in response to a request. But, would anyone would really use that kind of information? It gets back to the question is it worth the development time.

Another issue you had brought up was relative signal strength. I had actually looked at that myself. It might be possible to make signal strength measurements. However, the issue is again how to make this information available, and whether it would really be useful.

Well, back to the soldering iron...

Jeff

Reply to
Jeff Volp

You're more than welcome!

Sounds easy enough to upgrade the firmware. I had that process confused with the method you use to configure the device settings.

I've fooled around with both TM751 and RR501 mixes to try to avoid motion detector-induced collisions. As you may recall, some of the lights in my house are cascaded. In other words, I have a primary module and a "walking" light attached to that which lights up the room enough to walk through, but not much more. A second button press activates a module plugged into the first with the same unit and house code. The bulk of the room lamps are plugged into that second module, and in some cases, I've even added a third module to respond to a third press. While the system began as a way to prevent lamps that were out from lighting during power blips and thunderstorms, it's evolved into a primitive but highly effective "dimmer" switch to control the amount of illumination in the room without having to press other buttons or fiddle with DIM controls (low SAF!).

While most X-10 installations usually do nothing when a second ON command is received, mine responds by increasing the number of lights that come on with each push. The TV's are arranged in the same way. One button press turns on the room lights, the second turns on the TV in that room, tuned to whatever the master unit is playing. When I tried to use a mix of transceivers, polite and impolite, I would always seem to end up with an extra ON code. As a result, there's only one light left in the house on motion sensing and it works quite nicely now that it runs alone! (-: It controls the bathroom lights, which are not cascaded and don't care about receiving multiple ON commands in a row.

BTW, in case anyone's interested, I gave up on my stairway "fail safe" rig for several reasons. Number one: it would never pass inspection. The second problem was that constant switching really shortens CFL lamp life, so I would have to use an incandescent. After figuring out how much time it would take to build and test the multiple interlock system I talked about in another thread, coupled with the shortened bulb life from constant activations or the use of a higher wattage incandescent bulb, I realized I could keep a 13W CFL bulb on permanently for about two years and it would still end up being cheaper than a fancy, foolproof (hopefully) motion detector setup. I figure that mounting an emergency light with a gel cell battery that came on when the power failed would be enough protection on the stairway. It doesn't make sense to do more than that since we'll be moving soon.

That sounds like a good idea.

diagnostics,

I don't think it's really part of the repeater package, but it's something that I think would be worthwhile for me to pursue in the BSD. Since the heavy lifting has already been done in the ESM1, all I have to do is figure out the interface details and how to output information to a logfile - something I've done before with a parallel port interface and Basic.

Anyone who's got an XTB probably has some way of measuring X-10 signals already. Once again, it's something more suited to a measuring device like the BSD than a "working" device like the XTB. Still, from your descriptions you're doing a lot a analysis of the X-10 signal and it seems a shame it can't be exported to a log file. I'm sorry that all my suggestions have to do with analysis functions. It's what I've been thinking about lately.

Do you have a set of X-10 floodlights? They didn't seem to get along too well with the Leviton repeater I bought a while back, although I was never quite sure whether they were truly the cause of the bulk of the lockups. I think it would be important to ensure that your repeater handled the floodlights without any issues. If you don't have any, I have a couple of new units you can borrow to test. I decided to go with an el cheapo stand-alone motion sensor floodlight unit that was completely X-10 independent. Far too many times I'd come home and the X-10 floodlights would be on during the middle of the day. Putting a screw-in photocell switched stopped that behavior but caused the bulbs to extend far enough from the socket to cause SAF stinkeye. (-:

When does the "big heat" end out there? I heard that there were severe power failures when the heat topped out at 120 degrees. That's halfway to boiling water. Ouch!

-- Bobby G.

Reply to
Robert Green

(much snipped)

Yes, we do have X10 floodlghts. The exterior lights can be controlled from Leviton 16400 kepads at several locations in the house. There has never been any problem with the XTB-II or XTB-IIR repeaters even if multiple repeat is enabled.

The only problem we have with the X10 floodlights is that they often come on in response to lightning flashes.

It is supposed to be topping 100 most of this week, but it is starting to cool down.

Jeff

Reply to
Jeff Volp

Those floodlights have had a troubling history and I'm inclined to believe it relates to how the units are configured. I went to check on them at the X-10 site because it's too hot to hit the attic and found they were using this slogan to promote the floodlights:

We've had a nasty hot summer here, too. I can't wait for the Fall to arrive although I can recall some pretty nasty heat waves in Sept and Oct. I just bought some temperature and humidity monitors with alarm settings that I am hoping to be able to hack so that I can run the whole house fan based on whether the outside air it's drawing in is cooler and drier than the inside air that's being expelled. Humidity is a big factor in the DC area and if I based the fan's run time on temperature alone, it would result in some sticky situations as it replaced dry, warmer house air with slightly cooler but much more humid outside air.

-- Bobby G.

Reply to
Robert Green

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.