CTX35 and PMIX35 bugs
-
- Advanced Member
- Posts: 640
- Joined: Sun Apr 30, 2006 5:31 pm
- Location: Netherlands
- Contact:
CTX35 and PMIX35 bugs
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.
CTX35 and PMIX35 bugs
Is your driver working already ?
I'm trying to communicate with the PMIX35 with Hyperteriminal, I'm sending $>9000pxcs# But I'dont get a reply. any idee ?
I'm trying to communicate with the PMIX35 with Hyperteriminal, I'm sending $>9000pxcs# But I'dont get a reply. any idee ?
CTX35 and PMIX35 bugs
Have you turned on the "local echo" so you can see what you type?
You need to send capital letters; also instead of "cs" you have to send the checksum as calculated. So you should type
You need to send capital letters; also instead of "cs" you have to send the checksum as calculated. So you should type
Code: Select all
$>9000PXD3#
-
- Advanced Member
- Posts: 640
- Joined: Sun Apr 30, 2006 5:31 pm
- Location: Netherlands
- Contact:
CTX35 and PMIX35 bugs
It's a daemon, but yes, it's working. I have also written a similar daemon for the CM11 interface with a compatible software-interface.
Now I'm working on a Linux X10 implementation, which will be capable of handling multiple interfaces at a time, allowing you to selectively route traffic between them. This will enable you to use it as an advanced phase-coupler that can be configured to share common addresses and keep local addresses apart.
On top of that, I will write a device manager that keeps track of all addresses statuses to make them instantly available to software. I'm also planning to built in periodic validation that polls addresses to see if their their status is still in line with what's in memory. I will also add the possibility to have a status verified briefly after is has been changed, to make sure the request has been executed.
You're more than welcome to join me. But please keep in mind that it's all programmed in ANSI C, 1TBL Linux style, running on Linux. I can make all X10 device addresses available on a named pipe, or a socket if you prefer, but after that I'm a bit lost: I have no experience in getting this information into a database and publishing it on an Apache server...
Now I'm working on a Linux X10 implementation, which will be capable of handling multiple interfaces at a time, allowing you to selectively route traffic between them. This will enable you to use it as an advanced phase-coupler that can be configured to share common addresses and keep local addresses apart.
On top of that, I will write a device manager that keeps track of all addresses statuses to make them instantly available to software. I'm also planning to built in periodic validation that polls addresses to see if their their status is still in line with what's in memory. I will also add the possibility to have a status verified briefly after is has been changed, to make sure the request has been executed.
You're more than welcome to join me. But please keep in mind that it's all programmed in ANSI C, 1TBL Linux style, running on Linux. I can make all X10 device addresses available on a named pipe, or a socket if you prefer, but after that I'm a bit lost: I have no experience in getting this information into a database and publishing it on an Apache server...
CTX35 and PMIX35 bugs
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote"><i>Originally posted by JeroenE</i>
<br />Have you turned on the "local echo" so you can see what you type?
You need to send capital letters; also instead of "cs" you have to send the checksum as calculated. So you should type
<hr height="1" noshade id="quote"></font id="quote"></blockquote id="quote">I have tried to send it but i'dont get response. "Local echo" is on
<br />Have you turned on the "local echo" so you can see what you type?
You need to send capital letters; also instead of "cs" you have to send the checksum as calculated. So you should type
Code: Select all
$>9000PXD3#
CTX35 and PMIX35 bugs
MindBender is your daemon public ? Maybe I can use it.
-
- Advanced Member
- Posts: 640
- Joined: Sun Apr 30, 2006 5:31 pm
- Location: Netherlands
- Contact:
CTX35 and PMIX35 bugs
I will make it public as soon as it is fully functional. If you would like to co-develop, you can contact me off-line.
CTX35 and PMIX35 bugs
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote">I have tried to send it but i'dont get response. "Local echo" is on<hr height="1" noshade id="quote"></font id="quote"></blockquote id="quote">Did you try with all the settings as shown in the manual? I suspect that the flow control setting is not correct. You should set this to "none". As this is not the default setting this is often not in the right state for communicating with the PMIX.
-
- Advanced Member
- Posts: 640
- Joined: Sun Apr 30, 2006 5:31 pm
- Location: Netherlands
- Contact:
CTX35 and PMIX35 bugs
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote"><i>Originally posted by Lempens</i>
<br />I'm trying to communicate with the PMIX35 with Hyperteriminal, I'm sending $>9000pxcs# But I'dont get a reply. any idee ?
<hr height="1" noshade id="quote"></font id="quote"></blockquote id="quote">
Dude; This is clearly not a bug. I would appreciate it if you'd start your own thread on your communication problems.
And as a possible solution: You may need a fully wired cable (instead of just Rx, Tx and Gnd) and appropriate handshaking settings (Hardware RTS/CTS). When in doubt, verify if the Xanura analyzer application <i>is</i> able to communicate through the cable you're using. To find out the serial port settings you could use HDD Free Serial Port Monitor.
<br />I'm trying to communicate with the PMIX35 with Hyperteriminal, I'm sending $>9000pxcs# But I'dont get a reply. any idee ?
<hr height="1" noshade id="quote"></font id="quote"></blockquote id="quote">
Dude; This is clearly not a bug. I would appreciate it if you'd start your own thread on your communication problems.
And as a possible solution: You may need a fully wired cable (instead of just Rx, Tx and Gnd) and appropriate handshaking settings (Hardware RTS/CTS). When in doubt, verify if the Xanura analyzer application <i>is</i> able to communicate through the cable you're using. To find out the serial port settings you could use HDD Free Serial Port Monitor.
CTX35 and PMIX35 bugs
It's already working. I needed to calculated the checksum, en disable the hardware control.