RailComm block detectors/readers demonstrated

Re: RailComm block detectors/readers demonstrated

Postby Edwin_m » Sat Mar 21, 2009 6:00 pm

As I understand it there are two problems with Railcom:

(1) The Railcom signal is transmitted from the decoder at a low voltage, so that it won't get through the bridge rectifier on the input to each decoder. This means it won't get through current detectors that use diode drops. Hence you can't do a "global" interrogation of a decoder anywhere on the layout back to a single reader, if the decoder is sitting in a detector section it won't be able to transmit back. I don't personally have a problem with this as I have no interest in global detection.

(2) The decoder is only able to source a low current, presumably because it must supply this from on-board storage as no power is available on the rails during the cut-off period. Resistance axles and lighted coaches will provide other current paths for the Railcom signal to pass through, unless fitted with back-to-back diodes, and if there are too many the voltage of the signal will drop too low for the detector to see it. With block detectors fitted the problem reduces to the number of resistance axles and lighted coaches in the same detection section.

I only have this at second hand via forum discussions some time ago, so I can't claim any direct knowldge. But the logic seemed sound enough for me, involving some knowledgeable people and quoting various NMRA specs. I'd be grateful and happy to hear the reasons why these (especially (2)) are not actually a problem, as this would mean I could acually use Railcom when the hardware and RR&Co interface are both available.
Merely corroborative detail, intended to add artistic verisimilitude to an otherwise bald and unconvincing narrative

W S Gilbert
Edwin_m
.
 
Posts: 1515
Joined: Wed Mar 07, 2007 8:19 am
Location: Nottingham

Re: RailComm block detectors/readers demonstrated

Postby Dutch_Master » Sat Mar 21, 2009 6:14 pm

Railcom works (roughly, for non-techies) as follows:

The booster offers a window for the decoder to send data back. It does so by disconnecting the track from it's powersupply, but via a resistor still supply some low power to any decoder in it's section.
The decoder responds by superimposing a waveform containing it's data on the low track power by switching the motor on and off rapidly, causing dents and bumps in the waveform.
The detector picks up these minute variations and decodes them into whatever info is transmitted from the decoder.

If you want the tech stuff, visit the NMRA DCC pages here Of interest are in particular RP 9.3.1 and RP 9.3.2 as these deal with communication from decoder to a reciever.
"You don't need eyes to see, you need vision"

(Faithless, 'Reverence' from the 1996 Reverence album)
Dutch_Master
.
 
Posts: 323
Joined: Mon Mar 09, 2009 9:05 pm

Re: RailComm block detectors/readers demonstrated

Postby Two Tone Green » Sat Mar 21, 2009 7:34 pm

Edwin, we share a similar situation with regards our set ups me thinks and your questions are certainly at the top of my list as well for clarification.

As Tartan Trax is at the manufacturing end of Railcom goodies I assume his knowledge must include that covering our concerns. Hopefullly he will find time to finally lay to rest these and other concerns people may have.

So far as I understand it from his earlier posting, block occupancy detectors that use diodes are not a problem. This would be very good if true.

As for the RR&Co aspect, I thing Mr RR&Co is already onto this. :thup
CMEE Pembrokeshire Railway
User avatar
Two Tone Green
.
 
Posts: 445
Joined: Sun Mar 04, 2007 2:10 pm
Location: Deepest West Wales

Re: RailComm block detectors/readers demonstrated

Postby p_harman » Sat Mar 21, 2009 11:01 pm

The Railcom signal is transmitted from the decoder to the detector as a current, not a fixed voltage. The Railcom detector should be a very low resistance, but is to some extent dependant on the resistance through the track to the detector and in the case of a global detector this could be some distance away making any dead load on the layout become significant. In the case of a global detector every resistive wheelset and lit coach on the layout will be sharing some of the current. I accept fully that this is unlikely to be of any consequence in the vast majority of installations, but should be taken in to account along with the minimum current that the Railcom detector can accept from the decoder. If installing resistive wheelsets and lit coaches on a large layout it is something that should be considered to ensure reliable detection of Railcom data. When a few blocks have Railcom detectors, there is still some value in having a global detector to keep tabs on which locos are active on the layout, and perhaps what their current coal and water level is for the very keen.

I understand that for your specific application where you are not proposing use of a global detector, there is no likely issue - but good practice would be to provide inverse parallel diodes in series with resistive loads where possible. It should not be discounted out of hand as a wives tale, do the sums where appropriate. There is quite a lot that needs to be taken in to account, including maximum resistance of the Railcom detector circuit that the current is passing through (you state 1.5R, but include wiring and track resistance too. This is much more significant in the low impedance loop of the detector than in the passive shunt load of the rest of the layout). 30 bulbs on a layout? very likely to happen. What is the point of putting a resistor in series with a bulb and making it dim - having to calculate its value based in the number of bulbs on the layout, when a pair of inverse parallel diodes will do a better job for less money (two diodes is probably cheaper than one high power resistor).

Please don't think that I am critical of your product or approach to Railcom implementation, I am not and fully support what you are doing, but you cannot discount Railcom good practice out of hand because it is not relevent to your product or how you intend it to be used.
User avatar
p_harman
.
 
Posts: 159
Joined: Thu Aug 28, 2008 11:45 am

Re: RailComm block detectors/readers demonstrated

Postby Two Tone Green » Sat Mar 21, 2009 11:20 pm

Another question that springs to mind now, is this new Railcom product aimed at a new build layout or an existing one that could be already fully set up that has a reasonable amount of complexity DCC wise.

The plot thickens.
CMEE Pembrokeshire Railway
User avatar
Two Tone Green
.
 
Posts: 445
Joined: Sun Mar 04, 2007 2:10 pm
Location: Deepest West Wales

Re: RailComm block detectors/readers demonstrated

Postby Nigelcliffe » Sun Mar 22, 2009 9:29 am

TartanTrax wrote:......The interesting part will be when applications are added that only RailCom can achieve ??“ e.g. changing a CV or two on a particular part of your layout automatically and then changing them back again when the train leaves the area in question. In other words, the really exciting stuff will come a little later as people start exploiting the full potential of RailCom.


I'm interested in what's being said, but I'm pretty sure I can do the above (change a CV within a block and back again) without Railcom.
I need a detector which lets my system know when the train enters the block (Mk1 eyeball, beam breaker, reed switch, track current detector, RFID tag reader), and a means to change the train (speed, functions) or its CV's (Ops programming, manual or computerised). These don't even need specific "blocks" in the track supply, just well positioned sensors. Or have I misunderstood ?

We already know that layout software does a pretty good job of tracking which train is where on most models, though I can see that RailCom could make the initial setup much easier. TartanTrax has already said that you would put one detector on the entry to a fan of sidings, and then use dead-reconning to track the train into its specific siding.

I do appreciate that the value of any feedback system comes when people play with the ideas and come up with new/interesting applications.


- Nigel
Nigel Cliffe
Secretary and Webmaster for The 2mm Scale Association
Various other modelling projects described on my blog
Nigelcliffe
.
 
Posts: 668
Joined: Mon Jun 30, 2008 8:38 am

Re: RailComm block detectors/readers demonstrated

Postby Edwin_m » Sun Mar 22, 2009 5:12 pm

Nigelcliffe wrote:
TartanTrax wrote:......The interesting part will be when applications are added that only RailCom can achieve ??“ e.g. changing a CV or two on a particular part of your layout automatically and then changing them back again when the train leaves the area in question. In other words, the really exciting stuff will come a little later as people start exploiting the full potential of RailCom.


I'm interested in what's being said, but I'm pretty sure I can do the above (change a CV within a block and back again) without Railcom.
I need a detector which lets my system know when the train enters the block (Mk1 eyeball, beam breaker, reed switch, track current detector, RFID tag reader), and a means to change the train (speed, functions) or its CV's (Ops programming, manual or computerised). These don't even need specific "blocks" in the track supply, just well positioned sensors. Or have I misunderstood ?


I'd rephrase that - "I need a detector which lets my system know automatically, which train is entering a block (RFID tag reader, Railcom, Digitrax transponding, LISSY, or train tracking by software from a previous block)". Then it all makes sense - Railcom is an alternative to RFID or the other means of identifying which train is present in a particular section.

It is also in theory possible to achieve this by sending a "global" DCC command to be obeyed by all decoders that receive it. However this would require isolating the section in question and feeding it with a different DCC signal to the rest of the layout, which isn't particularly easy.
Merely corroborative detail, intended to add artistic verisimilitude to an otherwise bald and unconvincing narrative

W S Gilbert
Edwin_m
.
 
Posts: 1515
Joined: Wed Mar 07, 2007 8:19 am
Location: Nottingham

Re: RailComm block detectors/readers demonstrated

Postby Nigelcliffe » Sun Mar 22, 2009 5:28 pm

I'm happy with your rephrasing Edwin. But there is still a question: Does Railcom really do anything additional over identifying which decoder is in a particular block section ?

- Nigel
Nigel Cliffe
Secretary and Webmaster for The 2mm Scale Association
Various other modelling projects described on my blog
Nigelcliffe
.
 
Posts: 668
Joined: Mon Jun 30, 2008 8:38 am

Re: RailComm block detectors/readers demonstrated

Postby Ian J. » Sun Mar 22, 2009 6:28 pm

Nigelcliffe wrote:Does Railcom really do anything additional over identifying which decoder is in a particular block section ?


I think in the longer run yes, but not so much now.

I can imagine something like the ability to confirm whether a DCC controlled coupling has actually engaged/disengaged could be very useful, also if any proximity sensor of some kind (for coupling up) was onboard, then it would be essential to know how far the loco was from the carriage or wagon being approached (v useful for hidden sidings, or on part of a layout some distance from the operator (and essential for full automation). These are of course the kind of applications that aren't easily possible at the moment, but hopefully will be at some point in the future.
Ian J.

S&DJR Forum - For all things S&DJR, both real and model

My layout: Sayersbridge Junction - 4mm finescale-ish, preserved, BR(S) region
My novels: IceFire Books - Science Fiction of the 'Otherworld Saga' variety
User avatar
Ian J.
.
 
Posts: 1157
Joined: Wed Jan 02, 2008 10:31 am
Location: Lodnod, East of Dorset

Re: RailComm block detectors/readers demonstrated

Postby TartanTrax » Mon Mar 23, 2009 10:16 am

Greetings again One & All...

There have been some requests for a simple explanation of what RailCom is:

Railcom is a current based signal where a decoder detects an end-of-packet and transmits ones and zeros as 0mA and 30mA currents at 4?µs intervals. The RailCom detector is required to interpret current levels of 6mA or below and 10mA or above as ones and zeros respectively and usually does so through the use of a small (?±1.5?©) resistor. The size of the cut out and other factors limits the longest transmission to 9 bytes although normally only 2 or 4 bytes are transmitted so there is a potential to use the extra bandwidth in the future.

A little tricky but as long as your control centre / booster conforms to the relevant NMRA spec you should be OK in terms of the cut out. Initially we used an Intellibox, which didn??™t produce a cut out, and the signal was natively asymmetric. By connecting the CDE output to a Lenz LV102 booster, we were once again OK. Later we managed to find a relatively cheap LZV100 so now use that instead.

With specific reference to some of the recent posts:

Edwin_m ??“ We agree there are potential difficulties with global RailCom detection. Like you we have little interest in this model and our device is really intended for local detection, as is the one proposed by Lenz. While a global reader clearly can be made to work on certain smaller layouts, I can??™t see why one would bother given the simplicity and versatility of local detection. Your point as regards current detectors using diodes should not be a problem, as they would be wired in series with the RailCom detector. That said, if the diodes are too slow for the 4?µs signal you may well have difficulties, so if, like us, you make your own, remember to check the response times of your diodes. We have tested our current detectors in series with Railcom detectors & the signal gets through just fine. Our current detectors have 4 diodes (1.2V drop) and an optoisolator none of which were specifically selected for compatibility with RailCom. (We selected them because they were cheap.)

In terms of your second question: Well this is really the global vs. local debate again (remembering that global isn??™t really global but per power district). If you are looking at local sections and you have for example two 30?© tungsten bulbs in parallel per coach and you want to fit 15 x one-foot-long coaches plus the locomotive into a single section you need a longer than 15-foot Railcom section. Not impossible but probably pretty rare and solvable either with introducing diodes in a few coaches, using LEDs instead of tungsten or reducing the maximum size of the sections. If you wish to read a large layout globally these issues are more likely to crop up.

Dutch_Master ??“ The rapid switching on and off of the motor is how the Programming Track works. Also Zimo (pre-RailCom) had a location identification system that relied on command acknowledgement by their decoders emitting a current spike after a command addressed to them. RailCom doesn??™t actually do this.

p_harman ??“ You're right that with a global detector or sufficiently large blocks you could exceed Railcom's limits in which case diodes would be necessary. The "myth" for want of a better word is that diodes would be required on every resistive wheelset or lit coach in all circumstances. If instead as you say you were to provide them on those coaches where they are easier to fit then the more tricky ones could be left out (providing these number less than thirty or so) which could make life a lot easier particularly for N or smaller scales. I feel I must point out that we arrived at this number by calculation based on the parallel wiring of the bulbs as in our Roco coaches, however if the bulbs are in series as in some of our Fleischmann rolling stock, their resistance would be additive and you might find that double as many coaches could work. As you say you have to work out what you need based on your specific layout. The best rule is to ???suck it and see??? once the kit becomes commercially available. The bottom line for any RailCom section is that the combined resistance for that section must not drop below 0.75?© in order to remain within spec.

Two Tone Green ??“ The product isn't really aimed at either the new-build market or people with existing layouts in particular. Obviously it will be easier to integrate Railcom into a layout if it is designed in from the beginning however there is no problem with converting an existing layout to Railcom. You are likely to have more track cuts in an existing layout than are needed with Railcom but this isn't a major problem. The biggest advantage to incorporating it into a new layout is that you can work out the logic behind the layout with Railcom in mind, which is likely to produce a simpler result.

Nigelcliffe & Ian J ??“ RailCom is supposed to be able to do a number of things besides identity although the mechanics behind some of the applications are somewhat unclear. Currently our Lenz Gold decoders have only been observed to transmit address, actual speed and temperature. At present there are ten different message types defined allowing the decoder to transmit: address, CV values, flag bits (e.g. fault, consist), actual speed, load, route, location, fuel, water and temperature. What purpose some of these values serve is undefined. There's no clear way to implement some of the things you mentioned. On the other hand there is a CV Value packet that includes the CV address and could be used to extend the specification in a pretty much unlimited fashion (e.g. a "CV 267 has value 33" packet could indicate a value of 33 from the proximity sensor as suggested in your post). This functionality would require support from the RailCom decoder. The possibilities are clearly extensive.

Finally, we were experimenting with some variations in software on Sunday and took some video while we were about it. We will try to upload it to You Tube so anyone interested can see how a simple block-control algorithm works and see the display that shows the RailCom/DCC data per section as it is transmitted. We will post a notice once it is available online.

Many thanks to all those who have shown an interest in our endeavours.
TartanTrax
New Poster
New Poster
 
Posts: 5
Joined: Thu Mar 19, 2009 9:23 pm

Re: RailComm block detectors/readers demonstrated

Postby Ian J. » Mon Mar 23, 2009 11:08 am

TartanTrax,

Many thanks for the info.

Regarding the transmit-able values (address, CV values, flag bits (e.g. fault, consist), actual speed, load, route, location, fuel, water and temperature), I am presuming that 'actual speed' is as it says on the tin, and not the currently set speed step using the DCC controller? Also that 'temperature' is the temperature of the DCC decoder? Can you elaborate on what 'load' is? Could it be the train consist the loco is hauling/pushing? I'd also be interested to know whether 'route' and 'location' are coming from the Railcom block section, or whether they are values that are in some way programmed into a decoder :?
Ian J.

S&DJR Forum - For all things S&DJR, both real and model

My layout: Sayersbridge Junction - 4mm finescale-ish, preserved, BR(S) region
My novels: IceFire Books - Science Fiction of the 'Otherworld Saga' variety
User avatar
Ian J.
.
 
Posts: 1157
Joined: Wed Jan 02, 2008 10:31 am
Location: Lodnod, East of Dorset

Re: RailComm block detectors/readers demonstrated

Postby Two Tone Green » Mon Mar 23, 2009 12:34 pm

Yes, many thanks for the info Tartan Trax, very interesting. More food for thought.

My layout is already very much up and running with full track circuiting and block control using diode based current detection system, LDT RS8's of which there are many. But if as you say it is only a serial connection that is required then all should be well.

You mention the use of Lenz equipment to do your tests. The question springs to mind. where is the output of the reader fed into. You have a railcom detector in a block, fed into the reader and then where. It is the where bit that is now of interest. With Lenz there will be the option to feed directly into a PC via a USB interface or into the Xpressnet which obviously is then fed out of the PC interface along with any other info going back and forth between LZV100 and PC. Will your product be DCC system specific, Lenz, Digitrax etc or universal some how. The way I read the current situation it will be universal with your own USB interface.

Also the joining of readers to increase the number of blocks that can be monitored. Any thoughts on this?

Thanks again for your input. It is the most we have had from any one interested in making Railcom equipment and able to answer peoples questions. :thup
CMEE Pembrokeshire Railway
User avatar
Two Tone Green
.
 
Posts: 445
Joined: Sun Mar 04, 2007 2:10 pm
Location: Deepest West Wales

Re: RailComm block detectors/readers demonstrated

Postby Edwin_m » Mon Mar 23, 2009 12:50 pm

I must agree with the two posters above me, this reponse from TartanTrax is very useful and illustrates a willingness to make a product that actually suits people's needs and to let potential users know what it will do so they can plan their layouts accordingly. Building a complex layout takes a long time so it is good to know what features may be on the way even if they are some time off!

With regard to the resistance axles in section, TartanTrax and I are exactly in agreement. You can get away with having a few resistance axles in the detection section provided it is isolated from the rest of the layout by back-to-back diodes. So it's just a question of picking the length of the section to get enough time for detection as the train passes over but also stay below the total resistance limit. When I did the calcs before I'm pretty sure this was within the bounds of possibility.

However are you sure 0.75ohm is right for the resistance across the rails in each section? That would draw getting on for 20 amps at DCC voltage!
Merely corroborative detail, intended to add artistic verisimilitude to an otherwise bald and unconvincing narrative

W S Gilbert
Edwin_m
.
 
Posts: 1515
Joined: Wed Mar 07, 2007 8:19 am
Location: Nottingham

Re: RailComm block detectors/readers demonstrated

Postby JohnRussell » Mon Mar 23, 2009 8:58 pm

Dear All,

ZIMO have been quick to implement RailCom (please note correct spelling) in all their decoders and were the first to market with a reall application of using RailCom with the Global Detector in the MX31ZL (October 2007). This Global Detector is also to be released as an add-on board to the existing controllers. This Global Detector can find all locos with RailCom decoders on the layout and display any of the current RailCom messages being received (speed etc.) on the display of the MX31ZL.

Of course, this Global Detector cannot tell you where the locos are on the layout and you still need local detectors for this and I am glad to see that someone is working on this aspect of using RailCom.
Regards
John Russell
Probstdorf, Austria
User avatar
JohnRussell
.
 
Posts: 122
Joined: Sun Mar 04, 2007 9:01 pm
Location: Probstdorf, Austria

Re: RailComm block detectors/readers demonstrated

Postby TartanTrax » Mon Mar 23, 2009 9:57 pm

We were asked in a previous post whether there was anything that Railcom could do that could not be done using alternative methods. While this is of course a perfectly reasonable question, in all honesty, I had never really asked myself this before, as I have felt all along that the improved simplicity was enough of a reason to get involved. Nevertheless this puzzle has been nagging away at me. To be absolutely truthful the answer is probably not. However, on reflecting on a couple of applications we hope to implement on our own layout it struck me that I may have stumbled on a few examples which, if not impossible, would at the very least be quite difficult without RailCom.

Firstly, I thought that it might be nice to have the coach lights dim when trains were in the distance in order to enhance perspective. With conductive couplings (very nice ones available from Viessmann or Tams) coach lighting could be driven from a function output on the decoder. Automatic setting of CVs ???on the fly??? could then be used to easily produce this effect. Without RailCom it??™s probably not impossible (very little ever is) but it is unlikely to be achieved so simply.

The other desire I have is to own an automatic crane with its own decoder and an electromagnetic grab mounted on a wagon. With simple scripting a train can be made to stop automatically and load some scrap metal which could be delivered to a scrap yard elsewhere on the layout. You wouldn??™t even need to always use the same locomotive as both the RailCom from the crane as well as the locomotive could be read in the same section and the locomotive be given certain commands specifically due to the presence of the crane. I??™m sure this can be done in other ways but probably not without a lot more hassle and dedicated electronics. Then, what about the little lady from Viessmann who knows only to wave as passenger coaches go by and not to wave at goods trains? Or for N-scale ??“ you could have little speakers mounted directly under the tracks and accurate prototypical sound could follow your locomotives around your layout. I??™m sure you get my drift.

Well good people, we finally uploaded a bit of video footage onto YouTube. It can be seen at: http://www.youtube.com/watch?v=keDJOnSlqvc although I must warn you that the quality is very poor. (Our 1.25Gb original video is now only 17mb in size.) Still, you can see the bi-directional information loop in action. RailCom data goes from the 8 detectors to the reader in the centre, which interprets the packets and sends them via USB to the PC. (Our device uses true USB and doesn??™t have an onboard USB to serial converter like many other devices out there. The big advantage is speed and no need for a Com-port. The disadvantage ??“ we had to write a software driver for the device so the PC knows what it??™s talking to.) Inside the PC the incoming data is scrutinised and a proximity rule is applied. If a potential collision situation occurs, the following locomotive is sent a ???set speed 0??? DCC packet. Occupancy is denoted on the screen by the respective detector pane title going from blue to green. A ???set speed 0??? command is highlighted above the pane with a red octagon with a small cross inside. Once an unoccupied area exists between them, the trailing locomotive has its speed set back to the previous value. All DCC packets are sent to the tracks via the Lenz computer interface and the LZV100 control centre. You will notice that all hand-controllers are absent and once initial speeds have been set on the PC, all traffic runs automatically. DCC and RailCom data is displayed in those panes with RailCom decoders in occupation. Lit coaches only show ???Occupied??? with no further data and, naturally, unoccupied panes have blue titles and also show no data.

We would like now to answer some of the points raised since our last post but first let me thank you all for your positive responses and encouragement.

Ian J. - We really have no idea precisely what the various values mean. The specification says these values exist but makes no move to clarify their intent (although some like address and CVs are obvious). We've observed that the actual speed value seems to be a percentage between stationary and the maximum speed setting for the locomotive but even that is just a guess. We have noted that once a ???set speed 0??? command is received this percentage drops gradually to 0 in step with the locomotive following its prototypical breaking curve. We have assumed that Temperature is in degrees Celsius but if this is so then some of our decoders (especially some of the Gold Minis) seem to be running pretty hot. As regards Route and Location, we suspect (but it??™s just a guess) that this may tie in with Zimo??™s proposed ???signature cut out??? mechanism whereby decoders could transmit the identity of the RailCom section they are in by the unique variation to the cutout. I suspect this is intended to allow a global detector to function and so avoid the need for local detectors. However these coded cutouts would require local cutout-generating devices instead.

Two Tone Green - The reader devices plug into a USB port directly. We considered making a separate bus a la Lenz but decided against it given the extra complexity and that USB already supports adding large numbers of devices through the use of hubs. We calculated that in this way we could have a theoretical maximum number of 1016 RailCom sections controlled by 1 PC. (Without divulging too much here, our RailCom device is just the first of many devices we have in various stages of planning. Apart from our open-source train controlling software project our next device will probably be a control centre. We made a mock up on breadboard and it worked pretty well. Not bad with only 3 active components! The final version will probably have a few more bits but it should still be very cheap and quite future-proof as well.)

I am sceptical about feeding RailCom information onto Xpressnet given the sheer volume of data our device produces when compared to the bandwidth of Xpressnet. It would likely require the RailCom detector to process the data before relaying it to the computer whereas we have opted to transfer all the RailCom data raw so that any future extensions to the specification (e.g. new packet types) can be supported without changing the device. The concept of future proofing requires that most of the clever stuff be in software.

RailCom is exclusively a DCC technology. It is incompatible with Selectrix & Motorola etc. at present (and possibly always). It is also incompatible with the option of running one DC (non-chipped) locomotive alongside the DCC equipped ones. That aside, our device is not only compatible with Lenz equipment but should ultimately work with any NMRA compliant DCC system. Our software currently supports Lenz & other Xpressnet based devices (Roco etc.) as well as the Intellibox / Twin Centre codes. We hope to add support very soon for those using Ethernet interfaces such as Viessmann & Esu. We have no plans at this time to add Loconet support, as we want our software to be free and open source (published under the GNU licence) and Digitrax have restrictions placed on the use of their Loconet protocol.

Edwin_m ??“ You raised a very interesting point, however, by our calculations, at 0.75?© the current would be about 6.67A, as during the cut out the RailCom detector is effectively wired in parallel with the resistances on the track (which would make the combined resistance 0.5?© if the track resistance is 0.75?©) but when the cutout ends the detector and the tracks are wired in series making the combined resistance 2.25?© and the current 6.67A (assuming 15V as you did). The value of 0.75?© comes from the fact that the decoder produces ?±30mA and the reader requires 10mA. If a 1.5?© resistor is put in parallel with a 0.75?© resistor then the current will split 10mA/20mA through the two resistors. As you rightly point out the current drawn by such a low resistance is greater than that supplied by a booster (even a Lenz 5A booster) and therefore it is impossible to place enough resistance in a single power district to degrade the RailCom signal to the point where it can't be read (and obviously a RailCom detector can't detect more than one power district) so the problem of resistive loads is in fact moot.
TartanTrax
New Poster
New Poster
 
Posts: 5
Joined: Thu Mar 19, 2009 9:23 pm

Re: RailComm block detectors/readers demonstrated

Postby JohnRussell » Mon Mar 23, 2009 10:54 pm

Dear TartanTrax,

ZIMO have solved this problem of relating speed step to actual speed via a calibration run to determine the actual speed of an individual loco. If you use a ZIMO decoder (e.g. the MX620) in your RailCom tests then you can get real speed of the loco after a calibration run in the RailCom messages. After a calibration run, the CV 135 and CV 136 contain the parameters which convert from speed step to Km/h and are used to generate the speed in the RailCom message. For more details, see page 27 of the ZIMO Decoder Manual.

I hope you will consider using ZIMO decoders (as well as Lenz) in the further testing and development of RailCom local detectors. Although all the standards for RailCom are discussed and agreed in regular quarterly meetings of the RailCom Working Group (Lenz, ZIMO, Tams and Kuehn), I believe ZIMO are further ahead than Lenz with the actual implementation of RailCom.
Regards
John Russell
Probstdorf, Austria
User avatar
JohnRussell
.
 
Posts: 122
Joined: Sun Mar 04, 2007 9:01 pm
Location: Probstdorf, Austria

Re: RailComm block detectors/readers demonstrated

Postby samkiller42 » Mon Mar 23, 2009 11:33 pm

Am i right in thinking that, Block detectors can be used for automatic signalling? I.E, if a train occupied a block, the signals behind would be Red, slowing and or stopping trains, or Green lights infront of said train to allow a clear path.
Am i right in thinking this, or am i in fantasy land?

Thank you in advance

Sam
Can't actually decide what layout i want to build, that's not a good start
User avatar
samkiller42
.
 
Posts: 70
Joined: Sun Mar 22, 2009 4:57 pm
Location: Havant, Hampshire

Re: RailComm block detectors/readers demonstrated

Postby craigwelsh » Tue Mar 24, 2009 1:52 am

samkiller42 wrote:Am i right in thinking that, Block detectors can be used for automatic signalling? I.E, if a train occupied a block, the signals behind would be Red, slowing and or stopping trains, or Green lights infront of said train to allow a clear path.
Am i right in thinking this, or am i in fantasy land?

Thank you in advance
Sam

Block detection would help automatic signalling by telling the software which blocks are full and it would be up to the software to control what the signals do with this info..

If you look on the wirral frm website dave (beast) did a guide to setting up block signalling in RR&Co that could work with block detection.

Great video TartanTrax, impressive hardware and software by the look of it. The ability to do pantograph flashes when an electric loco passes under a section of wire would be another use by the way..
craigwelsh
.
 
Posts: 3401
Joined: Mon Mar 05, 2007 1:05 am
Location: manchester

Re: RailComm block detectors/readers demonstrated

Postby p_harman » Tue Mar 24, 2009 11:10 am

One of the best features of RailCom is its ability to identify which way a loco or any RailCom equipped piece of stock is facing. This makes it possible to automate fiddleyard dispatch where a train may be turned by hand on arrival so that it is facing the correct way to be dispached back to where it came from - very handy if you have steam locos where it may be possible to automatically script consisting of the loco with the coaches where the coaches stay on the track but the loco is turned and put at the other end, the tail light can then be made to work automatically at the correct end by consisting the coaches in reverse. This is one of the hardest things to automate in an end to end layout and now becomes possible where a simple button press by the fiddlyard road can be used to signal to the control system that the train is ready to be identified (by RailCom) and dispatched (in the right direction!).
User avatar
p_harman
.
 
Posts: 159
Joined: Thu Aug 28, 2008 11:45 am

Re: RailComm block detectors/readers demonstrated

Postby Crosland » Tue Mar 24, 2009 12:35 pm

TartanTrax wrote:Firstly, I thought that it might be nice to have the coach lights dim when trains were in the distance in order to enhance perspective. With conductive couplings (very nice ones available from Viessmann or Tams) coach lighting could be driven from a function output on the decoder. Automatic setting of CVs ???on the fly??? could then be used to easily produce this effect. Without RailCom it??™s probably not impossible (very little ever is) but it is unlikely to be achieved so simply.

The other desire I have is to own an automatic crane with its own decoder and an electromagnetic grab mounted on a wagon. With simple scripting a train can be made to stop automatically and load some scrap metal which could be delivered to a scrap yard elsewhere on the layout. You wouldn??™t even need to always use the same locomotive as both the RailCom from the crane as well as the locomotive could be read in the same section and the locomotive be given certain commands specifically due to the presence of the crane. I??™m sure this can be done in other ways but probably not without a lot more hassle and dedicated electronics. Then, what about the little lady from Viessmann who knows only to wave as passenger coaches go by and not to wave at goods trains? Or for N-scale ??“ you could have little speakers mounted directly under the tracks and accurate prototypical sound could follow your locomotives around your layout. I??™m sure you get my drift.

These applications still only make use of block detection and ID and can be achieved with, e.g., RFID, at a similar level of complexity. Once you have "train X is in block Y" the processing required to make anything happen is the same regardless how you gained that information. The only real advantage of RailCom in this case is that detection is active throughout the block rather than at a single point (e.g. next to the RFID reader).

RailCom is really about bi-directional communications and the ability to query the decoder about it's state or it's environment. At the moment this seems to be limited to ops mode CV readback and things like simulated fuel and water levels. Once manufacturers start adding *inputs* to decoders then it gets a whole lot more interesting. One example quoted is detecting positive engagement of couplings when shunting.

Andrew
Crosland
.
 
Posts: 139
Joined: Fri Nov 16, 2007 1:49 pm

Re: RailComm block detectors/readers demonstrated

Postby Two Tone Green » Tue Mar 24, 2009 5:33 pm

Thanks Tarten Trax. Yet more interesting info and a video as well. Suggest rapid first aid for plant outside though. :lol:

The Xpressnet does seem a little narrow to handle all the info unless as you say it is processed before sending out onto the net. The box under development by Lenz will possibly do this. Also it lags a tad behind development wise from what I understand. I think Lenz would prefer the USB version over the Xpressnet one.

The more I read about this the more I realise it will change things with regards functionality on the layout. But it needs the Decoder and hardware people to pick up the ball and run with it regarding applications. The list could be long, but how long will it take for it to happen. It has taken long enough to get this far. The talking at the NMRA has possibly stopped, now we need the goodies to further it.

Its all well and good Zimo leading the pack, but Zimo are not market leaders and unlikely to be at their prices. But is this a sign of the price we will have to pay for Lenz and the others to give us what we would like. As for Digitrax, huge market share but they don't always play along with the others. Their target market is possibly the biggest in the world and with out it coming on board to support Railcom with number of buyers, it could well still remain an expensive add on.
CMEE Pembrokeshire Railway
User avatar
Two Tone Green
.
 
Posts: 445
Joined: Sun Mar 04, 2007 2:10 pm
Location: Deepest West Wales

Re: RailComm block detectors/readers demonstrated

Postby wusko » Tue Mar 24, 2009 7:04 pm

Two Tone Green wrote:... Zimo are not market leaders and unlikely to be at their prices.


Really? I model in N gauge & have standardised on the Zimo MX620 6 pin decoder (assymetric DCC & Railcom) currently available from Bromsgrove at ??28. The Lenz options are the Silver Mini (assymetric DCC but no Railcom) at ??32 or the Gold Mini (assymetric DCC & Railcom) at ??38.25 - these prices from Digitrains.

Howard.
Howard, Merg Secretary
MERG
Now I've got a "roundtuit" there is no excuse (Yes that really is a BIG computer disk)
User avatar
wusko
.
 
Posts: 95
Joined: Wed Jun 18, 2008 8:42 am
Location: Goring, Oxfordshire

Re: RailComm block detectors/readers demonstrated

Postby Two Tone Green » Tue Mar 24, 2009 7:48 pm

Decoders are only one part of the system.
CMEE Pembrokeshire Railway
User avatar
Two Tone Green
.
 
Posts: 445
Joined: Sun Mar 04, 2007 2:10 pm
Location: Deepest West Wales

Re: RailComm block detectors/readers demonstrated

Postby Edwin_m » Tue Mar 24, 2009 11:01 pm

Like Howard I use the Zimo decoders which are better and often cheaper than Lenz if you want a top-of-the-range decoder, though TCS and Digitrax are alternatives for the more budget-conscious.

Not sure of what point you are making here TTG - if you're alluding to the cost of a Zimo command station then I agree they are verging on the exorbitant (sp?), but the Lenz set 100 is Railcom-compatible and a good deal cheaper (and if you have all Zimo kit you don't need Railcom anyway). I do agree however that Digitrax transponding is a serious rival to Railcom.

The (apparently) imminent arrival of Railcom was one of the reasons I went for Lenz kit when I bought my command station four years ago - I considered Digitrax but preferred an open standard for mobile decoder feedback rather than one owned by a single supplier. It hasn't worked out quite like that but I'm hoping that this product from TartanTrax will now deliver on my original expectations.
Merely corroborative detail, intended to add artistic verisimilitude to an otherwise bald and unconvincing narrative

W S Gilbert
Edwin_m
.
 
Posts: 1515
Joined: Wed Mar 07, 2007 8:19 am
Location: Nottingham

Re: RailComm block detectors/readers demonstrated

Postby Two Tone Green » Wed Mar 25, 2009 7:12 am

Hi Edwin, Yes my comment was about the price of their hardware, command station etc.

Like you I went the Lenz route when I changed over to DCC from ZTC. Poor reason may be but I just dont like the look of Digitrax, it looks so home built, toy like to me, sorry. It may do the job but there was some thing about it that put me off and went for Lenz.

With all the owrk now being done by the European makers, possibly Digitrax sales will drop off. Most people going for DCC now and post on hee seem to go for Bachmann, Hornby, ESU, Lenz as well as NCE, but you dont hear of many Digitrax.

Railcom is coming, like DCC it will take time to build upto mass use and a much lower price.
CMEE Pembrokeshire Railway
User avatar
Two Tone Green
.
 
Posts: 445
Joined: Sun Mar 04, 2007 2:10 pm
Location: Deepest West Wales

PreviousNext

Return to DCC Forum

Who is online

Users browsing this forum: No registered users and 4 guests