Track Occupancy / Shuttle Running

[bigal10]

I really fancy the idea of a little bit of automation, say, running a shuttle or 2, as mentioned in the ECoS manual.

 

This would allow me to run some other loco's at the same time around my layout (?) and provide some movement and interest.

 

The ECoS manual suggests that the 50200 will perform all the tasks, ie: set points, slow and stop the train, and after a suitable time, switch lights, and return the train to it's start position on the layout.

All that is required is a couple of occupancy detectors connected via the s88 bus, so as a starter, having read a million articles here and elsewhere I thought that the LDT RM-88-N might fit the bill.

 

Has anyone any comments on that unit?

Would it work OK with my ECoS 50200

Or (on Conrad's site) should I pay £4 more and go for the opto version?

 

And the big question, what sort of detectors? - Reed switch or what would you suggest?

As I run wholly DCC, I assume that reed switches would be a good option, as then I would only have to place a magnet on the chosen loco(s) to set the switch?

 

But then the REALLY BIG question, should I wait until ESU release their RailCom Detector? What on earth will that tell me about 4 locos that the LDT will do for 16 locos, for half the price?

I like the idea of knowing where my loco's are, but is it really any use to me?

 

Regards,

Alan

 

[TWG]

I have hesitated to reply to this question as I have never used an S88 system, but as nobody else has responded I give my views in the hope that they may be better than nothing.

 

LDT products have a good reputation and the RM-88-N will work with your ECoS.  It is important to choose a device that is to the S88N standard, which is comparatively new (the S88 system goes back to the earliest days of digital control); the N norm allows connection by cables with RJ45 connectors.  Previously connection was by a 6 way flat cable, which was very liable to pick up interference.  I think that it will not be worth going for the opto version; while separating the bus current has advantages the ECoS has this built in (moreover when I looked on the Conrad website the price difference was £13, not £4).

 

Reed switches would be a cheap and simple method of detection.  I think that I would prefer using a GBM8 unit with current flow detection.

 

As for your really big question, only you can decide if the cost is justified.  For the present purpose I doubt.  It is not even clear from the ESU instructions if their Detector would work with the shuttle.

[Phil S]

A Generic Answer that might have thoughts of wider interest/discussion:

1/ Double check with ANY 'feedback module' as these commonly only 'collate'/collect the informaton from your chosen sensing device - usually in the form of a 'common collector' input - so connection of power rail between feedback module and sensors is probably required. 

Opto-ISOLATION offered as alternative design on this module, if that is the case, is a way of keeping the 'collating module' electrically disitinct fromt he actual sensors in use.

 

2/ As for Actual Detection:

As a DCC user, it goes 'against the grain' to divide the track into uneccessary electrical sections simply to know where 'rolling stock' is occupying my track: My sections are chosen for reasons of 'power district' and 'geographically-based' fault-finding options, which have nothing to do with track occupation.

 

However, there are transformer-coil-based current detecting circuits which are DCC compatible, and will detect any current consuming rolling stock - locos, illuminated coaches and 'resistive axle' wagons.

 

A Reed switch is one of the cheapest methods available for contact detection - indeed Roco have built-in mouldings in their track to support their reed-switches 8-)

Now that small and strong magnets are readily available, this is a simple and effective method - of detecting specified rolling stock (usually locos).

 

I prefer to use Optical Occupancy Detection - whether by MERG Hector IR Reflective kits, or Beam-Breaks to cover junction pointwork - as this detects ANY stock present on the line - which is surely the intended function of 'occuancy detection' ... at least in the full-sized railway.

 

There is a differing level of coverage required for 'assisting' runing with track occupancy, and fully-automating the running - where slow-down and stopping points need to be identified as well ( although some decoders / controllers allow this to be done through software processes giving repeatability - and on a 'small' layout I have found this best suited to tram operation with their high acceleration and decelleration.

 

Also currently available is RFid reading - and again MERG produce a kit, and a 'concentrator' which combines readings from 8 sensors, or more, in cascade - this requires a unique tag on each chosen device, but gives complete identification when successfully read.

 

'Coming Soon' is a system form Hornby...

 

The S88 bus, as has been mentioned, is a widely used feedback bus, which originated back with Marklin, I believe, but has wider, open coverage  nowadays.

Proprietary feedback systems tie the user to one supplier (eg Rocomotion (hardware and software) with Roco Feedback Modules,

[TartanTrax]

I really fancy the idea of a little bit of automation, say, running a shuttle or 2, as mentioned in the ECoS manual.

 

But then the REALLY BIG question, should I wait until ESU release their RailCom Detector? What on earth will that tell me about 4 locos that the LDT will do for 16 locos, for half the price?

I like the idea of knowing where my loco's are, but is it really any use to me?

 

Hi Alan,

 

I'm not sure what you mean with "a little bit of automation" but thought to reply to your big question and see if that will provide more clarity. ESU has already released their ECoS Detect modules which have 16 detected zones for occupancy and 4 of these will also do RailCom. Generally occupancy is fine if all you need to know is that "something" is drawing power from the tracks in a particular zone. This could be a locomotive, lit coaches, resistive wheelsets or your pet cat, come in wet because it's raining outside and lying down on your tracks. If you want to know "who" is occupying a zone and in what direction it is moving, then RailCom becomes your best bet over all the other options mentioned. I know some will tell you RFid works just as well but that just isn't the case as receiving a radio signal just means the transmitter is nearby and not precisely where it is. The next most important aspect is what software do you want to use to do your automation? Most packages will use "prediction" algorithms to follow a locomotive around the tracks which, if coupled with RailCom to confirm the predictions every so often, generally works quite well. Prediction on its own tends to become confused by large "Irish harp" beds of tracks or several sets of points in succession. If the only computer you intend using is the ECoS then you are limited to the ECoS Detect (or their new boards which only have 4 RailCom zones per board) but if using a laptop or PC to run your layout you have several other options available depending on your choice of software. You may find a little bit of automation becomes quite a lot of automation once all the options are looked at.

 

Best wishes,

 

Ray

[Phil S]

Adding to Ray's reply:  I would suggest the 4 ESU detectors WITH Railcom® are used at the END POINTS where the control software needs to know WHICH loco to start using on the timetable sequence, and the 12 without (/module) should be allocated to the places IN BETWEEN .... where the knowledge of which loco is passing is derived from knowing already which one is being controlled in the sequence.

[bigal10]

Wow, thanks for the replies, guys, - and the phone call from Two-Tone-Green, whom I think you all know?

Lots to think about, just wish I'd read TWG's reply before I ordered my LDT RM-88N which is due to arrive any minute now.

 

I see what you all mean about occupancy, and the GBM8 would seem to be a good move, - reading LDT's website it seems that unit is designed for the ROCO system, but then one of their (LDT) wiring diagrams shows it connected to a RM-88-N-O and then connected via S88 bus to what?

Would that be able to be read by ECoS?

 

To dispel any fears, I only want to run one or two shuttles, not the entirety of my 21+ locos!

I still want the hand on the throttle approach, after all, Paul Chetter and the like spend umpteen hours/days/weeks programming so that I can enjoy endless possibilities of sounds/movement options!

 

Cheers,

Alan

[PaulCheffus]

If you want to know "who" is occupying a zone and in what direction it is moving, then RailCom becomes your best bet over all the other options mentioned.

 

Hi

 

From the testing I have done with Railcom it doesn't tell you which direction it is moving. I have tested this with Lenz Mini Gold, Mini Silver and Zimo decoders which give various pieces of information but never the direction.

 

One of the things I would like to detect is which direction on the track a train is going so that if the train is working reverse line (i.e. shunting) the automatic signals dont go green, yellow, red.

 

Cheers

 

Paul

[Nigelcliffe]

The notes I have on the Uhlenbrock Marco system (RailCom) indicate that two detectors are required to obtain direction of travel; and this will be physical direction, not locomotive command direction (which the control system should already know). 

 

If the identity and starting location is known (one RailCom detector, or pre-set starting conditions), then an adjacent occupancy detector should be enough for a system to deduce direction of physical travel. 

 

 

- Nigel

[TartanTrax]

Hi

 

From the testing I have done with Railcom it doesn't tell you which direction it is moving. I have tested this with Lenz Mini Gold, Mini Silver and Zimo decoders which give various pieces of information but never the direction.

 

One of the things I would like to detect is which direction on the track a train is going so that if the train is working reverse line (i.e. shunting) the automatic signals dont go green, yellow, red.

 

Cheers

 

Paul

 

Hi Paul,

 

The main problem with many manufacturers making RailCom equipment is that they may ignore parts of the spec for the system. The system as designed by Lenz stipulates that during the "cutout" the tracks are briefly connected to each other. While the DCC signal is a square wave alternating current signal, the RailCom transmissions are a DC signal with one rail positive relative to the other negative rail. As the transmissions are very brief (less than half a millisecond) NMRA spec compliant DCC decoders will ignore this as they do specks of dust on the line etc. Which track rail is positive and which is negative during a RailCom transmission is reflective of which electrical pickup is connected to the red and which to the black decoder wire. So, if we imagine a sequence of track zones called A, B & C and your locomotive is wired correctly so the software knows it is in zone B and pointing towards zone C. Then, if the next DCC command is a "go forwards at speed step X" command then the software will expect the locomotive to arrive in zone C once it gets moving.

 

By rights, some manufacturers claiming to be RailCom compliant should highlight any non-spec compliance but none have. Some, like Hornby's RailCom claims are simply untrue. Their saphire decoders are fully spec compliant but none of their command stations are even partially compliant as sold. Uhlenbrock have a RailCom implementation, Marco, that is partly hybridised with their earlier Lissy system which has introduced some limitations such as the direction of travel requiring two RailCom readers in succession or one reader and one occupancy detector etc. Some others have used incorrect resistor values in their readers which can cause problems with coach lighting etc. The brief answer is that the spec isn't very complex but non-compliance can cause problems. In terms of RailCom decoders, I am unaware of any that are non-compliant so I tend to buy based on price. When choosing your detection system you need to do some homework. The right system for you will depend on your choice of command station, your choice of controlling software and the features of your layout that you want to automate.

 

Hope that helps,

 

Regards,

 

Ray

[ColinK]

I could be wrong, but don't Tam Valley produce a DCC shuttle unit?

[IMG]

Hi Alan,

 

It's my first post and I just wanted to offer some words of encouragement.

 

I also fanced a bit of shuttle automation whithout going computer controlled so I purchased an LDT RMGB8N to try with my ECoS 50200. I think this works a little differently to the RM88N unit you have bought as it detects the resistance across the track from a loco.  I'm only using this on a short 12ft terminus to fiddle layout (hardly worth it really) so no middle layovers.

 

I'm using a short s88 cable (1m) to the ECoS - the longer wires being to the track.  I am please to say that it does work and I have had many enoyable hour watching a sound DMU shuttle backwards and forwards without touching it as I get on with other railway stuff.

 

They way it works for me is that the fiddle and the station have a break in the track one at each end on the same side approx 3 coach lenghs before the buffers.  You switch the shuttle on, power up to your max speed and watch the train trundle off.  When the motor crosses the break at the other end it slows down (ECoS switches the power off), stops changes direction waits for your pre set time and shuttles back again.  When it hits the break in the fiddle it slows down, stops, switches waits and repeats the cycle. I've linked this to the track layout so the section goes red when occupied.  From what I've read if you have a loksound V4 and an ESU railcom detector it will report the loco identity on the track plan. 

 

The time it takes to slow down is determined by your deceleration settings and engine speed so the faster you run it the further it travels past the break before it stops.  It can be a little tricky to set up in that getting the start end and direction right before turning on shuttle mode is important.  I have had engines setting off in the wrong direction and trains stopping in between the two sections and I have not quite got this sorted yet.  I've not tried the switching points.

 

For your middle layover, you will need a break in the track at both ends of the middle layover section so this needs to be long enough for the slowdown cycle.  Also you only need to detect your stop points, you dont need to detect any other sections between them which is something I learnt when I hooked up my unit.

 

I hope this helps a litttle.

 

regards

 

Ian

[TartanTrax]

Note, the Umelec ATLplus system pre-dates Lenz' ABC system by about a decade, I have the decoders to prove it Yes, these decoders are a bit more expensive then your average Lenz, Bachmann or Hornby decoder and will take a little more work installing a reed-switch (or Hall-sensor) but the benefits and cost savings are considerable. 

 

Got some older decoders from this Swiss chap, now saving up for a large® order to replace the old ones (the current decoder works with the Railcom cut-out enabled, the older ones I have will run-away uncontrollably and can only be stopped by physically lifting the loco from the track)

Hi Dutch,

 

The ABC system from Lenz, Zimo, ESU, Tams etc. is (as you no-doubt know) a rip-off version of the ATLplus system first produced by Umelec nearly 20 years ago. Umelec is a business owned by Ursula Meyer who is not only an electronic engineer but also a Swiss lady (and not a chap). Her DCC decoders are by no means cheap but as they are SOUND decoders with some pretty good features on board, they are cheaper than their Zimo or ESU competitor products that also offer the sound option. Like you, I also intend getting myself a few in due course.

 

However, for anything more than very basic automation I suggest that ABC (or ATLplus) may cause more problems than it is worth for a number of reasons. I did quite a lot of research on this method for controlling trains some years ago and finally gave it up as a non-starter. Speaking to Peter Rapp from Lenz some years ago, it seems this is their opinion too.

 

-The first problem users may encounter is that their command stations natively produce an asymmetric signal. I have an Intellibox from Uhlenbrock (bought about 15 years ago) that is guilty of this and at the time this wasn't a budget, entry level system. I tested a few other command stations at the time and only Lenz and Roco produced perfectly symmetrical DCC. Subsequently Zimo & ESU command stations were also tested and were also symmetrical, but as their decoders also included the ABC feature, that wasn't surprising and I would expect most modern equipment (i.e: produced more recently) to be OK.  

 

-The next difficulty was caused when using the "constant braking distance" setting. Any interruption to the DCC signal such as a dirt on the rails, would reset the distance causing the locomotive to crawl slowly past a signal set to stop. I believe that Zimo decoders (and from the details on the Umelec website, their decoders also) have a work-around for this, but I have over 50 locomotives with Lenz Gold decoders in them and would not be willing to rip them out and swap them for Zimo or Umelec ones.

 

-You can't stop trains in both directions at the same time. I have a fair number of points on my layout and thought I could switch track sections that would lead to a derailment, so as to stop the train and only allow it to go once the points had been changed to meet the oncoming locomotive. Problem was that in some places there was a relatively short piece of track between two points and if both directions were set to be asymmetric then the result was once again symmetric and neither direction would stop a train.

 

-Despite the claims for  simplicity, each of my points would require two sets of 5 diodes (and not just any diodes either, as they would need to be fast enough so as not to distort the DCC square waves) and also a relay for each leg of the point. So that would require 10 fast diodes and two relays per point and if all works to plan all you have prevented is your points causing derailments.

 

- And finally, your system still has no idea which locomotive is where and where they are likely to be in a couple of seconds from now. And I haven't mentioned double headers like the ICE train or consists etc.

 

Sorry Dutch, ABC braking is fine as a very basic, somewhat rudimentary add-on but isn't in nearly the same league as RailCom for automation. As for RailCom being more expensive, I'm not convinced of that either. If you cost both systems out accurately and check the marketplace carefully, you may be quite surprised.

 

Regards,

 

Ray.

[TartanTrax]

Hello Dutch,

 

I spent most of my life before university speaking mostly German but now, living in Scotland as I do, I rather miss it. I had assumed Urs was short for Ursula as I had never heard of a male called Urs before. (I have a male friend called Maria which is pretty odd but his parents are very Catholic so that might explain it.) I did some research and found you are right. Urs isn't abbreviated but is a boy's name found in Switzerland. You're never too old to learn, and thanks for putting me right.

 

I tried fixing my Intellibox using diodes but, as the asymmetry is introduced by an extra diode in its H-bridge, adding diodes to the track output didn't work. I spent many hours experimenting with an oscilloscope as well as running trains and finally gave up. The only solution would be to fix the H-Bridge and that would require a redesigned PCB so a job for Uhlenbrock and not an end-user. You say you bought a Roco Z21. In my opinion that is the most advanced command station available today. It isn't perfect but none of them are, but if they added a few more Amps and the ability to handle consists, they would be very close. I had better shut up now before all the ECoS owners get angry with me.

 

As regards the dirty track issue, that was a problem with Lenz Gold decoders. According to the spec on the ATLplus decoders they will only reset after a power interruption exceeds 3 seconds. Presumably Zimo decoders have something similar as they also seem immune to this problem. Sadly I have almost only Lenz decoders in my fleet so it is a problem for my locomotives. The spec for the ATLplus decoders looks excellent and I fully intend getting some to test as they are very reasonable for sound decoders and I am keen to have a more noisy layout. I managed to get a batch of Tams function only decoders off eBay for around £9.00 each so will piggy back one of these onto the ATLplus to get RailCom added and use the extra functions for more lighting etc.

 

In terms of my points and routes etc. I have around 20 points on my layout and can have trains running along routes as well as human drivers who are always an unknown quantity. Some parts of the layout are shared between two or more routes and trains can move in both directions so the idea was to make the system foolproof. (But as they say, nothing can be made foolproof because fools are so ingenious.) The main problem with ABC was that each section of track required 4 cuts to the rails at either end, a relay and 5 fast diodes (not Schottky diodes, but some I first bought, based only on the Amps & Volts they would cope with, pretty much destroyed the DCC signal so I had to get faster ones which then worked far better). With RailCom you only need one cut to one of the rails at either end of a zone and a single dropper wire to a reader, and now I can have one route for goods trains and another route for passenger trains. I can have only passenger trains stopping at station platforms while goods trains go through to the goods yards. Express trains don't stop at the village stations but speed through to the big city terminals etc.

 

The polarity of the asymmetry is used by ABC braking decoders to stop a locomotive in one direction only. This enables one to stop the train when approaching a red signal, but after passing a green signal and the occupancy detectors on the next section detect the train so the signal goes red, the train should not stop and it doesn't because the polarity of the asymmetry is wrong. That is why the system cannot work in both directions at the same time - because two asymmetries are once again symmetrical. In short, block detection and automation are almost always too complicated to solve using hardware alone, and software should always be cheaper than hardware, not to mention much more flexible and adaptable.

 

Finally you seem to believe your layout runs without a computer? The Roco Z21 is a computer in a box, just like the ECoS and most of the really high spec command stations available nowadays. System on Chip microprocessors have become so cheap that almost everything is computer controlled these days. Best of all the software on them keeps improving too. I learnt to program on an IBM Mainframe back in 1972, punching cards at a terminal and often having my work rejected by that blasted machine because I had used a semi-colon instead of a colon somewhere in my stack of a few hundred cards. The problem with computers today is that they have become much too easy to use, not to mention cheap as well. The huge hard drives on our mainframe cost about the same as a luxury car at the time. The trouble with the good old days is that we have forgotten how bad they really were.

 

Well Dutch, I suspect you have decided what you want to do and if that works for you then that's perfect. My layout has several difficult areas meaning that running more than one or two locomotives at a time without RailCom would be a nightmare while with RailCom I can pretty much run as many as I please without any danger they will derail or crash into one another and I haven't needed any magnets, LEDs between the sleepers, clusters of diodes linked to relays, reed switches or braking generators. When the RailCom detectors report two trains about to have a head-on collision, both trains stop because the command station tells them to. When a train approaches a point set against it, the point will change because the command station told it to, or if the point is occupied by another train the command station will tell the approaching train to stop. All this while passenger trains have priority over goods trains. It's just as if those little plastic drivers knew what they are doing as the entire layout can adapt to changing circumstances as they happen.

 

Well Dutch I hope the weather in Holland is better than here in the North of Scotland where we have had two days of dense fog and rain to amuse us.

 

Best wishes,

 

Ray

 

 

[Phil S]

Tartan Trax commented on the Z21, advocating that it would be better with more power output...

This is not necessary or always the best solution....

 

1/ The '764 Digital amplifiers used in the the Digital Start Sets can ALL be used as BOOSTERS - without any internal modification (if an external Y-splitter is used - or by adding the missing socket internally - the elecronics are otherwise identical .... it would lose the Railcom feature - but there was of addding that separately if required.

 

2/ Having a local current limit of 3-4A per power district helps avoid potentially catastrophic faults causing damage - where perhaps a continuous current of 5A might otherwise be flowing through a fault.

Don't forget that the larger the permitted maximum current in normal mode, the higher the wiring's current capacity needs to be (to all parts) and the higher the fault-tripping current.

If you don't need 8A for a confined area - don't let it have 8A !   IF you ARE using it for LGB, then use a high-current Booster, and keep the Z21 for the Accessory Bus, with less current in normal use.

 

The 'coin test' gets harder to PASS with higher rating Power Districts because the normal currents are presumed higher.

(I don't need to repeat earlier thread discussions on wiring size ... which it should be noted, is related to Controller Power Output and PASSing  the Coin Test .... and explains why those who 'convert their existing layout from analogue without changing the wiring' can 'get away with it' if they have only bought a low-power output DCC Controller)