CTX35 and PMIX35 bugs
Posted: Fri Aug 08, 2008 9:13 am
This thread is only interesting to those of use who are writing their own application/driver to handle the CTX35 or PMIX35 X10 interface box. Since the ACT X10 interfaces share the same protocol, those may be involved too.
When writing my own daemon to handle my PMIX35 interface, I have found a couple of bugs in how it handles the protocol. They are probably just flaws introduced by sloppiness, but some seem to be 'by design' and are harder to take into account.
<ul><li>The interface has a limited buffer to hold messages in between polls, but also when the computer is switched off. This buffer is NOT a circular buffer, as one might expect: When it's full, no new events are added, and hence it always contains the <i>first</i>events since polling was stopped, not the <i>last</i> events before polling was resumed as desirable</li>
<li>The interface inserts white spaces in between non-consecutively received data. Unfortunately these are NOT attached at the end of received data, but at the beginning of new data. This way you always need to wait for the next data to decide whether it was consecutive or not. It would make much more sense if the interface would wait for one bit-time after receiving data to determine if any consecutive data is following and attach a space if this is not the case. As an alternative it could even reply a single white space to indicate a non-consecutive occurrence. But as it is currently implemented we need to wait for a whole new data packet, or the lack of, to determine this.</li>
<li> Some PMIX35 commands offer both mandatory and optional replies. Unfortunately the unit does not inform the driver that it has finished replying. If only a mandatory reply is given, the driver can only determine no optional reply is given by time-out. It would have been nice if the unit would have send an ACK for this to minimize the waiting.</li></ul>
Please report the problems you have found here.
When writing my own daemon to handle my PMIX35 interface, I have found a couple of bugs in how it handles the protocol. They are probably just flaws introduced by sloppiness, but some seem to be 'by design' and are harder to take into account.
<ul><li>The interface has a limited buffer to hold messages in between polls, but also when the computer is switched off. This buffer is NOT a circular buffer, as one might expect: When it's full, no new events are added, and hence it always contains the <i>first</i>events since polling was stopped, not the <i>last</i> events before polling was resumed as desirable</li>
<li>The interface inserts white spaces in between non-consecutively received data. Unfortunately these are NOT attached at the end of received data, but at the beginning of new data. This way you always need to wait for the next data to decide whether it was consecutive or not. It would make much more sense if the interface would wait for one bit-time after receiving data to determine if any consecutive data is following and attach a space if this is not the case. As an alternative it could even reply a single white space to indicate a non-consecutive occurrence. But as it is currently implemented we need to wait for a whole new data packet, or the lack of, to determine this.</li>
<li> Some PMIX35 commands offer both mandatory and optional replies. Unfortunately the unit does not inform the driver that it has finished replying. If only a mandatory reply is given, the driver can only determine no optional reply is given by time-out. It would have been nice if the unit would have send an ACK for this to minimize the waiting.</li></ul>
Please report the problems you have found here.