Re: XTB-II Enhanced Repeater

["Robert Green" <ROBERT_GREEN1963@xxxxxxxxx>]

"Jeff Volp" <JeffVolp@xxxxxxx> wrote in message
news:PaUEi.515260$p47.398770@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Thank you for the detailed and thoughtful reply.  Just a few things to
add:

You're more than welcome!

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

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

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

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.

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

That sounds like a good idea.

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

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.

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

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.  (-:

> Well, back to the soldering iron...

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.