timer system - any thoughts?

Sorry, no references to give, but just wanted to bring up daylight savings. If your product must correctly adjust, be aware that daylight savings in the USA is due to be extended in, I think, 2007.

You could have regional daylight savings built-in, or have it user-programmable.

Just FYI.

Regards, Paul.

Thanks. I have considered that. In addition, it is probably a good idea to consider that DST has been bumped by 2 hours at times - may happen again - the politicians gotta look busy ya know.

Many years ago, I built a 7 day, 24 hour alarm clock. I was working a wierd shift and was tired of forgetting to set the alarm on worknights and turn it off for off nights. I also had a fairly funky stereo system at the time that benefitted from a 3 channel power sequencer. I built one with an old 6800 processor, LED displays, a 15 key keypad, backup batteries and a crystal oscillator. It worked reasonably well for 24 years. What I learned it was:

Use a timebase derived off the 60hz (or 50hz as appropriate) power line frequency. The absolute accuracy may not be stellar, but the long term average is excellent. The crystal oscillator I used would run a minute or so slow per month. The purpose of this 7 day alarm clock was to not have to mess with it, and a minute a month violates that.

The backup battery worked well. It would keep time and all settings for an hour or two. If I were designing Rev 2, I would have the backup battery keep the time values safe and let the timekeeping go quiet in AC Fail mode. Most AC failures seem to be a few seconds or greater than an hour.

The human interface design confounded everybody that tried to use it but me. Ten of the keys were 0..9 and 5 were "soft function keys". Real time set, alarm time set, exception flag set, backspace and manual power on/off were the normal operations of the keys and two of them would double for AM/PM selection when I changed it to read in 12 hour format. All keys were labeled. Maybe if I had written instructions down for it there would have been less confusion. Maybe people are so used to those wretched up/down buttons that a simple keypad freaks them.

Make sure it is ESD proof! It will get zapped and locking it up will cause hate and discontent.

Good Luck, Bob

...

I implemented schedule logic for one product. I implemented separate day schedules, each of which had a list of start times and corresponding operating modes. There were week schedules, each of which specified a day schedule number for each day of the week. A master schedule specified start dates for selecting a week schedule. In addition, special days (holidays) could select their own day schedule.

As far as daylight savings time, you could select normal US daylight savings time switching, disable DST switching, or specify custom dates to make switch in and out. If custom dates were used, they would need to be changed each year. It would be possible (not implemented) to create a way to specify a typical daylight switching choice: Nth Sunday of month M (also allowing choice of last). To generalize further, you might allow multiple fall forward/backward dates per year or other than 1 hour adjustment.

Thad

Thad,

Thanks for the info. Can you elaborate on the schedule logic? That's where I am hoping to get a better handle on how to set this up.

Thanks Scott

Create an ordered list of the scheduled events and just compare the earliest time for action with the current time. Perform the action when current time => current time.

The most difficult thing about this is when you add new items to the list you have to re-sort the list.

I trust you meant to say "current time >= event action time".

Also look at the source for things like 'cron' timed task scheduling.

Keeping also a flag for when last run, to cope with what to do when Daylight saving changes occur and someone has set an event for 02:30, to avoid missing or doing it twice! Similarly what to do if the system time is changed and you have missed events.

System time may be changed because of operator action or potentially software does how to adjust for losing/gaining time over a time period or you have a second source to synchronise time and date (e.g. radio clock or network time).

In this case what is often done instead of changing the system time abruptly upon reception of a synchronisation message is to speed up or down the system timer by modifying temporarily the value of the counter until the system time is synchronized again. In that way events are not missed.

Good stuff!!!

These are the kinds of things I want to know going in, rather than bang into them myself.

Yes depending on application, would not want a heating system controller on the coldest day of year need system time change to go through the whole weekend of on/off, as time was 'speeded' up. For whatever reason it was wrong in the first place (even operator error of setting wrong time in the first place). Sometimes if a bunch of events have been missed you have two choices (depending on application) just skip missed events, or another is only action last. If a whole bunch has been missed then some applications (brewing beer as an example) may mean throw away what the process is and reset.

Each application has its different issues and what to do with missed or potentially missed events and all mthods of time changes must be thought through before assigning thoughts to the scheduler software design.

I did mean that, yes.

The progressive adjustment of the system time is of course limited to the cases where the difference between internal time and source time is below a certain threshold. For instance if the difference is below one second you can adjust progressively otherwise you make an abrupt update. However when the hardware is fit and if the sytem time has already been synchronized at least once you should only see deviations due to the drift of the timer, except for changes due to daylight saving time.

If the system time can be set both by an operator and by an external clock you can use validity flags. For instance the time is valid only when it has first been synchronized by an external clock. It becomes invalid again if no synchronization message is received for a preset period of time.

You could also in some cases have the system time independant of the actual time, except for drift compensation. External clock sources give warnings about exceptional events and you can use them to discard changes and consider only the deviation.

Any sensible timing system should internally use a linear timing scale (such as UTC) for all time related events. When setting new events, the user interface should handle things like time zones and daylight saving time and convert these event times to the internal linear time. If there is an ambiguity about which time is intended when switching back from daylight saving time to normal time, the user should be required to specify, which time is intended.

It is far too late to worry about what is intended, when living in that one hour ambiguous period.

Paul