This note suggests methods for using OpenLCB to provide “fast clock” features for a layout.
A layout control bus could do a number of useful things with fast-time information:
Connect a number of clock displays to keep them synchronized.
Provide time information to plug in devices, e.g. throttles.
Provide cueing for time-based occurrences, such as lights coming on and off, etc.
Generally, fast clock systems have one unit that generates time information, and one or more units that consume it. Some fast clock systems track a day/date, in addition to time.
Fast clocks run at various rates, and can be controlled by the user either at the generator or from other locations. Some fast clock systems broadcast run/stop and rate information, which can also be useful when interpolating within a fast-minute.
There are slightly more than 216 seconds in a day, and just less than 211 minutes. An easy format would be 5 bits hour, 6 bits minutes, 6 bits seconds; that makes display computations easy, interval computations harder.
One solution is to define a range of events that will carry time as part of the 8-byte EventID. If sending minutes is sufficient granularity (its a fast clock, not a clock clock; fast seconds are a lot of event transmissions), the 12 bits can be used for that in the 16-bit lower part of the EventID. The upper 6-bytes are assigned in the usual way.
To provide a more display-friendly format, it's also possible to use 5 bits for hour and 6 bits for minute separately, or arranged in bytes.
Simple nodes can then use specific EventIDs to trigger their actions at specific times. For example, lights in buildings in a model town can be sequenced to come on at various times by using a standard 8-output node and configuring its consumers to different time events.
Blue and Gold configuration can be done by putting a programming button on the master time generator that sends the learn message for the current clock time.
Changes to the run/stop state and clock rate can be broadcast as separate events. That's better than coding them in the time events themselves, because if e.g. rate was separate bits in the event, simple nodes could not be configured to recognize specific times.
If remote control of the fast clock is desired, a datagram protocol should be defined. (This makes it possible for e.g. throttles to have a general fast-clock-control capability built in) The NodeID of the fast clock is made available through its event broadcasts when it's running. Even when stopped, it should broadcast its time so that it can be found by nodes wanting to locate it.
Operations:
Stop/start (“Stop” is similar to “Set rate zero”, but “Start” is “Set rate back to previous non-zero value”, which is different)
Set rate
Set time (and date?)
This can be put into a single datagram, but having separate ones might make for easier software (no need to remember state, worry about update consistency, etc)
Remote displays of the fast clock time (repeater displays) could be provided in several ways.
A remote clock display node can listen to the broadcast time and provide it's own display.
A clock node can send formatted characters to a remote display using the common display protocol. This may allow lower-cost display nodes to be used.
More complicated nodes, e.g. computer programs, can capture the time for their own more-advanced displays.
Site hosted by
This is SVN $Revision: 721 $