Re: CM11A lockup (broadcast storm)

["Robert Green" <ROBERT_GREEN1963@xxxxxxxxx>]

"Jeff Volp" <JeffVolp@xxxxxxx> wrote in message news:A1Ezi.51864

> > <(more) stuff snipped>
> >
> >>>> This feature will be in the XTB-IIR.  I can probably add it to the
> >>>> XTB-II firmware when I get the time.  A firmware update will require
> >>>> changing the plug-in PIC.
> >> >
> >> > Can you run them side by side or are there interference issues?
> >>
> >> There are timing differences regarding internally generated messages
that
> >> will cause collisions.  However, I have two in service here, and the
main
> >> issue I see is the two powerful 120KHz outputs beating together.  It is
> >> theoritically possible that there will be points where the signals will
> >> actually cancel one another when the beat frequency is low enough.
> >
> > Sounds like it's an either/or proposition.  Too bad.
>
> A house should only need one XTB-II or XTB-IIR.

However, if you've purchased an XTB-II you could find yourself needing both
if you really needed good repeater capability.  Can the XTB-II be wired to a
single leg of the panel and act as a smart interface to something like the
HAC 8x8 video matrix switcher that I currently have plugged into a TW-523
and an XTB-I?

> >>>> The XTB-II was really designed as a 2-phase high-power line interface
> >>>> for high end controllers.  The repeater capability was added as a
zero
> >>>> cost afterthought.  The XTB-IIR is intended primarially as a high-
> >>>> power repeater, but it can also boost X10 signals and provide the
line
> >>>> interface for a high-end controller.
> >
> > It sounded like the "R" was based on a different PCB but a quick check
of
> > your site (whose URL should probably be in your sig!)
> >
> > http://jeffvolp.home.att.net/x10xmtbuf/XTB-IIR_development.htm
> >
> > says it's a more powerful PIC.  It also sounds as if you've changed
other
> > components in the IIR.  Am I reading that right?
>
> The PCB is shared.  Too keep the cost down, I added the -IIR components
when
> I ordered more XTB-II boards after the initial batch.  In addition to the
> larger PIC, there is a gain switch in the return signal path (again
focusing
> on the repeater capability) as well as several smaller changes.
Originally
> I had planned on the XTB-II being the end of the line.  After adding the
> basic repeater capability to the XTB-II, I wondered how far I could push
> that capability - hence the XTB-IIR.
>
> >>> Thanks.  In two years I'll try to remember to ask what the "zero"
ended
> >>> up equaling.  (-:  There is, IMHO, no such thing as "zero cost"
> >>> anymore.  YMMV.
> >>
> >> Considering that the XTB-II price was not increased from when it was
> >> just a 2-phase version of the XTB, I would say the mode options and
> >> repeater capability were included at zero cost.
> >
> > Sorry I was unclear.  With two products doing much the same thing
there's
> > a tendency for dolts like me to get confused as to which does what.
Having
> > to explain that is a cost.  Having to support it if and when you do get
> > around to developing the firmware is a cost.  In this case, you're
absorbing the
> > cost and we thank you muchly for it!  (-:
>
> Yeah, not looking forward to rolling these features over into that other
> PIC.

Well, *I* am!  But I'm not the one doing the coding! (-:

> >> That is true if a button sticks or someone stacks something on top of a
> >> remote.  However, this thread was started by a CM11A losing its mind.
> >> There was also a recent thread about water dripping on a
maxicontroller.
> >> Those may happen out of the blue, and more than BEEP may be helpful.
> >
> > I agree.  That's why I think both would be useful, although the beep
would
> > personally be the more useful element for me, at least based on the most
> > recent broadcast storms I've experienced.  It probably wouldn't have
been
> > warmly received in the case of the CM11A that apparently began sending
its
> > storm a few hours after being disconnected from its serial cable.
>
> I thought about both myself, but that just caused too many side effects
that
> had to be worked through.

I think it's a nice feature for the XTB-IIR to have, but I'd also like to
have a unit dedicated to nothing but scanning for storms.

> >> I was in the process of testing the "Status OFF" when I decided the
lack
> >> of any additional information was a shortcoming.  The code is complex
> >> enough without having to jam a "Status OFF" into the middle of a
> >> continuous traffic string, so I just let it return traffic that it sees
> >> (with the
> >> transmitter disabled).
> >
> > So it's up to the controller to decide what to do based on the traffic
it
> > sees?  It seems that you then have two control points - one in your
> > firmware
> > and one in the CMax (or whatever) code that's interpreting the data
you're
> > sending to the interface.
>
> Actually, it doesn't matter what the controller does as its output will be
> inhibited (if it interfaces through the XTB-IIR).  I remember an early
post
> saying you couldn't find the cause of the problem because the XTB
> transmitted with so much power.  The XTB-IIR will just sit there flashing
> its LED, and returning line traffic back the digital port.  It will not
> transmit anything until the line has cleared for 10 seconds.  It should be
> easy then to go around with a signal monitor to find out where the source
of
> the problem is.

That was a concern of mine originally.  If the XTB stops repeating the storm
it might be possible for the user to believe the problem was squared away
when in fact the XTB had only stopped repeating the storm.  Having the LED
flash when it's in this mode is a great idea as it gives immediate visual
feedback that something's wrong.  If there's ever an XTB-III I would suggest
adding more LED indicators like the ACT repeaters to indicate various error
states like broadcast storms.  That's a personal preference, though, and
reflects a visceral dislike of one button (or LED) serving multiple
functions.  I realize that every hole that has to be drilled in the case
adds quite significantly to the cost of the unit, so perhaps it's cost
prohibitive on home manufactured items.  Even so,  I'm a big fan of red LEDs
indicate a problem and green ones indicating normal operation.  Now that I
think about it, you wouldn't have to drill more holes if you used a
multi-colored LED that can flash either red or green depending upon
polarity.

> (snipped earlier discussion about modifying a module to be a storm
detector)
>
> >> Actually, a mod to something like the chime module should be pretty
easy.
> >> It would require a little daughter board to be installed in place of
the
> >> original IC.
> >
> > I suggested the lamp module simply because I have quite an inventory of
> > them (as opposed to chime modules) that I'd be willing to hack up in the
name
> > of  science.  I assume there's a pin that goes high when the unit
receives
> > X-10 signals and you'd simply have to monitor that pin's output with a
555-type
> > timing circuit that closed some contacts when the threshold had been
> > exceeded.  It could be designed to auto-reset if the storm passed or to
> > latch and require a manual button push to reset.  I noticed that some of
> > the newer gear from X-10 is powered by a wall-wart (the LCD-based
Mini-timer,
> > for one) so it seems that it would be possible to build a "storm
detector"
> > without having to worry about dealing with line voltage components and
> > unhappy inspectors.
>
> Not so simple.  The modules only monitor a single house/unit code.  The IC
> would have to be replaced with one that includes something like the
XTB-IIR
> line monitor, and its storm detector. There may have to be some power
supply
> components too.

I'm confused.  Doesn't the chime module suffer from the same limitations
(ability to monitor only one house code at a time)?  Perhaps the best device
to modify would be the ESM1, which already lights two diodes in response to
legit X-10 traffic as well as strong noise.  If the LED's stay lit longer
than 30 seconds, ring the bell.

I'll bet it's even possible to design a snap-in storage cradle for the ESM1
that has two photodiodes that line up with the built-in LEDs.  No electrical
interconnections would be required at all as the connections are already
optically isolated.  Even better, it would give me a place to store the ESM1
which I only need rarely now.  I could even set up the cradle with a cheap
CCTV board cam so that I can monitor and even record the ESM1's readings
remotely.  That sort of set up could be used as a collision detector as
well!  If the noise LED lights up too often it would indicate that
something's colliding or otherwise garbling commands.

I could even use the "round robin" technique I described a while back with
multiple transformers located around the house feeding into the single ESM1
through a stepper relay and probably locate the storm's cause from any video
monitor in the house.  Best of all, this is all within my limited skill set.
I've designed a number of successful timer circuits using 555 IC's so this
should be a piece of cake.

Off to the Batcave and the drawing board!

--
Bobby G.