X10 commands and PBP

Several months ago, I did post for a problem faced with the XIN instruction, in conjunction with HSEROUT. Well after several experiments I came to the conclusion that HSEROUT has nothing to do with the problem, which depend exclusively on the XIN instruction! which doesn't work properly.

I tested XIN with several different pics (16F84; 16F88; 16F628; 16F876) and the XIN instruction fails to work with them all.

Sending an X10 command, the X10 device addressed, respond as it should while the testing device (which shold read the same command with the XIN instruction) reports always Home 17 and Key 10 whatever X10 command is sent.

On the contrary the XOUT instruction works correctly.(using the same powerline interface)

I wonder to who, I must address this issue to see if it is possible to remove the problem and be able to use the XIN instruction.

Any suggestion is welcome.

P.S. (I have PBP 2.47)

Al.

Are you using the TW523 interface or your own hardware to receive X10 from the mains?

Anand

No, I am using TR-2A Tx & Rx powerline.

Al.

Quote:

---

Originally Posted by aratti

No, I am using TR-2A Tx & Rx powerline.

---

Is that from Iriave? I have a TR-1A (IiRC) from 5-6 years ago. Do you have any documentation for your module?

EDIT: http://www.iriave.it/Datasheet/TR-2ArevB.pdf

It looks very similar to the TR-1A that I have (somewhere). They use a reed relay to disconnect the TX circuit when idle to avoid loading the network and attenuating other transmitters. Anand's advice re 50Hz is likely spot on.

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.

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.

What I'd suggest is, record the zerp crossing signals on one channel and the X10 signals on the other channel using your sound card, and see what you're actually getting. Confirm if the X10 bits are withing the tolerated delay of a true zero crossing. Decode the bit stream to see if it matches the transmitted signal. That would be a starting point.

Regards,

Anand

Thanks, Dave.

Aratti, with the interface PBP is designed to work with (TW 523 or equal), the transmitter is a simple physical interface to the mains. However, the reception goes thru' a processor that outputs a string PBP can recognise.

I am not familiar with the TR-2A, and could not find a schematic, but page 4 of the pdf suggests that the reception is also a simple physical interface that translates 120khz bursts to '1'; no processing is done, just the raw data received is sent to the host at TTL levels. In which case, XIN will not work. You will have to decode the bits manually, which s incidentally not too complex given all the X10 documentation on the web.

Regards,

Anand

Quote:

---

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

Quote:

---

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.

Quote:

---

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.

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

Quote:

---

Originally Posted by aratti

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.

Quote:

---

Originally Posted by aratti

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

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.