Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[bkenobi]

The code allows for selecting the frequency.  It defaults to 50Hz, but I changed it to 60Hz.  I'll verify that it didn't somehow revert though.  Is it possible that the code isn't waiting long enough between sending the command?  I mean, doesn't X10 PLC send a command first selecting the house and unit codes and then a second with a house code and command?  If the gap between them is different than what the XTB-IIR is expecting, it could try repeating before the PL513 is done, right?  Looking at the Wikipedia article to refresh my memory, this is an excerpt:
http://en.wikipedia.org/wiki/X10_%28industry_standard%29

The protocol may transmit a message that says "select code A3", followed by "turn on", which commands unit "A3" to turn on its device. Several units can be addressed before giving the command, allowing a command to affect several units simultaneously. For example, "select A3", "select A15", "select A4", and finally, "turn on", causes units A3, A4, and A15 to all turn on.

I don't know how the arduino code is sending the command, so I guess I'll have to review.

[bkenobi]

This is the list of global constants for the Arduino library.  I'm not sure if these timings are correct or should be tweaked.

Code: [Select]

// Number of silent power line cycles before command is sent
#define X10_PRE_CMD_CYCLES    6
// Sample delay should be set to 500us according to spec
#define X10_SAMPLE_DELAY    500
// Signal length should be set to 1000us according to spec
#define X10_SIGNAL_LENGTH  1000
// Set buffer size to the number of individual messages you would like to
// buffer, plus one. The buffer is useful when triggering a scenario e.g.
// Each slot in the buffer uses 5 bytes of memory
#define X10_BUFFER_SIZE      17
// Set the min delay, in ms, between buffering of two identical messages
// This delay does not affect message repeats (when button is held)
#define X10_REBUFFER_DELAY  500
// Chooses how to save module state and info (types and names).
// Set to 0: Neither state nor info is stored and state code is ignored
// Set to 1: Module state data and module info is stored in EEPROM.
// Set to 2: State data is stored in volatile memory and cleared on
// reboot. Module types and names are not stored when state is set to 2.
#define X10_PERSIST_MOD_DATA  1
// Length of module names stored in EEPROM, do not change if you don't
// know what you are doing. 4 and 8 should be valid, but this isn't tested.
#define X10_INFO_NAME_LEN    16
// Enable this to use X10 standard message PRE_SET_DIM commands.
// PRE_SET_DIM commands do not work with any of the European modules I've
// tested. I have no idea if it works at all, but it's part of the X10
// standard. If you're using a PLC interface and modules that support
// extended code: use the "sendExtDim" method in stead.
#define X10_USE_PRE_SET_DIM   0Also, the test code I posted before was set up to use 1 phase (no repeats) and 60Hz.  I wonder if I should change that to 2 phase since I do have a repeater installed which couples the phases.  Europeans don't need a phase coupling since they run on 220v for all equipment.  In the US, since we transmit on one leg and have to couple the other, shouldn't I make that 2 so that I give the repeater time to repeat to the other phase before sending a second command (or second half of the command pair)?  If I had a different repeater still, I'd throw it in there and see if it works the same or different.  I got rid of it a while back, so I don't have anything to test with.

[dhouston]

I don't know how the arduino code is sending the command, so I guess I'll have to review.

I doubt that it sends the sequence automatically. It's probably up to you to make sure there is an adequate gap. It may be that the gap is too long and Jeff's device assumes the line is clear and starts to repeat the code - then you step on it with your second command.

The only devices that automatically send both Address & Function codes are the RF transceivers.

But, I'm speculating. It's probably best to let Jeff help you with this.

[dhouston]

Also, the test code I posted before was set up to use 1 phase (no repeats) and 60Hz.  I wonder if I should change that to 2 phase since I do have a repeater installed which couples the phases.

No! Leave it at 1 phase. Your two phases share the same ZC time as they are 180° out of phase with each other. 3 phase ZCs are at 60° intervals.

[bkenobi]

I'm certainly on a single phase of electricity, I just wasn't sure if the nomenclature of the code meant something different.  I'm aware that in the US 3 phase is typically used to transfer power and not typically used for anything but factories.  Most residential power is 120/240V coming out of a pole mounted transformer.  In my case, it's an underground vault on the property, but same difference.

If there are 2 sequences sent right after each other, then I could possibly change the delay in the code to make it possible for the repeater to do it's thing prior to sending the second half.  I'd just have to find the right constant to increase.

[dhouston]

The delay to see if the powerline is clear before sending a code (#define X10_PRE_CMD_CYCLES    6) is absolutely worthless.

Oooops! I have to modify that - while none of the TTL interfaces (PL513, PSC24, TW523, PSC05, XM10, TW7223) can report in realtime to avoid collisions, putting 6 idle cycles in front of each command does guarantee the required gap between commands. So, its not absolutely worthless.

[bkenobi]

I'll email Jeff and see if he can help.  At this point it's probably best to understand what the XTB-IIR is expecting so I can make the code modifications necessary (if possible) to make them work together.

[bkenobi]

Unfortunately, Jeff didn't have the time to review my code (I don't blame him, I wouldn't want to take on that task either).  He did point out how all repeaters/signal boosters function which led me to the answer.  Basically, the repeater is waiting for a command to be sent over PLC.  When it sees the first 22 bits, it then begins repeating (and boosting if equipped) the same sequence right over top of the second set of identical 22 bits.  If there is an irregularity, then bad things can happen.

I started looking at the code and realized that the command string that library was constructing was not 22 or 44 bits long.

1110010101100110100101 (correct 22-bit, set unit E1)
11100101011001101001011110010101100110100101 (correct 44-bit, set unit E1)
10110000000000000000100111001 (incorrect 29-bit, E1 ON)

Now, the correct 22- and 44-bit signals include the two's compliment data.  Even if the 29-bit one did not, I don't see how it got the right data to the function that sends the data.

start string:
1110
house code (E):
0001
unit code (1):
01100
command (ON):
00101

No matter how I try to decipher the bad code, it doesn't make sense.  Irregardless, that's not the problem.  I found a couple more libraries and looked at them instead.  The other libraries send out strings that make perfect sense but still caused signal collisions.  The only way to fix this was to increase the gap between codes from 6 zero crossings to around 30 zero crossings.  I'm not sure why I need such a large gap, but I decided to simply add a 0.5 second delay after every X10 command.  With that statement included, the code works perfectly.  I was originally going to keep the first library since it's a much more powerful code, but I couldn't figure out how to get it going even with the delay.  So, I am now using the simpler code.

I have been testing the setup including the DHT11's on a breadboard over the weekend and it works great.  I'm going to put this setup in the attic for a few days just to be sure before I tear into the finished v1 project.  Assuming there are no errors, I'll update to v2.

[dhouston]

The Arduino is clueless as far as powerline activity. The PL513 & PSC04 do not receive PLC and the PSC05, TW523, TW7223 & XM10 all report PLC activity only after a 22 half-cycle delay. So, while the latter group may detect earlier activity, they do not report in realtime so collisions cannot be avoided.

The repeater starts immediately after the first code and you original Arduino code was stepping on the repeated code, resulting in the reported collisions.

[bkenobi]

The original code was somehow taking the house code, unit code, and command as input to the SendCommand function.  That function constructed and sent all bits for the 2 44-bit commands internally.  I tried to locate what bits were being sent and their timings, but could not find them.  The only thing that I can figure (guessing here) is that the code was sending the first 22-bits and waiting for 6 zero crossings to send the second set OR the the code was sending 44-bits in such a way that that the XTB-IIR was not able to write the second 22-bit command concurrently with the PL513.  Either way, using a different library has allowed me more control of what is actually being written and I have a way to get the results I need.

The first library is actually better since it uses the zero crossings as it's way to send/receive rather than using times.  Using times is ok, but zero crossings is per spec.  The library I am currently using really only uses the zero crossing to count how long to wait to send the next command in the buffer.  The author stated in the documentation that he wanted to someday update the code to include receiving as well as just transmitting (TW523/PSC05 is compatible for transmit currently).  As I see it, you can't do receiving without being fully driven by the zero crossings since that's when you have to pole for incoming commands.

[dhouston]

I'm not sure what you mean by using times. It has to be sync'ed to ZC. Here's the spec from the extended code documentation at http://software.x10.com/pub/manuals/xtdcode.pdf

Data is accepted bit by bit as the presence or absence of 120Khz carrier occurring after the positive or negative mains zero crossing. The acceptance window begins approximately 250 usecs. and ends approximately 900 usecs. after a zero crossing. In this window 48 or more cycle of carrier are accepted as a "1" bit and fewer than 48 as a "0" bit. Except for the Startcode, each bit of data is sent in its true and complement form.

and from http://www.x10.com/support/technology1.htm

A Square wave representing zero crossing detect is provided by the PL513/TW523 and is within 100 µs of the zero crossing point of the AC power line. The output signal envelope from the O.E.M. should be within 50 µs of this zero crossing detect. The signal envelope should be 1 ms (-50µs +100µs).

[bkenobi]

I don't have the code I'm currently using in front of me, but, as I recall, the zero crossing was only used for counting the number of crossings between commands.  If there weren't enough crossings, the code waited to transmit the buffer.  I do not believe it was used for anything else.  Yes, the zero crossing should be driving everything.  A delay from the zero crossing to start and end of the bit is obviously required.  I'll have to review the code again, but, like I said, I don't recall the zero crossing driving everything like it did in the original code.

[bkenobi]

Ok, looked at the code again and it does use the zc for sending bits.  Must have been a different code or a hallucination where it was hidden better.  In any case, here's how it writes:

Code: [Select]

void x10Class::sendBits(byte cmd, byte numBits, byte isStartCode) {
  byte thisBit; // byte for shifting bits
 
// iterate the number of bits to be shifted:
for(int i=1; i<=numBits; i++) {
// wait for a zero crossing change
waitForZeroCross(zeroCrossingPin, 1);
// shift off the last bit of the command:
thisBit = cmd & (1 << (numBits - i));

// repeat once for each phase:
for (int phase = 0; phase < 3; phase++) {
// set the data Pin:
digitalWrite(txPin, thisBit);
delayMicroseconds(BIT_LENGTH);
// clear the data pin:
digitalWrite(txPin, LOW);
delayMicroseconds(BIT_DELAY);
}

// if this command is a start code, don't
// send its complement.  Otherwise do:
if(!isStartCode) {
// wait for zero crossing:
waitForZeroCross(zeroCrossingPin, 1);
for (int phase = 0; phase < 3; phase++) {
// set the data pin:
digitalWrite(txPin, !thisBit);
delayMicroseconds(BIT_LENGTH);
// clear the data pin:
digitalWrite(txPin, LOW);
delayMicroseconds(BIT_DELAY);
}
}
}
}
The other function that sends commands has a wait for 6 crossings before continuing.  Also, there was another code that looked different.  I appear to have smeared them in my head.   

[bkenobi]

I found a few minutes this evening to put together the test setup such that it could interface with the installed sensors, installed the (hopefully) final version of the code, and moved everything to the attic.  If all goes well, I'll have log files in AHP and my custom script that will show things working as designed.  Everything worked perfectly at my test location, but who knows what will happen when it's out of sight.   

[bkenobi]

After a week of use, it appears that the controller is working PERFECTLY!  I set it up so it runs for 10 minutes and then delays for 30 minutes.  If the temp/humidity is above trigger points, it can then turn on again.  Doing it this way, I find that the fan triggers several times in a row from around 10am-6pm for my south attic (exposed to the sun for most of the day this week) but the north attic triggers once every couple hours or so.  I selected the run time to allow a full purge of attic air several times over (calculated attic volume and used fan flow rate to determine ~5-10x purge).  Based on the fact that the north attic only needs to run once every hour or two and the south attic starts at the end of the delay time, I'd say my method is just about right.

In any case, the X10 stuff is working great at this point, so I'm thinking I'll go ahead and modify the old controller when I get a chance.  I may even throw an Ethernet shield on the arduino and set it up to upload temp and humidity for each sensor, fan run state, and even the sensor check values (for validating that sensors aren't broken) to pachube or similar.  I just have to verify that the network cables running through the attic are hooked up how I think they are.

Thanks for all the suggestions!