RF Signals Problem - Bug in Pluto ?

[archived]

Hi all.

I have been working on a Pluto problem for the past weeks and I pretty much narrowed it out, but
I now need you guys to help solve it.



-=HARDWARE USED=-

CM11A (x10) (on ttyS0)
RR501 (x10) (later replaced by TM751)
LM456 (x10 light module)
MS16A (x10 motion sensor)
UR19A (x10 remote control)

Up-to-date Core/Hybrid Pluto




-=PROBLEM DESCRIPTION=-

When any of the RF devices sends a signal (MS16A or UR19A) to my RF receiver (RR301 or TM751 / never used at the same time BTW),
every other X10 controls stops working.

Eg:  
From pluto I made a lighting scenario controling A2 on the LM456 and A9 on my RR501. Works great.
Then I put the batteries in the MS16A motion sensor A1 (or UR19A remotre control, dosent matter) and everything
stops working.  To make it work again, I have to Unplug/Replug the CM11A module, and then it will work until
the next RF signal is tranmitted.


-=LOG MESSAGES=-

I found something interresting in the logs. Take a look:
(56_CM11A.newlog)



---LIGHT CONTROL 'BEFORE' RF (MS16A) IS TURNED ON-- SENDING OFF SIGNAL TO BOTH A2 AND A9

10      02/25/06 13:04:33.843           Child device 57 has channel A2.
10      02/25/06 13:04:33.845           Child device 58 has channel A9.
10      02/25/06 13:04:33.900           Sending address with HouseCode=6, DeviceCode=14.
10      02/25/06 13:04:33.900           Sending packet with HighByte=4, LowByte=6e.
10      02/25/06 13:04:33.900           Sending header with Checksum: 72.
10      02/25/06 13:04:33.924           Got response: 72 from CM11A.
10      02/25/06 13:04:33.924           Sending ACK.
10      02/25/06 13:04:34.364           Got response: 55 from CM11A.
10      02/25/06 13:04:34.364           Address sent successfully.
10      02/25/06 13:04:34.364           Sending function with Code: 3.
10      02/25/06 13:04:34.364           Sending packet with HighByte=6, LowByte=63.
10      02/25/06 13:04:34.364           Sending header with Checksum: 69.
10      02/25/06 13:04:34.380           Got response: 69 from CM11A.
10      02/25/06 13:04:34.380           Sending ACK.
10      02/25/06 13:04:34.824           Got response: 55 from CM11A.
10      02/25/06 13:04:34.824           Function sent successfully.
10      02/25/06 13:04:34.824           Sending address with HouseCode=6, DeviceCode=7.
10      02/25/06 13:04:34.824           Sending packet with HighByte=4, LowByte=67.
10      02/25/06 13:04:34.824           Sending header with Checksum: 6b.
10      02/25/06 13:04:34.848           Got response: 6b from CM11A.
10      02/25/06 13:04:34.848           Sending ACK.
10      02/25/06 13:04:35.288           Got response: 55 from CM11A.
10      02/25/06 13:04:35.288           Address sent successfully.
10      02/25/06 13:04:35.288           Sending function with Code: 3.
10      02/25/06 13:04:35.288           Sending packet with HighByte=6, LowByte=63.
10      02/25/06 13:04:35.288           Sending header with Checksum: 69.
10      02/25/06 13:04:35.308           Got response: 69 from CM11A.
10      02/25/06 13:04:35.308           Sending ACK.
10      02/25/06 13:04:35.748           Got response: 55 from CM11A.
10      02/25/06 13:04:35.748           Function sent successfully.


Works fine

---LIGHT CONTROL 'AFTER' RF (MS16A) IS TURNED ON-- SENDING OFF SIGNAL TO BOTH A2 AND A9

10      02/25/06 13:06:02.877           Child device 57 has channel A2.   <--- LM456
10      02/25/06 13:06:02.879           Child device 58 has channel A9.   <--- RR501
10      02/25/06 13:06:02.955           Sending address with HouseCode=6, DeviceCode=14.
10      02/25/06 13:06:02.955           Sending packet with HighByte=4, LowByte=6e.
10      02/25/06 13:06:02.955           Sending header with Checksum: 72.
10      02/25/06 13:06:04.079           Got response: 5a from CM11A.
01      02/25/06 13:06:04.079           Bad checksum received (send:72, recieved:5a).  <------- BUG
10      02/25/06 13:06:04.179           Sending address with HouseCode=6, DeviceCode=14.
10      02/25/06 13:06:04.179           Sending packet with HighByte=4, LowByte=6e.
10      02/25/06 13:06:04.179           Sending header with Checksum: 72.
10      02/25/06 13:06:05.919           Got response: 5a from CM11A.
01      02/25/06 13:06:05.919           Bad checksum received (send:72, recieved:5a).  <------- BUG
10      02/25/06 13:06:06.019           Sending address with HouseCode=6, DeviceCode=14.
10      02/25/06 13:06:06.019           Sending packet with HighByte=4, LowByte=6e.
10      02/25/06 13:06:06.019           Sending header with Checksum: 72.
10      02/25/06 13:06:07.763           Got response: 5a from CM11A.
01      02/25/06 13:06:07.763           Bad checksum received (send:72, recieved:5a).  <------- BUG
10      02/25/06 13:06:07.863           Sending address with HouseCode=6, DeviceCode=14.
10      02/25/06 13:06:07.863           Sending packet with HighByte=4, LowByte=6e.
10      02/25/06 13:06:07.863           Sending header with Checksum: 72.
10      02/25/06 13:06:09.603           Got response: 5a from CM11A.
01      02/25/06 13:06:09.603           Bad checksum received (send:72, recieved:5a).
10      02/25/06 13:06:09.703           Sending address with HouseCode=6, DeviceCode=14.
10      02/25/06 13:06:09.703           Sending packet with HighByte=4, LowByte=6e.
10      02/25/06 13:06:09.703           Sending header with Checksum: 72.
10      02/25/06 13:06:11.447           Got response: 5a from CM11A.
01      02/25/06 13:06:11.448           Bad checksum received (send:72, recieved:5a).
01      02/25/06 13:06:11.547           Failed sending address.
10      02/25/06 13:06:11.548           Sending address with HouseCode=6, DeviceCode=7.
10      02/25/06 13:06:11.548           Sending packet with HighByte=4, LowByte=67.
10      02/25/06 13:06:11.548           Sending header with Checksum: 6b.
10      02/25/06 13:06:13.287           Got response: 5a from CM11A.
01      02/25/06 13:06:13.287           Bad checksum received (send:6b, recieved:5a).
10      02/25/06 13:06:13.387           Sending address with HouseCode=6, DeviceCode=7.
10      02/25/06 13:06:13.387           Sending packet with HighByte=4, LowByte=67.
10      02/25/06 13:06:13.387           Sending header with Checksum: 6b.
10      02/25/06 13:06:15.131           Got response: 5a from CM11A.
01      02/25/06 13:06:15.132           Bad checksum received (send:6b, recieved:5a).
10      02/25/06 13:06:15.231           Sending address with HouseCode=6, DeviceCode=7.
10      02/25/06 13:06:15.231           Sending packet with HighByte=4, LowByte=67.
10      02/25/06 13:06:15.232           Sending header with Checksum: 6b.
10      02/25/06 13:06:16.972           Got response: 5a from CM11A.
01      02/25/06 13:06:16.972           Bad checksum received (send:6b, recieved:5a).
10      02/25/06 13:06:17.071           Sending address with HouseCode=6, DeviceCode=7.
10      02/25/06 13:06:17.072           Sending packet with HighByte=4, LowByte=67.
10      02/25/06 13:06:17.072           Sending header with Checksum: 6b.
10      02/25/06 13:06:18.816           Got response: 5a from CM11A.
01      02/25/06 13:06:18.816           Bad checksum received (send:6b, recieved:5a).
10      02/25/06 13:06:18.916           Sending address with HouseCode=6, DeviceCode=7.
10      02/25/06 13:06:18.916           Sending packet with HighByte=4, LowByte=67.
10      02/25/06 13:06:18.916           Sending header with Checksum: 6b.
10      02/25/06 13:06:20.656           Got response: 5a from CM11A.
01      02/25/06 13:06:20.656           Bad checksum received (send:6b, recieved:5a).
01      02/25/06 13:06:20.756           Failed sending address.                        <------- BUG






-=TESTS DONE=-
After all the tests I made, It seems to be a small glitch in the Pluto code. Let me explain why and what I did:

-HARDWARE VALIDATION

Replaced the RR501 Tranceiver by a TM751 = Didn't help.
Tried from Motion sensor (MS16A) and Remote (UR19A) = Didn't help
Used 3 diffent AC outlets = Didn't help.
Moved Tranceiver's antena in countless ways = Didn't help
I installed PLUTO on a different Computer (diffent tty port) = Didn't help.

-SOFTWARE VALIDATION
I re-installed PLUTO 4 times (2xCORE, 2xHybrid) = Didn't help.
I installed my CM11A on the MD instead of Core = Didn't help.
I installed a third party software (autoM8bit) = Worked fine with all RF devices
I installed a third party software (homeseer)  = Worked fine with all RF devices
(these test also validate my hardware now.)




-=MAYBE THE PROBLEM IS...=-

What the problem seems to be, is that the RF devices seems to "shift, de-phase" the data information in Pluto's buffers.
The data seem to be maybe Shorter or Longuer (bit terms) that what Pluto is expecting when comming from RF devices (input).

What makes me think that: the Checksum errors in the logs, Bad checksum received (send:6b, recieved:5a)
is always the same.  So it's not noise or anything.  It seems to be a protocol bug.  

Also the fact that other software work fine with my hardware and electrical network tells me its only a bad interpretetation from Pluto.
Once the CM11A received a RF signal, the rests of the sequences are all messed up for ever until I unplug and replug
the CM11A.


-=CONCLUSION=-

Sure hope you can help me with that.
I did everything I could to solve this myself (forums, e-mails, tests, troubleshooting docs...).
I love Pluto and I want to use it really bad.  But this problem is stopping me from using it the way I need to.
Please help me.


Thx alot.
If you have any suggestions, or tests you want me to do, pls contact me.

[archived]

We actually never tested CM11A with RF because we don't have any. We even didn't test it with an X10 transmiter (like motion detector) but the code exists and theoretically should work.
So this may be / be not a bug in pluto.
I see the situation you describe a little different:
The part you must look at is

10 02/25/06 13:06:04.079 Got response: 5a from CM11A.
01 02/25/06 13:06:04.079 Bad checksum received (send:72, recieved:5a)

The "0x5A" comming from CM11A is known as "Interface Poll Signal" on which we should respong with "0xC3".
This means that interface is trying to notify us of something. Howether it happend at VERY bad time:
CM11 was waiting for a checksum from command it sent few moments ago. Instead of getting a checksum it's waiting for (0x72) it get's pooling (0x5A), from it's point of view send was unsuccesifull and it retries.

Yes we have to limit this retrying (i'm not sure but i think it's already done), but this is also a misbehavior of CM11+RF.
As far as I know only 1 message should be on powerline on any given moment so it should finish sending one message (transmit, checksum, acknowledge) and only then start doing something else (like pooling).

Cant you test it somehow without triggering pooling while waiting for checksum ?

[archived]

Hi !  
Thx for the reply.

Instead of getting a checksum it's waiting for (0x72) it get's pooling (0x5A), from it's point of view send was unsuccesifull and it retries.

Here's the catch.  Has I said the checksums occur when I plug in a RF device, like a Motion Sensor or a Remote Control.  But what I might have not mentionned on my first post is this:  When I put the motion sensor on, bad checksum starts.  BUT then I take out the batteries, and even then, bad checksum continue, forever.  So Im pretty sure its not Polling from the motion sensor, cause even once its gone, Bad Checksum keep rising.  

I beleive that once my CM11A interface sends data to Pluto on the Serial Port, that some pins on the RS232 interface (DTR, DSR maybe) are set to a value that pluto can't deal with and then misunderstand the rest of the data.

As far as I know only 1 message should be on powerline on any given moment so it should finish sending one message (transmit, checksum, acknowledge) and only then start doing something else (like pooling).  

Thats not a problem with my RR501 RF transmitter, cause thats exactly what he is programmed to do.  He listens before he transmits (compare this to CSMA/CD on ethernet.)  If you guys are willing to work on the problem, I could plug a BOB on the serial port to see if my concerns are real...

Cant you test it somehow without triggering pooling while waiting for checksum ?

I don't really understand what you want me to do?
Can you give me a little more info please.

Thx

[archived]

Sorry but the message before somehow was posted as "guest".

What I was saying is that when CM11 initializes itself it does:
1. show child devices

10 02/25/06 13:06:02.877 Child device 57 has channel A2. <--- LM456
10 02/25/06 13:06:02.879 Child device 58 has channel A9. <--- RR501

2. Trying to send something

10 02/25/06 13:06:02.955 Sending address with HouseCode=6, DeviceCode=14.
10 02/25/06 13:06:02.955 Sending packet with HighByte=4, LowByte=6e.

3. Expecting a checksum as described in http://hypermetrics.com/rubyhacker/x10proto.html

10 02/25/06 13:06:02.955 Sending header with Checksum: 72.

4a. In your first example

10 02/25/06 13:04:33.924 Got response: 72 from CM11A.
10 02/25/06 13:04:33.924 Sending ACK.

4b. Your second example

10 02/25/06 13:06:04.079 Got response: 5a from CM11A.
01 02/25/06 13:06:04.079 Bad checksum received (send:72, recieved:5a).

It doesn't get a checksum for what it sent, and it retries forever (this is the only bug I see)

Now, the response instead of being 0x72 is 0x5A which may be (may be not) an interface pooling message. In this case somebody started transmition before completing previos transmision with checksum and acknowledge (the only "new" device is your RF)

Try to unplug you RF, quick reload router, let it work for few minutes, and only then plug your RF, and see what happends.

[archived]

I use a CM11A with the CM11A driver. I get exactly the same behavior as described here.

The CM11 can send commands and lamps react accordingly.
As soon as I use (even just once) another device than the CM11 to send commands (I have tried with two different types of RF transmitters), pluto becomes unable to send commands and I get

Bad checksum received (send:72, recieved:5a).

It looks to me that the command sent via the RF transmitter is queued in the CM11 interface, and when the pluto driver sends another command later on, it gets the polling message from the CM11 because there is sth still in the queue waiting to be polled by the PC.
I would then guess that the pluto driver interpretes this as a checksum instead of a polling message. Of course I may be completely wrong...

When does the pluto driver poll the interface for incoming X10 events?
I know the CM11 driver isn't supposed to support incoming events (too bad) but wouldn't it be possible to at least flush the CM11 queue before trying to send a command ?

[archived]

Hi,
I will make a review over CM11A source code in the next 2-3 weeks.
I hope I will detect the problems.
Regards,
Eugen