Block detection and automation test/practice layout

[gavino200]

1 minute ago, chadbag said:

 

Yes, that was what I was thinking.  Which would actually make this module very useful WITH the 5088RC modules -- the 5088RC modules detect in the block and report the train number.  This one with separate sensors can do totally separate detection (IR, reed switch, etc).  Very cool.  Thanks.

 

 

Confused. So is this a receiver for optical senosrs? Or not?

 

[gavino200]

1 minute ago, chadbag said:

 

 

It could still be useful.  You just need to get the separate sensors to hook to hit.  

 

I know that. I didn't think this device had sensors. I thought it was a receiver for optical sensors, which I would buy separately. Actually I have a couple on hand from my tram setup. Is that what it is or not. 

 

 

1 minute ago, chadbag said:

 

And since it is unrelated to the current sensing/DCC part (or however it would be described) it can be used in conjunction with it in a totally non-interfering way.

 

The DR4088GND/OPTO manual has some interesting example hook ups for it.   I may have to get one of these to play with eventually.

 

 

Yes, that was my assumption. 

[inobu]

Just now, gavino200 said:

 

Confused. So is this a receiver for optical senosrs? Or not?

 

Keep it it will come in handy.

 

It is an OPTO coupler type detector that allows you to use different type of relay and switches. One of which can be Optic switch.

 

Don't confuse an Optic switch with this detector which is an OPTO device. 

 

Keep the DR4088OPTO

 

Inobu

 

 

[gavino200]

Just like the junction switch unit doesn't actually include the junction switches, this optical sensor receiver doesn't have optical sensors included. Right? 

 

[chadbag]

3 minutes ago, gavino200 said:

 

Confused. So is this a receiver for optical senosrs? Or not?

 

 

Any sort of sensor, theoretically.   The manual shows reed switch, push button or switch, hall sensor, light barrier, etc (depending on how you hook it up).

[gavino200]

Great, I'll keep it. So it's what I assumed it was, and more. I'm happy with that.  🙂

 

[gavino200]

Just downloaded iTrain and asked for the trial version. That's it for tonight. I had my second Moderna vaccine today and am too out of it to do anything else. I'll tinker around a bit more tomorrow. 

 

Thanks guys!

[inobu]

Here is an example.

 

Say you have an optic switch the reacts to darkness. When you place you hand over it an prevents light from shining through it closes the connection.

 

If you place a loco over the sensor it will block the light. This in turn closes the switch and has the DR4088 to report that section occupied. This has nothing to do

with DCC. It is giving you the ability to inject control mechanisms into your layout.

 

Inobu 

[gavino200]

3 minutes ago, inobu said:

Here is an example.

 

Say you have an optic switch the reacts to darkness. When you place you hand over it an prevents light from shining through it closes the connection.

 

If you place a loco over the sensor it will block the light. This in turn closes the switch and has the DR4088 to report that section occupied. This has nothing to do

with DCC. It is giving you the ability to inject control mechanisms into your layout.

 

Inobu 

 

Yep, that's exactly how my Optical sensors work on my tram system. That's exactly what I thought this thing was. That's one thing I like about the digikeijs system. It incorporates a lot of different elements and formats, and integrates them in a very simple manner. 

[gavino200]

These are the optical sensors in my tram system. It's pretty crude. It could be done and disguised a lot better. Those little houses are just made of styrene. I'll re-do this eventually. 

 

Edited January 26, 2021 by gavino200

[Martijn Meerts]

8 hours ago, inobu said:

Based on the objective of automation Railcom detectors comes into play at the station. When the RC detector identifies the train in the initial block that train can be

registered and controlled or trigger specific events. A scripts can be set triggering voice announcements for that named train for play back on the stations speaker.

 

You don't need RailCom for any of that. The software will know which train will arrive where, and as long as turnouts switch correctly, everything will be fine. And if turnouts don't switch correctly, RailCom won't help much either, as the software will just detect an unexpected train movement and halt the automatic running.

 

Of course, if the RailCom enabled detectors are only marginally more expensive, definitely get them. But if they're say 25 euro more expensive per detector, and you need a lot of them, then the money saved can be put to much better use elsewhere.

[gavino200]

That's interesting. From the US dealer the DR5088RC  detector module with Railcom is $106.99 at regular non-sale price. The DR4088LN locoNet version without Railcom is $71.99. The DR4088 detector that uses S88 is $59.99. The price differences are very significant. 

 

https://www.ironplanethobbies.com/?s=dr+4088&jet_ajax_search_settings={"search_source"%3A"product"%2C"results_order_by"%3A"relevance"%2C"results_order"%3A"asc"}&post_type=product

 

Many of my decoders are European and some are TCS, but I have quite a few Digitrax and Digitrax/Kato decoders. I don't plan on changing them anytime soon. I should have everything on this practice layout to evaluate the difference in what I can do with Railcom and Non-railcom decoders, and decide if RailCom is worth it for me. 

[Martijn Meerts]

That's quite the difference... The S88 ones are cheap because there are a lot of manufacturers doing S88 detectors, and it's a widely used bus for occupancy detection. It also uses mostly very basic components. I have something like 10 Littfinski S88 detectors, which I bought as kits and then soldered the various components myself. It saved some money, and it was good soldering practice 🙂

 

I find RailCom loco and function decoders worth it, because programming works better, since you get feedback from the decoder. 

[inobu]

10 hours ago, Martijn Meerts said:

 

You don't need RailCom for any of that. The software will know which train will arrive where, and as long as turnouts switch correctly, everything will be fine. And if turnouts don't switch correctly, RailCom won't help much either, as the software will just detect an unexpected train movement and halt the automatic running.

 

Of course, if the RailCom enabled detectors are only marginally more expensive, definitely get them. But if they're say 25 euro more expensive per detector, and you need a lot of them, then the money saved can be put to much better use elsewhere.

What you are purposing is a basic script function. I am stating with RailCom the system can identify the train "by the name" as it is entering the station. It's using a next level approach of automation. 

 

When I did my preliminary test I was able to get the name of the engine in that case it was Kato EFE-3 838. That was all the confirmation I needed. Once it was reported in JMRI

the rest is fundamental.

 

Inobu

[inobu]

6 hours ago, gavino200 said:

That's interesting. From the US dealer the DR5088RC  detector module with Railcom is $106.99 at regular non-sale price. The DR4088LN locoNet version without Railcom is $71.99. The DR4088 detector that uses S88 is $59.99. The price differences are very significant. 

 

https://www.ironplanethobbies.com/?s=dr+4088&jet_ajax_search_settings={"search_source"%3A"product"%2C"results_order_by"%3A"relevance"%2C"results_order"%3A"asc"}&post_type=product

 

Many of my decoders are European and some are TCS, but I have quite a few Digitrax and Digitrax/Kato decoders. I don't plan on changing them anytime soon. I should have everything on this practice layout to evaluate the difference in what I can do with Railcom and Non-railcom decoders, and decide if RailCom is worth it for me. 

It boils down that people don't know what they don't know and it can create confusion. You have the DR5000 that offers something that most system don't have. The ability to choose between Digitrax's Transponding and Lenz's Railcom. Each offering their own version of secondary communication to the decoder.

 

The type of detector is going to determine which system you are going to use. That choice is also going to determine the prominent decoder ran on your layout. Most people are subject to their own layout and may not realize the varying difference in layouts and their effects. 

 

For example I have a client that I'm building and addition to his layout. Based on his modeling style I converted him from MRC to the ECoS system. In that transition I advised him to only buy Lok Sound trains as it will serve him better. As we were testing his layout the engine was on the mountainous side of his layout and to his surprise he heard the engine rev and the prime mover ramp up its engine speed. This is one of the features of Lok sound decoders now. When you have a flat layout you will not hears this as much or at all in some cases.

 

For Japanese railways the sounds are not as important but feedback of who is on the rail or block is. Know what train is at the station and what train is leaving is the central point of automation. When you understand the Japanese rail system station sound is the fundamental element. Each train has its particular chime as it notifies everyone in the station who is entering the station.

 

So your choice will be which system you are going to use and for what reason. 

 

Most of my comment appears to be off but they come from the aspect of seeing a number of different layout and modeling schemes. 

 

Inobu

Edited January 26, 2021 by inobu

[Martijn Meerts]

3 hours ago, inobu said:

What you are purposing is a basic script function. I am stating with RailCom the system can identify the train "by the name" as it is entering the station. It's using a next level approach of automation. 

 

When I did my preliminary test I was able to get the name of the engine in that case it was Kato EFE-3 838. That was all the confirmation I needed. Once it was reported in JMRI

the rest is fundamental.

 

Inobu

 

I get the names of each train in each block without RailCom / Transponding as well, the only difference is that the software keeps track of which train is where, and it can't verify that the train it expects to be in the block is actually in the block. So, if platform 1 is expecting the Niseko Express, but the Paleo Express is actually the one entering the station (due to turnouts being in a wrong position for example), the software will still think the Niseko Express entered platform 1. With RailCom, the software can detect it's actually a different train, but you'd still need to handle it manually somehow, because obviously something in the routing went wrong.

 

I'm not saying RailCom isn't useful, but it doesn't add features other than confirming which train sets of which detector. And considering the extra cost per detector for having RailCom, in my opinion it's not worth it.

[chadbag]

Using MSRP from the Euro Digikeijs store, the Loconet 16 zone occupancy detector (DR4088LN-CS) is 67.25 euro and the RailCom detector with 16 zones is 103.45 euro.  That comes to about 2.26 euro per zone more for RailCom compatibility.  Not a lot more in my book.

 

If you expand past 16 zones, the non RailCom becomes a slight bit cheaper as the S88 add-on to the DR4088LN-CS is a little cheaper than buying another of the same while with the RailCom you need to buy a second of the same.   In that case you are paying about 2.60 euro more per zone for RailCom compatibility.

 

In both cases you can add in the OPTO ones over Loconet separately for sensor activated occupancy (vs track) so that does not factor in.

[gavino200]

3 hours ago, inobu said:

It boils down that people don't know what they don't know and it can create confusion. You have the DR5000 that offers something that most system don't have. The ability to choose between Digitrax's Transponding and Lenz's Railcom. Each offering their own version of secondary communication to the decoder.

 

I know this, inobu. I'm just not a fan of Digitrax. Again, I'm not knocking them. Just not for me. I would change out my old Digitrax decoders, but it's a time consuming process so it's not my to-do list anytime soon. Eventually, I may do it gradually. However, for not they'll make a nice comparison for me to evaluate Railcom. 

 

 

3 hours ago, inobu said:

 

For Japanese railways the sounds are not as important but feedback of who is on the rail or block is. Know what train is at the station and what train is leaving is the central point of automation. When you understand the Japanese rail system station sound is the fundamental element. Each train has its particular chime as it notifies everyone in the station who is entering the station.

 

So your choice will be which system you are going to use and for what reason. 

 

Most of my comment appears to be off but they come from the aspect of seeing a number of different layout and modeling schemes. 

 

Inobu

 

I've tried a few sound decoders. They're ok, but I'm not big into them. Station sounds may be fun and I'll probably play around with them. I've been to Japan and am aware of station jingles. It may be fun to do, but I won't know until I try it out. I'm not sure that sound scales very well. It may be weird to hear station jingles at a station if you're a scale mile away. I think likely it would be a fun novelty to turn on once in a while. 

[Martijn Meerts]

I already have about 100 occupancy detector inputs active, so at 2.26 euro per zone, that's already 226 euro 😉

 

If you're starting from scratch, and you don't need a ton of detectors, it would be worth getting the RailCom enabled detectors. If you need a lot of them (those 100 I have are just for the yard and helix, not even the layout itself), it adds up.. If you have to replace existing detectors with new RailCom enabled ones... Well, I have more interesting things to spend money on for the moment 😄

 

 

 

[gavino200]

33 minutes ago, Martijn Meerts said:

 

I get the names of each train in each block without RailCom / Transponding as well, the only difference is that the software keeps track of which train is where, and it can't verify that the train it expects to be in the block is actually in the block. So, if platform 1 is expecting the Niseko Express, but the Paleo Express is actually the one entering the station (due to turnouts being in a wrong position for example), the software will still think the Niseko Express entered platform 1. With RailCom, the software can detect it's actually a different train, but you'd still need to handle it manually somehow, because obviously something in the routing went wrong.

 

I'm not saying RailCom isn't useful, but it doesn't add features other than confirming which train sets of which detector. And considering the extra cost per detector for having RailCom, in my opinion it's not worth it.

 

So as long as you tell the software at some point which train is where, it should be able to keep track of them. 

 

With RailCom you wouldn't have to input to the software which train is where. It would sense this directly. That would be the main difference. Some convenience. 

 

I'll probably go with the RailComm detectors as I can be a bit lazy sometimes. But I like to think about what I'm getting and why. 😊

 

[inobu]

Guy's I'm just stating the different aspects of modeling and that one has to take into account these aspect and make their choice in what ever product line they choose. I can care less what

product you chose. Just know what you are choosing and for what reason. Each product line has its advantages and supports certain modeling scheme.

 

Inobu  

[gavino200]

24 minutes ago, chadbag said:

Using MSRP from the Euro Digikeijs store, the Loconet 16 zone occupancy detector (DR4088LN-CS) is 67.25 euro and the RailCom detector with 16 zones is 103.45 euro.  That comes to about 2.26 euro per zone more for RailCom compatibility.  Not a lot more in my book.

 

If you expand past 16 zones, the non RailCom becomes a slight bit cheaper as the S88 add-on to the DR4088LN-CS is a little cheaper than buying another of the same while with the RailCom you need to buy a second of the same.   In that case you are paying about 2.60 euro more per zone for RailCom compatibility.

 

In both cases you can add in the OPTO ones over Loconet separately for sensor activated occupancy (vs track) so that does not factor in.

 

I can already tell from my practice track that I'm going to need a lot of these litte gadgets. The difference in cost will amount to the price of, at least, a few nice trains. If money isn't a concern that's great. If I like what RailCom does, (in practice) I'll gladly pay the difference. But it is a significant difference. 

Edited January 26, 2021 by gavino200

[chadbag]

One good thing with basic occupancy detection.  Even if using RailCom on the layout, there may be places where you don't care which train is where.  In those cases, a basic non RailCom detection zone will work and the RailCom compatible ones you can use where you need to know.  

[inobu]

50 minutes ago, Martijn Meerts said:

 

I get the names of each train in each block without RailCom / Transponding as well, the only difference is that the software keeps track of which train is where, and it can't verify that the train it expects to be in the block is actually in the block. So, if platform 1 is expecting the Niseko Express, but the Paleo Express is actually the one entering the station (due to turnouts being in a wrong position for example), the software will still think the Niseko Express entered platform 1. With RailCom, the software can detect it's actually a different train, but you'd still need to handle it manually somehow, because obviously something in the routing went wrong.

 

I'm not saying RailCom isn't useful, but it doesn't add features other than confirming which train sets of which detector. And considering the extra cost per detector for having RailCom, in my opinion it's not worth it.

The problem is you keep thinking routing. When you use RailCom to your advantage it is a different story.

 

In this example a Railcom section is placed at each entry of platform 1. The system can know from which direction the train entered and who it is without any

concern of the switch or route. The way you have it set up it is dependent on routing. In this scenario it is based on detection not routing. 

 

 

 

Inobu

[gavino200]

17 minutes ago, chadbag said:

One good thing with basic occupancy detection.  Even if using RailCom on the layout, there may be places where you don't care which train is where.  In those cases, a basic non RailCom detection zone will work and the RailCom compatible ones you can use where you need to know.  

 

That's a good point. It may be that If your  storage yard is RailCom detected, you just need to place the trains there to allow the computer that "know" the identity of the train. Then it should be able to follow it around the layout as the identified train even if the rest of the layout doesn't have RailCom detection. 

 

But this is a guess. An idea to investigate.