!!

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 316 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
Re: Block detection, railcom, loconet and some bullet points
« Reply #15 on: May 16, 2020, 04:49:39 PM »
Thanks again Nigel, this is really useful stuff and given me food for thought. It's appreciated.

Offline Shropshire Lad

  • Trade Count: (0)
  • Full Member
  • ***
  • Posts: 163
  • Country: gb
    • Awards
Re: Block detection, railcom, loconet and some bullet points
« Reply #16 on: May 16, 2020, 05:48:46 PM »
I've tried out Z21 occupation detection units, but only on two pieces of track! They work well and pick up at least in two Railcom Id's. Temporarily I'm using a Roco WiFi maus on a DR5000 connected to iTrain. Hoping to have built enough of the railway to start testing properly fairly soon.
Cheers Colin

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 #17 on: May 16, 2020, 06:17:26 PM »
I've tried out Z21 occupation detection units, but only on two pieces of track! They work well and pick up at least in two Railcom Id's. Temporarily I'm using a Roco WiFi maus on a DR5000 connected to iTrain. Hoping to have built enough of the railway to start testing properly fairly soon.
Cheers Colin

Is that the 10808? Seems like it only has 8 blocks for about £100, whereas the Digikeys has 16 for £60. Both Railcom. From my understanding they do exactly the same thing.

I'm also still really torn on the Z21 because I just like the actual controller of the ESU Ecos.

However, buying the Ecos and then running TrainCommander or iTrain means I won't use half of the Ecos's functions... so it would in turn be a very expensive controller!

Offline Shropshire Lad

  • Trade Count: (0)
  • Full Member
  • ***
  • Posts: 163
  • Country: gb
    • Awards
Re: Block detection, railcom, loconet and some bullet points
« Reply #18 on: May 16, 2020, 06:54:00 PM »
That's the one! The Digikeijs 5088RC is around £95 with 17 Railcom detectors  which the cheaper one doesn't have. Still a lot cheaper than the Z21 but I need the connectivity of the 10808.
If I was buying a new system now I'd probably go for a Digikeijs DR5000 but I wouldn't change my ZIMO kit.
Cheers Colin

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 #19 on: May 16, 2020, 07:24:57 PM »
Without wishing to hijack the thread I can’t decide whether Railcom detection is worth it or not.

Many (but not all) of my decoders are ESU or Zimo. I quite like that when I put an ESU Loksound loco on the track my ECOS identifies it, but I understand that’s Railcom Plus. If I get detectors do you get similar behaviour from ‘normal’ Railcom decoders? You can presumably mix and match (Nigel you imply so?), so you could have Railcom detectors (for example) in the fiddle yard to confirm starting positions, but then have ‘dumb’ detectors elsewhere where they’re cheaper.

The DR4088 is what I’m planning to use, they do a Railcom option (well the 5088RC), but the cost adds up across a whole layout at an additional €45 per unit. I suspect I’m going to need c200 blocks, so at least 10 or so units.

Offline Shropshire Lad

  • Trade Count: (0)
  • Full Member
  • ***
  • Posts: 163
  • Country: gb
    • Awards
Re: Block detection, railcom, loconet and some bullet points
« Reply #20 on: May 16, 2020, 07:34:06 PM »
I'm not sure I would have gone for Railcom detection other than in the fiddle yards but as I need CAN connectivity I'm limited for choice.
Cheers Colin

Offline Nigel Cliffe

  • Trade Count: (0)
  • Full Member
  • ***
  • Posts: 754
  • Country: gb
    • Awards
Re: Block detection, railcom, loconet and some bullet points
« Reply #21 on: May 16, 2020, 07:41:46 PM »
Without wishing to hijack the thread I can’t decide whether Railcom detection is worth it or not.

Many (but not all) of my decoders are ESU or Zimo. I quite like that when I put an ESU Loksound loco on the track my ECOS identifies it, but I understand that’s Railcom Plus. If I get detectors do you get similar behaviour from ‘normal’ Railcom decoders? You can presumably mix and match (Nigel you imply so?), so you could have Railcom detectors (for example) in the fiddle yard to confirm starting positions, but then have ‘dumb’ detectors elsewhere where they’re cheaper.


Be careful with "RailCom Plus", its essentially an ESU-only option (with some support in Lenz devices).   So, yes, very clever with an ECoS identifying ESU decoders and mapping all their function keys, but that's about it at present. 

With ordinary RailCom decoders (ie. not ESU with RailCom Plus), you'll just get the loco ID (DCC address).  With some RailCom decoders you get other parameters, but those are far from universal.   

Yes, you can do as you suggest with some RailCom detectors in key locations, to "prime" the system, or to deal with ambiguities.  Then use cheaper occupancy devices in other places.    Common places for the RailCom detector would include fiddle yards (or the entry or exit roads), or perhaps on the departure roads at a terminus, when a manual driver puts a train together for departure, and then the automation needs to take it away from the road to run elsewhere, and needs to know which loco you've put on the front of the "8.02 to Blackpool".   

One area where I think automation is under-used is fiddle yards.   If one spends ages building a layout, then why automate the "front" and leave the rear requiring a human driver ?   I'd much rather have to manually drive the front, and as the train leaves the scene, let the automation take over and store it in the correct fiddle yard road.  And have the automation present a train for me from the fiddle yard at the off-stage "outer home signal". ( See "automatic Crispen" in the ancient history of model railways)     But, there are lots of ways of doing "automation", and that's only one.       


Nigel
« Last Edit: May 16, 2020, 07:44:36 PM by Nigel Cliffe »

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 #22 on: May 16, 2020, 08:56:55 PM »
Perfect, thank you. I’m not entirely sure Railcom brings much to the party full stop, presumably most software programmes just assume that you’ve not put something back somewhere else, and thus starting state is the same as the end state.

Yes, the fiddle yard certainly seems ripe for automation, particularly with stacked trains automatically moving up, and services being routed into empty roads. This is rather my intention, as I’m quite happy driving ‘out front’, but happy not to control the fiddle yard, which will inevitably contain far too much stock!

Offline maninfreo

  • Trade Count: (0)
  • Newbie
  • **
  • Posts: 8
  • Country: au
    • Awards
Re: Block detection, railcom, loconet and some bullet points
« Reply #23 on: May 17, 2020, 03:00:09 AM »
 :helpneededsign:
Hello All,
I just logged in from Fremantle down-under with some questions re; block detection and after reading the threads, most have been answered. one biggie" still remains though". Our club uses T-Trak for our N guage as we are short of room and this allows members to take modules home and play. Our conundrum is what system of detection will accomodate the fact that modules are forever changing the format of a given layout assembly?? If anyone can offer any suggestions as to how to approach this problem ?
Best wishes to all.
Steve

 

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

anything
SimplePortal 2.3.5 © 2008-2012, SimplePortal