jamespetts

The only generic announcements that I remember were for found property, along the lines of, "If there is a Mrs. Joan Smith on the station, would you please come to the booking office on platform 4; that's Mrs. Joan Smith, please come to the booking office on platform 4".

After a little more refinement, here is an improved version. I have removed the distortion element of the PA system filter, as the pure tones generated by the chimes were not in fact distorted in the same way as voice captured from a microphone, as can be heard in the clips. I have also shortened the second note to make it more consistent with the clips and introduced a slight overlap between the notes to give it a sound closer to that which I have heard on the Youtube videos. The improved version is attached; this is also available with a Creative Commons Attribution Share-Alike 4.0 licence. Chimes.mp3

I am not sure about the progress of the software, but I have been working on reproducing the BR two tone chime that was common in the 1980s before being replaced with the three tone chime in the 1990s. I attach an .mp3 of the file produced. For reference, the notes are C# and A. As with the previous chimes file, this is available with a Creative Commons Attribution Share-Alike 4.0 licence. Chimes.mp3

That certainly looks more 21st century! Were you not satisfied with grey?

I have now obtained a copy of Oxford station working for the May 1989 - October 1989 period (i.e, the timetable period immediately preceding that of the working timetable that I found; this earlier period more accurately matches the period that I wish to model). Unlike the working timetable, this shows the following DMU shunting movements: (1) the 2C86 0051 arrival at Oxford (Mondays only) is a 6 car DMU comprising two three car trains; this shunts to the carriage sidings at 0054 and divides to form the 2C07 0530 to Reading and the 5C05 0450 ECS to Didcot Parkway; (2) the 2F01 0159 arrival at Oxford (0001 departure from Paddington) is marked as a DMU and has instructions, "detach van for 4M17 (2023) to Birmingham. Shunt to carriage sidings at 02+30"; the DMU is then kept in the carriage sidings overnight to form the 2C13 0803 to Reading; (3) the 2C10 0651 arrival from Reading is timetabled as 2x 2 car sets, which shunts into the carriage sidings and divides, forming the 2H12 0708 to Banbury and the 2H14 0727 to Bicester; (4) the parcels dock is used by the 4M17 2053 departure for Birmingham New Street; (5) the 2H81 2351 arrival from Bicester returns to Reading DMU depot ECS as the 2355 5H81, without combining with any other DMUs; (6) on Saturdays, the 2C24 1024 arrival from Reading shunts to the carriage sidings at 1027 and stables there until Sunday, where it forms the 2C13 0740 departure for Didcot Parkway; and (7) on Sundays, all the cross-country trains divert via the Cotswold lines (presumably due to engineering work) and regular 'bus services run to Birmingham International instead.

What I mean is that the greater the distance between the point where the software detects the train entering a section and the point where it has to stop, the more potential for slight inaccuracies to be magnified. One source of inaccuracy that cannot easily be mitigated is the different performance of motors when warm from being run compared to being cold - not even back EMF compensates fully for this. It may well be that inaccuracies of even fairly long distances between the occupancy detection break and the stopping point are still low enough to be acceptable in many situations, but where an especially high level of accuracy is needed (e.g. when coupling a locomotive to waiting carriages/wagons automatically), it is preferable to have the stopping point as close as possible to the actual occupancy detection section break.

It is possible to get accurate (as in circa +/- 1cm) stopping points using only occupancy detectors, but the trains must all be speed profiled fully to do this, and must use a good quality back-EMF decoder. The closer that the occupancy detector section is to the desired stopping point, the greater will be the accuracy.

For reference purposes, transcripts of those announcements are as follows: 1:43 "The 17:12 for Stevenage and London King's Cross will arrive at platform 2 in approximately 5 minutes. First class accommodation accommodation is at the front of the train. Platform 2 for the 17:12 for Stevenage and London King's Cross." 4:48 "17:22 to Newcastle, calling at Newark, York, Northallerton, [?], Eaglescliffe, [?], [?]borough, [?], Sunderland and Newcastle will arrive at platform 4 in approximately 5 minutes..." (the video cuts here so the end of the announcement is not heard).

I approve of scenery.

Thank you both. One thing that I wonder, however, is whether TrainController is capable of sending arbitrary LocoNet commands such as OPC_PEER_TRANSFER: I suspect that it is not. JMRI, I believe, can do this, but I think that TrainController is quite limited in its LocoNet implementation. I am not sure whether there is a sensible way around this.

Those are some very interesting and useful thoughts, especially as to the limitations of an Arduino and the actual number of steps available in the lighting strips, as well as the idea of doing all the calculations on the computer side. I wonder whether a similar thing could be done by way of a LocoNet interface?

Some very interesting ideas. I shall have to wait until my wired broadband is working again to watch Rudy's videos (I am currently using a 5g mobile hotspot following an internet outage), but the use of MOSFETs to switch the LEDs using PWM is particularly interesting. I wonder whether MOSFETs would be sufficient to switch ~7m worth of strip? I have been trying to think of the optimum way of achieving realistic layout lighting using an Arduino and LED strips on a TrainController controlled model railway. It may be some time before I am in a position to implement this for my railway, but it is useful to think of these things in the interim all the same. As I indicated above, I strongly suspect that strips of different colour temperatures of white (something like 2000k, 5500k and 7000k), all with a high CRI value (>90) will produce a much better light than RGB LEDs, as this is much closer to how daylight actually works. Adding a pure red, green or blue to a single colour temperature of white will produce a chrominance histogram with a large spike near the value(s) of the single colour LEDs, rather than the smoother histogram that one is likely to get by combining different colour temperatures of white. What one then needs to do is simply modify their intensities so as to produce a realistic mix for different times of day and degrees of overcastness. Ideally, one would want to have TrainController communicate to the Arduino the current layout time in real time so that it can update the lighting accordingly. However, a difficulty is that there is no easy way of communicating numerical data from TrainController to the Arduino. A possible way around this is to use multiple digital inputs on the Arduino, driven by outputs from a LocoIO device or similar, to make various numbers using binary. One could then write a script in TrainController that would run once a minute and set the various outputs from the LocoIO to the right pattern of states to represent the hours and minutes of the current time. One needs to be able to represent a total of 24 hours, so one would need a total of 5 bits for the hours channel (max. value: 31), and one would need a further 6 bits (max. value: 63) to represent the minutes channel, requiring 11 inputs in total. A further two bits (max. value: 3) could allow for an "overcastness" setting of between 0 and 3, 0 representing a cloudless sky and 3 representing thunderstorm conditions (and an overcastness setting of 3 in night time may well correspond to all LEDs being fully off). That would thus take a total of 13 inputs to represent the time of day and the degree of overcastness. I omit a further 9 bit channel (max. value: 511) to represent the day of the year, which would be used to determine sunrise and sunset time, because my own layout, as with many, will be set at a particular time of year, but for a layout not set at a particular time of year, this may be a worthwhile addition. One would then want to program the Arduino to give accurate sunset/sunrise times for the particular latitude and longitude in question. The Arduino could then be programmed to give a realistic level and balance of light for a number of points in the day for each degree of overcastness, and interpolate between those for each given minute of the day. A TrainController script, independent from the timing script, would set the weather, which could be randomised according to vaguely realistic patterns, which is probably what I will do, or based on actual weather records for particular days for anyone wishing to set a layout based in a real place at a specific date in history. Edit: What I am not sure of yet is whether any of the Arduinos have enough channels to allow for this sort of bit-bashing.

Very interesting! I love the idea of simulating a small cloud moving accross the layout: that is very sophisticated. I should be happy with basic non-addressable LEDs giving an overall brightness and white balance for the whole layout. I wonder whether the Arduino could have an input configured to pause and resume a transition between two presets? This could then be activated by the layout control software whenever the layout time be paused or on quitting the software so as to preserve transitions and keep them to the correct time.

Interesting - using relays presumably means that there are distinct steps in the transition? Ideally, one would have some sort of variable output PWM that can create a smooth transition, but I am not sure how one would achieve this other than using the Digikeijs unit.

I should anticipate that JMRI is much more suited to the sort of partial automation to which you refer; if you are not asking JMRI to handle timetables, then one of its major weaknesses in full automation is irrelevant.

That does look good. How did you interface with the MERG cards so as to be able to control the lighting using these; and how (if at all) were you able to get a smooth transition between different modes?

Interesting - those do have a good CRI. Controlling them is a complex thing: ultimately, one would want to control them from TrainController, iTrain or similar (I use TrainController) so that the lighting matches the time of day. This requires being able gradually to transition between different brightnesses and colour balances. Digikeijs supply a DCC controlled unit that tries to do something like this: it will transition smoothly (by a timer) between about four set scenes with different balances of RGBW, but the LED strips supplied are CRI unspecified and therefore probably <80 CRI, which is very poor. Also, they are stated to be "warm white", which is wrong for simulating daylight: daylight is circa 5500k, whereas "warm white" is generally circa 2,700k (i.e., the colour temperature of a tungsten filament bulb). I wondered about swapping the LED strips with those from Ali Express, but the wattage suggested that each 5m strip for each colour would take about 8A, which is more than the 6A for all four colour strips combined for each 5m segment on the Digikeijs module. This might be dealt with by using a resistor and omitting the useless green (and replacing red with orange), but I am not sure what sort of brightness that I might then get nor how well that the software would cope with the colours being meddled with in this way. Another problem with the Digikiejs unit is that it will transition between fixed states by a timer: if I were to pause the layout near the beginning of the day/evening transition (e.g. at 5 p.m. in spring), on resuming, the layout would be put immediately into full evening light (e.g. 7.30 p.m. in spring), which would look silly. Really, one does not need to have full RGB lighting for this function. Rather, what is needed is three different colour temperatures of white: one of 2000k - 2200k, one of 5000k - 5500k and one of 6500k - 7000k. These could then be combined in different intensities to model all of the various colour phases of daylight more accurately than using white plus colours. How to control this from model railway control software so as to synchronise with the layout time, however, is another matter entirely, and not something to which I yet know the solution.

InInteresting: have you a link to the CRI specified strips?

A shame - if one is setting up layout lighting for day/night cycles, it will make a huge difference to the appearance of colours on the layout if the white LEDs used have a high CRI (>90). Using low CRI LEDs has the potential to ruin the look of a layout. If anyone knows of any high CRI LED strips suitable for day/night cycle layout lighting, I should be very interested.

Am interesting topic. Does anyone know the CRI values of these LEDs?

The subject of station announcements in the 1980s is something that I have looked into in a little detail of late as I am working on my own automated announcement system for my model railway, albeit my system is not intended as a product for others to use, but is rather part of my own layout's automation using TrainController software. As I am developing my system bespoke for my own layout, I have taken a different approach to Phil/the developer of this system, and, instead of using a computer generated voice, I have recorded my own voice: this is viable for my process as I do not need to read out the name of every station in the country to do this, but rather just a limited number of calling patterns and lead-in/lead outs, delay notices, etc., necessary for the timetable that I will be running. However, I thought that it might be helpful to share some of the fruits of my research here for Phil or anyone else developing automated station announcements to use. First of all, the chimes. This is an interesting topic. My own memory of the details of this period is a little hazy as I was born in 1980, but I vaguely remember the three note chime as shown on the "Slam door train memories" video being novel in perhaps about the early 1990s or late 1980s (I think that I heard it first at Reading), suggesting that it may well have been new around this time. This is not by itself very reliable and it would not surprise me if I were proven wrong on this by more accurate source material, although the Youtube videos that I have seen so far have not falsified this. Phil's reproduction of the version of the chime used at Marylebone, which I think was fairly universal, is excellent. My own reproduction, which is here, created using MIDI software is slower and not quite identical melodically, but gives the general impression of the three note chime used at the time. Incidentally, my version is freely available under the terms of the Creative Commons Attribution Share-Alike 4.0 licence. In the 1980s, it was not at all uncommon for station announcements to have no chimes at all: see this video of Banbury in 1988, for example, at 1:56 (Edit: replaced the timestamp with a timestamp for a complete announcement). The video by City Transport Info linked above is actually an excellent example of the earlier, synthetic two note chime that seems to have been used a great deal at Ealing Broadway (and I had been trying to find this video for a long time, so thank you to whoever posted it). Here is another video of the two tone chime at Ealing Broadway circa 1990 (see 2:51): The two tone chime was not confined to Ealing Broadway, however: here is a video of it in use at Oxford in 1988 (see 8:19): This still seems to have been in use at Oxford in 1991, as seen here at 3:04: There seems to have been an intermediate style of chime, seen here at Reading in 1990 (13:14), comprising a three note synthetic chime: It is the melody and rhythm of this announcement that my version, linked above seeks to capture. As I indicated, I produced my version in MIDI software, and I was unable to find an instrument that matched the synthetic version of the chimes, so I copied the voicing of the acoustic version instead. Some other observations on chimes: these seemed to be used only by medium sized stations such as Reading, Oxford, Ealing Broadway, etc. Smaller stations tended to have more basic equipment, if they did announcements at all, and larger stations (e.g. Paddington) had such frequent announcements that presumably chimes would have been overly frequent and considered irritating and unhelpful. It was also commonplace - from memory - for chimes in the days of non-automated announcements to be omitted if one announcement followed closely after another. I have replicated this in my own TrainController implementation of announcements. Secondly, again, largely from memory, but also from fragments from the various Youtube videos, the actual pattern of words used in announcements changed over time. From the early 2000s or so, when announcements were automated, a standard pattern emerged (I am not entirely sure of how much regional variation that there has been in the last ~20 years) along the lines of: "The train now arriving at platform number / [platform no.] / is the / [departure time] / [operator] / service to / [destination] / calling at / [intermediate stops]; / platform / [platform no.] for the / [departure time] / service to / [destination]". The /s represent the boundaries between the different pre-recorded parts and consequent slight unnatural pauses. Pre-automated announcements were, as one might expect, more varied in style. Certainly in the 1980s, as we can see in the Banbury video above, the time was often omitted, and "service to" was replaced with "train for", so that one might get something more similar to, "The train now arriving on platform 5 is for London Paddington, calling at Ealing Broadway and London Paddington. Ealing Broadway and London Paddington, platform number 5". The actual words in the Banbury announcement are, "The train now approaching platform 3 for Oxford, Reading, Basingstoke, Winchester, Southampton Parkway, Southampton, Brockenhurst, Bournemouth and Poole." Note the omission of the word "is" between "platform 3" and "for Oxford...". In the video of Ealing Broadway in 1990 that I linked above, we have, "The train arriving at platform 2 calling at Westbourne Park and London Paddington..." (the announcement is cut off so it is not clear whether it ends here; and yes, platform 2 is correct: this video was taken during engineering works and a blockade of the relief lines). Intonation patterns were quite interesting and difficult to describe - suffice it to say for the present that they were quite different from the intonation patterns of the automated announcements and often quite distinctive. A good example of a distinctive intonation pattern is from this Ealing Broadway video from the early 1990s at 3:42 (and notice again the two tone chime): Note also the words used: "The train arrived platform 3 the late running 1823 service calling Hayes, Slough, Burnham, Taplow, Maidenhead, Twyford and Reading. Platform 3. British Rail apologise for the inconvenience". This announcement omits quite a few words for the sake of abbreviation: "the train arrived platform 3 the late running..." instead of "the train now standing at platform number 3 is the late running..." Note also the emphasis given to the word "inconvenience". One suspects that this announcer may have been at the end of a long shift. At some point in the late 1980s or early 1990s, sector names began to be introduced into announcements: in the Reading 1990 video above, just before the time stamp given, we have a reference to "Network Express" in a partly captured announcement, the "Network Express" services being the semi-fast locomotive hauled commuter trains from Paddington to Oxford, Newbury, Banbury and Westbury. It was around this time that speech patterns such as "the train at platform 5 is for London Paddington..." began to be replaced with "The train now standing at platform 5 is the 13:06 InterCity service to London Paddington...", the "[sector name] service to..." pattern being, from memory, a widely adopted standard that was presumably intended as a prelude to privatisation when the sector name would be replaced by the TOC name. Other noteworthy points about announcements is that they often referred to catering facilities, and, again if my memory serves me correctly, these references were standardised in wording in the early 1990s and phrases such as "a buffet car serving drinks, snacks and light refreshments is available aboard this train" became very common. For non-passenger workings, "The train now standing at platform X is not for public use; please stand clear of the train on platform X" or similar was a common form of announcement, with the phrase "not for public use" appearing to be standard. I also recall that there were fairly often non-train related announcements, most often in the form "If there is a [Mrs. Smith] on the station, would you please contact the booking office on platform no. 4" (which presumably would happen when Mrs. Smith dropped her purse or railcard and somebody handed it in). This is a delightful topic - really, the accuracy of the detail of station announcements is just as interesting as the accuracy of detail of the trains, track or signals for realistic operation, and getting station announcements to work in conjunction with the actual service of timetabled trains on a layout is a joy. If anyone can find a training manual from the period incorporating reference to how to make station announcements, that would be extremely interesting for anyone wishing to refine a system for modelling station announcements accurately. Finally, here is my video of timetabled operations on my own (under construction) layout, showing my automated announcements in action.

DCC decoders with back-EMF (most decoders have this in modern times; I have had good experiences with Zimo decoders, all of which have this feature and some of which are excellent value for money) give much more constant speed control on gradients than DC power (aside from the old DC feedback controllers, which were an earlier version of the same thing). Back-EMF will normally be enabled by default on decoders (it is enabled and set to its maximum level by default in Zimo decoders), but you should check this when installing a decoder to be sure. It is probably easier to choose one brand of decoders (Zimo, ESU and Lenz are the well reputed brands) and stick with it for all your locomotives to make it easier to remember how to configure each one. As others have pointed out, back-EMF will not help with wheel-slip situations, but that is a different kind of issue.

I should be interested to know how you get on with this. I looked into JMRI for full automation a few years ago, but decided to go with TrainController in the end because JMRI does not have the built-in abstractions necessary for automation without a lot of work writing scripts (e.g., the concept of a schedule). One would effectively have to write from scratch a very substantial piece of software in a scripting language to get serious, complex automation in which data are separated from code so that one does not need to undertake substantial programming work to change a timetable on a layout, and this may well be more than is workable without fragility in a scripting language (I think that someone tried something like this a few years ago, but JMRI updates broke the script). If you are an expert Java programmer, you might be able to add the necessary abstraction features directly into JMRI, which would be a happy thing for everyone.

There is some ambiguity in your post (which is understandable given the complexity of the topic) which makes it difficult to give good advice without a little more information. First of all, are you planning on full automation of the whole layout, semi-automation (e.g. automation of movements inside the fiddle yards only, or something else), or manual operation but with a computer interface instead of a control panel? Secondly, do you mean "block" in the sense that TrainController uses this term or are you referring to a physical occupancy detector section? The two are not the same - one can have multiple occupancy detector sections in a single block and it is possible to have occupancy detector sections not linked to any block (e.g. on turnouts). If you are planning on full computer automation, you need blocks on more or less every length of track that is not part of a turnout or closely connected set of turnouts. TrainController will need to know where trains are and signal/move them in accordance with blocks. If the only blocks that you are planning to have on the whole layout are those that are coloured, then you will not have enough for full automation. In terms of the "move up" functionality, I suggest reading the manual relating to this in detail; it has some very specific limitations, the details of which I cannot entirely recall, but which are of some importance in planning. One particular thing to bear in mind is this: if a given block in the fiddle yard encompasses all the track between a pair of turnouts, then, if any train is occupying any part of that block, the only way that the computer can tell that another train has entered the block is that it has left the preceding occupancy detection section. There are two issues with this: first of all, the farther away that the previous occupancy detection section is, the less accurate that the stopping point of the incoming train will be, so you are likely to need to have an occupancy detection section on the turnout itself (which will not be part of any block). Secondly, and more problematically, the DR4088 and other occupancy detection systems have a debounce feature meaning that there will always be a delay between the time that the train leaves a section and the time that the section is reported as unoccupied. This can be reduced in the configuration settings but cannot be removed entirely. This will also make the stopping point inside the block much less accurate. Accurate stopping is especially important for the move up feature. The solution to this is to split the block into multiple occupancy detection sections and in particular have a short section just after the turnout and before the part where all but the last train to fit in that section will stop so that you can control trains stopping in the block on the basis of detection of trains entering rather than exiting an occupancy detection section.

I also recommend updating the device's firmware to the latest version as older versions have some issues.