1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

timer system - any thoughts?

Discussion in 'Embedded' started by Scott Kelley, Oct 5, 2005.

  1. Scott Kelley

    Scott Kelley Guest

    I'm working on a project that requires a timer system which will turn a
    device on and off, and change some parameters at various times of the day.
    Since there must be all kinds of methods for doing this that have been done
    already I thought I'd ask before taking the time to design my own from
    scratch.

    choice of three operating modes, including

    OFF
    Parameter Set 1 (PS1)
    Parameter Set 2 (PS2)

    Typical functionality might be something like this:

    Saturday:
    6:00am PS1
    9:00pm OFF
    Sunday:
    6:00am PS1
    9:00pm OFF
    M-F:
    6:00am PS1
    7:00am PS2
    8:00am PS1
    1:00pm PS2
    2:00pm PS1
    9:00pm OFF

    Then there needs to be exceptions throughout the year for holidays, etc.

    Mostly, I'm trying to get the big picture figured out right now. Any
    thoughts as to published info for this type of thing, or approaches you have
    taken for similar type of timing system?

    Thanks,
    Scott Kelley
     
    Scott Kelley, Oct 5, 2005
    #1
    1. Advertisements

  2. 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.
     
    Paul Marciano, Oct 5, 2005
    #2
    1. Advertisements

  3. Scott Kelley

    Scott Kelley Guest

    I'm working on a project that requires a timer system which will turn a
    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.
     
    Scott Kelley, Oct 5, 2005
    #3
  4. Scott Kelley

    MetalHead Guest

    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
     
    MetalHead, Oct 6, 2005
    #4
  5. Scott Kelley

    Thad Smith Guest

    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 Smith, Oct 6, 2005
    #5
  6. Scott Kelley

    Scott Kelley Guest

    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
     
    Scott Kelley, Oct 8, 2005
    #6
  7. 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.

    --
    ********************************************************************
    Paul E. Bennett ....................<email://>
    Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
    Mob: +44 (0)7811-639972
    Tel: +44 (0)1235-811095
    Going Forth Safely ....EBA. http://www.electric-boat-association.org.uk/
    ********************************************************************
     
    Paul E. Bennett, Oct 8, 2005
    #7
  8. On Saturday, in article
    <di80dn$adm$1$>
    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).
     
    Paul Carpenter, Oct 8, 2005
    #8
  9. Scott Kelley

    Lanarcam Guest

    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.
     
    Lanarcam, Oct 8, 2005
    #9
  10. Scott Kelley

    Scott Kelley Guest

    Good stuff!!!

    These are the kinds of things I want to know going in, rather than bang into
    them myself.
     
    Scott Kelley, Oct 8, 2005
    #10
  11. On 8 Oct, in article
    <>
    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.
     
    Paul Carpenter, Oct 8, 2005
    #11
  12. I did mean that, yes.

    --
    ********************************************************************
    Paul E. Bennett ....................<email://>
    Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
    Mob: +44 (0)7811-639972
    Tel: +44 (0)1235-811095
    Going Forth Safely ....EBA. http://www.electric-boat-association.org.uk/
    ********************************************************************
     
    Paul E. Bennett, Oct 9, 2005
    #12
  13. Scott Kelley

    Lanarcam Guest

    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.
     
    Lanarcam, Oct 9, 2005
    #13
  14. 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
     
    Paul Keinanen, Oct 9, 2005
    #14
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.