Nigelcliffe

Its "just" CV changes.   Trouble is, its a lot of changes to work out without data from the sound project creator, unless you've got a computer connection and running JMRI.  (With JMRI, its wait for about an hour to read in all the current settings).    

Ask the provider for the information on the full current CV allocation, and the changes needed to get what you want, its only a handful of changes needed - alter the function keys which call the relevant lines in the function map.   

Or, with a copy of the LokProgrammer file of decoder settings (not the sound file, just the CVs).   You can import the Lokprogrammer file to JMRI to save a lot of reading time.  

50 minutes ago, PaulRhB said:

As most are the development defunct Digikeijs I doubt it ;) 

 

It was a bit cheeky of them to use another manufacturer’s app anyway and any current manufacturers that do use it could transfer their interface to work with freeware apps like Withrottle or Engine driver. 
 

 

I'm pretty sure that Yamorc (technology successor to Digikeijs) already has a WiThrottle server, so works with WiThrottle and/or EngineDriver.     

Those with defunct Digikeijs are now looking at either hardware upgrades to their system, or interfacing via a computer to give the servers for phone/tablet clients.    Or £18, which might seem quite cheap in comparison, particularly if it's a per-user-account fee (App fees usually are, and screen shot implies it is).  Worst case is two payments, one for Android and one for Apple, covering the home layout.  

There are things in the Roco App which are not present in most other Apps.  That's because the Roco App was "app only" rather than "App as interface to a service running elsewhere".   So, the App holds the layout plan, the roster list, etc, rather than having those held somewhere else and only visually shown on the device.   The end result of control is achievable both ways (within the App, or interface to elsewhere), but having it all within an App offers some users a benefit which other common approaches don't offer.   

There is no charging circuit,  you need one, unless the loco maker has added one to the loco PCB (unlikely).   The standards for 21pin, and Next18 have just decoder positive and decoder ground.   

The Plux socket has some provision for charging managed by the decoder via the socket on a specific pin, in that case, start reading the decoder maker's manuals about how they've provisioned it. 

Train-o-matic "sort-of" expects a 3-wire stay-alive (ToM's own, or those from Lenz), though will function with a 2-wire stay-alive, though programming track reliability isn't certain with a 2-wire connection.   Third wire is a solder pad on the decoder for most decoder socket variants.     Zimo have a variety of charging circuits on different decoders, with solder pads, or can work via the decoder positive and decoder ground pins.  

7 minutes ago, Nig H said:

Thanks for your help. Should the led and resistor be in series or parallel, and should they be in parallel with the stay-alive or in series?

 

Nigel Hunt 

LED+Resistor are in series with each other.      The (LED+Resistor) combination is then in parallel with the stay-alive unit.    

A 9volt battery would also function as a test power source, and may be simpler to arrange.    The positive from the DC power source, goes to the positive connection on the stay-alive module.

Testing a simple stay-alive (capacitor, resistor, diodes) without a decoder:   simple way is to use a 12v DC input voltage (smooth 12v, not the output from a H&M controller), and connect a small LED and resistor (something around 10kohm, so long as the LED lights) over the 12v as well.   Power on, and the LED lights.     Disconnect the 12v.   The LED should stay on for a while, decaying as the voltage declines.    
Similarly, if there are any LEDs in a loco, those can be used as evidence of stay-alive functioning. 

Programming.   As indicated, yes, set CV29 before you start, and set the address.    Thereafter depends on the decoder, some CT's and some programming tracks can be problematic, others are fine.      However, if you have the address, then Programming on the Main works fine all the time. 

Bear in mind that Programming on the Main doesn't have "read" ability (unless you've got RailCom and RailCom capable decoders), so you either need values you read earlier or are trusting the manuals (ha ha), or going blind on the changes being made.  If using a computer with JMRI, then the sensible approach is to read everything before adding the stay-alive, then you know all the starting positions, and subsequent programming (on the main or programming track) from JMRI will be changes to the pre-stored values for that specific decoder.     

I'd fit as much capacity as there is space, particularly if using a Zimo decoder (there's a trick in a Zimo which needs big power reserves).   That means checking if any of the commercial devices fit as those usually use much more energy dense capacitors than home-built.   The size of commercially available devices keeps changing, eg, the relatively recent Zimo Staco-3 devices are fairly small, and I've seen a pre-production sample from another maker which is much smaller again (can't reveal who until they announce the product).   

In most decoders one can control the run-on time with settings in the decoder (ie. how far it will run without a DCC signal before the decoder will decide to stop).  And thus a massive stay-alive can't run for a yard or more without DCC signal.     CT's don't have that run-on time setting. 

31 minutes ago, WIMorrison said:

Not sure that the NMRA DCC ‘standard’ existed when Zero 1 was conceived 😀
 

just checked and NMRA published their DCC ‘standard’ in October 1993 - which was 14 years after Hornby started selling Zero 1 😏

Published seven years after Hornby __stopped__ selling Zero 1.

20 hours ago, Maudy said:

Hi,

I have put a tts sound decoder in my loco and the directional lighting constantly flashes whether the function is on or not and at the slightest of acceleration/deceleration and only works as it should at full power albeit in the wrong direction. It all works as it should on dc or when putting the non sound decoder back in any ideas?

 

Thanks Andrew.  

As the loco works with one decoder (the "non sound" one), then that suggests an issue with the new decoder.  Fault is one of:  installation problem, a setting is wrong, or a fault. 

3 hours ago, Maudy said:

Anyone any ideas? I know I can get the soldering iron out to sort the direction of the lights but don't want to do this and find the lights are still flashing!

 

Making soldering changes on a decoder seems rather drastic, when its clear the loco is fine from previous statements.  

2 minutes ago, CFL said:

Bingo!

 

Writing the reset then group two then group one gives the desired result, as in:

 

White lights in the forward direction of travel. Red lights at the rear. Alternate with direction of travel. Interior light permanently on even at standstill.

All light functions operate on f0, f4 does not toggle the interior light.

 

As you say it is a bit weird, I can  only think that something in group two negates a setting in group one. Writing group one after group two overwrites the negative.

....

Most likely that there was something else set that we didn't know about in the other Advanced Mapping Groups.  

The "reset" would (should!) turn things back to what the manual describes, which is only four groups set.   Then your programming changes have altered the first two of the defaults.   
The other two default groups should also mean that you have: F1-key is on/off for red at one end, and F2-key is on/off for red at other end.   (What's seen is probably the sum of keys pressed.   ).  

If you want other keys to do things, for using the tram away from the auto-shuttle, it's pretty easy to work those out now.   

Anyway, a result !    It might now work correctly on your auto-shuttle.       
And I have something else to add to my pile of obscure information about decoders and how to control things with them.     

Thanks,  those read exactly as I'd expect them, which is most confusing.

Group 2:

CV273 = 16      F0 Key

...

CV279 = 128    Not in Forwards direction (ie. reverse)

...

CV285 = 17    Outputs Aux1 (front red) and Aux5 (interior)

CV286 = 2     Output RearLamp (rear headlamp)

...

Several approaches here.

a)   Could change Group 2 to operate on a different function key, or without direction, just to see what happens.  May learn something.   For example, could try things on the F1-key, and with and without the "not forwards" setting, and see what happens.   

b)   Reset the Advanced Function Mapping Banks (on basis something else is set we didn't know about), and then program them again,  this time, start by programming only group-2, and see if lights work correctly with F0-key and Reverse direction set.   Then add group-1.       The Reset for the Advanced Function Mapping is done by writing CV8=3.   

Depends what you're trying to do: 

• Permanently changing a loco - alter CV29 to change the normal direction of travel. 
• Manually setting Advanced Consists,  add 128 to the consist address you set in CV19 for that loco. 
• System aided Consists  -  there is usually something in setting up a consist , as RFS outlines above.  

19 minutes ago, CFL said:

I did do the second group, all the readings were correct.

Sorry, by all lights I meant white in the direction of travel, red at rear and interior light illuminated.

OK,  so we seem to have group1 working, which is forwards,  but something odd about group 2 which is reverse.    We're close, but must be missing something.

With CV31=8 and CV32=0 set as before,  read and report all of these  (16 of them).   I'm expecting zero for them, except those we set in the group-2 earlier.   Anything not zero is of interest..

CV273, 274, 275, etc.. all the way to CV288

1 hour ago, CFL said:

Update:

 

CV 257 = 0 no lights at all.

CV 257= 144 all lights on f0 but only in one direction, the reverse direction no lights at all.

 

Oh so close...

Have you done the second group as well ?    First group is only in forwards direction, nothing in reverse.....     Second group sets the reverse behaviour.   

And what is "all lights"  -  do you mean we have red+white both ends, and interior, or "correct for forwards lights"   ?  

The replies you've had recently from Uhlenbrock are misunderstanding - the CV100 setting tells us the lights output is on Aux5, not Aux4.  And thus what they're trying to do won't work.  

This starts from using JMRI, and selecting the decoder:  Uhlenbrock / IntelliDrive2 / Tilig E44 

Open up the  "Ext Function Mapping" pane,  and select the option on drop menu of "Bank Programming".    And use that to select what's needed, noting the CV changes that happen as a consequence (below).  I then checked some of it back to the decoder manual.   

Assumptions (from previous standard function mapping values) - lights are on Front Light, Rear Light, Aux1, Aux2 and Aux5.   

Where I use "set" I'm expecting you to write something to the decoder. 

Where I use "check" its read it back the value.  If not correct, report the value you find before changing anything else.  Those values match what the manual and the JMRI page says are the defaults in the decoder.  

First step - enable the Advanced Function Map, 
Set CV96=1   (to turn off and revert to standard function map, set CV96=0)

Before we begin, need to set the Index Key Values,  do this once (we reset them when finished): 

Set CV31=8

Set CV32=0

Uhlenbrock extend the number of CV's available using the index values (as do ESU).  In Uhlenbrock's case, its always CV31=8, but CV32 can take values 0,1,2,3,4.   We're only using CV32=0.  

First Group :   Use the F0-key, in the Forward Direction, to operate the following lights:  Front Light,  Aux2 (rear light), and Aux5 (interior light)

( all with indexes:  31=8, 32=0  ) 

Check :    CV257=144  (F0-key and forward direction)  

Check :   CV263=0  (not needing the reverse direction here)

Set:   CV269=18  ( Outputs:  Aux2, Aux 5)

Check :   CV270=1   (output: FrontLight)

Second Group :   Use the F0-key, in the Reverse Direction, to operate:  Rear Head Light,  Aux1 ("front" rear light), and Aux 5 (interior)

( all with indexes:  31=8, 32=0  ) 
Check:   CV273=16  (F0-key)

Check:   CV279=128  (reverse direction )

Set:  CV285 = 17  (outputs: Aux1, Aux5) 

Check:   CV286=2  (output: Rear Head Light)  

Now reset the Index Key values: 
Officially ought to Set CV31=0.   But as the only value of CV31 that Uhlenbrock use is 8, you could leave this alone.  

Pedantically we also set the other index, Set CV32=0, but as it was zero anyway, no need to actually do this.  

That should be it  (famous last words),  with two groups set, the F0-key should operate the lights required in both forward and reverse directions.       
I wouldn't have got here without the JMRI decoder file, and it probably helps that I've written other JMRI decoder files, such as some of the Zimo stuff.  

If you still want the F2-key to offer the parking lights, and the F4-key to operate the interior when not using the F0 key, those need additional groups adding to the Advanced Function Mapping.  

1 hour ago, CFL said:

The CVs are:

CV 100 = 8

CV 101 = 0

 

The instructions insist that when an f value is moved then it's original CV should be set to 0, presumably to stop a conflict between the two CVs.

 

I just got out the Tillig instructions, according to them the decoder was initially set to:

CV 35 = 0

CV 36 = 12

CV 37 = 0

CV 100 = 8

CV 113 = 2

CV 114 = 4

CV 186 = 47

CV 187 = 8

 

Then:

f0 front light dependent on direction of travel

f1 sound if a SUSI is fitted

f2 rear light dependent on direction of travel

f3 sound if a SUSI is fitted

f4 interior lighting

f5 shunting mode

 

I hope this is of some help. I don't know why but something at the back of my mind says A1 isn't the control for the rear lights, it might be something Uhlenbrock mentioned in an earlier e-mail but I cannot check.

CV100=8  says there is a "shift" operating on CV38.     (below)

The remainder of your quoted information makes sense (though doesn't list CV38 which defines what the F4-key does.).   

The "set other values to zero" is more about "getting oneself confused",  it doesn't matter if you don't get confused.    So, example where they are not "set to zero" would be the tail lights which operate either on the Lights (F0-key)  or the F2-key.   

The CV100=8 meaning there is a shift on the values set in CV38.  CV38=32 now says that the lights are on Aux5, (not Aux4).    That then makes your end-goal more complicated,  can't do it by changing CV33/CV34 because its not possible with the "shifts" to have both the lights outputs (headlight/tailight) and Aux5 at the same time.  

So, the only other way to address this is the Advanced Function Mapping options.   

It should be possible, but it means putting all of the function behaviour within Advanced Function Mapping.    So, complete change of tack.  

If Advanced Function Mapping is turned on (CV96=1)  then all function mapping goes to the Advanced behaviour.    Question is whether you want to go there ?    I think it can be done.  

Trying to make sense of the decoder manual (my German is weak, so it takes a long time) suggests this is really a JMRI/DecoderPro problem as the sequence of CV's required is complicated.    There is a decoder for an Uhlenbrock/Tillig loco with a Next18 decoder inside JMRI, and that appears to have advanced function mapping functionality.  So that's where I'd go to set this up....   Making the changes (I have no decoder to check against) suggests there are three CV's to set to make it work.     So even without JMRI connected to your system, it would be possible to work out the values and set them manually....

OK,  I'm now starting to feel stumped.    For some reason a value of 32  (32 plus the other outputs in each case) in CV33 and CV34 isn't being acted upon.  

The values in CV38 should be irrelevant.   

Read back the values in CV100 and CV101       Its possible that a value is shifting how CV38 works (and thus how the F4-key works), and its not really "Aux4" as the interior lights output, but something else....  

12 minutes ago, CFL said:

I just changed CVs 33 and 34 as you said but the interior light still needs f4 activating. The directional lights still work as before. I also found with f0 off and f2 active only the rear red lights were on.

What should be tried next?

Thanks

Ian

Changed to what ?      I can't diagnose on guesswork.  

43 minutes ago, CFL said:

That all looks good but can you just check something?

CV 33 = 41

CV 33 = 38

Shouldn't that be CV 34 = 38?

Yes, sorry, CV34=38

44 minutes ago, CFL said:

If I understand correctly this puts everything onto f0, I then set the shuttle unit to run f0 continuosly, I run the tram via the shuttle and all the lights will work, the lights might or might not turn off when the tram comes to a standstill at each end of the track, if the lights are off then when the tram starts in the opposite direction the lights will switch on. If this is correct then I owe you a beer or three.

One last question, will the shuttle unit 'remember' the f0 command or, like the ESU Lok Programmer, reset to default every time the plug is pulled or will it keep it's memory as a decoder does?

If this works the lights correctly on F0-key,  then if F0-key (lights) is turned on, the head/tail/interior lights should remain on.   Which end shows head/tail should swap when direction changes.    You should be able to show that with manual throttle control.  

Then it depends on the Block Signalling Shuttle unit, which I also don't own, and have only just now read the manual.   
It depends how the FL experimental feature actually behaves.    It should work.    ( The manual is slightly misleading in referring only to CV33...  CV34 is also relevant once the direction is reverse rather than forwards).  

Not clear whether it turns the light off at each terminus stop, then on again before departing. That's whatever the behaviour may be within the Shuttle unit.  

I'd expect the shuttle to remember the setting between operating sessions (seems silly if it didn't). 

CV33 = 9    That's outputs Front Light (1) and Aux2 (8)  1+8 =9

CV34 = 6    That's output RearLight(2)  and Aux 1 (4)    2+4=6

So, the F0 key gives you directional headlights and directional tail lights. 

Putting tail lights on F2 seems to be a "train stopped in sidings" indicator, where its often the case to put red at both ends.    So, intended use would be "F0 to off, F2 to on, loco parked up not running".  

CV113=0  means that there is nothing set as directional in forwards direction on the outputs (so F2 will be non=directional). 

So,  from here,  you could add the interior lights (Aux4) so the head,tail and interior operate on F0 key: 
F0 key forwards:   CV33 is currently 9.  9+32, and CV33 = 41   (1 + 8 + 32 )

F0 key reverse:    CV34 is currently 6.   6+32,  and CV33 = 38  (2 +4 + 32)

Not changed the F2 or F4 keys, but if they're not operated (set to off), the lights stay will follow the F0 key.  

I can't see a setting in the Uhlenbrock manual which is "lights on regardless of what you do".     There is a setting for "lights on when moving", but it would mean the lights go out when the tram comes to a stop.   

So, that means its going to be easier to change the shuttle control device to have lights-on (F0) as part of its operation (which was suggested as possible earlier)

ESU decoder, don't know what's happening if the tram wouldn't move.   The lighting settings in an ESU are totally different, and bear no resemblance to the NMRA conventions on function mapping.   

- Nigel

1 hour ago, Martin Elsworth said:

Thanks again Nigel. I'm afraid my experience with electronics is more failure than success! A rethink is probably needed.
I've been reluctant to embrace full DCC to start with but with a suitable system could I dispense with the need for a control panel at all and just use the display on a tablet say?

Seems like a lot of effort (if not overly technical)  or a lot of expense.  And potentially both if not technical.  To achieve a lot of complexity with little value add.   Not sensible for a handful of turnouts, unless you need the DCC for something else as well.

Might be easier to re-think how things are controlled.     If its not simple to bring the indicators back from the servo mechanisms,  then you may find it quicker/cheaper to re-think how you control things.   

For example,  one MegaPoints (series-1, not the new series-2 ) 4-way servo board replaces ESU Switch Pilot Servo in controlling four servo motors.  It takes input from an on-off toggle switch (or one contact on a rotary switch, which can give a pointer on a track diagram).   Either switch clearly shows which way it is pointing, or if not happy with that, a double-pole switch can switch lights/LEDs as well as showing its position.   
The Megapoints 4-servo board would require five wires back to the control panel (one for each of the four servos, one common wire), and a power source in the layout.    

55 minutes ago, CFL said:

After a couple of wrong answers by the Uhlenbrock techies I finally got the following suggestion:

 

CV 50=16 no sound module

CV 35=0

CV 36=12 f2 switch red light

CV 37=0

CV 100=8 f4 switch interior light

CV 38=32

CV 113=2 red light only in one direction

CV 114=4

CV 186=47

CV 187=8

 

These are how the decoder is set up at the moment, the directional lights and interior light work correctly but need the f0 and f4 button on, f2 has to be NOT activated as the front white lights turn to red i.e. red lights at both ends.

That's still incomplete...

Can I assume   ?  

CV33=1,  CV34 = 2  (defaults covering the outputs "Front Light" and "Rear Light"  (which may be "Rear Headlight", depends how it is wired) )

We then have from your list above: 

CV35=0   (nothing controlled by F1 key

CV36=12     12  = 4 + 8,   so the outputs Aux1 and Aux2 might be Red lights at each end,  controlled by the F2 key 

CV37 = 0  (nothing controlled by F2 key

CV38=32   Aux4 is the interior light, controlled by F4 key. 

CV113=2    Aux 2 turned off in Forwards direction

CV114=4    Aux 4 turned off in Reverse Direction   (but we said Aux4 was the interior light...)

CV186=47     47 = 32 + 8  + 4 + 2 + 1.    So, Aux1,Aux2,Aux3, Aux4 and Aux6 operate as fade-in. 

CV187=8     Fade in time of 80 milisecs,  which is pretty quick, so not likely to notice it.  

I think there's a mistake in the above, and  CV114 should be CV114=1 (turn off Aux 1 in the reverse direction)

Which implies the wiring is: 
Front Light output = Front Light

Rear Light output = Rear headlight  (but just maybe one of the tail reds?)

Aux1 output =  Red light at one end (probably rear)

Aux 2 output =  Red light at other end (probably front), but just maybe the other headlight

Aux 3 output = not used

Aux 4 output =  Interior

Then the lights are likely to be: 

F0 key (directional, turns on headlight at either end)

F2 Key (directional, turns on tail-lamp at other end to headlamp)

F4 Key (not directional, turns on interior lighting). 

If that's correct...   then can look at further changes to move things to the keys you'd like them on.  

( CV50 = 16 means "not using Susi data, Aux3 and Aux 4 are normal outputs".  Susi data can be used for an external secondary sound decoder, such as those sold be Dietz. )

A decoder not working at all in a Next-18 socket suggests it wasn't "clicked home" quite properly.   

- Nigel

Its a bistable circuit, there will be thousands out there.     

I'm guessing (you need to check) that the button contacts on the SwitchPilot Servo connect to the device ground.  So, you need a circuit which switches to ground.   

Here's one of thousands of circuit ideas 
https://www.circuitbasics.com/555-timer-basics-bistable-mode/

If you can make that work, then a very simple change on the output would allow one of two LEDs to show, eg: 
https://www.555-timer-circuits.com/using-the-output.html

You'll need power, 5volts is fine, as is 12v for a 555 circuit.     

Its also a very simple circuit and simple program for an Arduino (and similar programmable devices) if that's something you've played with.   There are eight inputs to scan (simple, just keep scanning them each time round the loop) and will need four outputs, with the LED pairs connected as per the second link above.  

You'll need some more devices to "latch" the current on for the LEDs.    Any good at basic electronics ?  Its a very simple circuit.   

39 minutes ago, CFL said:

Those original CV values are the ones that Uhlenbrock told me I should change, at the time I didn't ask about the shuttle and permanent lighting, it was difficult enough to get the correct CV values just for any lights, as I said they gave me contradictory information so I had to go with a 'suck it and see' approach.

I did try on the SDCC1 but (when I finally got it right) only the front lights came on. When I contacted BLOCKsignalling the guy said he was surprised as the DCC information was sent in packets. What that meant was never explained and anymore help was not forthcoming.

As you say it looks like Uhlenbrock are difficult to fathom and after this palaver I go exclusively for ESU. Tillig & Uhlenbrock seem to be working hand in glove as an ESU decoder I tried would not work at all.

I think you need to step back to basics.   

How is the loco wired up ?   ie. which contact on the decoder socket goes to which light ?   That's either manufacturer's documentation, or tracing wiring inside a loco, or careful and methodical setting a decoder to different values until things work and reporting what settings do work.  

Alternatively, what is the list of values Uhlenbrock told you to change.   That will then allow someone to work out how Uhlenbrock think the model is wired up. 

Many manufacturers are using Next18 decoders to their full extent; there are up to eight independent lighting outputs on the decoders, rather than the two or three that the older 8-pin and 6-pin decoder sockets offered.  

An ESU decoder "not working"  isn't helpful as a description.   Doesn't provide motor power ?   Or is the issue the lights not behaving on the default settings ?   Which comes back to "how is the loco wired up". 

This does seem to be making things determinedly difficult. 

TWG points out that the automatic controller (SDCC1) can be programmed to turn on certain functions.   Has that been tried ?  Does it work, or at least partially work (ie. some of the lights come on ?) .  

1 minute ago, Michael Hodgson said:

If you've got a lot of locos and want to convert, it's still expensive because you have to fit them with decoders and it soons adds up.

If you've got a lot of locos,  you either had deep pockets, or the person you inherited them from had deep pockets.....   

Most people have far too many locos.  One regularly hears of people with 50 or 100 locos.  How many of them actually get run ?  How often ?    There's nothing wrong with a hobby of "collecting", but don't use the shelf-collection to put down someone else' interest in running.