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

[nobody@xxxxxxxxxxxx (Dave Houston)]

The TW523 is not a good choice for a diagnostic tool unless you modify it as
Neil Cherry has done. Even then it is not a good choice to measure signal
amplitude.

The TW523 actually outputs on a delayed basis. It reports the first copy of
the X-10 code during the time frame of the second copy. This means it's too
late to see a collision in time to do anything to avoid it. It also only
reports part of the actual powerline activity so, for example, it does not
report all dim/brights or extended codes.

It also outputs an opto-isolated square wave that is in sync with the 60Hz
line frequency. It's purpose is to provide a sync signal for external
devices to input X-10 pulses at the proper times.

Maxim bought Dallas a few years back. I don't know whether the DS5000 is
still made.

I would suggest an easier way to learn about microcontrollers. The BasicX-24
uses an Atmel µController plus an external EEPROM and inverter (for RS232)
and is programmed in Basic (same dialect as BasicStamp). While its slower
than a directly programmed µController it is fast enough and powerful enough
to handle most HA related tasks. It's a cheap way to learn, as the
programming language is a free download, although its probably easier for a
beginner to buy the development system.

If you later want to take a more low level approach, there are Basic
language compilers for both Atmel and PIC µControllers that allow you to mix
assembler statements where you need even faster execution. The µControllers
are getting more powerful - faster with more RAM and internal EEPROM. They
are dirt cheap.

There are also many books and tutorials on assembly programming of both
Atmel and PICs. Start at Reynold's Electronics www.rentron.com for PICs and
www.avrfreaks.com for Atmel. Spark Fun Electronics www.sparkfun.com is
another good site to know about.

"Robert Green" <ROBERT_GREEN1963@xxxxxxxxx> wrote:

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