TTS sound switching problems in RM Programs

[96RAF]

I have been using RM programs to run complex TTS sound sequences (spot and looped) and find there can be problems whereby the initial command can be missed at initial selection on, then when it gets the second command for off it actually uses that command to switch the sound on. As there is no further on/off command in the program listing that sound plays forever, over-riding the use of other selected sounds until the program times out when it will eventually stop.

 

There is also a problem of playing some longer spot sounds as RM sends the command twice in order to 'reset' the controller button. The problem here is when the spot sound needs a specific delay time to fully play out. A double hit from RM can throw the spot sound out making for follow on selection problems with the next sound. Ray 9in another thread) has suggested listing spot sounds as on/off the same as toggled sounds to see if this will preclude RM sending the double command. I have yet to try this.

 

His other suggestion to make toggled sounds a definite on command followed by a definite off command would prevent the out of sequence toggling but I feel this may be either a limitation of the decoder rather than something RM can write into code. Further investigation of this via Hornby/HRMS required.

 

Any other suggestions from the membership for reliably playing complex sound sequences (not limited to TTS decoders) in RM programs?. I am not talking about using a decoder to play an MP3 player or similar kit, just standard loco sounds.

 

Rob

[St1ngr4y]

If anyone, like me, has tried to read and understand the DCC protocol, you will probably, like me, find it tough-going. For loco decoders, it looks like they started out defining a data packet format capable of handling about 5 functions, then when sound decoders came along, they had to provide extra packet formats to cater for the extra functions. But basically the underlying theory is fairly simple. The loco decoder has a chunk of memory which is used to hold the "state" of each decoder function. This memory, like computer memory, is simply a collection of binary digits (bits) each of which can hold the value 0 or 1. So each function that the decoder can perform has its own "bit" to hold its current state, where a value of 0 means the function is switched off, and 1 means the function is switched on. When the user wants to switch on a sound, the controller sends a packet of data to the address of that loco, but that packet does not just contain one bit, set to 1, for the required function. Instead it sends a packet containing the state values of several functions. The original NMRA specification defines "Function Group 1" packet as containing the values for functions F0 to F4. But now there are also other packet formats which send F5-F8, or F9-F12, or F13-F20, or F21-F28 etc etc.

How nice it would be, in hindsight, if there was only one packet for everything - one byte for speed and four bytes to cater for functions F0-F31. That way, every time the loco speed was changed, even by just one speed step, all of the function data would be re-sent, reducing the chance of a sound on or off command not getting through.

However, my main point here is that, the data sent to the decoder for a function is a definite 0 or 1, an off or on command, and that value reflects what the controller thinks the state of that function is. With the Elite, there is a display window which can be switched to groups of 10 functions at a time, and along the bottom of the window, there is a row of dots, each dot corresponding to one function in the group of 10. If the dot is showing the function is on. The Elink, of course, doesn't have this, but it is visible in Railmaster for latching functions - a green background for on and a grey background for off. But even then, RM can get these out of sync with the loco and for the life of me I can't understand why. If sometimes a switch on command doesn't reach the loco for some reason, it is possible to "kick" it into life by switching on or off a different function in the same group. I have several steam sound locos, none of which have lights, so normally for these locos, F0 is unused. But I define F0 as "Lights on/off". This means that in my Railmaster programs which use functions 1-4 for sounds, I can follow a sound on/off command by F0 Lights on/off. In this way, effectively, it will send the F1-F4 command to the loco a second time. It's a bit like having Double Pulse set to 1 in the INI file for points. I wouldn't need to do this, however, if the RM program would allow ...

 

Fn Sound on/off

 

to be replaced by ....

 

Fn Sound on

Fn Sound off

 

... so that the program could be sure achieving the correct outcome, rather than just toggling the sound from its current state.

 

Ray

[96RAF]

HRMSthinksthecommandskippingisduetovariousreasons...

Quote...

... The first and most basic is that the DCC decoder is busy and therefore ignores commands until it is not busy.  There is also the possibility that the program command queue in RailMaster is not able to send out commands to the DCC controller quickly enough.  Can you ensure the Bits per Second rate in Windows Device Manager for the DCC controller USB port is set to 115200.Have you tried running just the section of the program which deals with sounds and see what happens?  If it is consistent, then it sounds like the decoder may be busy.

...Unquote.

 

1. I wonder if the Elite will cope with the higher eLink baud rate. Also it is often just the first sound command it skips - busy doing nothing? Or is the first command preamble not being sent/heard. I would need to ‘scope’ it to be sure and I’m not content about rigging a USB ‘scope to a PC linked to an Elite also by USB, then probing the DCC signal, when the ’scope manual warns against parallel ground paths.

2. The decoder I am using does not have/use any motor functions, only sound, so there is no other part of the program to ‘comment out’.

 

Rob

[St1ngr4y]

Hi Rob,

This is exactly why I would like to see, in programs, the ability to send, for example, "whistle on" and "whistle off" as two distinctly selectable commands. Then, you could issue two "whistle on" commands, say, one second apart, followed by a "whistle off" or even two "whistle off" commands later in the program. Having two "whistle on" commands shouldn't cause the whistle to actually sound twice if both commands reach the decoder, because there hasn't been a "whistle off" between them.

 

Ray

[96RAF]

I have since had another response from HRMS saying the Elite will not work at the higher baud rate, so not to try it.

They also asked me again to try the program with only the sounds element. It only has sounds so I can’t turn off whats not there.

No further discussion about the Fx-on and Fx-off suggestion yet.

Rob

[St1ngr4y]

Hi Rob,

 

Did you try changing any of your "spot" sounds to "toggled" by adding "on/off" to their descriptions?

 

Ray

[96RAF]

Not yet Ray, but today is a train day so I will give it a go.

Rob

[96RAF]

Ray

I amended a couple of single play sounds to on/off in the loco definition screen and then inserted the extra line in the program listing after each earlier command.

I had to reselect each altered sound from the RM drop down as its old program description was now invalid.

Tried the new program but didn't see much if any difference in response, it still occassionaly skipped some commands so I put it all back to normal.

It would be better if RM could send a discrete ON and OFF for each toggled command because as you stated previously could send a double ON and a double OFF to be sure.

 

It is just very irritating when a command is skipped as the second command plays it when it should be switching it off, hence it plays to the end of the program and has to be manually stopped on the controller.

Rob

[St1ngr4y]

Hi Rob,

 

What you should notice is that there is no longer a delay on the first command, as there would be if the command was a spot function.

 

Do you watch the dots on the Elite display for each function as your RM program is working? They should match what the program is trying to achieve. You may be able to see whether the command is being lost between pc and Elite, or between Elite and loco.

 

Ray

[96RAF]

Ray

I have watched the function indicators synch on the Elite but today I was more interested in if the sounds I was hearing were the same as coming up in the program progress line.

 

The indicators are handy as you can cycle through the Elite screens to find out which sounds have skipped on/off then deselect them at the end.

 

I didn’t know there was a noticeable difference in timing between spot and toggled sounds, hence neither have I tried looking to see any difference in timing of program function events versus Elite function indicator activity. Maybe I will have to write another program just running a few more widely spaced commands to see if I can follow them on both screens. Unfortunately the PC and Elite screens are no longer adjacent in my train room layout. Previously I have videoed these type of events when my kit was within shooting range of a single camera, such as the Elite and a loco on the rolling road and an RM screen all in the one shot.

Rob

[St1ngr4y]

Hi Rob,

What I have found with spot commands is that when RM issues the command in a program, it then loops for about 2 seconds and then sends the command to "switch it off". The reason I have put these last three words in quotes is that it is NOT actually switching off the sound - it is just returning the status of the functuion to "off". So in a program if you have fior example...

 

10.00 Loco F2 Short Whistle

11.00 Point 0023 Switch right

 

.. you might find the point command isn't actioned until 12.00.

 

Also, if you have issued either an Accelerate or Decelerate command for a loco, then, while this is actioning, issue a F2 Short Whistle, for example, then while RM is in its 2-second hard loop for the spot function, it cannot action any speed changes associated with the accelerate or decelerate command. So adding such a spot command in the wrong place may necessitate the tweaking of the timing of the program.

 

Ray

[96RAF]

Thereby lies a problem Ray...

I am trying to overlay three channels of sounds, some are spot sounds, i.e. play once, and some are looped, i.e. toggled on and off. In addition each sound has a finite but different play out time, some as short as 2-3 seconds, some as long as 35 seconds.

 

In the case of a spot sound the play out time is the fixed duration of that sound, but in the case of a looped sound the play out time is clocked from when the OFF command is issued and can thus play on for many seconds.

 

Playing three sound channel commands is slightly different to sending three consecutive loco or point commands, where there must be clear breathing time after the last command sent before the next commamd can be sent. The sounds can be commanded straight after each other much like speed commands to different locos, but their various play out times must be allowed for before a fourth sound can be sent, else the decoder will ignore that command as it is essentially ‘full’. Hence much reference is made to the manual for these set timings.

 

If any command fluffs (regardless of where in the hardware chain) then it throws the rest of the scheduling out of kilter, worst case scenario being a sound that should be turning OFF is actually turning ON and can block later ON events.

 

If I try double sending any sound it actually hogs its own channel and the next spare channel, again blocking future commands. E.g. Sending a whistle twice will actually play that sound into two channels. Not so much a problem with a short sound but if I double send one of those long play events, it can totally block up the whole sequence until a channel clears and the next sound in the program after that cleared time point will jump in, whether it be a scheduled ON or an OFF.

 

The programs at present are just not reliable enough to guarantee that the commands sent will be actioned. Further work required.

Rob

[96RAF]

Ray

I have tried running the program as you suggested and when an event flags in the progress bar nipping across to see if the Elte has got the associated indicator showing.

 

Oddly in some cases the indicator was there but the sound was not playing and in some cases the indicator was not there but the sound was playing, else indicator and commands matched up around 80%, i.e. of 20 commands up to 4 did not match status with the Elite and/or loco. That doesn’t confirm where in the command chain the event is being lost, only that part of the command is being lost somewhere. Unfotunately I do not know the mechanism of how the Elite puts on the indicator as a result of a passing command from RM.

 

Backstop is if an event fails to switch on or off then it can be corrected manually at the Elite whilst the program is running. Unfortunately although the sound unit is spot on the RM program is still not really reliable enough to put on public display but I shall try shorter programs with longer gaps between commands in the hope it gets better.

 

The master plan was to have 3 sound units around the layout playing different ‘themes’ and merge the programs such that they would get on with it unsupervised, while I chin-wagged with folk.

Rob

[Colpatben]

Rob & Ray

 

I am following this discussion with interest as I have experienced similar problems, albeit with Zimo sound decoders with ‘Immersive Drive’

 

http://www.youchoos.co.uk/Index-QuickHelps.php?L1=WhatIsImmersive

 

But the problems are the same.

 

With ‘Incursive Drive’ the F2 Button is used to operate the loco brakes. By ‘Dabbing’ the F2 button the loco is progressively slowed down as if real brakes are being applied!

 

I do not have so much of a problem between function button operations as the actual running times of a complete track circuit for an N Gauge sound loco are much longer (in the order of 80 seconds.

 

However some problems do occur when F2 is activated as Ray says in the second post of this Thread:

 

‘The original NMRA specification defines "Function Group 1" packet as containing the values for functions F0 to F4.’

 

F2 Therefore has to be labelled as ‘Active Brake On/Off’, and each programme instruction has to be timed to slow the loco by the desired amount ie if it takes F2 held On for 4 seconds to stop the loco from a given speed then the programme steps would read:

 

Time at 98secs, Loco Stop (however with immersive drive the loco will now coast).

Time at 100secs, F2 Active Brake On/Off, (this operates and holds the brake ‘On’.

Time at 104secs, F2 Active Brake On/Off, (4 seconds later this operates and releases the brake ‘Off’.

 

So as you can imagine much more to do.

 

Please carry on discussing on this thread and I will chip in as and when I have a comment or solution.

 

Roll on Loco detection!!!!!

 

Or just turn the Active Braking Off for good.

[St1ngr4y]

Or just turn the Active Braking Off for good.

 

Hi,

 

Have you tried the "decelerate" command in a program?

 

Ray

[96RAF]

Good to have further input on these ill-working programmed events CPB...

 

I have been trying out my wide program timing gap methodology with a view to paring down the gaps until it went belly up then reverse a bit to hopefully end up with a stable sequential sound only program.

 

At first this seemed to be working until I got to the stage where I had listed conflicting sound commands in the program (i.e. calling up too many overlapping channels at once, which rings an alarm bell) so I deleted that sound. Save and rerun the program and oddly this deleted sound was still playing after the amended program ran out. Nothing in the program listing but when the program was run the Elite screen indicated this rogue function was on, so there is obviously a phantom command not purged by the RM program amend and save process.

 

Thinking initially that I had a fault with the sample decoder I had even drafted an email about it, however in another variation of this themed program listing I had the same thing happen with a completely different sound sequence using different functions, so it wasn’t the decoder at fault, it had to be RM programs.

 

I have yet to report this in to HRMS before I had tested all options.

Any suggestions as to what I can try...

Rob

 

[St1ngr4y]

Hi Rob,

Your observations tie in with things I have noticed in the past, mainly RM getting out-of-sync with the Elite and/or the loco. In the RM+Elite scenario, RM should be the "guvnor" - it should have control over the status (0 or1, off or on) of every function on every loco. For latching functions, this is reflected in the backround colour of the button on the RM display (Grey or green). Whatever it is sending to the Elite should contain the exact value 0 or 1 for that function and the Elite display should change to that value in its dot display even if it has that value already. The Elite should then pass this same value to the loco. I can't understand how things can get out of sync if these actions are carried out like this.

 

The only thing I can suggest is more monitoring - a DCC monitor on the track, and a USB monitor on the COM port to the Elite, to analyse what data is being transferred packet by packet.

 

Ray

[96RAF]

Ray

My problem with pukka monitoring is my ‘scope is USB i.e a box that uses the pc/laptop as its screen and software host.

There is a warming in the ‘scope blurb against providing parallel ‘earths’ by way of multiple USB cable screens, hence I have been loath to connect the scope to the track when the PC is also hooked up to the Elite by USB for RM purposes.

 

In previous testing I have already killed one Elite by connecting 2 of its back panel outputs that were illogically contra-phase each other to the ‘scope channels. This would not be seen as a problem in normal use as the device that would be connected to the errant output would have detected and reversed the bad polarity.

Rob

[St1ngr4y]

Hi Rob,

Yes I saw that warning in another of your recent posts. When my friend delivered my new DCC Arduino monitor, I had a small Windows 10 Notebook pc available to use for this, which I have on a small table next to my RM pc.

Ray

[Colpatben]

Or just turn the Active Braking Off for good.

 

Hi,

 

Have you tried the "decelerate" command in a program?

 

Ray

Hi Ray

 

If I remember rightly Decelerate knocks off 1 speed step every second, such that if the loco is travelling at a speed set at Speed Step 50 out of 126 then issuing a Decelerate to speed 0 it will take 50seconds to go from that Speed Step to Stop.

 

So in an 80 second programme I would need to issue the Decelerate statement at 30 seconds from the start.

Is that true?

 

Perhaps I will try it tomorrow

 

BTW the Christian name is Colin but I rather like Rob using CPB. 😆

 

[St1ngr4y]

Hi CPB,

 

Basically, yes, but the command is configurable. It has an extra parameter which you can put at the end of the command, preceded by a comma, which is the deceleration rate. The default value if it is absent is 1, meaning, as you quoted, a speed step per every ONE second. However, if you wanted a slower rate of deceleration you can increase this to, say, one speed step every 1.2 seconds. Similarly, you can have a faster rate of deceleration by using a value between 0 and 1, say, 0.8. Playing around with this value can provide excellent realistic decelerations.

So using your example...

 

Decelerate Forward [50} to [0],1.2 would take about 60 seconds to reach a stop

Decelerate Forward [50] to [0],0.8 would take about 40 seconds to reach a stop.

 

Ray

[Colpatben]

Ray.

That's useful, I should really read the Manual.

😳 Colin.