X10 Community Forum
🔌General Home Automation => Other Automation Systems => Powerline Control Reliability => Topic started by: JeffVolp on February 05, 2011, 03:13:07 PM
-
I have a question for those of you who use the CM11A as a powerline interface for PC-based automation software.
I have been developing a RS232 serial port XTB powerline interface. It is strictly a powerline interface, and does not repeat powerline commands. To make this compatible with existing systems, it would emulate the “real-time” CM11A protocol. It would not support any CM11A programmed functions, such as timers or macros. It would strictly work as a powerline interface.
The CM11A serial port includes a Ring Indicator output to wake up a PC as it begins to receive a command. My question is whether this signal is really needed for PC-based automation software.
The reason I ask is that I am at a quandary. It just won't fit. Adding the isolated serial port I/O takes too much PCB space, so I am looking for anything to reduce the size. Eliminating the ring indicator allows using a smaller PIC, and also eliminates an opto-isolator and related passive components. This may be just enough to let me squeeze everything onto the board.
If the ring indicator is needed, pretty much the only option is to go surface mount with components on both sides. That takes this into a different assembly class, and eliminates any possibility of a kit version.
Jeff
-
IIRC HeyU doesn't care about RI.
The half dozen times I've written something to control my CM11A, I've never cared about it either.
Personally I find the modem control lines (RTS, CTS etc) all more of a pain than value.
TX, RX and GND would be about the only ones I care about. :)
And - from what I've seen on the few USB/232 adapters out there, ignoring those non essential pins probably helps us out.
:)
-
I believe Active Home used the RI. Since yours is going to be a interface only. I doubt anyone would be using AH on it.
-
Thank you for the info.
Jeff
-
I managed to squeeze everything onto the board (no surface mount). Prototype boards are on order.
Jeff
-
I don't know about continuing this project. As most of you know, the CM11A had been discontinued several years ago, and the remaining supply of new units has pretty much dried up. Like with the XTBM, I started working this project to fill the gap.
Just yesterday I found out that a new batch of over 1000 CM11A's were manufactured several months ago, and they are available through a major eBay distributor.
Jeff
-
Wow. X10 actually did a production run of CM11A's. For an EBay dealer.
Does sound like you may want to put the project on the shelf for now.
-
Who's the EBay dealer for those who want a CM11A not for this project?
-
Google found a few EBay vendors with the CM11A search line.
One said more than ten available. :'
-
One said more than ten available. :'
How about 25 cases of 48?
Jeff
-
Oh I missed the one selling cases of 48. :o
Did a search directly on EBay and did find the vendor selling the cases of 48.
I also found an X10 dealer with 980 left. This morning.
-
For anyone interested, here is a photo of the prototype.
Jeff
(http://jvde.us/info/XTB-232_prototype_376.jpg)
-
JeffVolp,
To coin a phrase (more or less ;) )... This is obviously some strange usage of the word prototype that I wasn't previously aware of. :o
Where's the perfboard? Where are the unruly wires terminated in solder blobs that I know I should have reheated? ???
"Prototype". :P rofl
#:)
>!
-
Years ago a prototype for me was a wire-wrapped board, but that doesn't work well for mixed signal circuits, especially where high currents or 120VAC are involved. So a "prototype" now is a bare bones PCB without a solder mask or silk screen. That also verifies the PCB layout to minimize the risk transitioning from the prototype to the first quantity PCB order. A mistake there can be costly. And there was one on this "prototype" I had used the library SIP symbol for the programming header, and forgot to enlarge the holes from the PCB pins to the .025 square posts.
Jeff
-
Nice!!!
Jeff - add a USB interface, keep the CM11A protocol and you'd be elected Grand Poobah in the HeyU Hall of Heroes! :)
Heyu users still lament the fact there is no support for the CM15A.
-
Jeff - add a USB interface, keep the CM11A protocol and you'd be elected Grand Poobah in the HeyU Hall of Heroes! :)
Sorry, but USB just isn't going to happen.
FYI - The hardware is working exactly as shown above. You may note that I managed to squeeze in three opto-isolators (top left), so it will even support the ring indicator.
All that is left to do is code the CM11A protocol, but that may have to wait until after April 15.
Jeff
-
Yeah - I was just razzing you.
It looks great.
-
To make this compatible with existing systems, it would emulate the “real-time” CM11A protocol.
What does "real time" mean? One problem with all of X-10's interfaces is that they report only valid X-10 commands - they do not report all power-line activity.
-
Jeff -
Was this meant as a simple replacement for the "live" function of the CM11A?
Is there anything this product would do that a CM11A CAN'T do?
-
To make this compatible with existing systems, it would emulate the “real-time” CM11A protocol.
What does "real time" mean? One problem with all of X-10's interfaces is that they report only valid X-10 commands - they do not report all power-line activity.
My target for this product was the PC-based automation systems that interface to the powerline through a serial port. HomeSeer is one example that does not use the "controller" functions in the CM11A, such as timed events or macros. It uses the subset of commands that I call "real-time" because those are processed immediately. And you are right, the CM11A only passes valid X10 commands back to the PC.
(Boy, the spell checker had some interesting suggestions for this message. I especially liked "Pickaxed" automation systems.)
Jeff
-
Was this meant as a simple replacement for the "live" function of the CM11A?
Is there anything this product would do that a CM11A CAN'T do?
As stated in the prior response, the intent was to provide a high-reliabilty powerline interface for software-based automation systems running on the PC. Except for driving with a much stronger signal, the XTB-232 only currently supports what I call the "real-time" subset of CM11A commands (up through section 4 in the CM11A protocol document).
Once the hardware platform exists, it is certainly possible to provide extensions beyond that basic capability.
FYI: The prototype seems to run well under the original ActiveHome GUI.
Jeff
-
(Boy, the spell checker had some interesting suggestions for this message. I especially liked "Pickaxed" automation systems.)
Well, the PICAXE is actually quite impressive although I have no idea whether it includes any X-10 functions. ;D
-
I wanted to give an update on the XTB-232. There are a few beta units out there. One installation uncovered a problem with status reports from 2-way modules. The original beta firmware could receive standard STATUS_ON and STATUS_OFF commands, but not extended or preset-dim status reports. That is fixed now for X10 modules such as the LM14A. After I confirm it also works with a SmartHome 2-way module presently on order, the new beta firmware will be distributed.
The XTB-232 will be a “polite” transmitter. Not only will it wait for a clear line before transmitting, but it will also automatically abort and re-transmit a command if there is a collision with a command sent by a dumb controller such as the TM751. While that doesn't prevent corruption of the command from the dumb controller, the command issued by the XTB-232 should be received cleanly.
This may be an improvement over the actual CM11A because collision testing with that unit not only locked up the CM11A itself, but also the ActiveHome program. I suspect the occasional lockups that occurred back when I used the CM11A were also due to collisions.
The prototype XTB-232 has been tested running under ActiveHome, HomeSeer, and Home Control Assistant. Please let me know if there are other PC-based X10 control systems that I should also test for compatibility.
Jeff
-
Has anyone with a LM14A,AM14A or AM15A. Two way module tested it?
I understand from one of the old X10 whitepapers. They send a request to the controller {CM11A} when powered up. Asking its last known state as they have no memory to store the information. That isn't lost with no power.
-
I may be mistaken but I don't think that is what they send. It's been too long for me to recall such details but a search of comp.home.automation using Lanciani LM14A power up might show this.
Hmmm - I guess the old brain ain't totally fried. Here's one extensive thread from comp.home.automation discussing what the LM14A sent at start-up (soon after its introduction) and its effect on a CM11A starting up at the same time (e.g. after a power outage). It sent its status (possibly saved to the MCU's EEPROM) which would cause the CM11A to lock-up.
- http://groups.google.com/group/comp.home.automation/browse_thread/thread/b6604908532ee418/d75140d3de401d1f?lnk=gst&q=Lanciani+LM14A+power+up#d75140d3de401d1f (http://groups.google.com/group/comp.home.automation/browse_thread/thread/b6604908532ee418/d75140d3de401d1f?lnk=gst&q=Lanciani+LM14A+power+up#d75140d3de401d1f)
-
Has anyone with a LM14A,AM14A or AM15A. Two way module tested it?
Yes, I have been testing the status response with the LM14A, RR501, and the PR511 floodlight.
I've cycled power on the LM14A a few times, but didn't see anything strange happen.
Update: I just retested with a "port sniffer" watching RS232 traffic, and indeed the LM14A does send an extended code when it is powered up. ActiveHome (not Pro) responds with its own extended code. However, the command and data bit patterns are not defined in the extended code document I have, so I don't know what meaning either of those extended codes conveys.
Jeff
-
There was a White Paper about the two way protocol used by the LM14,AM14-15. On the X10 web site at one time, but I can't find it now.
It was from Dave Rye and I did find basically the same date here:
http://www.hometoys.com/htinews/apr99/columns/x10/2way.htm
-
From the Dave Rye paper...
When the unit is made to turn ON from being OFF, it fades up to the MEMORY level from FULL DIM at the normal dimming rate. When the unit is made to turn OFF, it fades from the MEMORY level to FULL DIM before turning OFF. The MEMORY is saved.
As best I recall, that's what it did way back when. There's a Commander X log in the CHA thread I referenced above documenting this. Whether it has since changed, I know not.
-
Yes, the LM14A ramps up and down like the Leviton dimmers, stopping at the last preset level.
I believe Brian asked about the LM14A powerline traffic after power is cycled. In that case there is extended message communication with ActiveHome. While the LM14A house and unit codes can be seen in those messages, it isn't clear to me what content of that communication is.
The LM14A remains off when power is cycled, just like other X10 lamp modules.
Jeff
-
Near the bottom of the link I gave. Is a explanation of with is sent when it wants to know its last know state and what the CM11A sent back.
-
Near the bottom of the link I gave. Is a explanation of with is sent when it wants to know its last know state and what the CM11A sent back.
Ah, after going through it again, I see that does define the data and command bytes received from the LM14A following the power-up (10 & 37) is the extended status request.
The response is the extended configuration data and command bytes (02 & 3B), which has the auto-acknowledge "standard" bit set.
Anyway, the communication through the XTB-232 agrees with the X10 documentation.
Jeff