Model Railroad Fast Clock Display

Roy Carlson

I would like to create a model railroad FAST CLOCK for use on my layout using the BS2 or SX Chip and a serial LCD or 7 Seq LED display.

The purpose of the fast clock is to speed up real time for running model train operating sesions.· For example, If the operating session will last 2 hours, we would want the clock to show a full 24 day in only 2 hours.· The software must allow for setting the session time frame with a start and a pause feature (for derailments or breaks).

I have used the BS2 with the RTC chip and know how to display the real clock screens but wasn't sure if this would be needed for this project.· I guess it would be good to have the real clock and the FAST Clock displayed on the same screen together or toggled.

I have the LCD APP MOD display with the four buttons - I could use this for the clock display and use the buttons as the inputs for setting the real time, start, pause, and scale modes.

I could increment the scale modes in even hours·or 30 minute increments to keep things simple.

Do you think I should use a software routine to take the real time and modify it for the FAST CLOCK or use some form of a·software timming sequence·using a count or other routine?

Any help or ideas are greatly appreciated.

Roy

PS - Any ideas on how to backlight the LCD APP MOD?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Roy Carlson

904-536-7405
roy-kathycarlson@msn.com

Bruce Bates

Roy -

The separate, hardware RTC will always maintain the "correct" time [noparse][[/noparse]RT], so that stands on its own. Adjustment routines for the RTC may or may not be required. Sometimes this is done in a separate program, since the RTC runs independently from the micro-controller, and it runs whether the micro-controller is powered up or not.

An accumulated time adjustment amount [noparse][[/noparse]ATAA] (for derailments or breaks) will have to be maintained if the "Fast Clock" [noparse][[/noparse]FC] is to be accurate. The ATAA is derived directly from the RT and is accumulated in minutes and seconds, or merely minutes, as you see fit.

Any and all other times which may be required for the FC, any accumulations of the FC, or any other FC features will be scaled from the RT or the ATAA and are really only used for display purposes. These FC times are not maintained, but rather are derived (by scaling from the RT) whenever they are used, and everytime they are used. None of these FC times are "real" in any sense of the word. Since these are not real, no software timing routines are used to maintain them.

Said a bit differently, these FC times are mathematically derived (scaled) numbers based on times and differences which have come directly from the RT or which have been accumulated from the RT. Their only difference is that they have the scaling factor applied to them before they are displayed. The scaling factor may or may not vary from run to run, as you see fit.

Regards,

Bruce Bates

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Roy Carlson

Thanks Bruce...

I will have to revisiting the RTC Clock examples and try modifying the code to show TWO clocks, one real time and the other a scaled version of the time.

I wonder if multiplying the real time by 12 would compress the time from 24 hours to 2 hours?

Or should I focus on just getting the seconds portion of the time and make up my own clock using a set start time, let's say 8 AM each time and use the seconds or minutes counter from the RTC to scale the FASTCLOCK time.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


·

DiablodeMorte

If i'm reading this right. You want to simulate a say 24 hour day in a predefined period of time(like maybe 2 hours?)?

If that is correct I would handle it this way:

First you need to set a "start time"(ie, 12 midnight) for the fake time to start at. The real time can be which ever you want.
For the purpose of this post, the fake time will be 12midnight(0 Seconds) and the real time will be 6 in the morning. A 24 hour cycle will happen in 3 hours.

Ok, First, divide 24 hours by the number of hours of a fake cycle. So, 24/3 = 8, Every real hour 8 hours will pass in faketown.
That should also mean every real minute is 8 fake minutes and every real second would be 8 fake seconds.
So, inorder to display the current fake time:

FakeTimeInSeconds = 0 + ((RealTimeHours * 3600 + RealTimeMinutes * 60 + RealTimeSeconds) - (RealStartTimeHours * 3600 + RealStartTimeMinutes * 60 + RealStartTimeSeconds) * 8)

To determine the minutes/hours/second in normal time(ie, not all seconds)

FakeTimeHours = DEC2 FakeTimeInSeconds/3600
FakeTimeMinutes = DEC2 (FakeTimeInSeconds /3600 - FakeTimeHours * 60)
FakeTimeSeconds = DEC2 (FakeTimeInSeconds /3600 - FakeTimeHours * 60 - FakeTimeMinutes * 60)

In theory(at 12:03 Midnight that is), this should work, I ran it through my head a couple of times and through a calculator a few more times and it worked..ofcourse that could be my sleep deprivation talking.

-Night

Bruce Bates

Gents -

Personally, I wouldn't be concerned with seconds at all, and minutes not too dearly. In both cases they will fly by so fast as to be nearly insignificant. Here's what I mean, although I wish you gents had both used the same examples. I am not considering TOD (time of day) adjustment below in my comments, and I'm honestly not sure I'd even bother with it in this proposed system:

In consideration of hours -

If the scaling factor is (say) 12, then 24/12 = 2 ("jumps") so there will only be 2 hour-long Train_Time periods in that 24 hours period. Effectively, the Train_Time will be 0:00 then 12:00 then 24:00, where 0:00 = 24:00 for a total of two displayed hourly Train_Time times.

Obviously with smaller scaling factors, there will be more periods, and Train_Time will ... appear to move more slowly.

In consideration of minutes -

The same can be said of minutes as was said of hours above, except that the "jumps" will be measured as 60/12 or 5 twelve minute periods, just slightly more "stable" than hours.

What I'm trying to illustrate here is that even if the mathematical calculations are spot on, and regardless of how the actual calculations are made, one has on one's hands (no pun intended) a rather "jumpy" clock whose true value is somewhat meaningless, except for display purposes, which I thought was the original, intended purpose.

- - -

Said perhaps in more scientific terms, in viewing real time (RTC time) here, and Train_Time (scaled time) the former represents a more fine-grained system (smaller intervals) and the latter represents a more coarse-grained system (larger intervals). By its very nature, when compared, a fine-grained time system will appear more accurate than a coarse-grained system to the eye, yet in truth, both have the same degree of individual accuracy relative to their purpose.

I hope I didn't make this more confusing.

Regards,

Bruce Bates

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Roy Carlson

Thank you all for your input...

I will have to sit down this weekend and put some of the ideas to a test.

Roy

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


·