Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[JeffVolp]

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

[pconroy]

Yeah - I was just razzing you.
It looks great.

[dhouston]

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.

[Noam]

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?

[JeffVolp]

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

[JeffVolp]

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

[dhouston]

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

[JeffVolp]

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

[Brian H]

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.

[dhouston]

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

[JeffVolp]

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

[Brian H]

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

[dhouston]

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.

[JeffVolp]

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

[Brian H]

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.