Nigelcliffe

Good. So, no electronics failures happening randomly between router and z21. Now layout stuff... If you have a moderately organised toolbox, check which tweezer, screwdriver, etc.. is missing. And any close-up glasses you might have. That's likely your short ! Isolating each baseboard should narrow things down quite rapidly.

When testing/resetting at this level of problem: have you disconnected the wires to the layout from the z21 ? I would, because you need to establish if the problem is in the z21 and not the layout.

Unless the other electrical stuff in this new building is huge, I can't see what load balancing is achieving. Within the room, if you plugged an electric heater and a kettle in one side of the room, and your model railway in the other side, you'd be drawing 2 x 13A on one side, and less than 2A on the other... I'd ask sparky to do it the way you want it to be done - one phase in the room. If that means re-work, then so be it. If the solar stuff is on other phases, fair enough, that's not touching the sockets. I'll assume you have good reasons for the different phases.

Recommend a fan to suck air from the soldering area. A cheap 5v (typically USB) device will move quite a lot of fumes away - I turn mine round so it is "sucking" the air away from the workspace, and blows away from where I'm stood. More advanced would be painting booth with extractor to outside.

Which models ? Which decoders ? I'm not aware of any UK models where CV128 is the sound level. UK Bachmann models are mostly fitted with Zimo decoders, though some may have had ESU decoders. CV128 is the sound level for US sound decoder maker Soundtraxx. Randomly changing CV's in a decoder can have all sorts of unexpected effects. You need to start from knowing which decoder is fitted to a model.

Not quite. JMRI reads CV8. Value = 13, which is "Public Domain and DIY". It then reads CV7, value = 1. JMRI then tries to match all decoder files it knows about which have CV8=13 and CV7=1. ( With some values of CV8 and CV7, JMRI will know to look for more CV's which give a more precise identification of that manufacturer's decoders ). In this case, there's an Accessory Decoder which has CV8=13 and a range of values (CV7=0 to 39) which includes CV7=1. There are other decoders files which will be closer to the CV's in the PI Loco Decoder. You should start with those, and then edit the decoder file XML to give the CV structure required.

You're both not understanding things.... The JMRI file found is for a different decoder, its for an Accessory Decoder. And knowing who wrote the file (name crops up on JMRI developer email lists), its likely correct for that decoder. It happens to share the same values in CV8 and CV7 as this Raspberry Pi decoder's firmware. CV8 being the value for a public domain project (so can be anyone) and CV7 being a version number. Anyone can write their own decoder firmware and give it any values for CV8 and CV7. Its fortunate that the writer used the public domain value for CV8. But then CV7 is a lottery, and its almost certain that someone else will be using the same version numbers (numbers in plural because quite a few decoder files specify ranges of version numbers, so the total of 255 available numbers is occupied very quickly). If you want a locomotive decoder file in JMRI, you need to start from one and edit it, or write one from the bottom up. Once written, JMRI will highlight both decoders as possible options, your new file and the accessory decoder file. From only two CV values the computer can't tell what is being read, so its down to the human operator to select from those highlighted. - Nigel

Which is sensible for the Accessory Decoder it is intended to service. Its inappropriate for a different locomotive decoder. As I said earlier, "public domain" means that you're on your own to an extent. JMRI/DecoderPro is reading CV8 (where it finds maker=public domain) then CV7 (version number, that can be anything when there are multiple designers of decoders in the public domain). You need to write the correct decoder file, or start from one which is "close-ish" and start modifying. I suggest the MERG loco decoders in the same public domain area might be a good place to start modifications. Though you'll have to look elsewhere for the function mapping in the Pi decoder as that's clearly a "done our own thing" set of CVs to deal with the outputs on the processor (and need to delve into the source code to find out what's going on). I'd suggest that unless already reasonably experienced in DIY electronics and code writing, that there are better ways to learn about DCC: buy a couple of mid priced decoders from established makers and learn about the various settings. Train-o-matic might be one such maker, decent quality, good range of features, decent documentation and not particularly expensive. - Nigel

JMRI/DecoderPro identifies decoders by starting from CV8, then CV7, then other CVs depending on the results of the first two. As the source code in this decoder is available, the values stored in CV8 and CV7 are "whatever you set it to" when loading the decoder firmware. It would appear to be (reasonably) stating the maker (CV8) is "public domain". The decoder you say is matched is an accessory (turnout) decoder, so the offered CVs may be appropriate for that. But in the "public domain" area there will be little control over values used for CV7, so any match might be possible. Clearly if there are more CVs in the decoder, then its an option to create an appropriate JMRI decoder file. Its a trivially simple thing to do compared to writing decoder firmware for microprocessors. So, if CVs are available in the firmware, get on and add them. Decoders running at full speed usually indicate a failed output transistor in the H-bridge circuit, or a failed output on the microprocessor. The presence or absence of overload protection in the circuit may be important. I'm not quite sure what people thought they'd get with an open-source firmware and a clearly experimental decoder hardware build. Its stuff for those who want to tinker with the firmware in the decoder, not a sensible way to "cheaper decoders". - Nigel

I wouldn't connect both at same time for all sorts of reasons. ECoS and LokProgrammer use the same quick-plug screw block on their outputs. So it seems its trivially simple to just plug into the one required. If wanting a switch on a panel, then a double-pole switch can swap the ECoS for LokProgrammer access to Programming Track. Or a 4-pole switch gives more options (rotary switches being common, make sure its a "break before make" type, and if the supplier can't tell you the make/break behaviour, go to a different supplier!). As an example, with a 4-pole 3 position rotary it could be wired so that: Position 1 = LokProgrammer to DecoderTester, ECoS to Programming Track Position 2 = all off. (useful position, and insurance against wrong sort of rotary switch) Position 3 = LokProgrammer to Program Track, ECoS to Decoder Tester

No, that's for sound decoders. Glad its working. Decoders require a "load" to be present to enable a "read" to be transmitted by the decoder (typically this is a motor). If you add the power-car, you'll get a "read", but you're then reading the power-car, and assuming its the same value in the trailer. The decoder will take a "write" on its own, without necessarily replying, so it can be programmed. Some DCC systems get upset about the lack of a confirmation "read" and will report an error (depends entirely on your DCC system). See page 7 of the manual for the options in the Zimo decoder, but they're not overly clear on the likelihood of success.

Yes, that's entirely possible. So, turning the decoder over would be another option.

Basics - the 671N decoder has outputs F03 and F04 on the pins in the socket. The Default Function Map puts those pins on F3 and F4 on the controller. So much so good. The NMRA table for function mapping won't allow F0-key to control outputs F03/F04, so need to use a different method. Fortunately Zimo anticipated this, and allowed a trick in the mapping table, see Page 12, LH side in manual referenced by LMSfan72 above. It shows the rows extending round on themselves. The numbers in the table refer to the "bit" in the number, thus bits 0,1,2,3,4,5,6,7 have values 1,2,4,8,16,32,64,128 CV37, default is bit-1 value of 2, set to value of 32 CV38, default is bit-2 value of 4, set to value of 64 If the lights are now "backwards" - ie. you have front lights when trailer is going backwards, then reverse the numbers, so CV37 = 64, CV38 = 32 There are other ways of achieving the result, and depending how the unit is used (perhaps combined with other units) you might be needing those more advanced options. - Nigel

What's needed is the command logs from the systems to work out what's happening. I'd lay odd-on it being in whatever "Arduino" thing you are using because JMRI itself doesn't do this on other systems. What appears to be happening at speed zero, the system is also setting "direction forwards". (ZTC got this wrong, and the arrogant attitude of various company owners was one of several reasons why ZTC is effectively defunct).

Ignoring questions over future of TC (see other threads - unless you've already bought TC, I don't think you'll be able to buy a copy any more in the UK. iTrain offers very similar capabilities at lower price ). I'd not put Digitrax in the same box as ESU or Z21. Digitrax stuff remains somewhat ancient, and wedded to their own methods, so no RailCom, and other newer features. Fine if you have a big investment in Digitrax hardware such as BDL168's but otherwise I'd go for something more up to date (many LocoNet items can work on both Z21 and ESU ECoS, so its worth investigating if you have a large LocoNet investment).