XM10E questions

[Ant Skelton <ant@xxxxxxx>]

Wotchamates,

Following on from my last post of 6 months ago (been too busy with work
for HA stuff ;) which Kwong Li was kind enough to answer, I have some
further queries on the XM10E (new version of TW523/TW7223).

Firstly, I have two X10 protocol documents which differ in their
descriptions of the protocol slightly. The first is the OEM note which
LBS supplied with the unit, the second is a document called "Standard
and Extended X10 Code formats" dated 5/7/98, ref "XTC798".
I've no idea
where I got it; I think maybe Mark sent it to me.

The OEM document defines the following codes:

Extended Code             0 1 1 1    1
Preset Dim                1 0 1 X    1
Extended Data (analog)    1 1 0 0    1

It suggests that Extended Code and Extended Data may be followed by an
arbitrarily long sequence of bytes, with the usual biphase encoding.

However, the "extended message format" layout which follows
describes
the data field as "D128...   ...D2 D1" which suggests an upper
limit
of 16 bytes of extended data, followed by a single command byte.

The same diagram shows the start code as "1100", although I
assume
this is a typo and they really mean "1110", the regular X10 start
code.

Furthermore, the diagram shows the trailing command byte as split
into two 4 bit nibbles, a "type" nibble and a
"function" nibble.
One of their examples "request for light data" corresponds to a
definition in the other document, but the other "Ambient Light
Data" is specified differently in the second document.


The second document has the following conflicting definitions:

Extended Code 1        0 1 1 1    1  For Data / Control
Extended Code 3        1 0 1 0    1  For security measures
Unused                 1 0 1 1    1
Extended Code 2        1 1 0 0    1  For meter read & DSM

It also suggests that Extended Code 1 may be followed by ONLY ONE
data byte, then the command byte. On the plus side, it goes on
to give a veritable plethora of type/function definitions, but
as I mentioned before this conflicts with the OEM document.

This all leads me to my first question: what exactly is the format
of these extended messages, and is there an up to date spec available
for it anywhere? I assume that my XTC798 document is out of date,
which is a shame because it did have quite an extensive description
of extended commands.


Secondly, in his reply to my original post, Kwong Li informed me
that the XM10E passes on received frames with a 1 frame (or
11-bit) delay, and that it is also capable of receiving extended
commands.

Since an extended command is longer than 11 bits, does this mean
the received frame is delayed by a frame (>11 bits) or by exactly
11 bits (ie the unit starts transmitting the frame to the PC before
it has completely finished receiving it) ?? If the former, what is
the largest sized frame the XM10E can buffer? And if the latter, my
collision detection routine is screwed ;).

Admittedly, all this 'extended command' talk is a bit esoteric, but
I'm writing a driver which I want to be as generic as possible, and
I don't have any devices which generate extended commands.

I applaud anyone who has read this far, and await your collective
wisdom!


cheers

ant

ant@xxxxxxx

------------------------------------------------------------------------
Save up to 54% on Quest & Kelty tents, backpacks, sleeping bags and
outdoor gear.  FREE Shipping and a 30 Day Money-Back Guarantee at
screaminghotdeals.com
http://click.egroups.com/1/4012/7/_/2065/_/957735178/
------------------------------------------------------------------------