Nigelcliffe

If it is a Gaugemaster badged version, I agree, return to them, repairs are cheap (often free) and quick.  

If its an MRC badged version, either send it to the states, or spend time digging around to find out the part number of the encoder.  The Yahoo group for MRC might yield an answer on part numbers. 

- Nigel

Simon,

your engineer is correct on electronics theory.     But, practise seems to be that manufacturers don't bother.   The TCS KA units lack a resistor ladder (I've not dismantled a decoder with integral KA module, but would be surprised if they built them differently)  and the guidelines from Zimo omit resistor ladders.   I've not done the maths, but wonder if even with every component at extremes of tolerance ranges, the capacitor's tolerance of over-voltage may still save the day.  

Some manufacturers use different approaches; a single capacitor with a voltage multiplier to ring the lower voltage up to that needed by the decoder will avoid the issue.    

If fitting a resistor ladder, and tight for space, surface mount devices will be a lot smaller than conventional devices with metal legs; there will be hardly any current flowing in the resistors.  Or, if sticking the legs, metal film resistors are usually a lot smaller than carbon film resistors.    And, if you do fit a resistor ladder, then,  if you choose the total resistance of the ladder wisely,  the discharge resistor described in the Zimo manuals is redundant. 

I covered resistor ladders in an article on Stay Alive devices in ScaleFour News some time ago.   Its only an issue when using lower voltage rated capacitors in series to cope with a higher applied voltage.   Its not relevant to parallel capacitor banks to increase total energy storage.   I've never fitted a resistor ladder.  

- Nigel

Unplug from modem, then restart everything and try again.

Matt has described what is (most likely to be) happening. The modem sets its address, and the TP-Link router takes the next address range.

The problem isn't in the z21 - at least not from what has been said so far - its in the router configuration.   So, if swapping things, on the evidence so far, its the router which needs swapping. 

The router appears to be set for range 192.168.1.0 to 192.168.1.255.   But, according to the documentation and Dutch_Master, the z21 is factory configured for 192.168.0.111,  so the router needs to be configured for that address range (192.168.0.0 to 192.168.0.255).

As the z21 has a static address, the only way to communicate with it is by using a router with the appropriate address range.    

Your laptop and tablet will almost certainly be using DHCP, so they get an address allocated by the router they connect with (and that address will change with each different router they connect with),  so those devices should sort themselves out - the reason for using cable from laptop to router for configuration work is that it reduces problems to one place (network addresses) rather than several (network addresses, WiFi network names, WiFi security settings,  etc.. etc... ).

- Nigel

Assuming fixed address in z21, you need to reconfigure the router to use the range 192.168.0.x. I'd so this with the laptop set to DHCP, as the address in the laptop needs to reset as the router resets.

( this is heading to moderately complex networking, so tread carefully if not sure about things )

Suggest connecting laptop, by cable, to the Roco supplied router, and then interrogate what IP address is issued to the Laptop by the router.   

Then work from there.   It is possible that the router is mis-configured, or its possible that the z21 is somehow wrong.  I don't know if the z21 is shipped with a fixed IP address (so router needs adjusting to match z21), or whether it uses DHCP and gains its address from the router.   I suspect it has a fixed IP address.

Unless I am missing something, I have always been led to believe locking a decoder via CVs 15 & 16 only prevents it from being programmed.

 

 It does not prevent function keys being operable.

 

 In this case the momentum button will still function if decoder is locked.

Yes, you've missed something. The momentum button is a short-cut to "ops mode programing (using currently active locomotive) of CV 3 and CV 4, with values using pre-determined settings inside the PowerCab/ProCab handset".

The momentum button is not a "function key" in the sense of sending decoder function instructions to the track. 

Many thanks for the clear explaination Nigel. All but one of my decoders are Loksound (v3.5 and V4), so locking the decoder would solve my momentum problem......

 

The odd one out decoder is a Zimo.

Of your list, only the ESU V4 decoders support locking. Its not in the manual for V3.5. Zimo only has lock against Service Mode (programming track) changes, not against Operations Mode (main line) changes. So, from your loco fleet, only a few could be protected with locking.

- Nigel

I had never heard of locking decoders, more info on which decoders can be locked, what locking does, how to lock and unlock would be appreciated.

Decoder Locking exists in the NMRA standard as a "recommended practise", so its optional. Not every manufacturer implements it, and not all implement it the same way. So, its a case of "read the manual for your decoder". In the case of LokSound V4's, they do implement locking and appear to use the NMRA method.

The NMRA method is to use CV's 15 and 16. A value of "0" in those CV's is the default and is "unlocked". Locking requires setting one to another value, and then changing the other to match (to unlock). If a decoder is locked, then it does not respond to any CV change requests. (I can't recall what happens in the standards with CV19, consisting, because a lock on every CV would mean that advanced consist instructions would also fail to work).

The original idea behind it was locomotives with multiple decoders; locking would allow one decoder to be changed without changing the other. The NMRA document even includes recommendations as to which values of lock are used for different classes of decoder. But it can also be used to stop accidental changes when a loco is in use.

(Note to any JMRI/DecoderPro users; decoder locking is deliberately absent from decoder definitions. This is because reading/writing a load of CVs from a decoder file and then hitting a "lock" value part way through could have all sorts of unexpected consequences. Used in isolation, through setting the lock CV values as individual changes, locking works fine. )

- Nigel

i think that's a little unfair, the interface does offer JMRI support, - throttles (WiFi and computer) and point control. The limiting factor is block control and feedback.

My point was about "change of interface". The old 511 had an external device to support the computer. The new 611 is reported to have a USB socket, which implies that a USB cable plus the appropriate software elements is required. The changes from old to new at software level may be trivial within an application (eg. JMRI), or they may be extensive. That I don't know. I do know where to ask about sorting the software elements for JMRI, and a reasonable idea of what is needed to sort it.

Agreed, there is nothing so far announced in the ZTC line-up which will give block control or layout feedback.  But that can be done with an independent layout control bus, using kit from third parties.  

If he is keen on JMRI, then he might want to get the interface sorted - quite easy if the question is asked in the right places. That would then add smartphone and tablet interfaces - Apple & Android, and at a push even Windows phone.

Hi

 

You could remap it to be a brake button - how to remap buttons is explained pretty clearly in the manual

Are you *sure* this works ?    My reading of the manual is that it is possible to remap the "shifted" buttons, ie. those when the shift key is pressed.  My reading is that the only non-shifted button which can be re-mapped is "option".  

One solution is to construct a ring around the button from a thick material to make it more difficult to press accidentally. 

- Nigel

And a couple of years ago, TCS were sending dealers in the UK official notices about not selling certain products which contained TCS' copyright code. The notices were under UK/EU customs regulations.

( I've read one of those notices ).

Nigel

Interesting - what DCC hardware do you use?  I use a Lenz Set 100 with LI-USB.

Mostly LocoNet based hardware, some home made, others various makers.

If you want technical assistance with JMRI, head over to Yahoo and the "jmriusers" group. If you provide the details (hardware used, possibly a copy of the data in the system console) someone with relevant experience is likely to help.

Large delays between data received and command sent shouldn't be happening inside the computer, so the question is where the delay is happening.

- Nigel

I've been doing some notice JMRI position detection and have written a simple script.  There seems to be a significant delay (3000ms+) between the input coming from the Arduino to the loco responding (via XpressNet.

 

Does anyone experience the same issue and is there any way of fixing it?

Sounds like your hardware. I don't experience any measurable delays unless I've deliberately set a delay in software somewhere.

- Nigel

Thanks for the invite, but I couldn't wait. Thanks to a wonderful service from Scograil (no connection other than as customer), I already have a Z21 up and running. What a simple controller to set up and use. My old ZTC511 is not going to get much of a look in now.

If all the Z21 features are working, you should be able to connect the ZTC to it. There is a "sniffer" port on the Z21, which (in theory) means any DCC system can connect there. Also, the Z21 claims to support Xpressnet, which is the throttle bus protocol of Lenz, which is what ZTC is supposed to use.

Thank you to all the above posters. I am considering purchasing the Z21 and this thread has helped me enormously. One question I can't find an answer for. How does data get transferred from one tablet to another? I'm presuming that loco and layout info does not have to be entered into each device separately.

There is a "transfer stuff" feature in the tablet/smartphone Apps. It works, I've copied Z21 stuff from Apple to Android as part of the "DCC Theatre" setup in preparation for the Warley show. (So, if you want to play with a Z21, come to Warley armed with your tablet/smartphone ).

- Nigel

http://signalist.co.uk/ is another UK designer and manufacturer.

 

Also http://www.cmlelectronics.co.uk/

 

and http://www.dcc4pc.co.uk/

 

Andrew

Also, don't forget that little startup company Hornby. Last time I looked, their head office was in Margate...

It is safe to add supercapacitors to the MX645 (it is a 'PluX-like decoder' per the decoder manual and I have it directly from ZIMO proprietor, Dr Peter Zeigler), but there are less expensive ways to acquire them than cutting up TCS KA modules. Buy 2.7v 1F supercaps from suppliers like 'RS online' for about £1 each or much less if you can buy in bulk. Then wire six of them in series to give 16.2v and a massive 166,666 uF.

Thanks for that Paul.

I couldn't understand why there is a 5000uF limit in the manuals, and its good to know from Dr Zeigler that it doesn't really apply.

- Nigel

Do the 2mm conversion kits come with everything need to convert the locos, inc wheels?

 

3-680   Class 03 diesel shunter (Farish)  £15.00 each   3-681   Class 08 diesel shunter (Farish)  £20.00 each   3-700   Jinty conversion kit to convert Graham Farish Jinty to 2FS

No. Wheels are extra (driving wheels cost £7 per axle, which should be a clue!),

In general, the parts are just the etched sheet of metal. You have to add wheels, bearings, gears and other mechanical parts. This is described in the instructions (and there is a link to the instructions from the sub-title above the kits)

3-700 is a bit different, as it contains special bearings, muffs, gears. You still need to add wheels and crankpins.

It does suggest that some changes to the way the shop list is presented may be needed to make things clearer. I've added another sub-heading and the sales officer and I can discuss whether further information could be provided in the shop list in due course.

- Nigel

Thank you Nigel - I was hoping you would respond. I accept and understand your warnings.

Just to be clear however for an electronics numpty like me is the Zimo black wire that leads to the capacitor on their drawing (page 9 of the instructions) the same as your "Zimo Ground" -and therefore to adopt your second choice involves connecting that to the TCS black with white stripe (and the blue of the TCS unit connected to the decoder blue (positive)?

My interpretation of Zimo's drawings is that the black wire to the capacitor on page 9 showing the MX645 is "decoder ground". The "capacitor positive" may be something specific to the MX645's charge/discharge circuit and is not the same as the decoder "common positive".  The "common positive" appears to be next to the index-pin on the PluX connector.

But, this is interpreting drawings.  I've not had an MX645 to install - the big batch of 4mm locos I did for someone were mostly MX640's.  My own stuff uses smaller decoders. 

So, to be absolutely certain, ask Zimo. Or, I guess, look up the Plux socket on the Morop website (NEM 658, probably in German only), where it should be specified.

- Nigel

Its not "dead simple".  And, this reply gets a bit technical.

Some newer Zimo decoders have internal charging circuits for capacitors (resistor/diode/inductor), and then present those as two solder points or two wires.  The two contacts are decoder positive (blue) and a capacitor negative.  These contacts are designed to have ONLY capacitors connected to them.  The Zimo manual gives a voltage rating of the capacitor depending on decoder (the PLuX decoders seem to need 16v rated capacitors, other types depend on track voltage).

All Zimo decoders (old and new) have a decoder ground and a decoder positive.  The positive is the normal decoder Blue wire. The Ground is a solder pad.  Consult the Zimo manuals for the location of the solder pad(s).  On some designs (eg. MTC 21Pin), the ground is presented on one of the connection pins. 

Excluding really small capacitors, any capacitor connected to the ground and positive requires a charging circuit (resistor/diode) and ideally an isolation inductor.  A large capacitor needs a discharge resistor.  The relevant circuits are in the Zimo manuals for some decoder types (the diagrams on page 61 for the MX623 and MX630 is the clearest), and can be generalised to any decoder. The arrangement of the charging 68ohm resistor and discharge diode can be moved to the negative wire if that is more convenient (assuming one understands what each component does, and which way current is flowing !).    The voltage rating for the capacitors in this case will be based on the track voltage, and the 16v track voltage rating of the TCS KA units should not be exceeded.

I think the Zimo rating of 5000uF (0.005F) refers to their charging circuit (first paragraph above).  The manual describes it in terms of current handling (which usually translates to "heat").  I'm not totally convinced by the manual's explanation, but for now assume it applies.   

The TCS KA units are in the region of 0.1F.  

The TCS KA1 and KA2 are a circuit containing both capacitors AND a charging (resistor/diode) circuit.   It doesn't seem wise to duplicate this charging circuit (because it drops voltages, which means things don't work as well as they should).  So, the choice is

• Either : Chop up the TCS unit interally to by-pass the diodes/resistors, and then use the bare capacitors (in series) using the Zimo capacitor connections.  It may be over-volting the TCS capacitors as I don't think the KA2 series quite add up to 16v rating (in the original TCS package there is a little bit of voltage lost in the diodes).  And, it's approx. 20 times the maximum capacitance quoted by Zimo in their manuals.
   
• Or :  Connect the TCS to the Zimo Ground and Positive.  Ideally add a discharge resistor and decide if an additional isolation inductor is also required.  

I've used the second method - connect to the Zimo Ground and Positive, and then use the TCS KA1/KA2 without modification. I fit a discharge resistor across the terminals to force the KA unit to fully discharge when off the track - I measured 25 minutes discharge time with the resistor fitted.  I don't bother with the inductor, instead arrange things so they can be disconnected if I need to blow new sounds or new firmware into a decoder. 

The time duration that the stay-alive actually runs the Zimo decoder can be set in a CV.  So, you can limit the stay-alive run time to, say, 2 seconds. This is plenty of time to deal with any pickup issues, but avoids a loco ploughing along deliberately dead track (or a bare baseboard) for a yard or more without any control. 

I think you need to be sure you know how these circuits work, and what you're doing before starting.  There is a huge amount of energy stored in a TCS KA unit, and the potential for explosive discharge is present.  I'm not accepting any responsibility for damage you might cause !

- Nigel

Will multiple operators ( as in operating session) using mixture of Android and Iphones etc, work together on same Z21 system?

 

 Cheers

 

  ian

Yes. Its fine with multiple devices with a mix of operating systems controlling the same layout. I guess there is an upper limit, but not attempted to find it.

- Nigel

Looks very promising as a design.  

Another suggestion/question, to add to Ian's about volume keys,  is to whether you have been able to replicate the slider used in WiThrottle.   I think it is necessary to handle the WiThrottle App on an iOS device to appreciate its design - its by far the best screen-slider throttle I've seen on a smartphone.   The slider responds to "stroking", doesn't suddenly lurch to a new speed if you touch a different area, and (in the version with centre-off) has a distinct "click" at the zero position. 

Thanks for the information Nigel

 

It does sound a bit like my chosen DCC system is going to make this a little bit harder that it could have been.

 

Could you offer any suggestions as to how I could get information from any sensors into JMRI then as I am certainly going to want some detection at some point. I am also interested in the idea of block detection.

 

[......]

 

It looks like I have a lot of research to do but thanks for the replies - it all sounds very interesting.

 

I thought that JMRi was the obvious choice ( actually its the only choice I know about )

 

Should I be looking at ( for ) any alternatives ?

Picking up on several questions from a couple of postings

Gaugemaster/MRC,  probably not the best choice for automated running, but suggest you are cautious about throwing out and getting something else.   The main constraint is that for Gaugemaster/MRC the only software option is JMRI.    With other hardware there is a much wider range of options. 

Automated running comes in various forms; an entire layout running to a timetable, with trains going across each other without collision, is one extreme.   But what you described (run onto a turntable, select road, run off and park,  then repeat) is much simpler.     For the former, the common software choice is TrainController.  But for the turntable idea, JMRI will do it fine, and in some cases, it could be done with just hardware and an appropriate DCC system. 

Detection,  people like Phil and Andrew have outlined the types of detector.  What is also required is a means to get the information into the computer.  This will need some more hardware.  From where you are starting, I think there are three main options for hardware to report detection back to the computer:  LocoNet, MERG's CBUS, and S88.  

• The CBUS option means joining MERG and building your own electronic devices from kits, and to an extent you need to engage in the hobby electronics arena (ie. being interested in how it works, rather than just that it does work).   Supported in JMRI, RocRail.  But, not supported in TrainController.  
• LocoNet is Digitrax' network, well established, with a number of third-party makers (both ready to use and in kit form), so it is possible to buy things "off the shelf" to do the detection you require;  if you run a LocoNet and wish to keep the Gaugemaster system for control, then you are setting up a "stand alone LocoNet" (search on that term) - the difference is that "throttle" devices don't work on it.  LocoNet is very well supported in JMRI, RocRail, TrainController, and numerous other software products.
• I know least about S88,  its a bus system used by ESU and some other European makers.  There are devices for it from third-party makers.  And support in some software packages.   Beyond that, suggest searching !

Identification is another matter,  Andrew discussed it above (main systems are RailCom, RFID,  secondary options include Lissy, Transponding).  If you know the starting point on a layout (ie. where the trains are to begin with), then identification isn't needed,  the software would be able to track movement by "detection".   Identification can be useful, and can simplify things, but you'll need more hardware, and it tends to be moderately expensive. 

If you're going to Warley, make your way to the large Computer Control of Layouts demonstration stand where there will be lectures, demonstrations and people to discuss things with.  I'll be there, as will others with a connection with David Townend's "McKinley Railway".     It is also worth searching YouTube for the four videos about the McKinley railway, it introduces a lot of concepts which are needed for automation, but you don't need to use the same hardware or software as David selected. 

- Nigel