Re: CM11A lockup (broadcast storm)

["Jeff Volp" <JeffVolp@xxxxxxx>]

See responses below:

"Robert Green" <ROBERT_GREEN1963@xxxxxxxxx> wrote in message
news:7IOdnS5sbN5WMlDbnZ2dnUVZ_gadnZ2d@xxxxxxxxxx
> "Jeff Volp" <JeffVolp@xxxxxxx> wrote in message news:jNKyi.47639
>
> <(more) 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?

Sending a bunch of transmissions looking for every repeat to be handled
correctly.

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

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

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.

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

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

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

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.

Jeff