Print

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

[Techowl]

Greetings all.

I have a macro setup that cycles through a set of various type of modules turning them all on in sequence, and a companion macro that turns them all off in sequence.

My problem is that the macros do not execute on time. They occur about 8 minutes after the scheduled time. If the timer is set to occur at a specific hour, say 11:00 PM, it will actually happen at 11:08 PM.

I have checked the CM15A clock and it is synced with the PC time.

I have wiped the CM15A and reloaded the timers and macros, but nothing solves this problem.

It is almost like the random time function is active that makes it look like like someone is home when it's the timer cycling lights etc.

Any help with this would be appreciated.

Thanks,

- Techowl -

[Noam]

Do you have the "security" option checked on those timers?

[Techowl]

No, that was my first thought too, but all timers have that box unchecked.

I noticed the "on" cycle hit 55 minutes early today as well, so something is definitely up with the clock in the interface.

Thanks for the input tho...

- Techowl -

[Noam]

Are you running with the CM15A plugged into the PC, and the PC turned on, or are you disconnecting after uploading your timers to the CM15A?
There were reported issues from the very beginning with the clock being unstable and drifting. Since the CM15A has no real-time clock in it, it relies on the timing of the 60Hz power cycles to keep the clock. If your power is not perfect (and a lot of power here in the US is close, but not perfect), it can cause some drift.
When the CM15A is connected to the PC (and the X10nets service is running), it syncs the clock every two hours, which should be enough to correct for that drift in most cases.

If you ARE keeping it connected, and it is still not working properly, you might try creating a brand-new AHX file (keep the old one as a backup, of course), and see if those timers are off, as well.

[dhouston]

Since the CM15A has no real-time clock in it, it relies on the timing of the 60Hz power cycles to keep the clock. If your power is not perfect (and a lot of power here in the US is close, but not perfect), it can cause some drift.

Are you sure about that? I suspect the Cypress MCU maintains a software based RTC, the accuracy of which depends on its (internal) oscillator. Unless something has changed, there have always been fairly tight tolerances for the powerline frequency and clocks that rely on it are reasonably accurate.

See the Long-term stability and clock synchronization section of...

• http://en.wikipedia.org/wiki/Utility_frequency

[Noam]

Dave -
That was the impression I was under. I never left my CM15A disconnected from the PC, so I never experienced it myself. There are plenty of posts referring to the CM15A's "clock drift" problem.

[dhouston]

Noam,
I don't disagree about the clock drifting but merely about the reason for it. Most software RTCs (especially of that era) are very inaccurate and those that rely on an internal oscillator source are often extremely inaccurate whereas counting rising edges on the ZC pin would be very accurate (with the caveat that anything that disables interrupts could interfere but that's also an issue with a software RTC) plus the CM15A must check for 120kHz at each ZC so counting ZCs is simple. Even crystal controlled hardware RTCs drift and the better ones have calibration registers to counteract the drift. I'm more inclined to blame X10 programmers rather than blame the stability of the 60Hz.

There is a link in the Wikipedia page I referenced earlier to a University of Tennessee project that watches the powerline frequency. Here's a direct link to their Frequency Gradient Map (in realtime) for the US...

• http://fnetpublic.utk.edu/gradientmap.html

[Techowl]

I may have sourced the problem.

Batteries.

Yup, I recalled that as alkaline batteries age, they get noisy. In a flashlight or radio, this is not an issue, but in electronic equipment, it causes erratic behavior. That's why your TV remote does weird things when the cells are getting low.

Anyhoo, I changed the batteries in the CM15A, and the timer hit right on the mark about 9 minutes ago.

The ones I took out still had life left in 'em, so I'll finish them off in a flashlight or other non-critical device.

I'll post again tomorrow with the 24 hour results.

- Techowl -

[Noam]

I may have sourced the problem.
Batteries.
Yup, I recalled that as alkaline batteries age, they get noisy. In a flashlight or radio, this is not an issue, but in electronic equipment, it causes erratic behavior. That's why your TV remote does weird things when the cells are getting low.
Anyhoo, I changed the batteries in the CM15A, and the timer hit right on the mark about 9 minutes ago.
The ones I took out still had life left in 'em, so I'll finish them off in a flashlight or other non-critical device.
I'll post again tomorrow with the 24 hour results.
- Techowl -

I've never heard of that one with the CM15A, but I suppose anything's possible.
It is also possible that the process of changing the batteries reset the CM15A.

[Techowl]

Sorry for the delay in posting the results of the battery change. I have had deal with a lot of weather related issues.

The final result is that the problem disappeared with the new batteries.

Although the software indicated the batteries were good with that little green dot, they were in fact, almost exhausted. They wouldn't light an LED flashlight even dimly.

After I discovered their charge state, I put them back into the CM15A, and the dot went red immediately. The interface must have locked the battery state or something, and then reset it when the fresh cells went in.

Every on/off cycle has hit dead on time since the batteries were changed.

Just goes to show that you need to check the obvious things, even if you think they are correct.

Hopefully this will help someone else out there who experiences this strange behavior.

- Techowl -

[Noam]

I had something similar (some timers didn't run properly), and it turned out to be batteries, as well. In my case, at least one of the batteries was dead enough to start leaking, and I had to clean some corrosion off the contacts before the CM15A would recognize the new batteries.

[Brian H]

OK. Sounds like we have to add, try new batteries, to our list of possible fixes.

[Noam]

OK. Sounds like we have to add, try new batteries, to our list of possible fixes.

Good idea.
We might also want to suggest checking the battery terminals for corrosion when changing batteries, too.