Powerlinc 1132 time accuracy resolution

[SmarthomeJohn]

It varies +- 2 seconds randomly it seems during the day.....Its a very small and insignificant amount but I do not understand what is going on. ?

I agree that plus or minus two seconds is pretty insignifant. What happens in the PLC is that at the top of every minute, it "runs through" the programming code to "see" if anything needs to be done, like sending a command. Depending on the if-then and all that other programming stuff, the time it takes to run the program could vary slightly resulting in the few seconds difference you are noticeing.

Also, the interface will first "look" for traffic on the powerline before transmitting. If their are signals or noise, the PLC will hold the transmission until the line clears. In some cases, this could contribute to delays, but the first expalination above it more likely.




WHERE does it get its time reference between RTC updates ?
The interface will transfer of the time from the RTC to the processor clock at 12:01 or 12:02 (something like that) daily so that the time in the processor is (hopefully) more accurate.



SJ

 

[SmarthomeJohn]

Its possible that the micro maintains a clock by counting zero crossings of the powerline since it has to monitor them anyway. I don't know enough about it to say whether it would be a reliable or preferred method.

This is correct. The processor uses the zero crossing detection circuit to help maintain the time between updates from the RTC.

 

[Xymox]

Interesting. I love a company that is just flat open and provides deep info.

I need to go edit my first post and remove my "not they they care" comment.

THANX John !

So, it uses zero crossings to keep time between RTC updates. I have charted the 60hz powerline accuracy and it seems amazingly accurate and I can't yet see the variation of the PLC matching the power line freq. I will continue to do so and see if this accounts for the variation during the times between RTC updates. It could well be as the freq devations on a power line are tiny and long term adjusted by the power company.

If some really nasty power line noise comes along at say 500hz could it count all those zero crossings as well ? A really good burst of very nasty crud could make the time go forward. If that happened a bunch of times a day, say with the air conditioning compressor, then the number of times it cycled would be related to the time shift.

How narrow is the passband for the 60hz zero crossing detector ? Is it just wideband ?

OoOo that might be a whole different mod I could do I like mods Having a very accurate Zero Crossing detector could benifit many aspects of the PLC. However this mod might become complex and expensive real quick.

So that also implies that the clock for the PIC is derived from the power line ? Interesting... It would be good to filter the 60hz very carefully. Clocking the chip too fast because of zero crossing detection of 500hz could cause all sorts of weirdness.

OR is the PIC clocking at some high freq and only the time function is derived from the zero crossing ?

Again,,,

After replacing the xtal with the DS32Khz I am extremely happy. Perfect operation.

I also have extensive experence with Crestron and for less then $100 this programable controller is amazing in what it can do. As I have used X-10 for, hmmmm, 21 years now ? I know how to deploy it and I never have any issues. So I consider it quite reliable.

This problem I had was more a fun exploration of a hobby. Like a puzzle. It took me a little bit to figure it out, but I got it Frankly I enjoyed the problem

Im very happy with my smarthome / X-10 stuff. I still have some stuff from when X-10 first shipped a few decades ago - and it still works ! I have some stuff from Radio Shack and Sears. YES Sears sold X-10, back in the day....


Excellent Smarthome support. I am impressed. Normaly with all other electronics companies getting to anyone with engineering experence in the product is impossible.

 

[Xymox]

New update...

After looking thru my logs of a week of once an hour timestamps I noticed some interesting and new things.

1. My PLC time between RTC updates always drifts 7 seconds fast a day or about 1/4 second an hour. This is of course insignificant. It is interesting tho because its always this much and its always fast. It's also meaningless long term as the RTC corrects the time once a day at approx midnight. It is still interesting as my logging of the power line freq shows it is 100% not fast and does not match the drift I see- so its not power line freq drift based on the zero crossing detection. So this fixed slowly gaining offset is kinda unexplained and might be a source of issues in other installations, possibly.

My DS32Khz based RTC is still less then a second off now in 10 days so at midnight my PLC goes back to exactly correct every day.

2. When my PLC does a operation based on sunrise/sunset my PLC will almost regain correct time. If its off by 7 seconds before the astronomical sunrise/sunset operation it will be almost correct again following the operation. usually off by exactly 2 seconds fast.

No other operations seem to effect the timing.

This might help some people if the RTC is mostly correct but the PLC time is getting wacky. Issue sunrise/sunset command and this should keep the PLC far more in tune to the RTC time giving 2 additional updates per day. I will be testing this and reporting if this works. So, create a sunrise/sunset and the PLC will update to the RTC time +2 seconds. Or so it seems. I will report if this works. So far I can see that it did for a week of updates.

___________________________________________________

A software update for the 1132CU that might catch all sorts of things before they become worse would be to check on the RTC far more often then once a day. Once a hour or every 6 hours might help a lot of people already in the field - IF the PLC is firmware updatable. Even if its not, this could be done in production.

This could catch all sorts of issues - known and unknown. If the PLC zero crossing gets the time all wacked out it will only be wacky until the next RTC update. -ASSUMING- the RTC is correct. At the very least it will lessen the time offset at midnight if the PLC is updated way more often.

I'm talking about the production 1132CU where the RTC is gonna drift some and the correction at midnight might be significant.

Having the PLC update from the RTC should not consume much in terms of CPU resources and could help keep things correct for many people. If it does consume resources then maybe this is not a good idea.

Maybe you could make it a configurable option "RTC update interval"

Even if the RTC is drifting a lot its still better to update more frequently to avoid a large offset at midnight I would think.

________________________________________________

You know,,,, I think I deserve something fun for my work on this issue. I never sent my 1132CU in, I required no support - ever. I think Smarthome could do something for me. I would really like a 2-way lamp module. Non-subtle hint.

Of course you guys may also wanna shoot me too. Yea, I guess you might, I did pinpoint a serious issue. Oops. There goes my lamp module.

Maybe you have beta testers ?. I could do that. You can get my contact info from my personal Website under contact me.

 

[Xymox]

So the update time is clearly 12:02AM. Also a new problem has appeared.

The offset below I created. So the PLC is behind because I created it. Normally its fast.

These are from my Smarthome logs - my computer time is accurate to .07 seconds according to Tardis and I update once every 15 minutes. So the logging is not off by more then .07 seconds assuming the logging does not take time - which it does. I'm sure its accurate to a .25 second in logging however.

My command is at 11:58
R: O1 - 11:57:55 PM
R: OOn - 11:57:56 PM
Offset -5 sec

programmed event 11:59pm
R: O1 - 11:58:55 PM
R: OOn - 11:58:56 PM
Offset -5 sec

programmed event 12:00am
R: O1 - 11:59:56 PM
R: OOn - 11:59:57 PM
Offset -4

programmed event 12:01am
R: O1 - 12:00:55 AM
R: OOn - 12:00:56 AM
Offset -5

programmed event 12:02am
R: O1 - 12:01:55 AM
R: OOn - 12:01:56 AM
R: O1 - 12:02:00 AM
R: OOn - 12:02:01 AM
Offset 0

Yes it did the command TWICE because of the RTC offset and update.

programmed event 12:03am
R: O1 - 12:03:00 AM
R: OOn - 12:03:00 AM
Offset 0
_______________________________

The repeated command at 12:02 is another serious issue connected to offset and updating the PLC from the RTC. The offset between the PLC and RTC at update REALLY needs to stay small as command repeats will occur. I suppose its also possible to miss commands as well. This is actually a real issue. A issue for everyone in fact. I suppose the best solution is to avoid timed events between 11:55pm and 12:05am. So as long as your PLC is not off by more then +-5 minutes ( huge and almost impossible amount in one day ) the RTC update will not loose or repeat commands. This might be a good argument for not updating the PLC often.

This will also occur I would think around a sunrise/sunset command as this command seems to update the PLC clock from the RTC clock. Not the commands issued by the sunrise/sunset trigger but if you have timed events that happen to fall during a sunrise/sunset event. I would think these commands might get lost or duplicated because of the update.

This 2 clock system with the PLC and RTC updates will loose or repeat commands around the update time. I can't think of any way around this in this case except for more precision in the clock updates so it never steps the clock more then 1 second. Actually I suppose any update at all where a "stepped clock" occurs will produce this result. ANY update that backs up or steps forward the minute will cause a trigger, or a lack of trigger, of a programmed command.

Maybe this is why the RTC update is 12:02 rather then 12:00. People will prob schedule things at 12:00 and those commands could get repeated or lost. 12:02 on the other hand is a much safer bet as few people would schedule at 12:02.

The sunrise/sunset thing is more difficult as it varies fairly widely daily and moves in time. If you have a timed event at the same minute as the sunset/sunrise and the PLC updates then,,, you got good odds of loosing or repeating a command.

I suppose the BEST solution would be a user controlled RTC update command that can be scheduled at any time. That way the user can set the update to not interfere with the program. This would be cool as you could also schedule it as often as you like as well. This is fine for the 12:02 thing, but is no help with the sunset/sunrise conflict issue.

However its really correct to spell it out and put it in the manual that you cannot schedule things close to the current 12:02am as these commands could be repeated or lost. This needs to be covered in the manual even with a new "scheduled RTC update" command. The Sunrise/Sunset thing is harder to cover.

Please excuse me in advance if some of this is already in a FAQ or in the manual.

 

[Xymox]

After examining stuff that occured overnight, im not sure the Sunset/sunrise updates the PLC time. There is a offset - but its not consistant.

 

[Xymox]

So far today I have a lot of drift. Just when i said it was always 7 seconds too..

Its gaining almost a second a hour right now. Sunrise did not effect it at all. I know sunset does - so maybe its only the sunset command that causes the PLC to be updated ?

R: O1 - 12:02:00 AM
R: OOn - 12:02:01 AM
R: O1 - 12:03:00 AM
R: OOn - 12:03:00 AM
R: O1 - 12:59:57 AM <<-- interesting backward drift.
R: OOn - 12:59:58 AM
R: O1 - 2:00:01 AM
R: OOn - 2:00:02 AM
R: O1 - 3:00:01 AM
R: OOn - 3:00:02 AM
R: O1 - 4:00:02 AM
R: OOn - 4:00:03 AM
R: O1 - 5:00:03 AM
R: OOn - 5:00:04 AM
R: D5 - 5:22:04 AM <<-- sunrise
R: DOff - 5:22:04 AM <<-- sunrise
R: O1 - 6:00:04 AM
R: OOn - 6:00:04 AM
R: O1 - 7:00:05 AM
R: OOn - 7:00:06 AM
R: O1 - 8:00:07 AM
R: OOn - 8:00:08 AM
R: O1 - 9:00:06 AM
R: OOn - 9:00:07 AM
R: O1 - 10:00:09 AM
R: OOn - 10:00:10 AM
R: O1 - 11:00:09 AM
R: OOn - 11:00:10 AM
R: O1 - 11:58:10 AM
R: OOn - 11:58:11 AM
R: O1 - 1:00:10 PM
R: OOn - 1:00:10 PM


Power line freq has varied in only small amounts both above and below 60hz during this time.

I did lower my thermostat from 73 to 71 last night so the temp for the module was 2 degrees lower then the last week.

My computer time updates via Tardis logging show no more then a .08 sec correction during the entire time above which was done by adjusting the clock freq rather then stepping the clock.

There was no additional commands or program changes to the PLC. It did nothing different then in the previous week.

So as far as I can tell it looks like the temp change effected the time keeping of the PLC. It might also be that the AC cycling more times may have added time via power line noise being coupled into the PLC somehow.

If the drift continues I will be off by 30 seconds at midnight when it will correct itself via the RTC update. This is actually a significate amount. Maybe it could be a lot more under some conditions for some people.

Im gonna get out a hair dryer and heat up the module and see what happens. Maybe place a incandescent light close to the module to heat it up for hours. Maybe put the module in the freezer - connected to line power - and see what happens.

Yea im gonna go drop the module into the freezer. Connected to power and the laptop. If its gonna drift with temp I will know shortly.

 

[Xymox]

Wow.. Interesting...

DO NOT TRY THIS AT HOME

A dead module could result.

I have frozen my share of electronics before. Its a great test. IF the device survives.

So I froze the PLC to -22C while it was running. The parts are all rated to 0C so this test was below the specs for the parts. It reached -22C from room temp in 7 minutes.

Usually this test finds loose solder joints and bad parts because of thermal shock - but not in this case. So far so good.

I warmed up the module - Over about 10 seconds. I used a hair dryer to do it quickly. I decided to thermally shock the unit and see what happened. I did the warm up with the top cover removed and heated the parts directly and quickly.

No prob. This indicates a well made product. No solder joint issues and the expansion and contraction of the parts caused by thermal shock did not cause issues.

I then froze it again.

YES I kept the condensation low. I live in Arizona and the humidity today is 7%. We don't get condensation on pop cans when the humidity is low like this for example.

Keep in mind this is outside of the modules temp range - I assume. The chips I see are 0C to 40C parts. However I could see a normal consumer placing the PLC in a garage and in the winter it could well drop to the temp I just tested or below. So this is a legitimate test. I could not find any temp ranges in the manual.

I wonder what the rated temp range is for the 1132CU ?? Its not online or in the manual.

So far with only a hour under my belt at -22C the PLC time looks as accurate as its been. But we will know more after 6 hours. If no variation from what i have seen occurs we can rule out ANY temp variations as the issue, we can also rule out any unseen oscillators causing issues as they would clearly change freq. It would imply the variation I have been seeing is related to the power line zero crossing detection and because its always fast would tend to indicate that the zero crossing detector is picking up more then the 60hz.

I could confirm this by super filtering the 60hz coming in, which would block the X-10 carrier of course, but should eliminate the fast running clock.

So a observation.... A good test for the module in final QC might be borrowed from the military, temp cycling at the devices temp extremes. This usually finds bad parts - bad solder joints, bad PC board issues and vastly increases confidence in the unit working longer term. IE MTTF and MTBF.

People like Rainbird and the sprinkler controller people all do environmental final testing and use industrial grade parts. So their products are -40C to +85C in part specs.

As its working I will leave it in there for as long as is practical. Its a funny sight having all these wires coming out of the fridge and a laptop on the fridge.

I will also test it at its +40C range, but I want to see at least 6hrs of data at -22C first.

 

[Xymox]

Many hours later, at a frozen solid -22C the PLC is not keeping time any differently. It seems to be very close to where I was before. I am gonna let it run overnight frozen and see if anything is different.

So temp MAKES NO DIFFERENCE.

Also, im running through a cheap 50 foot extension cord and a filtered power strip and plugged into a different phase and outlet then it was before.

I think its still gaining time. BUT I need more hours to determine completely.

Maybe it is the power line freq deviation. This is killer hard to measure. I have good test equipment and I only have 3 digits of accuracy at 60hz. The AVG has always been 60.000. I will see if I can measure this any more accurately.

I suppose the deviation might yet be the power line.

So I think its safe to say that the 1132CU is stable at -22C while operating. The normal Xtal based module will be off time wise at the 12:02 RTC update as the RTC will drift because of the cold. Im gonna see if mine drifts at all - it may not.

The 1132CU is impressive as it did not succumb to my torture.

 

[Xymox]

I ran the 1132CU for 24hrs frozen at a avg of -25C and did logs.

Perfect operation.

While it varied around -2 to +4 seconds It did recover and did not gain or loose time for the 24 hr period. so it drifted around but returned to the correct time. This variation -did- match the power line variation. Quite closely.

My RTC time did not vary at all - even at -25C for the 24hr period. As expected as -25C is within the DS32Khz's normal operating range.

So it appears the forward drift I mentioned in previous posts was gone.

This did not have to do with the cold. I think this was because I was filtering the power line noise out before it got to the module.

I pulled the module from the deep freeze and as quickly as possible blasted it with the hair dryer - and got it real hot. With the top cover removed.

Again it survived and seemed completely unphazed.

I have to go out of town for work for a week. During this time I will let the module run as usual and do logging.

 

[az1324]

This is becoming quite the case study. Its an interesting read, so keep it up.

 

[Xymox]

I have to go out of town for 10 days starting tomorrow.

I will be logging while im gone.

Its back to gaining a second a hour. Every hour.

Once i come back I will have a very good set of logging figures I think I can get into excel for graphing.

 

[Xymox]

I thought i would update this thread...

Its now 2 months since I set the time on the 1132CU.

I still log the time on the PC. Its still so close i cannot see ANY drift yet of the RTC.

So its less then a 1/2 second.

Thats, at most, 3 seconds a year drift. Assuming I would want to correct it if it got off by a minute thats 20 years without resetting the RTC.

That is pretty amazing. For a little $5 chip thats a fairly stunning accuracy. In fact it may be more accurate as I still cannot see any drift at all. After a few more months I shoud see at least some drift and be able to report what the real drift is.

It still has daily drift between RTC updates but they are no more then about 6 seconds at most. I think its power line freq drift. This small drift doesn't bother me so I could care less about it. It was the long term RTC drift that was important as its the reference for the 1132CU and that is -fixed-.

Here in Arizona we have had lots of storms in the last month. Lots of power outages and at least one brown out. Not to mention lots of power line spikes from serious lightning None of this has caused any issues.

I have now switched over to a much more automated system that revolves around the 1132CU and Smarthome V2 and ICON products. The 1132CU does a lot every day now. I have had -zero- problems.

I did mod all my V2 and ICON products as there was a serous issue with them, but everything works perfectly now and the mods make the products much better.

I think I will make up some web pages on all these mods.

So I consider this "case study" and RTC problem finished. I will update this in a few months to report on a real drift for the RTC chip.

 

[Xymox]

Another update.

Its now almost 3 moths after setting the time on my 1132CU after the mods.

I still cannot measure any drift. Its still less then a 1/2 second off.

This is a fairly stunning accuracy for a $5 chip.

At this rate it would take 30 years to be off by one minute. At most.

 

[Xymox]

Another IMPORTANT update on this thread.

First off Smarthome called me today. They said they had read through this thread way back in june and took it quite seriously.

In fact they have redesigned the 1132CU !!!!!

Based on what I did !?!!!!!

Wow !!!

4 months are we have a redesigned module.

They are sending one to me to test. They apparently used the same chip I suggested and did board layout to isolate the problems I described !!!!!!!

That IS IMPRESSIVE customer service.

I will get the newly redesigned 1132CU shortly and report here.