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