KingEdwardII

That's my trick!! See: and Yours, Mike.

Colin, I wonder whether the automation that you're looking for might be achieved using a Raspberry Pi running software like JMRI or RocRail, rather than using an Arduino. If you used an Arduino, I think that you would have to implement a lot of software yourself, both on the detection side, since you need to know where trains are located dynamically, and also on the control side, since you have to set routes on the layout and drive trains. I am sure that this could be done using an Arduino, but from what I know about available software, it looks like a lot of work. Yours, Mike

I agree with Iain that the Digikeijs DR4018 is one very good option. It can control 16 on/off channels which can be used for lighting etc, each on its own address. Pay attention however to the max loadings - 3A in total but 2A on any pair of channels. Yours, Mike

My thinking is that, for a point motor fitted above the baseboard below the points, this is not a particularly big distance. For the MP1s that I use, it represents a gap from the top of the motor to the base of the turnout of 15mm. The equivalent distance on my own layout with the motors fitted under the baseboard is 12mm. I don't forsee any problem with this working successfully, unless the track itself is not held firmly and gets moved sideways when the motor switches. Using physically larger motors like Tortoise can give problems where there is not enough space to mount the motor above the baseboard, requiring an ingenious solution such as that shown by Pete above. Mike.

How far above the baseboard is the track? It isn't very clear from the photos in the link. I use MTB MP1 point motors. In principle, these could be mounted on the top of the baseboard in a hole in the foamboard layer under the points. On my layout with the MP1s mounted underneath the baseboard, there is a 12mm gap between the motor and the underside of the point. I am pretty sure that the control rod from the motor to the tie bar could deal with a gap significantly bigger than this - certainly 25mm and very likely more - the control rod is surprisingly rigid and does not flex much. Bear in mind that the motor itself is 17mm thick. If the distance from the top of the baseboard to the base of the track is very large, then I would consider mounting the point motor on a raised solid platform attached to the baseboard. One concern I'd have is to make sure that the track itself is held firmly in place, otherwise there is a danger that the movement of the point motor would shift the track sideways. I suppose that if the track is not held rigidly, you might have to consider an approach that attaches the motor to the track itself. Yours, Mike.

Privy at the end of the garden? That brings back some memories - my great aunt's house in the 1960s, the only one of our relatives who still had one of those. Taking a torch and a bucket of water down the path to use it in the dark evening. Luckily I never had to use it in freezing weather - my dad had tales of those times where he had to break the ice first before using the toilet. Not so long ago, this was the normal way of life for many folk... Mike.

Keith, I operate all the points on my layout with MTB MP1s - they are great. Very compact, easy to install with excellent adjustments if you don't line things up perfectly. Very reliable, low power and with a built-in switch that can handle frog power. I now drive them all from a touch screen using JMRI on a Raspberry Pi. Yours, Mike.

Keith, I think that the simple truth is that you need to download a .uf2 file to your Pico that contains all the modules that your programs are going to use - and at the moment, that does look a bit messy since this is all very new and things are being updated in real time ("it's still steaming in the morning air" as I said in an earlier post). There certainly seems to be: a uf2 file produced by the Raspberry Pi folks, which I think is quite vanilla a uf2 file produced by the Pimoroni folks, which I think addresses their hardware a uf2 file from the Adafruit folks for circuitpython The grousing mentioned by Kev above seems aimed at the Pimoroni material which clearly had problems. It may be that some of the programs you're trying to run don't make it clear which uf2 to use and clearly if stuff is missing, it ain't going to work. Alternatively, there are probably still bugs in that there code... Yours, Mike.

Yes, perhaps. Although the differences are so many it looks to me almost like scratchbuilding from generic Scalescenes materials to get something close to the original. Mike.

Andrew, I think we all agree that it's the voltage drop across the wire that counts. And I also agree with you that it is always better to over specify. I probably don't need a 2.5mm2 track bus on my layout, with its maximum cable run of the order of 5m and a max of 4 or 5 locos running at the same time, but the hassle of having to rip out and replace underspecified cable just isn't worth considering. Perhaps to assist the OP in deciding what cable to use, I'll provide a link to a useful Voltage Drop Calculator tool, which can give hard numbers to the use of any given size of wire, taking into account its length: https://www.omnicalculator.com/physics/voltage-drop Yes, short lengths of thinner wire are typically used - like the droppers from the track bus to the track which have to be soldered to the track and be as unobtrusive as possible. Their short length and the lower amount of current they have to carry mean that they are OK. Mike.

Keith, I assume that you found the Pico Python SDK document here: https://datasheets.raspberrypi.org/pico/raspberry-pi-pico-python-sdk.pdf This then references the general MicroPython docs here: https://docs.micropython.org/en/latest/reference/index.html An import statement references a module that contains a library of functions that you can use in the Python program. The machine module is described here: https://docs.micropython.org/en/latest/library/machine.html The machine module is supposed to be part of the MicroPython implementation. This article might help with first steps: https://magpi.raspberrypi.org/articles/programming-raspberry-pi-pico-with-python-and-micropython Yours, Mike.

Sorry - no can do. The hint is in my moniker

So I think it's a good idea to separate out the different connections that you are talking about: 1. "phones can all connect fine" - what phones are you talking about, and what app(s) are you running on them? - I assume you are talking about the phones connecting directly to the DR5000 over WiFi - i.e. you are not using your home WiFi system 2. "the Z21 app can't" - you mean that you are running the Z21 app on a phone, but it is unable to connect to the DR5000 WiFi? 3. "the computer can connect fine but can't control the device" - is this a Windows PC? - it is able to connect to the DR5000 WiFi? How do you know it is connected? - which app(s) are running on the PC that you want to use to control the DR5000? Separately, I'd like to ask how the DR5000 WiFi is configured. In particular, what Protocol is set and what port in being used as shown on p25, p26, p27 of the DR5000 manual. The protocol & port settings are very important for the clients that you are trying to connect to the DR5000. Yours, Mike

I'd be careful over the use of the term "mains cable", since it can mean two very different things. There is the solid core cable typically used to provide the supply to mains sockets in a ring main (etc). Then there is the very different stranded core flex typically used to go from a socket to some appliance. I would not recommend using the solid core cable for wiring a layout - it is not very flexible and it is generally not so easy to use. The stranded core flex is ideal - nice and flexible and easy to work with (hence the name!). Flex cable is generally available with wires having a cross section from 0.5mm2 up to 2.5mm2 - 2 and 3 core cables are the common ones, but it is possible to get greater numbers of cores if required - 5 core is quite common. It is easy to obtain flex and it is relatively cheap. The main drawback is having to strip the flex when you want the individual wires - but there are cases where having the 2 or 3 wires combined is useful, such as when running connections from accessory decoders to point motors. In my case, this involves a 3-wire connection for which I use 0.5mm2 flex. Yours, Mike.

Andy, The 1.0mm2 wire that I use for my accessory bus is rated to 10A, which is way more than my power supply is capable of providing. My accessory bus is drawing a lot less than 4A: I use point motors that have zero draw when not moving and ~150mA when moving. I have a relatively small number of LED lights that take only a small current. My future plans for semaphore signals involve using low power servos involving no more than 150mA when moving. I don't see the need for anything larger than 1.0mm2 for the forseeable future. Yours, Mike.

Its all about minimising voltage drop for the feeds to the track - the bigger the wire size, the lower the resistance and the lower the voltage drop. 16/0.2 is roughly 0.5mm2, which is a bit on the small side, particularly if you have a long cable run (say 3 metres or longer). I use 2.5mm2 wire derived from mains flex for my power bus and 1.0mm2 wire for my accessory bus. Yours, Mike.

I know that this might sound stupid, but have you got the 21-pin decoders installed the right way round in the '66? It is possible to mount a 21-pin the opposite way and if so, it would not work. If they are the right way round, then my suspicion would fall on the wiring in the '66 - has a wire come adrift? Yours, Mike.

Have you tried the Firmware Recovery procedure described in 3.8 of the User Manual? Mike.

Well, I think you can "get away" with quite a lot more if you model a preserved railway. All kinds of locos hauling all kinds of stock. Formations that fit the available space. Mixtures of different eras. GWR King hauling a fine rake of LNER teak coaches? No problem - happens in the real world on the preserved lines... Mike.

& I have come across another DCC servo controller which seems exceptional value: https://chesterfield-models.co.uk/product/arduino-dcc-sniffer-relay-servo-decoder-all-in-one-copy/ ...controls 16 servos using DCC commands.

There is the Digikeijs DR4024 DCC servo controller: https://www.digikeijs.com/en/dr4024-4-channel-servodecoder-with-4-additional-switching-outputs.html ...controls 4 servos using DCC commands

That is definitely what I don't want to do. The reason is simply that the mobile devices I use are not dedicated to running only Engine Driver apps - so having internet access is important to them and so the house WiFi is the best connection for them. It is also necessary for the Pi 400 to have internet access for software installs & updates and it also needs access to the house LAN for file sharing, backups, etc. I could connect all the devices to the house 5GHz WiFi, but in practice, connecting the Pi 400 via Ethernet is straightforward and simple for me since the Pi 400 is static and there is an RJ45 wall port within a short distance. Mike.

I'm assuming that you've never programmed this decoder before. In which case it will have the default address value of 3. Have you tried using loco address 3? Mike.

I think that Meister Bach would have been astounded (and pleased) at that use of his music. Sheer artistry.

Nah, beans is orf...