6 pin Rails decoder unreadable

[96701]

My new 07 from Rails came with a Rails 6 pin decoder in the box, no surprise as I'd ordered it.  I have tested the loco on a DC rolling road, and all is well with it, so after half an hour in each direction at half power, I took the plunge and fitted the decoder. All was well with address 3, lights, direction, power and speed, so I followed the instructions to enable long address and set CV 29 to 38 as per the instruction and programmed the address to 7002 all using my MERG CBUS handset programming on the main with no other locos on the layout, as I have done for all my locos except in this instance it didn't work.

 

I cannot now find the decoder using the handset, on neither 3 nor 7002 and when I try to read any CVs, I get "No Ack" which means no decoder found. When I had it on address 3, I had the lights on. They are still on, and as far as I can see, no magic smoke has been lost.

 

Does anybody have any ideas please?

[Oldddudders]

Have you tried setting CV 8 to 8? This should reset the decoder to factory settings. 

 

I almost always use POM to program decoders, but I do have a program track when one is obstinate. Does your setup allow for such a facility? 

 

You might try withdrawing the decoder and re-inserting, as any loss of connection on one pin might trigger the behaviour you are seeing. Do check it is all the way home - 6-pin decoders are among the least satisfactory for this, I find. 

 

I hope something works!

[Nigelcliffe]

You can't "read" values with Programming On the Main.    So, unless your terminology is a bit loose above, what you're trying to do doesn't work. 

 

With a MERG system, depends which version you've built.  With some, you have to set a jumper internally to change it to programming track output. With other configurations, they have separate main line and programming outputs.   With the programming output setup, you'll be able to read values from the decoder.   

 

 

( And I'd not expect much from a Rails / Hattons / random shop brand  decoder.   It will be a cheap chinese clone of an old design.    ). 

 

- Nigel

[96701]

49 minutes ago, Nigelcliffe said:

( And I'd not expect much from a Rails / Hattons / random shop brand  decoder.   It will be a cheap chinese clone of an old design.    ). 

 

- Nigel

The blurb on the packaging says that it is made for Rails by DCC Concepts.

[96701]

Quite a thick plot, probably to match the loose nut on the handset. It seems the decoder had decided to set itself to address zero, so I managed to get CV 8 back to 8 which brought me back to address 3 and everything working as it should. The instructions are as follows:

 

Long address  

Long address (High Byte)  

CV17  

Long address (Low Byte)  

CV18  

Enable long address  

CV29  

  

To modify long address simply program CV17 and CV18 to a different value between 128-9999.  

Once the derived values have been programmed, enable the Long Address by adding a value of 32 to CV 29. CV 29 has a default value of 6, so to enable the 4-Digit Address just add a value of 32 and program the resulting value of 38 into CV 29.  

 

So, if I would like the decoder to respond to 7002, do I set the value of CV 17 to 70, then CV18 to 02 and then change CV29 to 38? Just changing CV29 to 32 just sets the address to 0000.

 

[96701]

27 minutes ago, 96701 said:

 

So, if I would like the decoder to respond to 7002, do I set the value of CV 17 to 70, then CV18 to 02 and then change CV29 to 38? Just changing CV29 to 32 just sets the address to 0000.

 

Just tried my suggestion, and have lost the decoder again. Unknown address, so at the moment no way of knowing what values any of the CVs are. All done on the programming track by the way.

 

JMRI can't find it either via PanelPro on neither the programming track, nor the main. I think I may just have to cut my losses and get another 6 pin decoder. This one has been the most troublesome by a country mile.

Edited March 6, 2021 by 96701
added note re JMRI.

[Nigelcliffe]

On 06/03/2021 at 19:38, 96701 said:

The blurb on the packaging says that it is made for Rails by DCC Concepts.

 

 

For the programming,  you do not set CV17/18 the way you're trying to do it.   Firstly, I expect the MERG handset does all the sums for you, and you just tell it to set a long address as a four digit number.   

To save me copying my words out,  read this, particularly the lower bit on how addressing works

http://www.2mm.org.uk/articles/cv29 calculator.htm

 

If you built a MERG system,  are there not manuals and instructions with it ?   

 

Under JMRI, for these cloned decoders, use any of DCC Concepts decoders, or any Lais, or an older TCS decoder.  They all use the same CV structure.  And JMRI does the CV17/18 and other sums for you.  

 

Giving a decoder an illegal address, and then wondering why it doesn't run has the same problems if you programmed any decoder with an illegal address.    A quality replacement decoder would be a Zimo at £20.      

 

 

- Nigel

 

Edited March 8, 2021 by Nigelcliffe
edit to add the JMRI bit

[96701]

10 minutes ago, Nigelcliffe said:

 For the programming,  you do not set CV17/18 the way you're trying to do it.   Firstly, I expect the MERG handset does all the sums for you, and you just tell it to set a long address as a four digit number.   

- Nigel

 

Thanks for taking the time to respond. The first thing I tried to do was set CV1 to a 4 digit number, but it topped out at 3 digits. 

 

Yes MERG does have a manual, so that of course, being a bloke, is the last port of call particularly as I have set up many decoders without issue, and never found a need to mess about with CV29, so I had no idea how important it is, and thank you again for clearing that one up.

 

My son has an N gauge layout, all sorts of pc tech, I think he even has a SPROG, so it may well be going his way to play with. Thank you for the suggestion of the Zimo, I shall dig one out and order it.

[BromsMods]

1 hour ago, Nigelcliffe said:

 

Giving a decoder an illegal address, and then wondering why it doesn't run has the same problems if you programmed any decoder with an illegal address.    A quality replacement decoder would be a Zimo at £20.      

 

 

- Nigel

 

 

...... ora recently manufactured TCS decoder!

[sparaxis]

I have around 200 locomotives fitted with decoders. Bitter experience has taught me that saving a little on a "bargain" decoder is really not worth it. I prefer ESU decoders, as the rail-com plus feature is really useful (automatically identifies the locomotive to the command station with all the function assignments etc.) but Zimo is a good alternate choice with affordable options like the MX600 series. And both Zimo and ESU allow CVs to be read "on the main" using rail com. In addition, both offer superior motor control with no problems controlling almost any type of motor you can think of.

 

When I first moved to the USA I bought some locally manufactured decoders from a major brand. I could never get the motor control characteristics adjusted properly. Money saved was money wasted, as I ended up replacing them in the end.

[Richard Johnson]

RAILS Decoders are not "Cloned Decoders".

 

They are based on our ZEN current software which contains significant original evolution and are well above that sort of level in every sense.  They also out perform many so-called "Name brand" decoders in many areas. The registers are similar to some other brands simply because it makes NO sense at all to force modellers to re-learn how to do things differently with every different brand they buy.

 

regards, Ahjay

[96701]

4 hours ago, Richard Johnson said:

RAILS Decoders are not "Cloned Decoders".

 

They are based on our ZEN current software which contains significant original evolution and are well above that sort of level in every sense.  They also out perform many so-called "Name brand" decoders in many areas. The registers are similar to some other brands simply because it makes NO sense at all to force modellers to re-learn how to do things differently with every different brand they buy.

 

regards, Ahjay

Thanks, Richard. Do you have any idea on how I can discover the address of the decoder so that I can try to do the long address correctly?

[Butler Henderson]

Reset the decoder, CV8=8 is the norm but check the instructions for the decoder in case it's a different CV8 value. That will put it back to the address of 3

[Oldddudders]

1 hour ago, Butler Henderson said:

Reset the decoder, CV8=8 is the norm but check the instructions for the decoder in case it's a different CV8 value. That will put it back to the address of 3

He did that a couple of days ago, as per my suggestion. 

[meil]

6 hours ago, 96701 said:

Thanks, Richard. Do you have any idea on how I can discover the address of the decoder so that I can try to do the long address correctly?

There's no need to "discover" the address simply re-programme it with a new address.

[woodenhead]

This might sound daft, but have you tried turning the chip over - I've a dozen of Rails '6 pin decoders, all programmed through JMRI and I've found some would not read unless I reversed them and then swapped them back to use them in 'run' mode.

 

It sounds daft I know, I put it down to how Farish had designed their connections or something but it happened a couple of times, Yet my Zimo chips were all fine one way only.

[woodenhead]

@96701 Did you resolve your problem?

[96701]

@woodenhead, I'm afraid not yet. My MERG Command Station doesn't appear to want to read CVs on the programming track, so I need to solve that particular problem first.

 

I have fitted a Zimo MX617n and set that up properly. 

 

Thanks for thinking about me anyway, I'll be off to the MERG Forum to try and solve the command station conundrum which is also the reason why JMRI can't read CVs either.

[96701]

We have steps forward, thanks all those who have suggested answers and put me right. A quick chat with son and heir,  and am now reading decoder details, so at the moment it is showing short address 3 and long address 6950, so I have obviously loused the decoder up good and proper. I cannot at the moment rewrite CV8, no response from loco = 3 nor 6950 on the main, except on 6950, turning the speed knob beyond zero, the buzzer sounds.

 

Currently letting JMRI read all the CV Values, and take it from there. I plan to get rid of the long address to stop the conflict to see if I can get CV 8 to 8.

 

[Nigelcliffe]

You don't actually write a value into CV8 in the conventional sense.   Whenever you read CV8, you always get the manufacturer ID for the decoder, so a given decoder will always return the same value.  Writing a value to CV8 just causes the decoder to execute a command to change some values internally - exactly how it resets depends on the maker's instruction sheet.  (So, don't assume because one decoder uses CV8=8 for reset, that another does as well).  

 

JMRI will have a reset for decoders on the menu bar for the selected decoder.  The command sent will depend on the decoder make/model chosen (ie. the JMRI decoder writer probably looked at the manual for the decoder in question and set the menu values correctly).    Decoder resets are not done in the usual CV list in JMRI to avoid extremely messy mess-ups. 

 

Speed knob buzzing is a MERG system issue (possibly operator error).   

 

There is "no conflict" in storing a long and short address;  those are stored in different locations.   And as previously posted, CV29, determines which of the long or short addresses is active (or a tick-box on the decoder basics pane in JMRI).     As another current thread points out, do check whether CV19 (consist address) has been accidentally set to anything other than zero.