X10 commands and PBP

[aratti]

dhouston wrote: ..... Is that from Iriave? I have a TR-1A (IiRC)

Dave,
Yes, Iriave is the manufacturer, very likely TR-2A is the updated version of the TR-1A. The reed is anabled before X10 Tx and disable at the end. This works fine and I can Tx out all X10 codes. The problem is the X10 Rx which is reading the same value whatever X10 code you burst on the main. We have 50 Hz, (which should be better, since we have longer time for the burst, 10 millisec delay among zerocrossing while 60 hz has 8.33 millisecs).

ardhuru wrote: .....The reason I asked was, the delays incorporated in PBP for X10 commands assume a 60 Hz system; if you are in a 50 Hz country, you might have to tweak some values in the XIN and XOUT routines in the .lib files, especially if your transmitter and receiver are not on the same phase.

ardhuru, I don't think the main frequency matter, otherwhise I should not be able to burst out with the XOUT instruction.

ardhuru wrote: ..... When I design around X10 (my hardware directly interfaces with the mains), I do use the XOUT, but for receiving I decode the incoming signal manually.

if I read correctly your words, you did already experiment XIN without success, so you solved the problem decoding the X10 burst writing your own Rx routine. More explicitely "XIN instruction doesn't work" and forget about fixing PBP XIN instruction, write your own Rx routine.

Sounds very wise and realistic.

Thank you very much for your posting.

Al.

[dhouston]

After sleeping on it...

The TR-1A may have been a prototype. It output the 120kHz bursts rather than the data envelope as the TR-2A does.

50Hz should not be a problem for RX since you are only interested in the 120kHz burst that immediately follows ZC. But, I have never tried XIN so cannot offer anything meaningful.

If this is a one-off project, I would suggest a different chip. The ZBasic ZX328n sells for $10 plus the cost of the interface board and parts kit (plus shipping from the USA) but it has built-in low level interrupt driven X10 routines operating in the background. It has a serial bootloader making it easier to develop your program.

If it's a commercial project, I'd follow Anand's advice.

• http://www.zbasic.net/Microcontrolle...857161d7d13f51
  http://www.zbasic.net/Interface-Kits...oard/p-71.html
  http://www.zbasic.net/Interface-Kits...it-B/p-69.html

[ardhuru]

you did already experiment XIN without success, so you solved the problem decoding the X10 burst writing your own Rx routine.

Without success, if I interfaced the circuit directly with the mains, *without* a TW523. Yes, I did manage to decode the signal with my own routine, rather than XIN.

More explicitely "XIN instruction doesn't work" and forget about fixing PBP XIN instruction, write your own Rx routine.

Not quite true; XIN does work, only when used with a TW523.

http://www.x10.com/products/x10_tw523.htm

Regards,

Anand

[dhouston]

There are some other reasons to write your own routines. The TW523 delays its output for 22 half-cycles of the powerline (so it can validate the commands) and it only outputs if the commands are valid. This saves you the trouble of checking the manchester coded commands but also means your processor is deaf to the powerline while the previously received command is being output. The 22 half-cycle periods of deafness mean you miss 2/3 of dim/bright commands and cannot receive X-10's extended commands. Most importantly, the TW523 cannot avoid collisions as it is not operating in real time - it can only detect them after the fact. The TW523 was designed about 30 years ago and uses outmoded technology.

XIN assumes a TW523 so it does not handle extended codes.

• ftp://ftp.x10.com/pub/manuals/xtdcode.pdf

XIN may also be expecting a silence after 22 half-cycles and is being confused by the continued output from the TR-2A.

The TR-2A operates in real time so you need not miss any powerline activity. You can avoid collisions but you will also need to check the manchester validity of received commands.