Nigelcliffe

9 hours ago, Velocemitch said:

Totally different topic to track work and apologies if it’s in the wrong place, but DCC….

I’m coming back in to modelling after a long break, back when I built up my 2mm and N Gauge stock, DCC was confined to the larger scales, I think Zero one had just come out!

so looking now at the bewildering options, what is the best way to go with control systems, who does the smallest decoders? how does stay alive work? How do you graft these into converted Farish ( old Farish that is) locos or split frame scratch built chassis.

where the hell do you start, or do you not bother and stick with DC?

I’m tempted to change more for the possibilities of better running, than sound etc, particularly on the 2mm stuff. I gather the higher current and the stay alive chips help the ( always problematic) pick up issues.

I plan to build a hybrid layout with some areas 2mm, some finetrax N gauge, though currently I only have one suitable N gauge loco ( and about 8, 2mm ones).

Smallest (good) decoders, some combination of Zimo, ESU and Train-o-matic.   There are others who claim to be good and claim to be small, and they're neither in my experience (which is quite thorough).  

Fitting to old Farish designs, of the three or five-pole motor on a big metal chassis design.  Used to be "not difficult" with a device called a "digihat", which is an insulated bush, and thus separates the brush gear (typically lower brush on steam locos) from the track pickups.  The "digihat" may be becoming harder to find now, as most folk who wanted to convert those old locos will have done so.  They're very easy to make if you have a lathe (and really hard to make if you don't have one!).     Alternative is to remotor the loco, where "Tramfabriek" offer a number of motor kits as replacements, which will solve the pickup-connected to brush problem.   (But your costs are now approaching £60 per loco, with motor kit and DCC decoder, which is getting a bit silly priced for those old locos).  

Control system choice:  two questions really come to mind here -  what's your end ambitions, and what's the budget ?   

Stay-alive units are transformative in running qualities.   The higher track voltage doesn't make that much difference if you clean your track regularly.  

23 minutes ago, Izzy said:

You will see I have now changed the layout's name. ..... Anyway, since people always like to shorten names and so forth the idea that Blue Circle's Sidings would just become Circle's sidings seem plausible, so that's what they have become.

 

I think there's something rather nice about making a rectangular plank layout called "Circle's Sidings" from the same builder of a famously small diameter circular layout  :-)  

8 hours ago, jTrackin said:

I seem to keep coming up against negative comments on z21 systems but don't seem find any from LODI is that because one is old and Lodi is newer?

More likely that on UK/English forums, LODI is almost unheard of.  Probably more on German speaking forums if you frequent those. 

How many users are there on RMWeb who post about using LODI ?  Almost zero.   

How many retailers carrying LODI gear in the UK ?  Is it just one ? 

 
How many RMWeb users posting about Z21 ?  Lots - and that includes those who are using the Z21 software Apps to control hardware other than that supplied by Roco.   

How many retailers carrying Roco gear ?  Dozens, including "box shifters".  So, likely more threads seen. 

Age of development has little to do with it, other than time for a larger installed base to be established. 

17 minutes ago, WIMorrison said:

You will find people who don’t understand the difference between a z21 and a Z21 then buy the wrong unit, but that isn’t the fault of the z/Z21.

Though I would throw some blame at Roco for their naming of the two systems - that naming of Z21/z21 leads to confusion.  

Are you sure its not your phone deciding there's no internet access via the Prodigy module connection,  so instead reconnects itself to a different WiFi ?    As such, you need to look in your phone to tell it to not to hunt around for alternative ways to talk to Apple HQ (or where-ever its looking).  

Alternative strategies would be to use a computer on your home network to talk to the Prodigy system, but that requires different hardware from Gaugemaster/MRC.   

The manufacturer says eight connections at a time: 

https://www.modelrectifier.com/Articles.asp?ID=278

55 minutes ago, duff man said:

Many thanks for your interesting input. with Prodigy Wi-Fi I always had cable backup and needed it on more than one occasion. I'm going to have to take my time over this and investigate JMRI because I do like the simplicity of Wi Throttle. 

The WiThrottle you're used to via the Prodigy is the minimalist version (because the Prodigy gizmo has a minimal WiThrottle server).   A full WiThrottle server can do LOTS more, and arguably there are more capabilities in the Android "EngineDriver" App than the Apple App.    
It can:   label all the function keys uniquely for each loco (useful for sound or complex lighting);  determine if keys are "latching" or "momentary" (again sound, much easier if horn/whistle defaults back to "off" rather than needing a second push), give locos names rather than numbers, filter the set of locos offered....   and more.  

 

Adding the computer and JMRI, also adds the alternative WiFi throttle route via the WiThrottle server.   That gives Withrottle (Apple) and EngineDriver (Android) apps, which can have addresses entered in the App, or offer more options on filtering a list of locos.  
It is more complexity to iron out ahead of any events.   At a show you need to be telling operators to use one App, and that's it, not different Apps for different people.  

Also, if exhibiting, you need to be confident about WiFi, and what to do if/when your WiFi gets swamped.  See the experiences of several large "flagship" layouts at major shows in recent past with long periods with nothing working.    There are ways to make wireless work reliably, or, you need cabled backup.   
Cables might be simpler - its relatively cheap to get an ethernet cable adaptor for a phone/tablet, and providing a few network connection points (or long bits of ethernet cable) means they can plug in.   Or people bring with them Digitrax or Lenz handsets to be used if things go wrong.   OK, its not wireless, but if the WiFi gets swamped and you're not a wireless networking tech-head, then the trains keep running.  

10 hours ago, 5BarVT said:

        [ On JMRI reading in all CVs for function mapping an ESU decoder ] 

 

Thank you Nigel, I was wondering if it was my set up when it took so long to read in.

 

If you have the ESU LokProgrammer file for the CV setup (the better sound providers will send you this) then you can get the defaults into JMRI much quicker - there's a facility to import the ESU LokProgrammer CV file, and that gives the starting values for all the CVs.    Once read in, things are quicker as changes are just "write out and save", or "read changes on sheet" which is a much smaller set of things to read. 

It takes so long because of all the CV's to read, there are thousands of them.   Some devices are faster than others, but its still a long process.  

The isolation of the stock rails is the starting position, because in many track formations there will be other turnouts just downstream from the slip which will likely have polarities changing at crossings (frogs).   

When you get it all straight and working, if you then find that an IRJ is doing nothing because the rails each side are always the same polarity, then that IRJ isn't needed.      But, start from an isolated slip and get that working first.  

Double slips are like two turnouts which have been slid over each other.  If you pull it apart (mentally) so the tie bars lie beside each other, then the control of crossings (frogs) from each tie-bar becomes more obvious. 

1 hour ago, Tim V said:

.....

 

How many others saw the radio controlled battery operated Wickham Trolley in 4mm scale, or the radio controlled bus?

You just have to ask  :-)     

Trolley was a promise to complete it and take it out to a few shows.  Body by the late Chris McCarthy from an N-Brass 4mm scale etch, mechanism is my work.  It has P4 wheels.  

Its tight on ground clearance;  if a layout has anything above rail top (bits of tie bar mechanisms, crossing sleepers, etc..)  then the gearbox will catch on it.  

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....