JZjr

The next project on my workbench is to bring my Lima Class 60, 60016 'RAIL Magazine', to modern standards. This is similar to what I have done to my Hornby Class 56 which has featured in this blog previously. I have found it cheaper than replacing the loco with the newer versions which are available - as with the 56, if I didn't already have this model, I would probably buy the newer version rather than buying this especially for upgrades; particularly because of the internal detailing which has already been completed on this model. As it stands, the model has had transparent grills fitted with internal detailing and has crude weathering applied. I have etched nameplates but they have not yet been fitted which I will do before weathering. I am undecided if I will put DB transfers on the cab sides - you'll find out later if I decided to in the end. Aims Lighting - Individually controlled running lights and cab lights. DCC Fitting - Fit a Plux22 socket and speaker ready for a LokSound decoder. Motor - Fit a new motor (if required after testing with a quality decoder) 60016 in 1999, before being named. Photograph: Steve Jones, licensed under CC Attribution 2.0 Lighting For the lighting, I have an unused Class 67 lighting kit from Express Models which I will adapt by removing the top marker lights which will come in useful when I repair my Bachmann 57 which will be done at a later date. Express Models do have a DCC lighting kit for the Lima 60 but it is not prototypical, there are other suitable kits though, the 67 kit is just what I had to hand. The lighting kit is easy to fit to the 60, the light clusters are glazed and are almost the correct size so no drilling needed. The head and tail light glazing is attached to the cab-end glazing and can easily be snapped off after scoring with a scalpel. The marker lights have a separate piece of glazing which can be pushed out from the inside with a needle or the blade of a scalpel, the hole for the marker lights is tapered so needs widening on the inside - I used the scalpel blade. The only other adjustments needed are: To cut away the chassis edge around the front to accommodate the black LED surrounds, I did scrape away a little of the paint while doing this but it is an easy touch-up. To mount the internal cab mouldings into the body rather than in the chassis so the lighting units don't foul it at the body is placed back on. The glazing holds the main clips for the body so careful placement is needed to ensure a secure fitting. Then, the Express Models LED's from the lighting kit slid right in and hold with friction alone. When testing from a bench PSU at 12v they are a little bright (not obvious in the photos) but I can dim them by adjusting the decoder settings and there's always the option to add an additional resistor at a later date if they are still to bright at the minimum setting. For cab light I will simply use small white LED boards which include a resistor, I bought these on eBay. I chose these due to the compactness, it can get a little messy inside the locomotive with lots of wiring and through-hole components so the fact that the board accepts 12-18v directly from a decoder is ideal - as with the running lights, I can adjust the brightness via the decoder if necessary. DCC Fitting I have purchased some Plux22 socket board from Illuminated models, using Plux22 gives me enough function for individually controlled lights without soldering to the decoder or adding a second decoder to the loco which can make it difficult when programming. Each end of the loco will use five functions (cab light, marker lights, tail lights, left headlight, right headlight) totalling 10 and the Plux22 socket gives access to 9 functions meaning that I will require one more function, the ESU LokPilot and LokSound 5 series decoders offer an Aux8 via a solder pad which is a full power function. They also offer a further four logic level outputs if desired - two via solder pads and two via the socket - although these by default are not enabled as the pins/pads are for different features by default. The intention is to add Legomanbiffo sound with a suitably sized speaker given the space in the body. The use of an ESU chip gives me an easy way to program complex rules which dictate what each function does depending on multiple 'states' of the loco. Motor If - after testing - the motor does need replacing, I intend to use a Hornby Class 66 motor bogie as I did on my old Hornby 56 - this time, I will need to create a mounting as I do not have a donor chassis. Basic testing with a bench power supply shows the motor has a starting voltage of 5.2-5.8 volts and the current draw looks good but doesn't run very slowly so will need further testing.

I've upgraded from 20.04 to 21.04 due to upgrading my motherboard and CPU, the newer onboard NIC wasn't supported in the kernel shipped with 20.04 so I upgraded in place. I've also installed 21.04 onto a laptop with no problems - that was using a USB stick though.

Thanks, it's a shame there isn't more flexibility but with the majority of the world using a single horn rather than the British two-tone it makes sense that only the single function latches by default. I'm open to changing the function mapping I use but with only a single momentary function I wouldn't know which horn to put on it so disabling it on a Digitrax might just be enough.

Thanks for the help from everyone so far. I'm chiming back in hoping someone can answer another question - I use a non-standard function mapping that will require customised latching options on a handset. For example, F2 is usually for horns and is a momentary function (that I know on some handsets cannot be changed) but I use F2 for 'Rear Tail Lights' while I have horns on F7 & F8 respectively. Which handsets give me the option to customise any function to be either latching or momentary? I've read that the WLANmaus offers this but I also know that I can't use LocoNet over Ethernet and have a WLANmaus attached to a Digikeijs command station - are there any other options? Thanks again

To us crew, they are Twerton Long and Short, couldn't say how long they been called that though. To many locals, they are the Carr's Wood Tunnels. Cheers

I can't remember hearing any of yours but I can't picture them with much zummerzet zest. Mine are all in an awful phone voice!

DCC controlled accessories aren't out, I'm just thinking I could throw something together that can control lighting with MQTT using mostly components I already have - maybe signalling too but the convenience of a ready prepared package with the correct settings for a range of signal head styles is quite appealing. The new digitrax handsets do look appealing, I'm going to look further into them, for sure. Thanks

Thanks Nigel, RailCom may not be a hard requirement but I like the idea of using block detection and knowing what is sitting in that block. Many of my models are RFID tagged for security anyway - I'm not sure if any of the tags would be readable from underneath but RFID detection could be an option. I have looked further into the Digikeijs and it does look like it could be the best option - price wise it is quite fair, and the ability to mix from a wide range of handsets means I could add a simple LokMaus or similar handset which would be super simple for the kids to use. Then I could add a more comprehensive handset to give access to a wider variety of functions for my sound unit. As much as I like tinkering and building, I'm not sure if I'd want a DIY style system - I think the Digikeijs may be a good balance between this and a complete, ready-to-use kit. I have enough to tinker with on my models and computers as it is. Cheers

It's definitely possible to start the local engine from outside the unit - I think 166's might even have a start button inside, I can't remember. It isn't usually done unless there is an engine that won't start remotely. Thanks

Thanks, I think it is just a case of getting used to it where they are the first decoders with that feature. Thanks for clarifying.

Currently, I use JMRI on my desktop for programming and testing. Without a layout, I haven't got any other DCC system currently. I am perfectly comfortable with JMRI and computing/Linux/Python although I haven't spent much time exploring anything beyond the Roster and Throttle as that is all I have needed. With limited space, I am building a hybrid model-railway/train-set for the kids (but mainly me). As many of my models have Loksound chips and most use functions right up to F28 or above I am looking for a command station that will connect to JMRI with little fiddling that also offers handheld cabs that can switch high function numbers - I know many can only do up to F19 or F20. The idea being I can teach the kids to use the handheld with the physical buttons being easier than the app (for adults too). I'm definitely open to mixing and matching components to make the system complete. Going forwards, I am looking to use accessory decoders for points, and possibly RailCom compatible block detectors. For signalling and other electronics I may well go down the MQTT route rather than using DCC-based signalling - that way it opens up very cheap control devices using a protocol that (in my experience) is solid and very well tested. While price is a concern, I'd like to keep the table open so I don't miss anything. Ultimately, I may end up settling for something less that the ideal device if it is too expensive. Thanks

I have waited during testing for plenty of time to check if it happens before moving off if I just leave it. I wouldn't say I am against using Zimo decoders but make full use of the extensive function mapping available with ESU decoders, pairing them with LokPilot FX function decoders to build complex rules around what can happen when. I have only briefly looked at the programming options on a Zimo (not sure of the model or age) in a 66 that belongs to @JZ and it doesn't seem to have anywhere near the number of options around function control but I am willing to explore newer decoders which are probably more advanced. It does seem a little odd, I spend plenty of time around the real things (well, not 150's or 153's anymore) to know that you can't really notice any delay at all between multiple engines starting unless there is a fault on one vehicle. It is something I can live with once I get used to it although it isn't something that my 170 does which is also a legomanbiffo project, although on a LokSound 4 rather than a 5. Thanks

That's a little disappointing, I have three 153's to chip along with another three 150's and another 158. I think I can live with it for the 150/158's but I'm not decided about the 153's. I might see what is about. It can be a little difficult to judge a project from a video as it is often recorded with a cheap phone mic. Thanks

Thanks for the replies, so it is correct that the second engine will not start at all until movement starts? On the real things, while there is sometimes a delay between engines starting - it's usually less than a second between them. Thanks

Good morning, I've been scratching my head over a small problem that I have noticed on a couple of legomanbiffo loaded Loksound 5 chips. The problem doesn't happen with Loksound 4 chips or with locos (56 and 66) but does happen on my 150 & 158. See the video below: (not sure how to embed videos on here any more). https://youtu.be/5FGU0K5Y09g Once the engine has started, when taking power the engine start-up plays again before it revs up. I noticed this after remapping some functions so I reset the decoder and found that it still happens. I have tested this on a Sprog and a Prodigy Advance so I am confident it is to do with the configuration of the decoder rather than the command station. If anyone has any ideas, then I'd be grateful to receive some suggestions. Thanks in advance Fred.