CM11A lockup

Back when I was beta testing the CM11A, whenever anything bizarre went on in X10 land, a quick power cycle on the CM11A was always the fix.

This was very good info. Just checking for a repeated command (stuck button) would not catch something like this. Also, there was no fixed housecode to help identify the offending device.

FYI, when testing the XTB, I plug my ESM1 into a X10 filter (XPPF) to get usable readings.

Jeff

Now that I've got the XTBs, I've thought about putting the CM11As back on line. They used to be far too weak to reach every branch, but that's no longer a problem. Their tendency to go wild might be the limiting factor now. Still, having a small unit that can do macros is awfully tempting, especially now that I've got an X-10 AV matrix switcher that requires multiple keypresses on a Palmpad to operate. The CM11A could reduce that to a single button push.

I discussed that a while back and I thought someone had said it could skew the readings as well as interact with signal suckers in an unpredictable way. Besides, one of the greatest features of the Monterey is that it's smaller than a cigarette pack and has just an AC line cord. There's no wall wart that may or may not fit into the test outlet easily. I'd hate to have to graft one onto it at this late stage.

Using the XPPF is great for bench testing but I'd hate to have to deal with it crawling around things looking for outlets to plug into. As it is, the ESM1 is looking rather like a bolo with the extension cord, wall wart and meter head. (-: If I ever get a second ESM1 I'll calibrate it to read the XTB's. What I'd rather have is a slide switch on the Monterey that attenuated the readings, just the way some multimeters have range scales.

-- Bobby G.

The XTB-IIR will shut off its transmitter in response to a 'broadcast storm". Two thresholds are available. One allows a burst of about 80 commands in a minute, or a continuous average of 15 per minute. A higher threshold allows a burst of about 160, or an average of 30 per minute. In either case the XTB-IIR transmitter will re-enable itself after 10 seconds of clear line.

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?

Jeff

Nearly missed this in the "broadcast storm" of MI5 bushwa!

Your parameters sound quite reasonable. What does the process for updating the firmware entail? (I'm assuming that my unit's firmware *can* be updated!)

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.

-- Bobby G.

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

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.

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.

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.

Jeff

(earlier stuff snipped)

That seems high. In what sorts of simulations?

Can you run them side by side or are there interference issues?

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.

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.

See responses below:

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

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.

Considering that the XTB-II price was not increased from when it was just a

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

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

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.

Sounds like it's an either/or proposition. Too bad.

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

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

brain-damaged

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.

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.

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.

A house should only need one XTB-II or XTB-IIR.

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.

Yeah, not looking forward to rolling these features over into that other PIC.

I thought about both myself, but that just caused too many side effects that had to be worked through.

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.

(snipped earlier discussion about modifying a module to be a storm detector)

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.

Jeff

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?

Originally

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

maxicontroller.

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.

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.

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.

Sure. The XTB-II works just fine as a high power TW523 when connected to a single leg. Actually, it does a bit better because it recognizes sequential and extended commands, which the TW523 cannot.

Lets just say I'm going to take a little vacation from coding after I finally finish the XTB-IIR.

(deleted earlier discussion on how the XTB-IIR will shut down its transmitter in response to a command storm)

You know how hot the CM11A gets when it is stuck in a continuous transmission mode. The XTB-II transmits with at least 25 times as much energy. So disabling the transmitter during a storm will prevent stressing and possibly damaging the output driver stage. That's why I'll eventually roll that feature over into the XTB-II PIC.

I agree with you that more info would be useful. It would also be nice to provide DIP switches for the mode programming rather than the 9-8-2-X sequence. I had considered a bi-color LED, but sharing the PCB limited what I could do. The PIC being used in the XTB-IIR is already fully utilized. A larger PIC would have forced tradeoffs I didn't want to make.

FYI, I had thought about a XTB-III (3-phase version for Europe), but I think this is the end of the line. I would consider adding some intelligence to the plug-in version with surface mount components on both sides. But that will only happen if someone steps up to the plate to offer it as a production unit.

(deleted earlier discussion on modifying a lamp module as a storm monitor)

Yes, the chime IC would have to be replaced with some sort of microcontroller. That can be done with a tiny daughter board that would have pins to solder into the same footprint. Snip out the IC, unsolder the pins, and install the daughter board.

However, I think the market for something like that would be too tiny to pursue.

Sounds like you have the solution in hand.

Jeff

That's good to know.

A well deserved one, I'd say.

True serendipity-doo! If I want to expand the broadcast storm detector's intelligence, I'll tape a thermistor to the back of the CM11A so I'll know where to look first in the event of a broadcast storm.

I generally hate having to program X-10 modules that don't have codewheels or slide switches. It's not as much a problem with the XTB since I don't expect to have to replace it as often as I do X-10 modules.

Boosting the X-10 signal is the main course, the rest is just gravy.

Good luck with finding a sponsor. Someone out there in the X-10 world must realize the benefits of boosting the X-10 signal for their products.

In mind, certainly, but not in hand, but I'll move that to a separate thread . . .

-- Bobby G.