Re: CM11A lockup (broadcast storm)

["Robert Green" <ROBERT_GREEN1963@xxxxxxxxx>]

"Jeff Volp" <JeffVolp@xxxxxxx> wrote in message news:jNKyi.47639

<stuff snipped>

> I run into the storm limit often during testing, so I may double the
numbers
> to 30 & 60 per minute average.

That seems high.  In what sorts of simulations?

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

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

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.

> >> The LED flashes continuously in response to a storm.  I had planned to
> > > issue a STATUS OFF out the digital port when a storm occurred, but it
> > > may be more useful to return the actual traffic on the powerline.
> > > Thoughts?
> >
> > Whatever it takes to immediately ring a bell or sound a buzzer without
the
> > X-10 storm blocking the alerting signal!  If you're thinking Ocelot,
then
> > whatever would end up reacting to the simplest of CMAX programs.  Sounds
> > like the Status Off flag would be simpler than parsing the actual
traffic.
>
> Guess it depends on whether you want to sound an alarm when it happens, or
> to have some helpful info available to find what is going on.  I don't
think
> most people have a Monterey available for troubleshooting, so the digital
> data would be helpful.

I wouldn't need the Monterey, in all probability, if an alarm sounded in
very close temporal proximity to the "stupid act" that caused the storms.
Even the old BSR that went gaga began its descent into madness as a result
of a button press.  The bell or contact closure provides immediate feedback
that the lights are hosed.  That has very high SAF as opposed to finding out
the lights won't turn out as you're on your way out the door for some
emergency.  Also, this way, from far away I can respond to "the X-10 alarm
is sounding, Bobby - what do I do?" phone call with some hope of resolving
it remotely.

Broadcast storms are insidious because they don't turn all the lights on or
off at the time they occur.  Big lighting changes are something you'd notice
immediately.  Instead, storms freeze the current state of the lighting so it
can be a long time before they get noticed.  Knowing what control was
operated at the time the the storm began is probably the most useful clue I
can think of when it comes to locating stuck transmitters, brain-damaged
CM11A's and other storm-makers.  That information alone would have solved
perhaps 80% of the past incidents within minutes, if not seconds.

Capturing the actual line traffic would be very useful as well, but, as you
note, probably less important to PLA owners than others.  I should have
taken better notes during each failure because I recall a lot of false
starts.  Worse, still, I disconnected things that were working perfectly in
some cases, and failed to reconnect them because I was under pressure to
solve the problem quickly.

Line traffic capture pinpointed the CM11A failure because not many
controllers fail in an iteration mode, spitting out A commands, then B
commands, etc. in sequence.  The Palmpads also send out pair commands, so
they have a different signature than a stuck MaxiController.

Jeff, as a circuit designer whose very conversant in X-10 technology, how
much of the circuitry to detect a broadcast storm exists on something like a
standard X-10 lamp module?  Would someone be able to remove the board and
remount it so they could add additional circuitry to close a contact when
more than X minutes worth of signal is detected?

--
Bobby G.