Jump to content
 

Video: wires under the baseboards


jamespetts
 Share

Recommended Posts

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.

 

title-still.jpg.7304ada4d0234ecefeef8e671de4c9ee.jpg

 

Watch it (completely and permanently advert free and free of charge; no login required) on Peertube here.

Edited by jamespetts
  • Like 4
  • Informative/Useful 3
  • Interesting/Thought-provoking 1
  • Funny 1
Link to post
Share on other sites

Just now, Andymsa said:

Excellent video, your coming on in leaps and bounds, two questions

what unit are you using for short circuit shutdown and what item is the point motor servos mounted to to give lateral movement,

 

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.

Link to post
Share on other sites

8 minutes ago, jamespetts said:

 

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.


thanks will look later when I am home. 
 

not a merg member unfortunately 

Edited by Andymsa
Link to post
Share on other sites

3 minutes ago, Andymsa said:


thanks will look later when I am home. 
 

not a merg member unfortunately 

 

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.

Link to post
Share on other sites

29 minutes ago, WIMorrison said:

Unfortunately it only sees MERG CanBUS as an option for automation and AFAIK there are no commercial programs that support MERG CanBUS :(

 

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.

  • Informative/Useful 1
Link to post
Share on other sites

If I can just referee this, it seems to me that there is no contradiction between the SIG group head having different equipment and software on his layout compared to presumably most other people in the group he heads up. Like having windows at work and apple at home. So all the statements can be true.

 

I enjoyed the video. Even someone with no prior experience (not referring to me) they could make some sense of it.

 

I notice that you have some different current detection units on different parts of the layout, and got that you had the DR5088RC's with Railcom only for the places where you might place stock onto the layout, otherwise 4088LN's. Apart from anything else did you have to use longer cable runs  anywhere due to using 2 types of detector? I had wondered about using both types as the DR5088's are around double the price of the 4088's. But I understood they might have different sensitivities (possible false occupation issues) for example.

 

On a more modellers aspect, you seem to have mixed concrete and wooden sleeper track. Just saying...

  • Like 1
Link to post
Share on other sites

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.

  • Agree 1
Link to post
Share on other sites

12 minutes ago, jamespetts said:

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).

I was of the same mind but I am intending to buy iTrain. I think the situation is the same, but Im not sure. Im not planning to identify turnouts although they will all be individually wired and therefore capable of being identified if necessary. It also wasnt clear to me that the LN was Railcom enabled - its clearly marked on the front of the 5088CS.

Link to post
Share on other sites

1 minute ago, RobinofLoxley said:

I was of the same mind but I am intending to buy iTrain. I think the situation is the same, but Im not sure. Im not planning to identify turnouts although they will all be individually wired and therefore capable of being identified if necessary. It also wasnt clear to me that the LN was Railcom enabled - its clearly marked on the front of the 5088CS.

 

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).

Link to post
Share on other sites

Thanks, I was clear on 95% of that. What I meant was Im not planning to put occupancy detection on turnouts. As you didnt say, the software relies on the turnouts being in the correct positions as set. I have been wondering where I might need to put Railcom detection, if anywhere, on my layout. Mynormal approach is to have all my rolling stock on display although I will be converting locos one at a time - Im actually building the new layout with DC power for testing and will swop over when I'm ready.

Link to post
Share on other sites

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.

Link to post
Share on other sites

iTrain is the same, at least thats my understanding.

 

I have a few places where I will have a sequence of points, as you have on your layout, and i did wonder about the possibility of losing the trains position, even if the software might be able to calculate where it is "In theory". 

 

My era is 1960 and mostly tender locos but as they are today the number of pickups varies and so the "Footprint" will too.

  • Agree 1
Link to post
Share on other sites

To be clear the DR4088xx is Railcom compatible, however it doesn’t have a Railcom detector therefore does not report railcom to the command station.

 

items that are not compatible with Railcom are liable to fail if the Railcom signal is present. This was the case the case with the MERG District Cutout although and update has made that unit more stable when Railcom is present. The PSX breaker fall over similary.

 

when using Railcom it is essential that you confirm all equipment is compatible as many DCC items fall over when  the railcom cutout is present. 

Link to post
Share on other sites

44 minutes ago, WIMorrison said:

To be clear the DR4088xx is Railcom compatible, however it doesn’t have a Railcom detector therefore does not report railcom to the command station.

 

items that are not compatible with Railcom are liable to fail if the Railcom signal is present. This was the case the case with the MERG District Cutout although and update has made that unit more stable when Railcom is present. The PSX breaker fall over similary.

 

when using Railcom it is essential that you confirm all equipment is compatible as many DCC items fall over when  the railcom cutout is present. 


just a thought, is it possible to have a occupancy detector with railcom in one area, and just a digitrax occupancy detector in another. Would issues arise as the train crosses from one area to another. Obviously both rails are cut between areas and the only time they are bridged is when a train crosses.

Link to post
Share on other sites

21 minutes ago, Andymsa said:


just a thought, is it possible to have a occupancy detector with railcom in one area, and just a digitrax occupancy detector in another. Would issues arise as the train crosses from one area to another. Obviously both rails are cut between areas and the only time they are bridged is when a train crosses.

 

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.

Link to post
Share on other sites

9 hours ago, Andymsa said:


just a thought, is it possible to have a occupancy detector with railcom in one area, and just a digitrax occupancy detector in another. Would issues arise as the train crosses from one area to another. Obviously both rails are cut between areas and the only time they are bridged is when a train crosses.

 

Andy

 

it *shouldn't* be an issue but bear in mind my comments about RailCom compatibly as to make Railcom work you need the Railcom cutout present in the DCC signal everywhere and this causes issues with many systems not designed to work with it. I am not sure whether it would cause issues for the BDL 168. There don't seem to be issues with decoders having CV29 set to respond to Railcom on systems that don't have the Railcom cutout in the DCC signal but that would be because the decoder isn't being polled for information and therefore doesn't respond :) 

 

I do recall that I attempted to inject a Railcom cutout into a Digitrax DCC signal (after the controller) and it wasn't 100% successful. The controller (DCS210?) continued to work OK but Railcom reporting wasn't consistent and change the controller resolved the problem. (We scrapped the injection idea and rewired the entire layout using DR5088RC and Z21 later). 

 

As I keep saying to people Railcom is good and useful (you know that as you have seen me use it :) ) but it does need thought and testing properly with everything you are using - most boosters fall over when it is present. I am also aware that some people have issues with the DR5088RC and TC9 whereas there are no issues with iTrain.

 

Iain

Link to post
Share on other sites

  • RMweb Gold
12 hours ago, jamespetts said:

It is not essential to have occupancy detection 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.

 

I would not recommend it for TrainController, nor does Herr Freiwald. Assuming you are running trains under automated schedules then your issues are covered. Wiring up all turnouts with sensors, particularly in a complex station throat area, would be costly and greatly complicate the wiring with little gain. You would also need to fit all vehicles with resistor wheel sets to enable detection.

 

Trains run on schedules which consist of one or more linked routes, a route being between two connected blocks. For example, a train travelling a route covering blocks A -> B -> C -> D will consist of routes A-B, B-C and C-D. There may be turnouts between the blocks in each of the routes. For example, a train leaves A and is expected to arrive in B. Until it has been detected in B, and has reached the stop marker in B, then A and any turnouts between A and B remain reserved.

 

Therefore (1) a turnout cannot be changed whilst is occupied and (2) cannot be reserved whilst it is occupied. The fact that a short train goes "under the radar" for a short period whilst travelling over turnouts between blocks does not cause TC to lose control of it. 

 

I've run my large layout for many years now and have never felt the need to put sensors on turnouts. 

 

 

  • Like 1
Link to post
Share on other sites

4 minutes ago, RFS said:

 

I would not recommend it for TrainController, nor does Herr Freiwald. Assuming you are running trains under automated schedules then your issues are covered. Wiring up all turnouts with sensors, particularly in a complex station throat area, would be costly and greatly complicate the wiring with little gain. You would also need to fit all vehicles with resistor wheel sets to enable detection.

 

Trains run on schedules which consist of one or more linked routes, a route being between two connected blocks. For example, a train travelling a route covering blocks A -> B -> C -> D will consist of routes A-B, B-C and C-D. There may be turnouts between the blocks in each of the routes. For example, a train leaves A and is expected to arrive in B. Until it has been detected in B, and has reached the stop marker in B, then A and any turnouts between A and B remain reserved.

 

Therefore (1) a turnout cannot be changed whilst is occupied and (2) cannot be reserved whilst it is occupied. The fact that a short train goes "under the radar" for a short period whilst travelling over turnouts between blocks does not cause TC to lose control of it. 

 

I've run my large layout for many years now and have never felt the need to put sensors on turnouts. 

 

 


Yes your absolutely correct that it may not be needed on points. But what the above situation does not allow for is a divided train, traincontroller or any other program like it will assume the whole train has arrived in the destination block but will not see any stock left on points if any have been left behind. And then the next train is routed through that point with the expected results of a crash

  • Like 1
Link to post
Share on other sites

17 minutes ago, RFS said:

 

I would not recommend it for TrainController, nor does Herr Freiwald. Assuming you are running trains under automated schedules then your issues are covered. Wiring up all turnouts with sensors, particularly in a complex station throat area, would be costly and greatly complicate the wiring with little gain. You would also need to fit all vehicles with resistor wheel sets to enable detection.

 

Trains run on schedules which consist of one or more linked routes, a route being between two connected blocks. For example, a train travelling a route covering blocks A -> B -> C -> D will consist of routes A-B, B-C and C-D. There may be turnouts between the blocks in each of the routes. For example, a train leaves A and is expected to arrive in B. Until it has been detected in B, and has reached the stop marker in B, then A and any turnouts between A and B remain reserved.

 

Therefore (1) a turnout cannot be changed whilst is occupied and (2) cannot be reserved whilst it is occupied. The fact that a short train goes "under the radar" for a short period whilst travelling over turnouts between blocks does not cause TC to lose control of it. 

 

I've run my large layout for many years now and have never felt the need to put sensors on turnouts. 

 

 

 

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.

Edited by jamespetts
Link to post
Share on other sites

  • RMweb Gold
16 minutes ago, Andymsa said:


Yes your absolutely correct that it may not be needed on points. But what the above situation does not allow for is a divided train, traincontroller or any other program like it will assume the whole train has arrived in the destination block but will not see any stock left on points if any have been left behind. And then the next train is routed through that point with the expected results of a crash

 

It really depends on how far you want to go - the law of diminishing returns applies here. I have so far fitted resistor wheel sets just on the last vehicle of every train. This does protect against coupling failures, but obviously not if a train divides on a turnout without leaving the last vehicle in the preceding block. Reliable couplings are a must! 

 

 

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...