Hello,
I have an idea I'd like to toss around: what if the fast clock time was sent to the train - or rather accessory - decoders?
Obviously that would make it possible to have the time on display on the layout facia without any extra wires (which would be especially convienient on a modular railroad). I'm aware that Digitrax and NCE offer something like this, but if I got it right they are sending the information to the throttles, which isn't what I have in mind.
But it would also be possible for devices on the layout to use the fast clock time, for example:
a) Church bells, school bells and factory whistles
b) Office/Industrial sounds at working hours only
c) Interior lights in buildings, as well as street lights.
And while at it, the reason I started to think about the feature in the first place:
d) layout lighting.
The latter because I'm concidering a bookshelf layout built in short sections (for easy maintenance and to make relocation possible), and I would like to keep the wires as few as possible. It struck me that LEDs powered by a DCC power district (or possibly several small ones) might do the trick. And if I install LEDs, why not having them in several colors to simulate diffent daylight conditions.
Now, there are two major problems with all this:
1) This is a signal which ought to be broadcasted - the time should be the same over the entire layout (should it not? ). So it makes sense to have the time information on a specific address, which all accessory decoders reacts to, as opposed to commands sent to a specific decoder, for instance church ringing for a wedding, etc.
2) There is as far as I know no suitable packet format for time settings.
I think the straightforward way to send the time would be to send the hour and the minute every time the clock should be updated (seconds I think we can dispense with). And 24 hours * 60 minutes makes 1440 minutes. That requires a minimum of 11 bits and there is no accessory decoder command which sends so many data bits (there is one which sends 5 bits though). I think it might be possible to shoehorn it into a engine decoder package, but this seems stupid to me, since this feature hardly will be installed in trains.
So what I'm really polling is whether there is an interest for extending the DCC standard to accomodate for the time of day.
Actually I would suggest an extension to "extended accessory decoder control packet format" (the one which can send 5 bits of data, for instance up to 32 signal aspects) with one extra byte of data.
The hour would fit snugly into the original 5 bits of data, and the extra 8 bits would accomodate for the minutes - actually you have two unused bits, which can be used for fractions of minutes in which case the clock migtht be updated every 15th fast time second if so desired. (One nice thing about broadcasting the time in hour+minute format is that you don't have to send every possible time update, you can jump in time - as we tend to do with fast clocks... .)
Any suggestions or interest out there?
Regards
Stefan Isaksson
JMRI can doa ll of this. And even be the clock source (since your PC will be far more accurate than any PIC processor in a typical DCC command station). You cna build scripts to command decoders, both stationary and mobile, based on time. And JMRI also supports, in addition to multiple DCC interfaces, home control interfaces liek X10, so you cna controlt he room lights as well based on the clock. So, fast clock on your throttle, fast clocks hanging on the walls, send sounds to speakers under the layout, command decoders, and control the room lights. All right there. With Digitrax and NCE you can use the Logic Rail Technologies fast clocks for the fascia/wall displays. Other systems either do not have the capability for fast clock or have not revealed enough about their command structre to make it possible. The Digitrax one has been around for ages, it's always been a feature of Loconet. The NCE one is newer, as I think the fast clock capability was more recently added - several years now.
--Randy
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.
Thank you for your reply.
rrinker JMRI can doa ll of this.
JMRI can doa ll of this.
Not the way I want to do it, unless I completly misunderstood their home page.
As for the clock support, what JMRI does is to tap in to the Digitrax or NCE throttle buses and send the time information. Only Digitrax and NCE are supported with this particular feature, other brands are not (presumably because other brands does not support fast clocks at all).
And the point is that I like the information to be sent on the track bus, not the throttle bus. Otherwise you are stuck with only two brands (for now at least) to choose between, and further, if you go for wireless throttles you either must choose the high end throttles (those with a display) or install a throttle bus only to drive Logic Rail Techonlogies displays.
rrinker And even be the clock source (since your PC will be far more accurate than any PIC processor in a typical DCC command station). You cna build scripts to command decoders, both stationary and mobile, based on time.
And even be the clock source (since your PC will be far more accurate than any PIC processor in a typical DCC command station). You cna build scripts to command decoders, both stationary and mobile, based on time.
Quite, even though there seem to be a polling problem for the throttles, so even with JMRI accuracy might not be that good. On the other hand, scripts for accessory decoders should be as accurately timed as you can ask for, I suppose.
rrinker And JMRI also supports, in addition to multiple DCC interfaces, home control interfaces liek X10, so you cna controlt he room lights as well based on the clock.
And JMRI also supports, in addition to multiple DCC interfaces, home control interfaces liek X10, so you cna controlt he room lights as well based on the clock.
But that would require special wiring for the lights, would it not?
<snip: the rest of the reply covers mostly topics already discussed above>
It sounds like you want to use the main DCC bus with accessory decoders to control a bunch of different animation things on the layout. The DCC bus was not designed to do this. It was designed to run the trains, not accessories, other than turnouts.As was mentioned, JMRI is capable of doing what you have laid out, but not in the specific way that you envision.
EDIT: I have no interest in what you are proposing because it is available in another form (JMRI) if I want to use it. I also have added a Circuitron Fast Clock Module to my NCE system for an external display.
Elmer.
The above is my opinion, from an active and experienced Model Railroader in N scale and HO since 1961.
(Modeling Freelance, Eastern US, HO scale, in 1962, with NCE DCC for locomotive control and a stand alone LocoNet for block detection and signals.) http://waynes-trains.com/ at home, and N scale at the Club.
There's a reason those two DCC systems are the top sellers - they ARE the most capable.
Digitrax does not poll, Digitrax is a peer to peer network, so there's no issue getting the time ont he throttles, or any accessory devices like the Logic Rail clocks. The issue with keeping time is the command station simply is that inaccurate. NCE polls and requires unique IDs for each device on the cab bus, and there are a limited number of them. Wireless or not, you still need a throttle bus run fromthe command station to the wireless receiver with either system, and also between command station and any extra boosters. Not to mention signals and block detectors - with Digitrax this can be all done with one Loconet. On a larger layout, it is usualyl best to distribute the boosters so the track power bus runs are kept short, rather than cluster them together and run long bus wires all over the place. So again, the command bus is in place - with Digitrax this is the same as the throttle bus, with NCE and others it is not and you may have a point.
Lighting control with X10 or Insteon requires NO special wiring - the signals are boradcast over the power line to receivers that plug between the outlet and the controlled device. I use X10 to turn my workbench power on and off as well as my DCC system, so I don;t have to crawl under the layout and hit the switch on the power strip. For layout lighting the same thign would work, with strings of lights plugged in to X10 modules and controlled by JMRI. If finishing a space liek a basement or gargae for the layout, you cna install X10 outlets instead of standard outlets so there's no module to plug in. Same with light switches, you can install an X10 switch instead of a standard one, it gives you local control like an ordinary light switch but it also responds to X10 commands. Or just use the modules in existing outlets and plug the layotu lights into those. Definitely no special wiring required. Runnign LED lights fromt he DCC bus is a really bad idea - a string of LED lights runs off a fairly powerful transformer, to get that power fromt he DCC bus would require extra boosters as well as a suitable transformer for each - in the end much more expensive than just using X10 modules. As of now, any device that acts as a stationary decoder but controls a high current output derived from an external source (for brighteness - for simple on/off there's the Aux Box) is strictly a homebrew. I'll admit I like playing with electronics, but if I was goign to do this I would just use X10 (although maybe not the actual X10 modules - they do have issues. Rather some higher quality X10 compatible modules) since it is well established and proven, and compeltely off the shelf ready to use. I actually have a bunch of X10 equipment as I used to have a good portion of my house controlled by it, although not for railroad purposes. It was also automated under computer control, although with a purposeful home automation program, not JMRI.
Stefan-
I think that putting the time value in the DCC data stream would be over-complicating things. All that the buildings, church bells, etc. need at their end is "turn on" and "turn off" signals. Those are already built into the DCC track signal standard. There is no need for each item to track its own time.
Given that, I'm skeptical that there is a terribly strong case to add the extra data traffic to the DCC track bus that a recurring time packet would add. Such a signal costs bandwidth, and I'm not convinced that the benefit comes anywhere near to the cost, especially for large layout installations with large amounts of throttle traffic being sent to active locomotives and accessory decoders.
For the limited number of times over a given period that the message would be acted upon, I don't see a proportional benefit to having the extra packets out there on the rails.
Looking to implement this on the current architecture, what I would see as useful would be for some of the manufacturers who don't already support a JMRI interface to do so-- it's the de facto standard in the hobby right now.
An alternative would be for a manufacturer wanting to support this functionality to produce a box (with or without its own timebase, as required by the specific manufacturer's system) that could send out pre-scheduled activation packets to accessory decoders at the predetermined times. The thing would plug into the system's throttle bus and look like a throttle to the command station. This is a more modular approach that wouldn't require a new packet structure and could be built with a user interface that would be much nicer than having end-users program CVs on an accessory decoder.
-Fritz Milhaupt, Publications Editor, Pere Marquette Historical Society, Inc.http://www.pmhistsoc.org
fmilhaupt An alternative would be for a manufacturer wanting to support this functionality to produce a box (with or without its own timebase, as required by the specific manufacturer's system) that could send out pre-scheduled activation packets to accessory decoders at the predetermined times.
An alternative would be for a manufacturer wanting to support this functionality to produce a box (with or without its own timebase, as required by the specific manufacturer's system) that could send out pre-scheduled activation packets to accessory decoders at the predetermined times.
This is already available in our LocoNet Fast Clock modules! We call the feature "Event Triggers" and each LNFC module allows you to define 3 separate events. Each event trigger can be of the type "one-shot" or "duration." Rather than clog up this forum thread with all the details please visit our website for more information. You can download the user manuals in PDF format under the Documents section.