Jump to content

Railmaster interaction with Elite


Recommended Posts

In the last day or two, I reported what I thought was a fault through the Help system. I had noticed that when using F1 on the Elite to switch on and off the sound on my steam sound locos, that the loco throttle window for that loco was showing the F2 Whistle switching between green and grey, instead of F1. Today I received the follwing reply from HRMS, which I thought may be of interest to those who use an Elite with RM:-

 

"There is no interaction or feedback between the Elite display and RailMaster when it comes to loco control functions.  When operating a function on the Elite, this will not be reflected on RailMaster and when operating a function on RailMaster the Elite display will not update.  This is because there is no function in the Elite's firmware to report function settings back to software.  It is therefore not wise to use the Elite and RailMaster to control functions for the same loco.  Use one or the other otherwise you will see unpredictable results."

 

I don't know if anyone else has noticed this but if you switch any latching function on or off on the Elite, then the RM window for that loco DOES reflect the change, but F1 on the Elite reflects a change to F2 on the RM loco window.

I ask myself also "Are speed changes on the Elite reflected on RM?". I'll have to try that this afternoon ;-)

Ray

Link to comment
Share on other sites

As far as I understand communications between the Elite and the track and RM with the eLink and the eLink to track is as far as it goes. With the hardware and software from the Elite and RM not being written to work together and the firmware, as HRMS point out, not being able to communicate or report function settings back to RM then anything you do notice from what you have said in your post is purely coincidental and definately NOT intentional.

 

With some hardware and software on computers that are not supposed to work together normally, or indeed, communicate in any way it sometimes is just down to one of those stupid things that happens.

 

What we have to understand is that hardware and its chips and any software that is written can only ever be understood by binary code and electrical inputs with a status of being on or off. That translates to the software understanding binary which is a series of ones and zeros... on or off. Zero for off and one for on.

 

Occasionally one charge will find its way through circuits it is never intended to and an odd result will occur when that charge is recognised somewhere else. Because both the Elink and RM are running one such instance may be happening here against the rules so to speak. Now some folk will deny this but it does happen. If that instruction bypasses its correct destination it HAS to reach somewhere else before stopping in its tracks and thus can cause an interaction with something it is not intended to.

 

If a bolt of lightning hits an electrical circuit and then finds its way through the circuits of a TV it has to find an end point. That end point could be part of the circuitry, a mains outlet or elsewhere. But it will have an effect. A large one yes but you see where I am coming from?

 

Now I am NOT saying this is what is happening here but it does throw some possible light on a subject that, if not understood, can lead to all sorts of unecessary investigation and other stories popping up. I'll probably get some of you having a laugh at this one maybe but that's OK... a few electrical engineers have spoken to me on this one before... a very good one is my eldest brother who has taught me loads of stuff re electrics. Anyway... the result is that this may have absolutely nothing to do with your probs or questions but at least it is out there now... :-)

Link to comment
Share on other sites

Hi AC,

I understand what you are saying and I have told HRMS that I am happy with their explanation. However, I would like to understand how the DCC protocol works in terms of switching sound functions on and off. For example, if you have a steam loco standing on the track with sound on, then you switch off the DCC power for a few seconds, then switch it back on, the loco sound comes back on. So what has happened here? Has the decoder remembered the sound on setting during the power off - unlikely. When power is restored, does each loco send a packet of data to the controller requesting a refresh of its sound function settings? Are these settings constantly being broadcast down the DCC bus for every loco? - unlikely.

Do you know of any website I can go to which will explain the DCC (or ExpressNet) protocol in words of one syllable? :-)

 

Ray

Link to comment
Share on other sites

Hi AC,

I understand what you are saying and I have told HRMS that I am happy with their explanation. However, I would like to understand how the DCC protocol works in terms of switching sound functions on and off. For example, if you have a steam loco standing on the track with sound on, then you switch off the DCC power for a few seconds, then switch it back on, the loco sound comes back on. So what has happened here? Has the decoder remembered the sound on setting during the power off - unlikely. When power is restored, does each loco send a packet of data to the controller requesting a refresh of its sound function settings? Are these settings constantly being broadcast down the DCC bus for every loco? - unlikely.

Do you know of any website I can go to which will explain the DCC (or ExpressNet) protocol in words of one syllable? :-)

 

Ray

No probs St1ngr4y...

Re the sound issue on your steam loco: when a loco receives a signal to do something the decoder is programmed with that command, whether or not it is a sound decoder or not.

When power is lost to that loco or track where it stands then there is no way there is enough energy to keep that loco and the decoder doing what it should.

Upon reconnection of power to the track or loco there is enough then to reach the decoder and resume its functions it has been programmed with.

The upshot really is that a decoder will ALWAYS remember the last set of instructions it was given prior to power loss. This is because the decoder on each loco has what is called flash memory and is able to retain all instructions until over ridden by a new set of the same.

Where sound is concerned I assume there is a similar process going on. When you say the sound goes off on power loss and returns when power is regained then that decoder is likely to have the software resend the command unless it too has lost power where it would return to a standard default boot setting when switched on normally.

For a definitive answer maybe you should tell us the sequence of events up to power loss and where that occurs. Is it on the Elite/eLink or pulling wires from the track? Is it the software causing the loss? Are you lifting the loco from the track when power is lost so it breaks its connection too or leaving it standing? Each step is important here as this may just define an answer for you.

 

 

Link to comment
Share on other sites

Hi AC,

Is the flash memory the same memory as used to retain its CVs? I suppose we could try these theories by leaving a loco with sound on, then power down the whole system and on again. I think the sound on status would be lost in these circomstances. I wasn't saying, by the way, that I am regularly losing power on the DCC bus. Where I noticed this is when I am writing CVs to a loco on the programming track, I usually disconnect the power from the main DCC bus, and if there happens to be a loco on the main with sound on, that's when I notice the restoration of sound when I reconnect the bus.

When you say "then that decoder is likely to have the software resend the command " this would mean that ALL locos on the main would do this when power is restored.

Ray

Link to comment
Share on other sites

St1ngr4y...

Sorry, that reads incorrectly... my wording that is. I state "then that decoder is likely to have the software resend the command " and this is not what I meant. Sorry!

It should have said "then that decoder is likely to wait for the software to resend the command " because as Fishy rightly points out the decoder does not request anything from any software in this scenario.

The sound will come back on simply because the software or the Elite has not been altered to a state whereas a new command has to be sent to the decoder and thus the same instructions are sent as was set before the power was removed. I assume the commands are not just sent to the decoder on a one time only status and that they are continually sent.

Link to comment
Share on other sites

Rather than saying anything about instructions being sent, simpler to just say the functions remain as they were when the power went off.  So if sound was on when the power went off, it will still be on when power comes back, until the function is accessed to turn it off.

Link to comment
Share on other sites

Rather than saying anything about instructions being sent, simpler to just say the functions remain as they were when the power went off.  So if sound was on when the power went off, it will still be on when power comes back, until the function is accessed to turn it off.

In the immortal words of Clive Dunn as Corporal Jones in Dad's Army...

 

"Right'o sir!!" :-)

 

 

Link to comment
Share on other sites

Rather than saying anything about instructions being sent, simpler to just say the functions remain as they were when the power went off.  So if sound was on when the power went off, it will still be on when power comes back, until the function is accessed to turn it off.

In the immortal words of Clive Dunn as Corporal Jones in Dad's Army...

 

"Right'o sir!!" :-)

 

 

Hi AC & Fishy,

After further experimentation this morning, I can safely say that the sound settings of a loco decoder are held in memory in the decoder over a DCC power off. If the track is connected to the Elite when power is restored to the Elite, I believe the Elite must broadcast some sort of initialise packet to all locos to switch sound off i.e. zeroise all function flags. If the track is disconnected when the Elite is powered on, the loco sound resumes when the track power is restored, because the locos have missed the initialise packet.

Does that seem logical to you?

I also think that whenever a command is sent to the loco to switch a sound (or lights) on or off, then the status of ALL sound functions as known by the controller for that loco are sent in the same packet.

Ray

 

 

Link to comment
Share on other sites

I also think that whenever a command is sent to the loco to switch a sound (or lights) on or off, then the status of ALL sound functions as known by the controller for that loco are sent in the same packet.

 

 It is a little more complicated than that, a good resource for XpressNet commands is: http://www.opendcc.de/elektronik/opendcc/xpressnet_commands_e.html it shows what commands are possible without reading the whole specification but doesnt go into detail about how they are implemented.

On your specific point, there are 3 function groups (5 if the controller is XpressNet 3.6 compatible) Group 1 contains the instructions for functions 0 to 4 (so 5 functions in all) and there are 2 types of commands, Set the functions to operate or Get the functions current status. like so (simplified):

Header | F0 State | F4 State | F3 State | F2 State | F1 State | Checksum

Each of the function states are a binary switch so basically can be either on or off and must all be sent at the same time so the command station is required to have an internal table to keep an eye on the function state.

Momentary commands also follow this principle and the command station sends the packet multiple times at the required interval (although there is an XpressNet command for momentary functions, it is only to tell the command station it is such so other controllers can know its type).

It is likely on powerup, the command station is broadcasting the default state for all functions of all known locomotives upon powerup, however a possibly better way would be for the command station to poll all known locomotives to update the command stations internal table and set the function state on the command station accordingly.

 

Hope all that makes sense,

Robin.

 

Link to comment
Share on other sites

Hello Robin,

Many thanks for that. I think it more or less confirms what I was thinking, until I got to the last paragraph. The thing is, I haven't intentionally configured any locos on the Elite, so, unless the details configured in RM are somehow passed across to be stored on the Elite, then I can't see how the command station can "poll all known locomotives to update the command stations internal table and set the function state on the command station accordingly". Is there not a broadcast address available (e.g. decoder address = 0) to which ALL locos will respond as necessary i.e. only sound decoders will take notice of a broadcast to initialise sound function statuses?

Ray

Link to comment
Share on other sites

Hello Robin,

Many thanks for that. I think it more or less confirms what I was thinking, until I got to the last paragraph. The thing is, I haven't intentionally configured any locos on the Elite, so, unless the details configured in RM are somehow passed across to be stored on the Elite, then I can't see how the command station can "poll all known locomotives to update the command stations internal table and set the function state on the command station accordingly". Is there not a broadcast address available (e.g. decoder address = 0) to which ALL locos will respond as necessary i.e. only sound decoders will take notice of a broadcast to initialise sound function statuses?

Ray

 Sorry, I was specifically talking about how RailMaster would talk to the command station (be it an Elite or eLink). I am not really up to speed with the DCC protocol as I have not yet designed a command station but a quick skim on the NMRA standards shows a broadcast packet called Digital Decoder Reset Packet For All Decoders

 

Its explaination is:A three byte packet, where all eight bits within each of the three bytes contains the value of "0", is defined as a Digital Decoder Reset Packet.  When a Digital Decoder receives a Digital Decoder Reset Packet, it shall erase all volatile memory (including any speed and direction data), and return to its normal power-up state.  If the Digital Decoder is operating a locomotive at a non-zero speed when it receives a Digital Decoder Reset, it shall bring the locomotive to an immediate stop.Following a Digital Decoder Reset Packet, a Command Station shall not send any packets with an address data byte between the range "01100100" and "01111111" inclusive within 20 milliseconds, unless it is the intent to enter service mode.

 

I am guessing this is being issued by the command station on powerup which would explain your situation perfectly. However without getting the oscilloscope out I couldnt confirm for sure.

Information from: http://www.nmra.org/index-nmra-standards-and-recommended-practices s-9.1 

Link to comment
Share on other sites

The Elite retains knowledge of locos in use only for a session, thus if it is powered off then that internal listing expires so the Elite cannot possibly send rest to any specific previously in use loco on startup, but it can send broadcast signals to all decoders.

I would quote specifics about such commands and their structure from my DCC book but it is 2000 miles out of reach for now.

Link to comment
Share on other sites

The Elite retains knowledge of locos in use only for a session, thus if it is powered off then that internal listing expires so the Elite cannot possibly send rest to any specific previously in use loco on startup, but it can send broadcast signals to all decoders.

I would quote specifics about such commands and their structure from my DCC book but it is 2000 miles out of reach for now.

 

 Hi RAF,

Thanks for that. Could you post the name of the book and/or author?

Many thanks

Ray

 

Link to comment
Share on other sites

I've been thinking about this for a little while now... well, about a couple of hours... and this is what I am thinking of:

My oldest brother is somewhat a tech whizz when it comes to music and sound files etc. I remember him saying to me a while back that music files are different to data files in the way they are read and utilised.

If power is pulled when a data file is in operational mode (being read or writing to disk for example) then that file will either just stop working or can be become corrupt. Let's worry about the first part of that statement only here... the file, when power is resumed will not start being read from the middle of it. It either starts from scratch or doesn't get read until you instigate the initial operation again.

With music, it's totally different. If power is pulled from the middle of a track or sound file it either stops with a long continuous tone until it is completely stopped by another means or it will pause and has the ability to continue where it left off. This is NOT always the case, I know, but there are times when this happens. This is because the music file or whatever is read differently and operates differently to a data file.

So is this what is happening here with the sound on the locos? I am going to do some searching on this and ask wor kid if this is possible with a loco using the technology we have at hand. If this is so then that file or sound is being dropped on power loss but the chip has the ability to pick it up where it left off but not by using any memory or cache in the chip for instance.

If you don't follow what I am trying to say I do apologise. I haven't found it particularly easy to explain this one but maybe later when I can offer up some fresh info we can all jump for joy!

Link to comment
Share on other sites

 

Could you post the name of the book and/or author.

Ray

 

Digital Command Control : the comprehensive guide to DCC by Stan Ames (with additional chapters by others).

Out of print and only available second hand from the likes of Amazon.

It's a bit dated in terms of current kit descriptions,but it has the NMRA basics and is written by NMRA 'officials'. 

Link to comment
Share on other sites

 

Could you post the name of the book and/or author.

Ray

 

Digital Command Control : the comprehensive guide to DCC by Stan Ames (with additional chapters by others).

Out of print and only available second hand from the likes of Amazon.

It's a bit dated in terms of current kit descriptions,but it has the NMRA basics and is written by NMRA 'officials'. 

Many thanks, RAF & John - I've just ordered it from Amazon.

Ray

 

 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
  • Create New...