TWG

I am confused by your statements. You should programme the SDCC1 to turn the headlight on and then go on to add other things via CV33. The instructions say "If you want to turn on other functions (such as...rear light, interior light etc), check your decoder instructions to see if CV33 on the decoder can be used to map FL(f) to operate the required functions(s) when the loco departs the end sections". I am not an expert on function mapping, but I think that if you change CV33 to 34 (2 for the rear lights and 32 for the interior lights) this should achieve what you want. If you managed to have all the lights on permanently the tram would have both head and tail lights on at both ends, which would not be realistic. Your statement that Uhlenbrock ignore standard CVs is wrong. I have just looked at the instructions for the 73236 and CV33 is there, described as Funktionstaste F0 fuer Vorwaertsfahrt, which is what we want. Where did you get the idea that CV33 is Uhlenbrock CV38?

Have you rejected the lighting scheme described on page 15 of the SDCC1 instructions, which turns on directional lights and anything else programmed a second before the vehicle departs and off again on reaching the destination? This seems to me a good arrangement, because it is easy to set up and will save you head scratching and consumption of oil. Having programmed the SDCC1 in accordance with the instructions, you should then (I think) set CV33 to 32 to make the interior light come on.

At £145 the Piko SCL is, in my opinion, a remarkable bargain. However I think that it is now obsolete, replaced by the SCL WLAN. It no longer appears on the Piko website. DCC Train Automation do not have it in stock, but it is still available from Gaugemaster. The Smart Control Light WLAN, mentioned by moawkwrd above, is reasonably priced for a wireless device. I do not think that overall it is more advanced than the Uhlenbrock Daisy WLAN, though it does have a better display, support for the extended accessory format, Railcom Plus and XPOM. It is not based on the Daisy; Piko are going their own way with digital equipment. It has no connection for a wired controller and it has, though Loconet was included in the original specification, no communication bus. Regrettably in my view, Piko have come up with their own wireless system, rather than using the well established z21 or Withrottle - unlike the Daisy WLAN, which can also communicate with an ECoS or a Märklin CS3 - so there is no way to use a phone or tablet for control. However if these limitations do not bother you, the Piko product could be a good buy.

I wonder if you have started at the wrong end by assuming that the trouble is with the Multimaus. I think that you may be confusing current and voltage; you start by saying that "Multimaus too high of a current" but subsequent discussion has been of voltage. The general opinion, as I read it, is that decoders can stand the voltage that your system is likely to be putting out; this is especially true of good quality decoders such as ESU and Lenz. I am with Iain Morrison when he said above that "I think that your issue lies elsewhere and not with the Multimaus amplifier". I suggest that the problem might be in the loco. There could be a fault with the motor that causing it to draw too much current, or there might be a small (possibly intermttent) short circuit that is not sufficient to cause the digital system to cut out but causes the decoder to overheat. A decoder tester (e.g. ESU or Lais) is useful in such circumstances.

There is an up to date Uhlenbrock device, the Intellibox2 neo, which has a lot to be said for it (available from DCC Train Automation). I have had the previous version (Intellibox2) since 2010 and it has proved completely reliable. Intelliboxes are expensive (made in Germany) but a bit cheaper than the ECoS. It has an extensive specification and might be more sophisticated than you need, but it is worth a look.

Nigel Cliffe's statement above that there are no problems in principle with coreless motors is correct. Over the years I have bought a number of locos with such motors and have retrofitted others with high quality ones (Faulhaber and Maxon). I have never had a failure. It looks to me as if Oxford, probably to keep costs down, bought some cheap motors of dubious quality. The fact that your latest motor is different could suggest that they have realised their error. I hope that the new motor is satisfactory, but £5.00 for a coreless motor does not to my mind suggest a top quality item

I hope that I am not misunderstanding something, but I find your posts confusing. Setting CV30 to 128 is not mentioned, as far as I can see, in the Lenz instructions, but how did the CV get set to that anyway? How do you know that it did, if you did not do it? You say CV30 shows 4. Then you say that the setting of 128 made the chip get hot and short circuit so you could not reset it, though in your first post you say that you did reset it. Even if the overload protection was turned off, this would not of itself make the decoder overheat unless there was a fault causing this. You seem to be conflating overheating and a short, which have different fault codes. If there is a motor short the lights on the railbus (if it has them) would flash, but that cannot be the problem because there would be no reaction when you tried to set CV values. I think that, if we are to have any chance of helping you to solve the problem, you need to provide a more coherent account of events.

This is an odd situation. The Sonic instructions clearly show the decoder fitted in the direction of the chimney, as one would expect. As all NEM651 decoders must be fitted a certain way round, as Nigel Cliffe points out, no decoder on the market will fit. The only conclusion to be drawn is that Sonic have wired the socket incorrectly, so it would seem desirable to contact the firm to obtain their view. They need to do something about it.

The Roco decoder has a sophisticated specification and I expect that it is a good quality product. It is also very expensive, and as you have already purchased it seems to me desirable to find a way to use it. I suggest that you use a simple relay, able to carry a sufficient current, as an intermediate switching device; the decoder switches the relay and the relay switches the point. This admittedly adds an additional complication to the setup, but it is easy to implement. I have used such a system for many years and it has proved completely reliable.

I think it likely that the ESU decoder will work, but your problem highlights the unsatisfactory nature of the MTC21 standard, which is not a standard at all. The current NMRA document, as far as I can see, does not appear to specify which outputs are full power and which are logic level; it merely states that "the manufacturer must specify the maximum current allowed to be drawn for each output and input". The Railcommunity norm (RCN-121) requires that all outputs above AUX 2 are logic level. It also allows a variation, used mainly by Maerklin, in which AUX3 and 4 are amplified, which should be described as MTC21-M. The DCC Concepts decoder seems to conform to the DCC Concepts standard. As noted above, Zimo have a decoder that can be switched between 2 versions. I think it is regrettable that American and British producers stick to MTC21, which the NMRA said long ago should not be incorportated in any model after 2010. To my mind, it would be better if all manufacturers switched to the Plux22 alternative, which is now general in the rest of Europe.

Did the person on the other forum tell you how to attach the ESU device to your decoder? If so, disregard the following. If not, is it clear to you how you will do it?. The ESU stayalive has 3 wires. In addition to + and ground there is one called by ESU "charge". The instructions relate only to ESU decoders and show that this is connected to a function output (which one depends on the decoder type); then certain CVs have to be set to make the stayalive work. Current Piko decoders are made by Uhlenbrock; they are very similar (but not identica)l to the corresponding Uhlenbrock decoders. The Uhlenbrock instructions anent stayalives deal only with the Uhlenbrock version, which has 4 wires. However they do show + and ground connections, to which you could attach a 2 wire stayalive. You might do best to ask Piko.

There was a similar discussion not long ago arising out of the refusal of the Lenz importer to be involved in sending items back to Germany. I wrote that I sent items for repair to Uhlenbrock without much difficulty. I downloaded a Customs form CN22 from the Royal Mail website. This does not require any Customs codes. You have to tick a box describing the contents; I ticked Other and entered Reperatur (Repair). I took the package to the Post Office and paid £14 for tracked delivery with insurance of up to £250. I assume that Uhlenbrock did not have to pay anything on receipt as they charged me only for the repair. I had nothing to pay when I received the goods. So not really a minefield in my (admittedly limited) experience.

It is a reasonable inference that A&H have not told Lenz that they will not involve themselves in repairs. The two parties clearly need to discuss the matter. Am I right to presume that If a firm takes on the task of being an importer and agent there is some sort of a written contract setting out how business will be conducted? This would probably include responsibilities in relation to after sales service and support. Simply taking your profit margin and thereafter absolving yourself for any further responsibility is, if you are an accredited importer, not a commendable attitude in my estimation. It will be interesting to see what attitude Lenz take; I hope that Scottish Modeller will let us know further developments. There was a discussion in the forum some time ago about a similar problem with the ESU importers. I suspect that being an importer involves a lot of work and some small firms do not have adequate resources. I fairly recently sent a faulty device to Uhlenbrock in Germany for repair. I marked the customs form "Reperatur" (repair) and it duly came back without any problems. I would have been content to pay VAT on the cost of the repair, but no one asked for it.

Are you looking at the right manual? If you follow the link given by 96701 above to the manual to the LZH200, you will find in Section 5, starting on page 34, a picture showing what the various connections are followed by a full explanation.

The ESU pcb has a blue wire attached. You will need to solder the other wire from the stay alive unit to the solder pad marked GND. The ESU instructions show clearly where this is. When making connections remember that the ESU socket is wired for the Next18 version for sound decoders.

Something else that might be a possibility is the new Uhlenbrock LNWI module (63860), the release of which is imminent according to the website. This is designed to work with the Z21 app and will translate signals to Loconet messages for the Intellibox. Whether this would work with a Digitrax system I do not know, but I think that it probably would; the other way round, a Digitrax LNWI works with an Intellibox.

According to an Austrian dealer (Mostviertler Modellbahnhof) deliveries from ESU seldom take place, so it is not just the UK that is affected by shortages. The Mostviertler has quoted a message to dealers from Zimo about supply problems. An order for 50000 processors, paid for in advance and promised for August this year, has been postponed until March 2023. Alternatives have been sought and so far limited supplies found that will enable production of MS440 and MS450, MX615,616, 671, 689 only. The price of the chips has increased from €3 to €14. A surcharge of €10 or €7 will be imposed in the hope that this can be dropped if prices eventually decline. Zimo at present plan to absorbe the additional costs of revised PCBs, software and alterations to the production machines.

When a loco is running the base station is continually sending out messages, as you have deduced, to confirm to the loco what it is supposed to be doing. When the loco is stationary it does not, as there is no point. I do not know how other systems work (probably in a similar manner), but on my Uhlenbrock Intelliibox the refresh commands cease 2 minutes after the last change by the user or if the speed is set to 0. The time can be set to anything between 1 and 240 minutes, but I do not suppose that many people find the need to change it.

Have you any other devices, which have an additional power supply, attached to your Loconet bus? On my Uhlenbrock system I have had situations where the Loconet become confused, things stopped working and modules lost their programming. The solution was to change the power supply to the device causing the problem to one not otherwise connected to the layout

I have fitted a Krois digital coupling to a loco, which has a Döhler & Haass SD10A decoder. In the decoder instructions it says that an electric coupler is inductive and it is essential to wire a diode across the 2 poles to prevent a high back current which could destroy the function output. I am familiar with this concept and have such diodes on most of the relays on my layout which are connected to electronic devices. However, having looked through the instructions for other decoders which have an appropriate CV for switching off the function output to couplings after operation (Lenz, Uhlenbrock, Tams, ESU, Zimo) I can find no mention of the need for a diode. So is one necessary?

I suggest that you look at the Uhlenbrock Intellibox 2. This has two knob controllers in a tastefully designed box with a restrained display and pushbuttons with a quality feel. It is admittedly expensive (made in Germany) but is a very capable device. Mine has been totally reliable over 11 years and I would not swap it for anything else (except possibly a Z21). There is a new improved version called Intellibox 2neo. Available in Britain from DCC Train Automation in Somerset, who according to the Uhlenbrock website are the new official importers.

A good question. You probably would not. Sorry, my thinking was confused. There are however 2 reasons why I, if I had the Piko system, would want an internet connection. The first is for software updates. The second is because I think that the Uhlenbrock programme Daisy-Tool would work with the Piko. This makes it quick and easy to enter into the databank locomotive numbers and names, symbols for function outputs (including drawing your own symbols if the ready made ones do not include anything suitable), route setting etc. This can be done on the handset, but the process is very time consuming and tedious.

Another system that is worth looking at, in my opinion, is the Piko Smart Control light. It offers a lot for the fairly modest price and meets most of your requirements (though you would need a Loconet USB interface to connect to the internet). The SCL is an Uhlenbrock Daisy in a different box, which opens the possibility of using accessories from that manufacturer and other Loconet producers.

I am confused by this. I can see no evidence on the ESU website that there are different decoder versions for certain geographical areas, except in so far that ESU make decoders for various American locos where the decoder is incorporated into a complete replacement pcb, as is common in the USA. What makes you think that the decoder part is different? What is the "American protocol" for programming? How does it differ from the European protocol (if there is such a thing)?

So do Uhlenbrock, Döhler & Haass and Train-o-Matic. I agree with Paul Chetter's view on the advantages of updateable decoders, but the snag is that each manufacturer has his own updating device that is suitable only for his decoders. Such devices are expensive, so one either needs to be rich or to confine oneself to a single make of decoder.