🖥️ActiveHome Pro > SDK
Collision management in X10 pure RF
dhouston:
--- Quote from: toasterking on June 28, 2015, 01:27:46 PM ---I was envisioning a noise source that only spews its 120kHz burst on the AC half-cycle, i.e. only on a rising ZC or only on a falling ZC. Wouldn't that be interpreted to an X10 receiver as 101010101010? Then if only one of those 0 half-bits gets changes to a 1 half-bit, you get 111010101010, which is a valid start code and house code J (not M; my mistake). My thinking was that if you have a valid start code and house code composed of just line noise, that just raises the probability, with only 5 bits to go, that eventually, you could have an entire valid X10 PLC command composed of line noise.
--- End quote ---
That is a bit more plausible. While most switching power supplies use full-wave rectifiers, there may be some that use half-wave and they might spew harmonics during half cycles. Still, I find it difficult to envision how to get a housecode and function code pair, especially those that are frequently reported. It's much easier to envisage them as noise sources blocking X10 signals.
Also, it begs the question, "Why does it seem to show up when you are trying to generate collisions but not at other times?"
toasterking:
--- Quote from: dhouston on June 28, 2015, 03:21:36 PM ---Still, I find it difficult to envision how to get a housecode and function code pair, especially those that are frequently reported. It's much easier to envisage them as noise sources blocking X10 signals.
--- End quote ---
I checked the PLC protocol specification, and after the 4 bits for the house code, a 1 means it's a command code and 1 for each of the remaining 4 bits is "Status Request". So if the aforementioned scenario occurrs in which there is noise only on the AC half-cycle and one 0 half-bit is changed to 1 by another random noise spike, an X10 PLC receiver will see 1110101010101010101010, which translates to "J STATUSREQUEST". So at least in theory, that is the most likely command to be received errantly as the result of line noise and it's a rather innocuous one, since it won't signal any module to change its state nor affect the perceived state of any module nor select a different unit code. In theory, it would elicit a status response from whichever unit code was last selected if that unit has 2-way capabilities, but nothing else. This could be a coincidental assignment in the protocol, but I choose to believe that it was carefully selected by whatever engineer chose the assignment for 1111.
However, this doesn't give us any clues as to why M is the most frequently reported house code resulting from signal collisions. I've only seen it on RF so far, which uses a different protocol than the PLC one I've been discussing here. But if it's a bug in the SDK or PC interface firmware, it's possible that the bug is at a higher level than the processing of either protocol.
toasterking:
I just wanted to post a follow up on this. 4 years later, I am still using mostly the same setup in my office and still using the same algorithm for collision avoidance and detection. However, I have tweaked some values:
* I check to see if any commands were received in the last 750 ms (instead of 200 ms). I changed that because if an RF transmitter key is held down, the SDK waits up to 728 ms to begin showing repeats of a code, and I need to also be able to detect if a code has recently begun repeating.
* Commands are now transmitted with a duration of 90 (instead of 1). This seems the lowest value that will cause the CM19A to transmit the command twice rather than once. Very rarely, a command would not get received by both RR501s when transmitted only once.
* After transmitting, I delay the next transmission by at least 1200 ms (instead of 1100 ms).So the full algorithm with its current values is:
--- Quote ---
* Every time any copy of an RF command is received, reset a global timer.Transmission sequence:
* COLLISION AVOIDANCE: Before transmitting, check to see if any commands were received in the last 750ms (using the timer defined above). If so, delay the transmission until 750ms has elapsed since the last received command. (This accounts for the delay between reception of repeated commands, including repeating ones.)
* Transmit the command with a duration of 90 (transmits 2 copies).
* After transmitting, wait 1200ms before allowing the next transmission to be sent.
* COLLISION DETECTION: If a command is received during the ("non-deaf" portion of the) 1200ms window, check to see what the command was.
* If it was the same command that was just sent, ignore it because it is probably an echo.
* If it was any other command, treat it as a collision and immediately repeat the entire transmission sequence.
--- End quote ---
This got me to about 95% reliability. But on rare occasions, the CM19A's receiver seemed "deaf" for much longer than usual after the transmission window. I was not able to predict the occurrence nor duration of this "deafness window" with any consistency. I think, at this point, that it is a race condition within the SDK that rarely gets triggered. And I wasn't happy with 95%, so eventually, reluctantly, I added one more tweak: I added an X10 MR26A receiver and a USB serial adapter (with PL-2303 chipset). So just to be clear, I have both a CM19A RF transceiver and an MR26A RF receiver connected to the same PC, and every X10 RF message is transmitted once (by the CM19A) and received twice (once by each receiver).
The advantage (sadly) of the old fashioned MR26A receiver is that no SDK functionality is offered. I had to write my own code to decode the X10 messages from the serial stream, but I am not subject to the software bugs in the SDK. This is probably the best tweak I have made so far! It works with the existing algorithm I had in place for handling collisions and greatly boosts the reception range for most devices. The exception is the SS13A Stick-a-Switch; that doesn't work more than about 4 inches away. I tried with two MR26As! (I assume its frequency is poorly tuned, but I have no way to test.) I could actually lower some of my values and get the system working faster with the MR26A, but I'm leaving it as is to err on the side of reliability. The only disadvantage of the MR26A is that it does not recognize security codes. Those codes are still received by the CM19A, but they don't get the extra edge on range or collision handling from the MR26A. (I'm not using any so-equipped devices, so it's irrelevant to me.)
EDIT 8/22/2019: Fixed values in the quote block that did not get updated when this message was posted originally. Weird.
Navigation
[0] Message Index
[*] Previous page
Go to full version