The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: XM10E questions


  • To: ukha_d@xxxxxxx
  • Subject: Re: XM10E questions
  • From: "K. C. Li" <li@xxxxxxx>
  • Date: Wed, 10 May 2000 11:05:45 +0100 (BST)
  • Delivered-to: rich@xxxxxxx
  • Delivered-to: mailing list ukha_d@xxxxxxx
  • Mailing-list: list ukha_d@xxxxxxx; contact ukha_d-owner@xxxxxxx
  • Reply-to: ukha_d@xxxxxxx

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

The XTC document is the correct one. X-10 have updated the X-10 command
set to include "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.

The 11-bit frame is for standard X-10 commands. As you have correctly
pointed out, X-10 have added additional bits to the standard commands to
make the extended command set.

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

I would guess that the XM10E would buffer a variable length frame, not
just 11 bits. Since we don't currently have any X-10 controllers that send
the extended commands, we couldn't verify it. One of the projects that we
are working on is a remote X-10 temperature sensor that uses the extended
command set (Extended Code 1) for communications. I am sure we will come
across the same problem that you are having soon...

We could refer the query back to X-10 (Pico Electronics) for
clarifications but judging from our past experience, it would probably
take a while for them to answer (if at all).

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

The CM12U is also capable of sending and receiving the new extended
command set. It might be a better tool to use for generating extended
commands for testing.

Regards,

Kwong Li
li@xxxxxxx
Laser Business Systems Ltd.
http://www.laser.com


------------------------------------------------------------------------
Failed tests, classes skipped, forgotten locker combinations.
Remember the good 'ol days
http://click.egroups.com/1/4053/7/_/2065/_/957953096/
------------------------------------------------------------------------




Home | Main Index | Thread Index

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.