Malformed Packet issues

Forum about PLCBUS devices & software.

Moderator: Digit

Malformed Packet issues

Postby hto » Tue Jan 03, 2012 2:36 pm

Hi All,

My first post here, and I'm a beginner with reference to the PLCBus communication protocol, so please bear with me.

I am attempting to roll a PLCBus controller using ruby (and thus the Ruby SerialPort gem), and I have had some success in being able to control my devices. Where I am having difficulties is with the responses I am getting from the units; I have a 1141+ controller, so I am expecting a 9-byte return packet, with the checksum at the end (as opposed to the 0x03 ETX on other firmwares).

In order to debug, I am running Interceptty on my /dev/ttyUSB0 device, which should be showing me all the packets returned to the serial port by the devices. I believe this to be working, as when I use my PLCBus 4043 UK (a hardware remote) to actuate my devices, I see a return packet as below (example shows unit with address A1 being turned on):

Code: Select all
>    0x02
>    0x06
>    0xa9
>    0x00
>    0x22 (")
>    0x64 (d)
>    0x00
>    0x0c
>    0xbd


As you can see this is a perfectly formed PLCBus frame, with the correct checksum. I get this result consistently every time, so I believe there are no interference issues or otherwise on the power line, and that my adapter is set up correctly.

What I get when I am using Ruby (or indeed the Perl script available in another thread on this forum) are some strangely formed packets, with varying numbers of bytes, and no clearly defined structure (examples below).

Example turning A1 ON with the Perl script (packet sent 02 05 a9 00 22 00 00 03):
Code: Select all
>    0x02
>    0x06
>    0xa9
>    0x00
>    0x22 (")
>    0x64 (d)
>    0x00
>    0x1c
>    0xad
>    0x02
>    0x06
>    0xa9
>    0x00
>    0x22 (")
>    0x64 (d)
>    0x00
>    0x20
>    0xa9


Example turning A2 ON with Perl script (packet sent 02 05 a9 01 22 00 00 03):
Code: Select all
>    0x06
>    0xa9
>    0x01
>    0x22 (")
>    0x64 (d)
>    0x1c
>    0x02
>    0xa9
>    0x01
>    0x64 (d)
>    0x20


As you can see, these packets are clearly malformed, and inconsistent.

Going by the fact that I can see correct frames when the hardware controller is used, I am led to think that there are two possible problems:

- The packet being sent is incorrect (though this seems unlikely as there are no reported issues with the Perl script)
- Writing to the serial port is being done in such a way that it is somehow blocking or garbling the returned packets

So my question is, has anyone else come across this? Can anyone suggest ways that I might be able to more thoroughly debug what is happening (I am unfamiliar with the 1141+ at a debugging level).

For reference, I am using a 1141+ from x10-hk.com, connected to a server running Ubuntu Oneiric Ocelot. I have tried actuating various different modules, including plug-in lamp modules and micro modules in 2-wire and 3-wire modes, to eliminate the possibility of faulty devices.

Many thanks for any assistance!
hto
Starting Member
Starting Member
 
Posts: 8
Joined: January 2012

Re: Malformed Packet issues

Postby Digit » Tue Jan 03, 2012 5:59 pm

I think there has been a topic about this in the Domotiga forum some time ago.
Yep, here it is. viewtopic.php?f=38&t=5735&start=0
I think you can find the answer there.
(hint: the 1141+ works with a checksum)
User avatar
Digit
Global Moderator
Global Moderator
 
Posts: 3388
Joined: March 2006
Location: Netherlands

Re: Malformed Packet issues

Postby hto » Tue Jan 03, 2012 6:20 pm

Hi Digit,

Thanks for your reply - I did have a look at that thread, which was very helpful for determining why I wasn't getting a 0x03 byte at the end of my packets. But that isn't the problem - i know that a 9-byte packet with a checksum at the end that brings the sum of all the bytes to a multiple ox 0x100 is a valid packet (indeed this is the format of the valid frames I am getting in response to the commands sent from the 4034UK).

The problem is that the frames sent by devices in response to packets sent by the 1141+ are not coming out in this format (as per the examples in the original post, the sum of the bytes is not a multiple of 0x100 and does not end with 0x03, so neither formats are valid). The packets sent do, however, actuate the devices correctly, so I believe the problem lies in the handling of the return packet either by my code or the 1141+ so I'm hopeful someone can help me to debug a little better.

Thanks!
hto
Starting Member
Starting Member
 
Posts: 8
Joined: January 2012

Re: Malformed Packet issues

Postby hto » Tue Jan 03, 2012 8:11 pm

Further to my last post, I have realised that my examples may not have been good ones - the checksums actually do cause the packets to sum to a multiple of 0x100 in both cases (both sums are equal to 1024). They are, however, 18 bytes long, and each segment of 9 bytes sums to 512, which makes me believe there are two properly formed (though different) packets here; again, this threw me as I was expecting only 9, since the packet should be sent by the receiving device only once. Have you encountered two separate packets being sent, or is this a case of my debugging picking up the packet that I am sending and then also the received packet?

I think what may have thrown me may be related to another thread that I have just seen, which indicates that the 1141+ behaves strangely when it is used to send a command to an address that does not exist; I had been doing this to test, but restarted the server prior to posting these examples. Previously, the behaviour sounds like it was very similar to what is described in that thread. Was any solution to this found?

Thanks again!
hto
Starting Member
Starting Member
 
Posts: 8
Joined: January 2012

Re: Malformed Packet issues

Postby Digit » Tue Jan 03, 2012 8:29 pm

(I wrote this before I approved and read your last post above)

Your example:
Code: Select all
>    0x02
>    0x06
>    0xa9
>    0x00
>    0x22 (")
>    0x64 (d)
>    0x00
>    0x1c
>    0xad
>    0x02
>    0x06
>    0xa9
>    0x00
>    0x22 (")
>    0x64 (d)
>    0x00
>    0x20
>    0xa9

should be read like this (yep, it's actually 2 responses):

Code: Select all
0x02 0x06 0xa9 0x00 0x22 0x64 0x00 0x1c 0xad
0x02 0x06 0xa9 0x00 0x22 0x64 0x00 0x20 0xa9

Just by looking at the last 2 bytes on each row I immediately 'see' the checksum. I bet both rows add up to 0x200. Try it.

Your 2nd example (A2 ON) is a mess, it doesn't even have the STX. Throw it away, skip it, filter it out, whatever.
Or can you reproduce this one over and over again? In that case, it starts to become interesting and I'd also like to see responses for other addresses 8)
User avatar
Digit
Global Moderator
Global Moderator
 
Posts: 3388
Joined: March 2006
Location: Netherlands

Re: Malformed Packet issues

Postby Digit » Tue Jan 03, 2012 8:42 pm

I think what may have thrown me may be related to another thread that I have just seen, which indicates that the 1141+ behaves strangely when it is used to send a command to an address that does not exist; I had been doing this to test, but restarted the server prior to posting these examples. Previously, the behaviour sounds like it was very similar to what is described in that thread. Was any solution to this found?

I don't know what thread you're referring to. Why not ask your question in that other thread?
User avatar
Digit
Global Moderator
Global Moderator
 
Posts: 3388
Joined: March 2006
Location: Netherlands

Re: Malformed Packet issues

Postby hto » Tue Jan 03, 2012 9:20 pm

Interestingly, I seem to be getting some repetition in the responses. Here are some examples, all with an identical packet sent by the 1141+ (A2 On, 02 05 a9 01 22 00 00 03):

Code: Select all
>    0x06
>    0xa9
>    0x01
>    0x22 (")
>    0x64 (d)
>    0x00
>    0xac
>    0x06
>    0xa9
>    0x22 (")
>    0x00
>    0xa8


Code: Select all
>    0x02
>    0x06
>    0xa9
>    0x01
>    0x22 (")
>    0x00
>    0x1c
>    0x02
>    0xa9
>    0x01
>    0x64 (d)
>    0x20
>    0xa8


Code: Select all
>    0x06
>    0xa9
>    0x01
>    0x22 (")
>    0x64 (d)
>    0x1c
>    0x06
>    0xa9
>    0x22 (")
>    0x64 (d)
>    0x20


Code: Select all
>    0x06
>    0xa9
>    0x01
>    0x64 (d)
>    0x1c
>    0xac
>    0x06
>    0x01
>    0x64 (d)
>    0x00
>    0xa8


Code: Select all
>    0x06
>    0xa9
>    0x01
>    0x22 (")
>    0x00
>    0xac
>    0x02
>    0xa9
>    0x22 (")
>    0x00
>    0xa8


As a control, below is the packet received without modifying anything, but sending the on signal from the 4034UK. It appears to be correctly formed, with a valid checksum:

Code: Select all
>    0x02
>    0x06
>    0xa9
>    0x01
>    0x22 (")
>    0x64 (d)
>    0x00
>    0x0c
>    0xbc


I have posted these in order, and did not modify any settings between each on signal being sent (no local adjustments to the modules either). You will notice that they are all malformed, thought there seems to be some consistency (most of them start with 0x06 instead of the 0x02 STX). Interestingly, having done this experiment with the A2 module, I tried the A1 module again, and here is what I got:

Code: Select all
>    0x02
>    0x02
>    0xa9
>    0x22 (")
>    0x64 (d)
>    0x1c
>    0x06
>    0xa9
>    0x22 (")
>    0x64 (d)
>    0x20


Another invalid frame, where before I was getting good frames from A1.

I tried unplugging the 1141+ from the server, as the thread that referred to malformed packets previously indicated that resolved the issue. Tried A1 ON again, and another malformed packet:

Code: Select all
>    0x06
>    0xa9
>    0x22 (")
>    0x64 (d)
>    0x1c
>    0x02
>    0xa9
>    0x22 (")
>    0x64 (d)
>    0x20


You mentioned that you would like to see some responses from other addresses, so I have pasted below the responses received from a module at P1, which is a micro module hard-wired into some halogen lights (modules with Ax addresses are plug-in modules):

P1 ON:
Code: Select all
>    0x06
>    0xa9
>    0xf0
>    0x22 (")
>    0x64 (d)
>    0x1c
>    0x02
>    0xa9
>    0x22 (")
>    0x64 (d)
>    0x20


Code: Select all
>    0x02
>    0xf0
>    0x22 (")
>    0x00
>    0xbd
>    0x02
>    0xa9
>    0xf0
>    0x22 (")
>    0x64 (d)
>    0x00
>    0xb9


Again some malformed packets, one with 10 bytes, one with 11 bytes. As a control, below is the response when using the hardware controller, which looks good:

Code: Select all
>    0x02
>    0x06
>    0xa9
>    0xf0
>    0x22 (")
>    0x64 (d)
>    0x00
>    0x0c
>    0xcd


Apologies for the very long post, but I am keen to provide as much info as possible, which will hopefully allow someone to assist me (which may also benefit anyone else who comes across this). Once I get this kink worked out and get my Ruby code finished, I look forward to repaying the useful help with some useful code!
hto
Starting Member
Starting Member
 
Posts: 8
Joined: January 2012

Re: Malformed Packet issues

Postby hto » Tue Jan 03, 2012 9:28 pm

The thread I was referring to is entitled "Plcbus 1141 ACK bug" but since my last round of testing, it is clear that the issue described is a different one (in that issue, the malformed packets were only received after a command was sent to an address that does not exist, and could be corrected by unplugging and re-plugging the 1141, but that is not the case here (and I have been very careful not to send packets to non-existent addresses while testing)).
hto
Starting Member
Starting Member
 
Posts: 8
Joined: January 2012

Re: Malformed Packet issues

Postby hto » Sun Jan 08, 2012 9:05 pm

I'm pretty stumped by this issue - particularly as I have started getting perfectly formed packets every time from the 1141+. The only thing that has changed in my house from the point where I was getting malformed packets is that my wife has taken down the Christmas decorations, though I have so far been unable to reproduce the issue by plugging them back in individually (though I was not able to plug the pre-lit tree back in as it was back in the attic before I realised).

Nonetheless, since I am now able to use the system, I have put together a first draft of my Ruby script, which can be found at https://github.com/htowens/PLCBus-Ruby - contributions, feature requests, and branches are welcome.

I have sought to create a slightly simpler solution than the existing perl script, in that it is not necessary to run the script in background and connect using netcat - it is possible to simply specify the command to send to the units on the command line (e.g.
Code: Select all
ruby plcbus.rb --device A1 --command ON
).
hto
Starting Member
Starting Member
 
Posts: 8
Joined: January 2012


Return to PLCBUS Forum

Who is online

Users browsing this forum: No registered users and 1 guest