!!

Not Registered?

Welcome!  Please register to view all of the new posts and forum boards - some of which are hidden to guests.  After registering and gaining 10 posts you will be able to sell and buy items on our N'porium.

If you have any problems registering, then please check your spam filter before emailing us.  Hotmail users seem to find their emails in the Junk folder.


Thanks for reading,
The NGF Staff.

Author Topic: Block detection, railcom, loconet and some bullet points  (Read 317 times)

0 Members and 1 Guest are viewing this topic.

Offline Ted

  • Trade Count: (0)
  • Full Member
  • ***
  • N Gauge Society Number: 28852
  • Posts: 490
  • Country: gb
  • Gender: Male
  • Needs. More. Grime.
    • YouTube
    • Awards
Block detection, railcom, loconet and some bullet points
« on: May 16, 2020, 11:53:59 AM »
I was literally about to start soldering and gluing track to my new open-frame, and then I remembered my requirements:
  • I wanted to control 1 train myself
  • I wanted to schedule/automate everything else including shunting
  • Setup is DCC and I want to run TrainControllerô
  • Handset is NCE Powercab - this will be replaced (I don't like it), perhaps ESU Ecos
  • Electrofrog points using Cobalt IP motors with adjacent semaphore signals

I wanted to double-check a few items specifically, the block detection!

Questions for your experienced thoughts please:

1) Am I right in saying you only need to insulate the negative lines at start and end of the each block, and that all positive can be joined?

2) I'm thinking of using insulating joiners because they are accurate, keep the rail-to-rail join aligned and are invisible. A cut - I believe - is visible to the eye and also has the potential for the rail-to-rail connection to be out of line. Agree/disagree?

3) Are DR5088RC my best option because they do both the block and the loco (decoder) detection? I understand that the DR4088LN are inadequate because they only provide block detection and nothing more.

4) And finally, am I right in saying blocks are best on their own DCC power - with turnouts/points on another. I.e. 2 DCC power circuits/buses, entirely separate and therefore requiring 2 power supplies? If yes, how do they communicate?

As ever, thank you for your input and assistance!

Online njee20

  • Trade Count: (+4)
  • Full Member
  • ***
  • N Gauge Society Number: 22598
  • Posts: 6570
  • Country: gb
    • Awards
Re: Block detection, railcom, loconet and some bullet points
« Reply #1 on: May 16, 2020, 12:49:21 PM »
Are you sold on Train Controller? The man behind it is very odd, and prone to absurd business practices, I wouldnít give him £5, let alone the £500 for TC gold! Iím going to give iTrain a go.

There are quite a few concerns presently about what happens when he retires, as he refuses to provide anything other than a USB flash drive with the licence key.

Offline Ted

  • Trade Count: (0)
  • Full Member
  • ***
  • N Gauge Society Number: 28852
  • Posts: 490
  • Country: gb
  • Gender: Male
  • Needs. More. Grime.
    • YouTube
    • Awards
Re: Block detection, railcom, loconet and some bullet points
« Reply #2 on: May 16, 2020, 12:50:10 PM »
I actually have a 5th question:

5) Can DR5088RC detect multiple locos on one block? Or for a siding full of diesels (as seen at Shirebrook in the 80's) would I have to have diesel locomotive length (15cm) blocks?

Offline Ted

  • Trade Count: (0)
  • Full Member
  • ***
  • N Gauge Society Number: 28852
  • Posts: 490
  • Country: gb
  • Gender: Male
  • Needs. More. Grime.
    • YouTube
    • Awards
Re: Block detection, railcom, loconet and some bullet points
« Reply #3 on: May 16, 2020, 12:52:49 PM »
Are you sold on Train Controller? The man behind it is very odd, and prone to absurd business practices, I wouldnít give him £5, let alone the £500 for TC gold! Iím going to give iTrain a go.

There are quite a few concerns presently about what happens when he retires, as he refuses to provide anything other than a USB flash drive with the licence key.

Bloody hell, there's always an hidden issue isn't there...  :smiley-laughing:

I have no idea of how iTrain compares?

The main reason I thought TC was the way to go is watching some videos (example https://www.youtube.com/watch?v=leqbgI-47Rk.

If iTrain can do all those things and the owner is less of a hurdle, then - why not!

Online njee20

  • Trade Count: (+4)
  • Full Member
  • ***
  • N Gauge Society Number: 22598
  • Posts: 6570
  • Country: gb
    • Awards
Re: Block detection, railcom, loconet and some bullet points
« Reply #4 on: May 16, 2020, 12:57:00 PM »
Thereís an enlightening thread on RMWeb, but for example he refused to sell to US states who voted for Trump. A prolific club user told him that they were big advocates of the system and often demoed it at exhibitions, making him several sales, he told them they were in breach of their licence conditions and unless they paid significantly more he would terminate their licence...!

I understand iTrain isnít quite as fully featured, particularly around macro implementation (Although I donít know the ramifications of that in use), but theyíre constantly evolving, whilst TC has been relative static for a good while.

Offline Ted

  • Trade Count: (0)
  • Full Member
  • ***
  • N Gauge Society Number: 28852
  • Posts: 490
  • Country: gb
  • Gender: Male
  • Needs. More. Grime.
    • YouTube
    • Awards
Re: Block detection, railcom, loconet and some bullet points
« Reply #5 on: May 16, 2020, 01:03:35 PM »
Thereís an enlightening thread on RMWeb, but for example he refused to sell to US states who voted for Trump. A prolific club user told him that they were big advocates of the system and often demoed it at exhibitions, making him several sales, he told them they were in breach of their licence conditions and unless they paid significantly more he would terminate their licence...!

I understand iTrain isnít quite as fully featured, particularly around macro implementation (Although I donít know the ramifications of that in use), but theyíre constantly evolving, whilst TC has been relative static for a good while.

That sounds like the behaviour of someone who doesn't leave his cabin and interact with actual people, ever.  :D

Macros are indeed a feature I really like the look of, if iTrain doesn't handle them or have a similar functionality - that could be the deciding factor for me.

Offline Ted

  • Trade Count: (0)
  • Full Member
  • ***
  • N Gauge Society Number: 28852
  • Posts: 490
  • Country: gb
  • Gender: Male
  • Needs. More. Grime.
    • YouTube
    • Awards
Re: Block detection, railcom, loconet and some bullet points
« Reply #6 on: May 16, 2020, 01:57:44 PM »
Another ps @njee20 from what I've read "TC also supports manual control including running of TC Schedules. In this mode TC controls the turnouts and signals but you control the throttle. There are options to allow you to ignore all signals or have TC enforce them preventing you from overrunning a red signal."

This sounds perfect.

Does iTrain allow that?

Offline Nigel Cliffe

  • Trade Count: (0)
  • Full Member
  • ***
  • Posts: 754
  • Country: gb
    • Awards
Re: Block detection, railcom, loconet and some bullet points
« Reply #7 on: May 16, 2020, 02:33:50 PM »
As with njee20, I wouldn't spend a penny on TrainController, and would encourage others to think hard before designing a layout around the software.   I understand those who bought in the past and they'll stay with it because the cost of change is huge (as much in how they've constructed a layout and its operation around the software).  His business approach is bizarre.   If still tempted, I recommend a long read of the RMWeb threads.     

I suspect iTrain will do what you want.   Depends exactly what you want it to do, but I'd be surprised if it didn't do enough.

Block detection detects current on a section of track.  Could be one loco, one carriage with lighting, one wagon with resistor over the wheels, twenty locos, doesn't matter.   It either detects current or it doesn't.   So, "occupied" or "clear".    It cannot tell the difference between one loco and two (or ten, or twenty). 

How do you plan to connect your block detectors to the system ?   The equipment list you've given doesn't have a means to link the DRxxxx devices to the system, you need some sort of interface unit.

If you stay with NCE, then the DR5088RC RailCom detectors are a waste of money and time, the NCE kit doesn't generate a RailCom signal, so the detector cannot detect anything from the decoder.   

The ESU ECoS can generate RailCom, so the RailCom detector is a possibility.  You'll still need a data connection method for either detection device;  there is an ESU LocoNet adaptor, no idea if it works for the devices in question.   

Other possible command station might be a RocoZ21,  seems to have more interface options to other hardware than most. 

RailCom (identification of decoders, and thus locos) only works if your locos have RailCom capable decoders within them.  That's mostly European brands,  though some TCS units claim to have it.  Other non-RailCom decoders should still run, but won't be identified by the system.  A few old-design loco decoders will run erratically if there is a RailCom signal.
If going with RailCom, you need to check your other devices (accessory decoders, power district breakers, etc. ) are not upset by the RailCom signal. 

Automated shunting, depends what you mean by that.   But, its really hard to arrange shunting; the stopping point of a loco to couple/uncouple changes depending on the lengths of each wagon in the train and their exact place along a siding.   Anything which relies on calculating the distance a loco moves at a given speed setting is likely to fail because loco performance drifts as the loco warms up.   (About 12 years ago, I built an automated shunting demo in 2mm scale, just moving a couple of wagons between two sidings.  The software used had a number of "tweak the settings" features to allow it to be tuned to the changes in loco response ). 
Some shunting might be possible, depends on what is wanted, and to an extent how "rough" you're prepared to make it. 
I recommend building a test setup before committing to a design. 
 
Splitting up a DCC system.  This is done with "power districts".   Take the output of the command station, and split into two.  Each goes through a "power district breaker", before going anywhere else.  One to the track, one to the accessories.   A short or other fault on one causes its breaker to shut down, leaving the remainder running.    However, several "gotchas" before you buy:
1 - you talk of using RailCom.  You need breakers compatible with RailCom.  (I know what I'd use, but they're self-assembly electronics).   
2 - you've mentioned Cobalt IP motors.  If tempted to use the "frog" wire on those, you break your nicely separated wiring by connecting your accessory bus to the track.   You have to use the other set of change-over switches for the frog if using power districts. 
3 - (saving a bit of money), having a breaker on the Accessory Bus is optional, because once its installed, the chances of a short on there is negligible.


- Nigel

Offline Ted

  • Trade Count: (0)
  • Full Member
  • ***
  • N Gauge Society Number: 28852
  • Posts: 490
  • Country: gb
  • Gender: Male
  • Needs. More. Grime.
    • YouTube
    • Awards
Re: Block detection, railcom, loconet and some bullet points
« Reply #8 on: May 16, 2020, 03:01:46 PM »
As with njee20, I wouldn't spend a penny on TrainController, and would encourage others to think hard before designing a layout around the software.   I understand those who bought in the past and they'll stay with it because the cost of change is huge (as much in how they've constructed a layout and its operation around the software).  His business approach is bizarre.   If still tempted, I recommend a long read of the RMWeb threads.     

Thanks Nigel, I tried to read the RMWeb post but it's just infighting and pretty ugly - perhaps as ugly as the TC chap!

Quote
I suspect iTrain will do what you want.   Depends exactly what you want it to do, but I'd be surprised if it didn't do enough.

I've requested a demo!

Quote
Block detection detects current on a section of track.  Could be one loco, one carriage with lighting, one wagon with resistor over the wheels, twenty locos, doesn't matter.   It either detects current or it doesn't.   So, "occupied" or "clear".    It cannot tell the difference between one loco and two (or ten, or twenty). 

I found this - https://www.coastaldcc.co.uk/products/dcc4pc/rail-comm-reader - looks like it fixes the issue of reading multiple trains on a block?

Quote
How do you plan to connect your block detectors to the system ?   The equipment list you've given doesn't have a means to link the DRxxxx devices to the system, you need some sort of interface unit.

If you stay with NCE, then the DR5088RC RailCom detectors are a waste of money and time, the NCE kit doesn't generate a RailCom signal, so the detector cannot detect anything from the decoder.

The ESU ECoS can generate RailCom, so the RailCom detector is a possibility.  You'll still need a data connection method for either detection device;  there is an ESU LocoNet adaptor, no idea if it works for the devices in question.   

Other possible command station might be a RocoZ21,  seems to have more interface options to other hardware than most. 

NCE is going, I only used it to test really (my first controller).

I like the Ecos because it's a proper controller, tactile. I did look at the Roco Z21 but operating from a touchscreen just doesn't float my boat. I assumed (might be wrong) that the ESU Ecos would act as the 'system'.

Quote
RailCom (identification of decoders, and thus locos) only works if your locos have RailCom capable decoders within them...

I should be good, I only have Zimo (latest sound chips) and LokSound 4 and 5 chips. :)

Quote
Automated shunting, depends what you mean by that.   But, its really hard to arrange shunting; the stopping point of a loco to couple/uncouple changes depending on the lengths of each wagon in the train and their exact place along a siding.   Anything which relies on calculating the distance a loco moves at a given speed setting is likely to fail because loco performance drifts as the loco warms up.   (About 12 years ago, I built an automated shunting demo in 2mm scale, just moving a couple of wagons between two sidings.  The software used had a number of "tweak the settings" features to allow it to be tuned to the changes in loco response ). 
Some shunting might be possible, depends on what is wanted, and to an extent how "rough" you're prepared to make it. 
I recommend building a test setup before committing to a design. 

I watched a video where a shunter on TC, using macros, would pull in to a siding, to a magnet, uncouple, move away. It was flawless... but 00, so a little more tolerant than N! I was hoping with Dapol easyshunt and an electromagnet, operated by DCC, I'd be okay. It wouldn't be frequent shunting, more a case of loco dropping off a rake and leaving, or perhaps splitting a rake and leaving.

Quote
 
Splitting up a DCC system.  This is done with "power districts".   Take the output of the command station, and split into two.  Each goes through a "power district breaker", before going anywhere else.  One to the track, one to the accessories.   A short or other fault on one causes its breaker to shut down, leaving the remainder running.    However, several "gotchas" before you buy:
1 - you talk of using RailCom.  You need breakers compatible with RailCom.  (I know what I'd use, but they're self-assembly electronics).   
2 - you've mentioned Cobalt IP motors.  If tempted to use the "frog" wire on those, you break your nicely separated wiring by connecting your accessory bus to the track.   You have to use the other set of change-over switches for the frog if using power districts. 
3 - (saving a bit of money), having a breaker on the Accessory Bus is optional, because once its installed, the chances of a short on there is negligible.

Noted and again, very helpful - thank you! Some more research for me to do. :)

Offline jpendle

  • Trade Count: (0)
  • Full Member
  • ***
  • N Gauge Society Number: 23638
  • Posts: 1518
  • Country: us
    • Awards
Re: Block detection, railcom, loconet and some bullet points
« Reply #9 on: May 16, 2020, 03:27:42 PM »
Hi,

A couple more things to consider.

As Nigel said, for Railcom you'll need to stick to European kit, I have NCE stationary decoders and a PSX-1 circuit breaker, the NCE stuff won't boot with Railcom enabled and the PSX-1 filters it out! (The PSX-1 is going and I have a booster to run my stationary decoders)

The Z21 can be used with the Roco Multimaus to give a more tactile throttle and has every interface you can think of.

As far as that piece of Coastal DCC block detection kit goes, it is not clear to me that it knows what the order of locos is in the block, just that there are multiple locos there, I could be wrong.

I have also kept an eye open on the Traincontroller thread on RMWEB and the owner does appear to be a little volatile, to say the least!

Hopefully you can be persuaded to give a blow by blow account of this, as Automation is on my (long) list of things to do on my layout.

Regards,

John P
Check out my layout thread.

Contemporary NW (Wigan Wallgate and North Western)

https://www.ngaugeforum.co.uk/SMFN/index.php?topic=39501.msg476247#msg476247

Offline Ted

  • Trade Count: (0)
  • Full Member
  • ***
  • N Gauge Society Number: 28852
  • Posts: 490
  • Country: gb
  • Gender: Male
  • Needs. More. Grime.
    • YouTube
    • Awards
Re: Block detection, railcom, loconet and some bullet points
« Reply #10 on: May 16, 2020, 03:30:32 PM »
As they say a picture is worth a thousand words. Here's my plan, I've highlighted the shed:



Question: am I best to split these tracks in to many blocks i.e. 2 blocks inside and 2 outsider per rail? A total of 8 for both lanes in to the shed.

That way the system will be able to see each loco in the shed and parked outside, and also manoeuvrer them safely in close proximity. Allowing prototypical stabling of locos.

If this is a yes - then I will have to do this with the rail running behind the shed and in front of it too. Splitting in to blocks of 15cm each, to accommodate a diesel with a little wiggle room.

I don't wish to be crass, but cost isn't an issue - if I have to buy more kit to cater to this, then that's fine!

Offline jpendle

  • Trade Count: (0)
  • Full Member
  • ***
  • N Gauge Society Number: 23638
  • Posts: 1518
  • Country: us
    • Awards
Re: Block detection, railcom, loconet and some bullet points
« Reply #11 on: May 16, 2020, 03:35:01 PM »
Hi,

I don't have the answer, but it seems to me that your best plan may be to start experimentally.

Replace the NCE, lay a single piece of track with a couple of blocks, buy the block detectors, hook up the equipment and software and have a play.

Unless someone on here has the definitive answer, I think that's the approach I would take.

Regards,

John P
Check out my layout thread.

Contemporary NW (Wigan Wallgate and North Western)

https://www.ngaugeforum.co.uk/SMFN/index.php?topic=39501.msg476247#msg476247

Offline Ted

  • Trade Count: (0)
  • Full Member
  • ***
  • N Gauge Society Number: 28852
  • Posts: 490
  • Country: gb
  • Gender: Male
  • Needs. More. Grime.
    • YouTube
    • Awards
Re: Block detection, railcom, loconet and some bullet points
« Reply #12 on: May 16, 2020, 03:36:39 PM »
Hi,

A couple more things to consider.

As Nigel said, for Railcom you'll need to stick to European kit, I have NCE stationary decoders and a PSX-1 circuit breaker, the NCE stuff won't boot with Railcom enabled and the PSX-1 filters it out! (The PSX-1 is going and I have a booster to run my stationary decoders)

The Z21 can be used with the Roco Multimaus to give a more tactile throttle and has every interface you can think of.

As far as that piece of Coastal DCC block detection kit goes, it is not clear to me that it knows what the order of locos is in the block, just that there are multiple locos there, I could be wrong.

I have also kept an eye open on the Traincontroller thread on RMWEB and the owner does appear to be a little volatile, to say the least!

Hopefully you can be persuaded to give a blow by blow account of this, as Automation is on my (long) list of things to do on my layout.

Regards,

John P

Thanks John, NCE is out - I only use the Powercab for testing and to be honest, I now have an Aruino and JMRI for that.

I was so close to buying the Z21 but swayed by the Ecos, perhaps uninventively because of it's bulk and feel. I appreciate that's the opposite of what many want. I like the rotary controls, function buttons and even the horn toggles. The big screen is a bonus. Heck, if I could buy one of these for the UK, I would in a heartbeat - https://www.iascaled.com/protothrottle/  :thumbsup:

As for "Coastal DCC block detection kit goes, it is not clear to me that it knows what the order of locos is in the block, just that there are multiple locos there, I could be wrong." - you might be right, in which case it's a bust. See my post above, it sounds like I need to slice and dice to get what I want!

Offline Ted

  • Trade Count: (0)
  • Full Member
  • ***
  • N Gauge Society Number: 28852
  • Posts: 490
  • Country: gb
  • Gender: Male
  • Needs. More. Grime.
    • YouTube
    • Awards
Re: Block detection, railcom, loconet and some bullet points
« Reply #13 on: May 16, 2020, 03:38:54 PM »
... but it seems to me that your best plan may be to start experimentally.

Replace the NCE, lay a single piece of track with a couple of blocks, buy the block detectors, hook up the equipment and software and have a play.

Unless someone on here has the definitive answer, I think that's the approach I would take.

I think you're right. At least I have something to progress with, a strip of flexitrack full of blocks is pretty easy even for me! :)

Offline Nigel Cliffe

  • Trade Count: (0)
  • Full Member
  • ***
  • Posts: 754
  • Country: gb
    • Awards
Re: Block detection, railcom, loconet and some bullet points
« Reply #14 on: May 16, 2020, 04:07:26 PM »

......Block detection detects current on a section of track.  Could be one loco, one carriage with lighting, one wagon with resistor over the wheels, twenty locos, doesn't matter.   It either detects current or it doesn't.   So, "occupied" or "clear".    It cannot tell the difference between one loco and two (or ten, or twenty). 

I found this - https://www.coastaldcc.co.uk/products/dcc4pc/rail-comm-reader - looks like it fixes the issue of reading multiple trains on a block?


You appear to be conflating "block detection" with "railcom decoder identification devices".   

Block detection will only detect "block occupied" or "block clear".   It cannot tell how many.

RailCom, with some compatible hardware (including the loco decoders), may be able to identify multiple decoder addresses within a block.  So, it can say locos A, B, C, D are in the section.   But, it cannot tell the order by itself.  Note that not all hardware will do this, you'll need to research and test if wanting to identify multiple decoders in the same section. 

However, with several locos in a block, your software may be able to keep track of the order of things.   You need to think of the software and hardware working together.   Example,  if you run a loco from A, into B, then later on, move another loco via A into B, then the software could "know" the order of the locos. 

Additionally, there are other types of "detector".  It is quite common to combine "block" detection (something is sitting somewhere within the block) and "spot" detection (something is over the spot).  Spot detectors are often light beam devices, such as an infra-red LED (so not visible to the eye) and detector in the track, which bounces off the bottom of a loco indicating it is over the "spot".


I know, at a arms length, the DCC4PC chaps, and I used to live near Kevin at Coastal DCC, and in the past Kevin and I designed and wrote a significant part of JMRI/DecoderPro, so I know Kevin quite well.   The DCC4PC stuff hasn't had lots of development in recent years,  I think its stalled a bit.   And, critically, you need support for devices and their data output in software.     

In many cases, you don't need "train identification" (ie. RailCom), because if the software knows the starting places of locos, it can track their movements around the layout.  eg. if software is told Loco-1 is in FiddleYard-Road-X, and Road-X is selected on turnouts, and a detector sees a train on the exit from the FiddleYard, the software could deduce that is Loco-1.  Similarly, as Loco-1 moves from block-to-block around the layout.    One only needs block detection (occupancy) , plus known starting state, for this to work.    In practise, if RailCom is available, the use of strategically sited RailCom identity detectors (reading the decoder ID) solves the "what is the starting point" question. 

When desiring automation, things seem to get turned on their head;  start with software which does what you need, then find hardware which supports the software, and finally, find the controller which fits your hand best from those left in the list of hardware compatible with the software.   



- Nigel

 

Please Support Us!
May Goal: £60.00
Due Date: May 31
Total Receipts: £95.00
Above Goal: £35.00
Site Currency: GBP
158% 
May Donations

SimplePortal 2.3.5 © 2008-2012, SimplePortal