It was not a cheap shot at the NMRA as you put it. The fact that the RailCommunity’s RailCom spec. RCN-217 is the fastest changing and largest spec. out of all the DCC specifications and needs updating for the user’s sake. For your information I was contacted some time back by a NMRA member apparently part of the team updating the NMRA’s version of the RailCom spec., he requested a copy of the latest English version of RCN-217 which I duly provided him with (so they have an English copy) and was told they would keep in contact, never heard from him since.
?
To clarify my position in all this, I’m a member of Merg and have taken ALL the RailCommunity’s ??DCC specifications and translated them into English, and keep them up to date. I’m a totally non-paid volunteer and have made all these DCC specs. available to the Merg membership only through their website. So, if Merg can do it the NMRA should be able to as well. If you wish to read the latest DCC specs. join Merg.
?
I’m not sure that it’s a problem of unpaid manpower more the interest in RailCom. I have been involved in the bidirectional element of DCC for quite sometime now and it seems that the North American market doesn’t want to know about RailCom. Digitrax has quite a large hold on the DCC market over there and promote their own Transponding system which is not NMRA compliant and is incompatible with RailCom which is compliant.
?
jmri is the poorer without RailCom and the required hardware is cheap, simple and many decoder have the option built in already. ???
