I visited the Model Rail Scotlands??™ big exhibition at the SECC in Glasgow yesterday and one of the most interesting products on display was on the DCC Supplies stand.

They had an oval of track demonstrating their pre-production RailComm block detector and reader. The oval of track was cut (one rail only as per usual block practice) into eight blocks with one of the RailComm detectors for each block, each detector was then connected to another module (designed to take up to eight block detectors) that then fed the information via USB to a laptop. As two locos circulated the oval one could see all the details of the decoder such as address, direction of travel as well as orientation, speed step etc. appear on screen in the relevant box of eight (one for each detector).

According to the developers the block detector could be configured to read any of the decoders??™ values using software that will be supplied with the modules.

I asked why they were feeding the signal from the detectors to the computer via a dedicated/direct USB link rather than letting the information travel back to the command centre via the main bus or even a dedicated feed-back bus (as per Lenz practice) and it appears that the amount of information to be transmitted causes unacceptable latency on the XpressNet bus, so there is little point in feeding it back to the command centre if the command centre can only talk to a computer via the XpressNet bus, hence why they have a dedicated information route from the detector to the central module that then puts the information directly to the computer via USB.

The modules look like they do what Lenz claim their modules will do, but the DCC Supplies modules are here and working, even if only in pre production form.

DCC Supplies are in the process of, or are about to, ship samples to the NMRA to get conformance approval for the modules.

I asked about getting the information into control software such as RR&co, and DCC Supplies said it was up to the control software to understand the information format, although I understand they have talked to Freiwald (RR&co.).

It is maybe idealistic of me, but I do hope a common format is arrived at for presenting RailComm information over a USB interface so that all control software companies find it easier to support these up and coming devices .

As regards cost it is difficult to be precise as the modules are at a pre production stage and costs will vary depending on who will be doing the assembly and on volumes produced, however they did mention a price of around ?? 38.00 for each detector/reader. I forgot to ask about the price of the central module that gathers the info from up to eight detectors, apologies .

It is good to see RailComm devices beginning to appear, if only to justify my decision early last year to fit only RailComm capable decoders in my locos.

Two Tone Green wrote:Sorry, forgot to ask, how many blocks can a detector, reader handle. That is for ??38, how many blocks can it cover? If it is ??38 per block, that is a tad expensive.

According to the Lenz info, their units can handle four sections, with up to 256 detectors on the RailComBus, making a total of 1024 sections. As yet no pricing for the units though. Hopefully DCC Supplies unit will be able to handle as least four sections.

Each reader/detector only reads one block. When discussing this with them i mentioned the LDT 8 block detectors and mentioned i had twelve of them, LDT cost around ?? 620, cost of these a shade under ??3,800 . As you said a TAD expensive

And that is without factoring in the cost of the collecting/USB interface modules.

Thanks Mike, thats the bit that is a bit frightening. Current block count 107 X ??38 = ??4066. And I have plans to add another few blocks to that to improve signalling.

The otherthings is, will it handle block occupancy for non railcom items as the new Lenz units will as long as resistive wheel sets are fitted ? Just another thing to look at. But at the price, it may be a while before I go with DCC supplies for my Railcom equipment.

May be LDT will join in and upgrade the RS8 to a Railcom version and save the day with a kit or ready built version for a lower price as they currently do.

Excellent news that another party is moving forward with Railcomm - and a British firm at that! (or is it actually developed by someone else?). Will keep an eye on the DCC supplies site for any emerging details (nothing yet).

I guess at those sort of prices we will be keeping our RS8s etc for the vast majority of detector sections and using the new kit just where it is needed to supplement the train tracking features on RR&Co which I understand work pretty well most of the time, and are after all good enough for the prototype! As I posted on another thread recently, although resistance axles are not officially compatible with Railcomm I think (based on theory not practical experience) they can be made to work together under certain circumstances.

Railcom detection is interesting, and as the previous posting says, detailed identification will only be needed on occaision, not every block.

But, I wonder if at the prices suggested whether RFID would turn out to be cheaper and simpler for identification ? Evidently Railcom can readback all sorts of decoder details from the main line, but if its just identification of the specific loco number (or rolling stock item), then RFID could do all that is required (with the added advantage that you can find stock not on a layout with a hand-held scanner!).

Perhaps what is needed is two levels of Railcom read back/detector. One being a simple, cheaper, type that just reads back the decoder address in those places where you need to know what is where, or confirmation that loco 1234 has reached block 27B. The other would be a more sophisticated type that gives you full read back of all CVs in those spots on the layout where you'd want that. That way you could get detection without having to install the most expensive type everywhere just to get the address of the decoder in the loco/Mu occupying the block. The alternative is the current draw type or IR detectors embedded in the ballast as simple occupancy types.

However, RFID does look more attractive if Railcom read back detectors are so expensive that you cannot afford them. It would be a pity if the promise of Railcom for occupancy detection was lost because of the cost of the units.

Keith.--------------------------------------------------------------------------------------------------------------------------------------The only good locomotive or Multiple Unit has collector shoes, or pantographs, or both.

I think that as these units and the RailComBus are relatively new in the RailCom electronics world that they will be a bit expensive to start with. Hopefully over time they will become cheaper, and hopefully if the system is as 'open' in its standards as Lenz profess, then maybe MERG or some-such will do an electronic kit for somewhat less money...

Compared with Railcom, RFID has the advantage of being a mass-market technology (therefore probably cheaper) and only requiring a passive detector on the rolling stock (particurly important for anyone who wants to track everything not just locos).

I suspect Railcom would be easier to fit to the layout - just interpose a reader in the wire to a particular section, rather than having to position the readers exactly under the relevant track and worry about cross-talk from adjacent tracks. Also for us N-gaugers where space is at a premium, it is better to have the existing decoder performing the identification rather than having to add something else.

Not sure that a address-only Railcom detector will be any cheaper as such, as reading the full set of CVs requires exactly the same hardware and very little extra software. Could be a case for "crippleware"? Also, provided you haven't got resistance axles and diode-drop current detectors, a single Railcom detector ought to be able to interrogate CV info from a loco anywhere on the layout whereas position identification needs a detector on each block where it is fitted.

DCC Supplies may have gone out on a limb here, with regard to price and the number of blocks covered by a single detector (if that is actually the case?).At least two manufacturers, Lenz and Viessmann, have already announced detectors that will cover 4 blocks each. ESU on the other hand are introducing a combined 16 block detector, of which 4 blocks will be Railcom (the ECoSDetector). I'm sure more products will follow.

With regard to the possibility of simple Railcom detectors only supplying ident data to the bus; would that be possible if the decoder transmission is a packet, without the detector having to be more complicated (so that it can strip out the other data) and therefore more expensive? It might be a pointless exercise if such a supposed "basic" detector cost much more than a standard one.

I was told about this thread by Andy at DCC Supplies earlier today. As it turns out my son and I were the people demonstrating our RailCom prototype on their stand at his kind invitation in the SECC in Glasgow. Firstly let me thank Mike Friedman for his explanation. It was excellent and also pretty accurate. What has become clear from some of the people we met at the SECC, and for that matter from comments on this and other newsgroups out there, is that there seems to be some confusion regarding RailCom and what it could and should be used for. (There is even one newsgroup specifically that seems determined to spread as much misinformation as possible.)

RailCom is an ideal technology for introducing a level of automation to a layout. Which of the currently available software packages will support this technology is dependant on the individual software producers. In order to fully exploit the potential of RailCom, specific upgrades would be needed for each software package in order to take advantage of information beyond just identity - e.g. actual speed, direction, orientation etc. We intend bundling a stand-alone software package with our device if and when we get permission for commercial use of the RailCom patents from Lenz. (The NMRA has recently decided it cannot issue warrants of conformity for these devices as they have no suitable equipment for verification of their compliance with the specifications.) We intend that our software will be sufficiently simple so that a total programming novice will find it easy and intuitive to set up rules and commands specific to a particular layout configuration.

A number of posts seem to be concerned with costs. We have absolutely no idea what the final costs will be but are working with everyone in the supply chain to keep prices down. The guestimate of ??38 was based on us earning nearly ??5. When you add component and manufacturing costs, wholesaler or agency fees, retailer markup and finally the 15% VAT you get to ??38. Sadly, if we made nothing at all it wouldn't get much cheaper and none of this takes into account the ??550.00 laser-cut metal solder mask we would need to have made before we could even get the first production run arranged. Chaps, ours is not a cheap hobby! That said though, on reading some of the estimates in this thread I felt I needed to restore some sanity. ??4000!!! On one layout? Dear God- if that were likely we would have abandoned the project at the start. Also those people talking about swapping all their occupancy detectors with RailCom detectors are either very wealthy or missing the point a bit. The idea is to place RailCom detectors only at "decision points" on your layout. Let's say you have a fiddle yard with parking for 20 trains: You could use 20 RailCom detectors but more reasonable would be one monitoring both the entry and exit points and 20 ordinary occupancy detectors - one per parking area. Software can easily record which trains are in and log where they were parked. Also, in order to monitor all your (RailCom enabled) point decoders as well as set CVs anywhere on a layout, only one RailCom detector would be needed.

Our system has a reader device which can take up to 8 detector devices plugged into it. Each detector will only monitor a single RailCom zone. (Unlike the Lenz model which will monitor up to 4 zones - but has the disadvantage that you have to use the same rail for all 4 - ours will read either rail or even both should you wish, although we can't imagine a circumstance where this would be required.) Our detectors can also read more than one train within a single zone. If you imagine a large RailCom zone also containing several simple occupancy detectors on sequestered sections of track within the zone, (You can make your own occupancy detectors for about ??2 each.) with suitable software you can now set up block control or operate signals with pinpoint accuracy. We estimate that most home layouts will probably need, on average, between 4 and 8 detectors in total, at least to start with. Further complexity can always be added in later if desired. The key is good software combined with clever planning.

Another question that came up was regarding resistive wheelsets and occupancy detection of non-RailCom transmitting wagons, coaches etc. Resistive wheelsets, lit coaches etc. would show up as "occupied" but initially without identity to the reader. Our intention is that the locomotive identity would then be assigned in software to the entire train. By doing this, handling consists and reversing etc. are all easy. For those with no room for a decoder in the locomotive or a non-RailCom sound decoder already in place, the RailCom transmitter could be fitted in the guardsvan, lit coaches etc. It would make no difference as the software should treat all trains as if they were very long, flexible locomotives.

Remembering that Lenz first patented RailCom in 2000, it is now 9 years later and the only working application using the technology we have seen to date is our own and we only developed it (It took us under 6 months.) because we were tired of waiting for the NMRA Working Group to do so. (Although the Lenz LRC120 was a fine proof of concept its functionality can't be extended to include any form of automation.) We have chatted to Peter Rapp at Lenz and sent him one of our prototypes to test but are still waiting to hear how they got on. We are really very keen to get this into production as we have several other items in development which we feel could also help enhance the enjoyment of our hobby.

If anyone has any further questions or comments we would be glad to hear them and will try to help where we can.

The disk came from an old CDC computer that was de-commisioned in the 1970's. It probably only has 32 to 64K storage per side! There is an area where a head crash occurred. I plan to donate it to the computer museum at Bletchley Park (when I get "around to it"!)

Howard.

Howard, Merg SecretaryMERGNow I've got a "roundtuit" there is no excuse (Yes that really is a BIG computer disk)

Interesting hearing from a manufacturer of an actual proposed Railcom product. I think quite a few people on here will be interested in listening to what you have to say with regards developments in the Railcom world and what progress is made with your product.

Two things spring to mind straight away with regards use of your Railcom detector, 1 the cost and 2, will my chosen software support it. That being RR&Co of course. Should RR&o not be able to make use of the output from the reader, then obviously it will be of little use to me. Has an approach been made to the writers of this well known software to see about getting support built into it as Lenz are currently doing.

The cost as well, how will your single detector compare with the the Lenz unit that has four detectors built into it. As yet, the cost of the Lenz units I believe is unknown.

LDT in their efforts to reproduce equipment that matches some of the well know DCC manufacturers at a much reduced cost in ready made and kit form has been a great success and their equipment used by members on this forum. I expect you aim for similar and I wish you every success.

As I said, I look forward to any updates you have about progress and also about the abilities of Railcom and what it can do for us. Thanks.

Edwin_m wrote:As I posted on another thread recently, although resistance axles are not officially compatible with Railcomm I think (based on theory not practical experience) they can be made to work together under certain circumstances.

The resistance axles need to have a pair of back to back diodes in series with the resistor, and non-decoder fitted stock with lighting will need to be treated the same to prevent interference with the Railcom signal.

Edwin_m wrote:As I posted on another thread recently, although resistance axles are not officially compatible with Railcomm I think (based on theory not practical experience) they can be made to work together under certain circumstances.

The resistance axles need to have a pair of back to back diodes in series with the resistor

I don't think this is achievable on an N gauge axle, unless someone sells the three components integrated onto a single SMD package. I think I can make Railcom do what I want it to, but if I can't then I'll do without it rather than changing all my resistance axles and possibly also the current detectors.

p_harman wrote:I think that a solution might be to use small SMD components glued to the axle and 'wired' up to the wheels with conductive paint. Three times as much work as just a resistor unfortunately.

Yes I thought that would be the answer Usually takes me several attempts to get a resistor working on its own, having to get it in series with a pair of diodes doesn't bear thinking about.

In my previous post about getting Railcomm to work I wasn't referring to this method, rather suggesting that the signal levels still to work even if there are a couple of resistance axles in circuit. So should still be OK to identify a loco provided the Railcomm detection section is short enough to include only the loco plus just the first bit of the train. I can't have "global Railcomm detection" (anywhere on the layout from a single interrogator) due to having diode block detectors, but personally I don't have much need for this facility anyway.

Thanks to those showing an interest in our RailCom device. With regard to some of the comments:

Two Tone Green ??“ As regards support by other software manufacturers ??“ We have not spoken to J??rgen Freiwald (RR&Co) as yet but fully intend to do so once we have an indication that we will be permitted to use the Lenz patents. In the meantime we have produced a Software Developers Kit that will allow any interested software manufacturer to easily adapt their software to use the technology. Essentially, if the software already supports Lissy or RFID etc, including RailCom is very simple to incorporate. 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.

We are aware of the Litfinski (LDT) DIY option and it was a consideration but as a major cost component is actual PCB size as well as the number of holes required, we opted for SMD components as far as possible. Hand soldering components that are practically dust-size is not really an option.

We have no specific plans at this time to exhibit again but once the patents question is sorted out, we may well do so. I will post an announcement on this forum if or when we do. Alternatively, if anyone lives near central Scotland we would be happy to have you drop by for a demo.

In fact the only strange problem we have experienced was from a Lenz Gold Mini in a small Fleischmann locomotive that transmitted so much noise onto the tracks that the detectors couldn??™t read the DCC signal and hence couldn??™t calculate where the cut outs were occurring. This was fixed subsequently with some filtration in the software on the RailCom reader??™s chip.

And finally, yes we are British, based in Scotland and the product is entirely home-grown using the NMRA on-line specifications ??“ RP-9.3.1 and RP-9.3.2. (The double-sided PCBs are made in Hampshire.) The software is written by my son who did 3 years of a combined Software Engineering / Electronic Engineering degree at Edinburgh University before specialising in just the software side. We obviously appreciate the cost problem but we will try to keep manufacturing entirely within the UK if at all possible rather than outsourcing to China.

Interesting reply and I for one will be watching your space for further updates.

Also the reply to the others regarding the 'myths' floating about. Possibly some of this has come about from not being able to play for real due to the lack of hardware to play with. I for one was under the belief that resistive axles causes a failure in the Railcom detections process. So if it is right that the use of resistive axles is not a problem, it may well come as a relief to a lot of people, me included.

Perhaps if you have time an 'idiots guide to Railcom' would be of use, posted for all to read and understand. Most people tend to rely on the big boys like Lenz's web sites for information but this is not always the best way to understand what Railcom is all about, how it works, what is needed and also what we as users can expect to see in the future. You certainly give the impression you have your finger on Railcom's pulse and I am sure there are plenty of members on here who would like to share some of your knowledge on this subject. Thanks.