Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[bkenobi]

This is a request for other people's experiences of actual X10 module actuation times.  I have a light that is controlled by both a motion sensor and a ToggleLinc switch (sending an X10 on/off command).  What I'm trying to do is switch to a different setup using a Raspberry Pi instead of a Windows XP server.  When I use the AHP SDK and a custom AutoHotKey script, the switch will turn on/off the light in approx 1.5 seconds.  I have tried using Mochad and it will toggle the light in just shy of 2 seconds.  A 3rd method (my intended approach) uses HomeGenie and a C# script and takes 2.8 to 3.5 seconds.  The issue is obvious...3.5 seconds results in a very low WAF.

What I was hoping is for some people to try a simple test to see how long it takes on their setup.  The requirements for this would be:

• CM15A
• X10 controller (RF or PLC of any kind)
• One X10 module (preferably relay based)
• Stop watch (phone will work)

The test basically can be run using whatever code you run (AHP, Homeseer, MisterHouse, Heyu, etc).  Configure your setup such that you have it look for one X10 command and then send out an on/off for the test module.  In my case, I have the switch set to B6 and the light to A6.  When "B6 ON" is received, the code sends "A6 ON" and the reverse for off commands.

[dhouston]

I doubt you will improve on the 1.5 sec. It takes nearly that long for the B6 ON & A6 ON to traverse the powerline.

[bkenobi]

I don't doubt that.  It takes fractions of a second to transmit a command, but in reality 1 command per second is about all I've been able to use consistently.  I'm OK with 1.5-2 seconds for the light to turn on.  I'm not OK with 3.5 seconds.  This thread was posted with the hopes to see what a realistic time is for AHP versus non-AHP.

[dhouston]

I suspect most of the delay with the other methods is in the time they take to implement your code. That will vary with each hardware/firmware/software combination. If they are interfacing with the CM15A, the delay could come with their particular USB implementation.

[dhouston]

You are receiving B6:B_ON and sending A6:A_ON. Given that each code is sent twice and each doublet must be followed by 3 silent cycles, B6:B_ON uses 50 cycles of the powerline. A6:A_ON requires the same amount of time but most X10 receivers will react to the first copy of the function code which would be 36 powerline cycles. So, the minimum time will be 1.43 seconds (86 cycles) and this is without any time allowed for the CM15A to react to B6:B_ON and send A6:A_ON.

• http://digilander.libero.it/cvolpato/elettronica/X-10_Transmission_Theory.htm

Obviously, the fastest implementation would be if the macro can be loaded to the CM15A eliminating any delay caused by external hardware/firmware/software. Having never used X10 AHP software, I don't know whether this is a possibility.

[bkenobi]

I didn't do the calculations myself, so this is very useful.  I think it shows that the AHP SDK is pretty well optimized since my AHK script solution runs in effectively the minimum time.  I am timing this with a stop watch, so if I see 1.5s then I'm probably at least a tenth of a second slow.

Do you really think USB drivers could cause that big of a difference in speed?  Mochad uses the libusb-1.0.0 development drivers.  I don't know a lot about Linux, but I know that these are not part of the Kernel.  As such, I'm sure they run somewhat slower than if they were built right into the core of the OS.

I don't think that's what is slowing HG down though since I tried it on both Linux and Windows and they seem the same speed.  HG is written in C#, but I'm not sure how the USB is implemented.  Perhaps it's a higher level code that gets interpreted somehow.  I guess I'll have to ask the author.

Btw, the attached file is what I was using to test Mochad.  It's really simple to use, but it doesn't output anything finer than seconds.  If it could go to milliseconds, I could use it's log instead of a stopwatch.

[dhouston]

I really do not know enough about Linux, C#, etc. so I'm guessing a bit that it's the additional overhead of the various systems that are creating the delays. Here's a quote from the wikipedia entry for C#...

Although C# applications are intended to be economical with regard to memory and processing power requirements, the language was not intended to compete directly on performance and size with C or assembly language.

My programming, whether for Windows, Linux, OSX, Android, iOS  or embedded (PIC, Atmel) has always used various versions of Basic (PureBasic, ZBasic, PicBasicPro, Basic4android, etc.) that compile to either C or Assembly which are usually competitive in both size and speed with more advanced languages used by professional programmers. And, after reading Jan Axelson's excellent books on USB and Embedded USB programming, I have tried to avoid dealing with the complexity of USB by opting for USB-Serial converter chips wherever possible.

In my own efforts, I've tried to get as close to the powerline as possible to get around X10's censorship (i.e. only reporting valid X10 codes) and the delayed reports.  I designed a daughterboard that replaced the microcontroller in the RR501 turning it into a CM15A-like interface but with a serial port which reported all activity. And, I designed a daughterboard using an LM567 tone decoder that could be added to a PL513, turning it into a two-way TTL interface that reported all activity in realtime. Unfortunately my health and X10's health put an end to my projects and to the RR501 and PL513.

[JeffVolp]

In my own efforts, I've tried to get as close to the powerline as possible to get around X10's censorship (i.e. only reporting valid X10 codes) and the delayed reports.  I designed a daughterboard that replaced the microcontroller in the RR501 turning it into a CM15A-like interface but with a serial port which reported all activity. And, I designed a daughterboard using an LM567 tone decoder that could be added to a PL513, turning it into a two-way TTL interface that reported all activity in realtime.

Both the XTB-523 and XTB-IIR digital ports include a mode to pass all bits received real-time with no error checking.  Each bit is output for the full half-cycle, which makes this a good tool for analyzing powerline traffic on a digital scope.

Jeff

[dhouston]

I don't think that's what is slowing HG down though since I tried it on both Linux and Windows and they seem the same speed.  HG is written in C#, but I'm not sure how the USB is implemented.  Perhaps it's a higher level code that gets interpreted somehow.

This is pure speculation since my knowledge of low level Linux is limited but there is a Virtual Port driver called socat which has both Linux and Windows versions. It simplifies programming by letting you address a USB device or TCP/IP device (or ??) as though it were a serial port. I found one discussion where someone was using it (under Linux) as he developed his (medical device) application but was seeking advice on other methods for his final version as socat introduced what were unacceptable delays for his application.

[bkenobi]

I asked the author and it turns out that both the Windows and Linux versions use the same driver.  I looked around and there are both libusb-win32 and a 64-bit version available from the same code base as the Linux driver.  Perhaps this could be slow, but I'm not sure it could be THAT slow since Mochad is using the same driver.  It's got to be something with the implementation within the HA software.