🖥️ActiveHome Pro > SDK
Collision management in X10 pure RF
dhouston:
One more clarification. When capturing/decoding low level X10 RF, I've never seen anything suggesting a collision resulting in a phantom code. I've only seen the valid codes expected during my extensive testing. That's the reason I suspect the reports of such collisions are due to faulty logic in X10 firmware/software.
dhouston:
--- Quote from: toasterking on June 26, 2015, 11:40:26 AM ---It may be a bug in the firmware or SDK, but the SDK captured the M1 ON code several times while I was experimenting and I don't have any devices on house code M. It was always when I was intentionally causing overlapping transmissions. IIRC, the conflicting codes that were being sent at the time were F3 ON and either F2 DIM or F2 BRIGHT. I didn't capture any other errant codes besides M1 ON.
--- End quote ---
Was the M1 ON reported as RF, PLC or both?
toasterking:
--- Quote from: dhouston on June 26, 2015, 01:11:09 PM ---I didn't intend to dissuade you and my tone may have come across as more critical than intended.
--- End quote ---
No worries! I did not feel dissuaded, no tone was interpreted, and I took no offense. I was just summarizing my conclusion.
--- Quote from: dhouston on June 26, 2015, 01:11:09 PM ---Having 2 or more polite PLC transmitters can lead to problems.
--- End quote ---
I was aware of this, but only because you had already documented it so well at http://davehouston.net/multiples.htm! :)
--- Quote from: dhouston on June 26, 2015, 01:11:09 PM ---If I manage to finish the projects I've started, they will provide low level access to all the raw RF & PLC signals free of any interpretation by X10 firmware/SDK issues.
--- End quote ---
I am interested to see what you and others develop with that! I would certainly welcome an attempt at a do-over for RF decoding firmware!
--- Quote from: dhouston on June 26, 2015, 01:11:09 PM ---M is frequently the housecode reported as evidence of phantom codes from collisions. So much so that I suspect it's a firmware or SDK issue.
--- End quote ---
--- Quote from: dhouston on June 26, 2015, 02:57:39 PM ---One more clarification. When capturing/decoding low level X10 RF, I've never seen anything suggesting a collision resulting in a phantom code. I've only seen the valid codes expected during my extensive testing. That's the reason I suspect the reports of such collisions are due to faulty logic in X10 firmware/software.
--- End quote ---
I'm seeing one more reason not to use housecode M for anything important. I already had two others:
* Absence of a house code wheel equates to house code M, so modules with dirty contacts on the code wheels are probably more likely to send commands for house code M than any other errant house code.
* The raw sequence for start code + house code M on PLC is 111010101010, so if there is continuous noise around 120kHz only on the half-cycle, all it takes is for one of those empty (0) frames to be filled in with another errant noise spike, and the noise becomes a valid sequence for house code M.
--- Quote from: dhouston on June 26, 2015, 06:07:51 PM ---Was the M1 ON reported as RF, PLC or both?
--- End quote ---
It was definitely reported as RF because I was filtering to only "recvrf" events from the SDK. With that in mind, it is possible that there was a matching "recvplc" event but I would not have seen it.
dhouston:
--- Quote from: toasterking on June 27, 2015, 10:54:54 PM ---
* The raw sequence for start code + house code M on PLC is 111010101010, so if there is continuous noise around 120kHz only on the half-cycle, all it takes is for one of those empty (0) frames to be filled in with another errant noise spike, and the noise becomes a valid sequence for house code M.
--- End quote ---
I think M is 01010101 at the PLC level. Changing any of those 0 half-bits to 1 results in a 1110 start sequence (which will be followed by an invalid code).
It also requires that a 1 half-bit be changed to a 0 half-bit. Changing a 0 half-bit to 1 is simple; changing the adjacent 1 half-bit to 0 is not. IOW, it requires changing a 10 sequence to 01 or vice versa.
The NEC protocol used for RF follows each byte with its complement so there a 0 bit changed to 1 requires a corresponding 1 to 0 change in the following byte. That seems even harder to imagine but, when you consider the physical layer where a 1 bit and 0 bit have different times between rising edges, it becomes extremely difficult to transpose corresponding bits in adjacent bytes without some shift in the time/space continuum.
At a higher logic level where 01010101=M becomes 0000=M it appears far more doable without calling on Dr. Who.
toasterking:
--- Quote from: dhouston on June 28, 2015, 08:21:56 AM ---I think M is 01010101 at the PLC level. Changing any of those 0 half-bits to 1 results in a 1110 start sequence (which will be followed by an invalid code).
--- End quote ---
You are correct as usual. I was thinking that the complementary half-bit came before the actual half-bit, but it is after. That means that 111010101010 is valid for house code J, not M. It is disappointing to me that I have been avoiding the wrong house code for all this time and have 16 devices on house code J!
--- Quote from: dhouston on June 28, 2015, 08:21:56 AM ---It also requires that a 1 half-bit be changed to a 0 half-bit. Changing a 0 half-bit to 1 is simple; changing the adjacent 1 half-bit to 0 is not. IOW, it requires changing a 10 sequence to 01 or vice versa.
--- End quote ---
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.
This is a tangent because we were initially discussing the RF protocol, not the PLC one, but still an interesting tangent!
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version