jamespetts

There is that - the trouble is predicting whether that will be before or after required for the future layout. Given that the layout in question is behind one and a half larger layouts in the queue, perhaps it can wait - but there is real uncertainty and the small question of inflation, too.

These things seem to be selling out everywhere, and selling out on pre-order in a number of places. I am wondering whether to get enough of them now for a layout that I am planning to build in the future that will require several of these...

The MRC's new YouTube channel is here. Only one video so far, but do subscribe for more updates from the club.

Command station: HDL LocoCentral (kit of parts for self-soldering) Computer interface: HDL LocoBuffer (kit of parts for self-soldering) Servo control: HDL LocoServo (kit of parts for self-soldering) General I/O*: HDL LocoIO (kit of parts for self-soldering) Short circuit protection: MERG DCO (kit of parts for self-soldering; available to MERG members from the MERG Kit Locker) Booster: Digikeijs DR5033 DigiBoost Converter from Loconet-B to Loconet-T: HDL LocoPanel (kit of parts for self-soldering) Feedback (non-Railcom): Digikeijs DR4088LN/CS Feedback (Railcom): Dijikeijs DR5088RC Digidetect Turnout operation: Dingo Servo Micro 10 mounts (servos sold separately; I specified the 4x microswitch version) Fixed uncouplers: 20x4x2mm magnets embedded in the cork Automatic couplings: Dapol Easifit Computer operated uncouplers: Dingo Servo Uncoupler (servos and magnets sold separately) Automation software: TrainController Gold 9.0 DCC decoders: mostly Zimo MX617 and MX618N18 Stay-alives: Zimo SACC16 with ~4 470µF surface mount tantalum capacitors * Including powering and controlling colour light signals, receiving point positional indication feedback and uncoupler position feedback and, in the future, controlling relays for yard/station/town lighting.

Ahh, yes, that is a different thing. I can see how that might cause indeterminacy - I have some locomotives from OO Works for the planned 00 gauge layout that have pickups like this, so will need to think about dealing with this, either by adding more pickups or putting resistance wheelsets on the leading and trailing axles.

There is a very interesting mechanical system for this involving servos, but I cannot recall the details now.

In other words, when I asked, "Do you have definite information on this that I do not? If so, it would be very interesting to know the details. If not, then it seems misleading to describe it as "false" rather than merely stating that it is uncertain." The correct answer would have been to state that you do, in fact, have specific information that I do not, rather than falsely stating that I have somehow claimed "that an interface will be developed". I notice that you have now for the third time totally ignored the response to the effect that there is no possible good faith interpretation of, "There has been some suggestion recently that iTrain might one day support CBUS, but I am not sure how accurate that this information is" that amounts to the statement "that an interface will be developed". If you have information that I do not, hostility to me personally, rather than simply stating that fact plainly, is totally inappropriate and positively abusive. Miniature block instruments and bells connected to automation software such as TrainController would be a delight. If anyone manages to get anything like this working with automation, it would be wonderful to see a video of it in action. I know that one of the MERG members is developing a lever frame compatible with automation by having servos move the levers but also allow - in some cases - the levers to move manually.

I wrote, "There has been some suggestion recently that iTrain might one day support CBUS, but I am not sure how accurate that this information is." Can you explain how you can possibly conclude in good faith that this is in any way misleading, or how you can possibly conclude in good faith that this amounts to a statement that "an interface will be developed"?

Yes, quite: reliability is important for automation, as discussed in the video.

In terms of occupancy detection for turnouts, incidentally, one of the matters that influenced my decision to install them on this layout is that I am trying to make the representation of the signalling system as realistic, within the bounds of my resources and skill level, as the trains themselves. In reality, in the 1980s, switches and crossings would be fully track circuited and the occupancy of switches and crossings would be shown on the signaller's display and would in fact control whether points can be changed or routes set. (Also, do not forget that it is possible that a train under manual control in the yards might well end up on a turnout which the automation wishes to use in a route; trying to move a delicate, code 40 hand built turnout under a locomotive might possibly cause significant damage). This is similar to part of the reason to use point position indication: in reality, a points failure would be detectable by the signalling system in this era, and an error message would be given. I have gone so far as using the sound file from SimSig for this error message in my computer as the sound played when a points failure is detected for this reason. The next layout that I am planning, an 00 gauge layout set in the 1930s that will occupy the space above this layout, will instead seek to replicate, so far as it can be done within my skill level and resources, mechanical absolute block signalling, so it may be sensible on that layout to omit these features, which did not exist (or, at least, were not widely deployed) in the 1930s.

Indeed - the tail lamps will all be set to be DCC controllable so that they will only illuminate when at the rear of the train, and the locomotives have been/will be (only some are complete) re-wired so as to allow independent control of the front and rear lights. Unfortunately, for obvious reasons, it is not possible physically to remove the tail lights when not at the rear of a train, so one will have to make do with them being present but dark, which is the best that can be done for rakes that can be hauled in either direction without human intervention.

My own layout is set after the era of brake vans - but I do plan eventually to fit tail lights to rear wagons. I may have to add resistive wheelsets in the interim, however, as fitting carriage/tail lights can be quite time consuming and I may well wish to run the layout before I have finished this task.

Michael - RailCom decoders are not necessarily very expensive; the basic Zimo decoders (e.g. the 6 pin MX617) cost £20 and come with RailCom as standard. Nonetheless, it is not an essential feature; you just need to do manual data entry every time that you put a train on the track if you do not use RailCom. It is right that it would be unwise to plan on the assumption that iTrain will be able to interface with MERG CBUS, as this has not been confirmed, but I do not understand why Iain Morrison states with such certainty that it is a false rumour; do you have definite information on this that I do not? If so, it would be very interesting to know the details. If not, then it seems misleading to describe it as "false" rather than merely stating that it is uncertain.

Interesting. I shall have to consider that for my next layout. However, occupancy sensors for turnouts do enable a nice display of the train moving along the layout in the signalling display of TrainController. I should note that I do plan to fit carriage lighting, so the resistance wheelsets will mostly not be an issue.

There should not be any issues with trains passing from a section with a RailCom occupancy detector to a section without one: the tiny signal sent back by the RailCom equipped decoder is ignored by the section without a RailCom sensor. Just as long as your hardware supports RailCom and generates the appropriate RailCom cutout, there should not be a problem.

It is not essential to have occupancy dectection for turnouts, but I recommend it (at least for TrainController - check whether this can be done in iTrain). An occupancy sensor on a turnout has two functions: (1) it prevents the turnout from being changed while it is occupied; and (2) it prevents any route including the turnout being reserved while it is occupied. If you have a short train and a long turnout (as I have on my layout with class 121s and British Finescale CV10 turnouts), it is possible for a train to disappear entirely from being able to be detected while crossing a turnout.

To clarify: DR5088RC: connects with LocoNet, RailCom compatible DR4088LN: connects with Loconet, not RailCom compatible, has S88N bus interface DR4088CS: connects with S88N bus, not RailCom compatible. I am not sure what you mean by identifying turnouts here, and I wonder whether there may be some confusion over various concepts, especially the difference between blocks, occupancy sensors and train identification. A block is a logical section of track which may have one or more occupancy sensors to detect the presence of trains. It is also possible to have a block with no occupancy sensors, but this is best avoided for automatic running. Normally, turnouts are not in blocks. An occupancy sensor is a means of determining whether anything is drawing current from an isolated section of track, which may be a turnout or a length of plain track. Train identification (either using RailCom or Digitrax Transponding) is a system for allowing a decoder to send its address back along the DCC bus to a detector unit (usually combined with occupancy sensing capability as in the DR5088RC) to give this information to a computer. In TrainController, only blocks can have train identification inputs, and, while blocks can have multiple occupancy sensors, they can only have one train identification input. Turnouts can be associated with occupancy sensors but are not in blocks and cannot have train identification inputs. This may be similar in iTrain, but I am not sure; I recommend downloading and carefully studying the iTrain manual. In both TrainController and iTrain, once the computer knows the initial location of a train, it will track its movement automatically throughout the layout providing that it be moved by means controlled or detected by the computer (i.e. by automation, the computer throttle or a hand-held throttle while the software is running). Thus, only where powered vehicles will regularly placed onto the track by hand do you potentially need RailCom (and it is not essential even in these cases, although it does save significant amounts of work in manual data entry; make sure not to negate this work by setting up direction sensing correctly so that you do not need to tell the computer which way that the locomotive is pointing).

Thank you both for your feedback. As to MERG, there are a variety of people with different hardware and software setups in the automation special interest group; some of them use CBUS, others not. It is not the case that MERG people are only interested in CBUS based automation as I think was suggested earlier. In relation to the types of occupancy sensors, although I did not mention it on the video as this is not a necessary part of the wiring, I do in fact use three types of occupancy sensor; the DR5088RC RailCom sensor and the DR4088LN and DR4088CS. The only difference between the DR4088LN and DR4088CS is that the LN version connects to the LocoNet bus whereas the CS version uses the S88N bus. I do not need to use the DR4088CS - I could simply have used the DR4088 everywhere that I do not need RailCom (e.g. for turnouts), but the DR4088CS is cheaper than the DR4088LN, and the DR4088LN has an S88N interface built in so that one can connect up to 16 DR4088CS devices to each DR4088LN. The S88 bus uses RJ45 cables (the blue cables that you can see in the videos). I am not sure whether it was really worth the effort to use the DR4088CS as opposed to the DR4088LN - but I definitely recommend using the DR4088LN (or CS) instead of the DR5088RC for places where RailCom is not required because of the great difference in price between the two and the fact that there are many places on the layout where RailCom will never be necessary or useful (TrainController cannot even make use of RailCom data on turnouts, for example). In relation to mixing concrete and wooden sleepered track, this is intentional: this is how main line track was laid in the 1960s-1990s. It is only from the 1990s onwards that concrete bearers have routinely been used on pointwork. In the 1980s, it was also normal for yards and sidings still to be laid with old bullhead track.

The first part of this is not correct: the automation special interest group is headed by a person who uses TrainController, and therefore not CBUS. It is unfortunate that CBUS is not compatible with TrainController or iTrain, but there are alternatives, such as LocoNet, which I use. There has been some suggestion recently that iTrain might one day support CBUS, but I am not sure how accurate that this information is.

I do recommend joining MERG if you are interested in automation - there is an automation special interest group, which has a lot of very interesting information.

Thank you! Glad that you found it interesting. The short circuit prevention device is the MERG District Cut-Out, available to MERG members from the Kitlocker. The aluminium mount is the Dingo Servo Micro 10 mount, available here.

I have produced a video describing the electronics on an N gauge layout, Oxcott that I am currently building that will be fully automated and computer controlled. Watch it (completely and permanently advert free and free of charge; no login required) on Peertube here.

The poor little fuzz. My condolences.

How splendidly 1980s!

This calls for a photograph of the full rake, I think!