Re: Preventing Random X-10 Code interference...

["Robert Green" <ROBERT_GREEN1963@xxxxxxxxx>]

"Dave Houston" <nobody@xxxxxxxxxxxx> wrote in message

> My plan has been to output 3 bytes per half cycle. They would give the
> amplitude (8-bit resolution) at ZC+250µS & ZC+900µS as well as the number
of
> rising edges between those points. All would be logged to a file with a
> timestamp for the start of each sequence. Logging would stop once 3 idle
> cycles were seen and resume on a new line at the next "1" seen. Software
> would be able to reconstruct the sequences. Even the average frequency of
> the carrier or noise could be calculated.

Sweet!  It would be nice to have one!   I'm sure there's nothing I can do to
help because of my limited experience but I have been looking at various
tutorial sites that might be helpful.  I was wondering what the TW523 can do
at the very raw level because the LynxView software ran from the standard
Marrick Lynx interface.

I'm not sure if I am understanding what I've read correctly but it seems
that the various clones of the TW523 can be made to output useful
information to a log file - not with the detail that you're proposing but
with a great deal more detail than anything short of a powerline analyzer.
Would TW523 make a good base for building on something that could do more
Monterey-like analysis at the bit level or does it require really starting
from scratch?  I like the idea of hacking a TW523 because it seems that it's
UL listed and the outputs and inputs to the PC are optically isolated.

In fact, while looking for tools to work with the TW523 I came across this
article:

http://www.hkrmicro.com/course/lesson16.html

which talked about something we had discussed previously:

"As you see here, the START code takes 2 cycles, the HOUSE code 4 cycles,
and the KEY code 5 cycles. This is the 11 cycle message segment. One
complete command consists of the message segment sent twice, taking 22
cycles of power to send. If the TW523 was receiving this 22 cycle
transmission, data will only be sent out to the DS5000 during the second
message segment. The proprietary chip inside the TW523 is comparing the
first message segment with the second segment as it is received and presents
data to the DS5000 during this second segment. This comparison is made to
validate the X-10 command, and that it wasn't garbled with noise during
transmission."

It this 1st/2nd command comparison something unique that they are doing to
interface with the DS5000 microprocessor or what?  I'm convinced that wall
switch modules from X-10, at least, respond to the first command because of
the time lag I noticed that corresponds to the Monterey's indication of a
"bad first command."  But the above statement seems to imply that TW523
devices read only the second command and act only if it matches the first.

Of course, the only place I have any TW523's are with the Omni and the
CPU-XA so I probably wouldn't notice any time lags in their operation. Gawd,
this stuff gets confusing.

Do you think the course at:

http://www.hkrmicro.com/course/micro.html

would help an electronic feeb like me to build something useful?

It's surely not current (This page last updated on Jun 24, 2001!!) but I
think if I set my mind to it, I could build something out of the components
there, maybe even the base platform for your proposed meter, if given enough
time (could be months, years or decades!)

For example, the author at the above site wrote:

"The TW523 outputs a square wave, in sync with the power line frequency and
within the 50 microsecond window of zero crossing. This is a 60 Hz square
wave."

Does this mean that the TW523 essentially "follows" the powerline and that
by looking at one of the data lines coming from the unit you will see a
logical 1 for half of one powercyle and a logical 0 for the other half?
Does the "within the 50µS window of zero crossing" imply that it takes up to
50µS to process the zero crossing information and place it on the TW523's
output line?
Which I can't claim to undestand at all.  )-:

OK,  I've got to read up some more . . .

--
Bobby G.