Re: CM11A lockup (broadcast storm)

["Robert Green" <ROBERT_GREEN1963@xxxxxxxxx>]

"Jeff Volp" <JeffVolp@xxxxxxx> wrote in message news:9Wkzi.455352

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

I see.  That's test data not representative of typical real world use.  I
would think any X-10 home that actually depended on 30+ commands per minute
would have reliability issues just based on the possibility of collisions.

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

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

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

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

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

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.

--
Bobby G.