DCC++ Not Talking to Decoders

[Chuntybunt]

So after my adventures on this topic http://www.rmweb.co.uk/community/index.php?/topic/141517-dcc-on-rduino-mega/ I fitted a loco decoder to the DCC++ base station but I am unable to read or write any data to or from the decoder. JMRI just returns "No acknowledge from loco (308)" and the DCC++ processing sketch returns "Error - Reading Short Address Failed". I thought it may be the decoder, a laisdcc 4 function, so i have also tried it with a brand new out of the box Zimo MX600r and i get the same results. if the decoder is fitted to a loco, Hornby class 73, the motor twitches when JMRI tries to read all the CVs the voltage into the motor shield is 13.5v is that enough? I would appreciate any help as I don't know how to proceed now.

[NIK]

So after my adventures on this topic http://www.rmweb.co.uk/community/index.php?/topic/141517-dcc-on-rduino-mega/ I fitted a loco decoder to the DCC++ base station but I am unable to read or write any data to or from the decoder. JMRI just returns "No acknowledge from loco (308)" and the DCC++ processing sketch returns "Error - Reading Short Address Failed". I thought it may be the decoder, a laisdcc 4 function, so i have also tried it with a brand new out of the box Zimo MX600r and i get the same results. if the decoder is fitted to a loco, Hornby class 73, the motor twitches when JMRI tries to read all the CVs the voltage into the motor shield is 13.5v is that enough? I would appreciate any help as I don't know how to proceed now.

 

Hi,

 

Most designs of  DCC loco decoder require to be connected to a motor or a suitable resistor connected across the motor outputs before the command station can read information from the decoder.

 

This is so ACK or acknowledge pulses of current from the loco can be used by the decoder to send info back to the command station.

 

 

Regards

 

Nick

[Crosland]

So after my adventures on this topic http://www.rmweb.co.uk/community/index.php?/topic/141517-dcc-on-rduino-mega/ I fitted a loco decoder to the DCC++ base station but I am unable to read or write any data to or from the decoder. JMRI just returns "No acknowledge from loco (308)" and the DCC++ processing sketch returns "Error - Reading Short Address Failed".

You always need a load (e.g. a loco motor) connected the the decoder motor output for the command station to see the ACK pulses. Without a load, writing will probably work but you will never know for sure. Reading will not work at all.

 

I thought it may be the decoder, a laisdcc 4 function, so i have also tried it with a brand new out of the box Zimo MX600r and i get the same results. if the decoder is fitted to a loco, Hornby class 73, the motor twitches when JMRI tries to read all the CVs the voltage into the motor shield is 13.5v is that enough? I would appreciate any help as I don't know how to proceed now.

If the motor is twitching then the decoder is responding. If you still can't read anything then the DCC++ system is not sensitive enough to detect the ACK pulses.Your supply voltage should be adequate.

 

The spec is for a 60ma current pulse for 5ms to acknowledge programming operations.

 

I know nothing about DCC++ so cannot help any further.

[Chuntybunt]

Thanks for the responses, I didn't know that about the load. The Zimo decoder Is working If I put the loco on the main track I can control it with the JMRI throttle but I still cant read or write o the decoder so any suggestions are welcome.

[NIK]

Thanks for the responses, I didn't know that about the load. The Zimo decoder Is working If I put the loco on the main track I can control it with the JMRI throttle but I still cant read or write o the decoder so any suggestions are welcome.

 

Hi,

 

If you post a schematic on here concentrating on the programming track output then more help may be forthcoming.

 

 

Regards

 

Nick

[Chuntybunt]

Hi,

 

If you post a schematic on here concentrating on the programming track output then more help may be forthcoming.

 

 

Regards

 

Nick

Hi Nick, I'm not sure what you mean, there is a motor shield mounted directly to an Arduino Mega and the output from the shield goes directly to the programing track.

[NIK]

Hi Nick, I'm not sure what you mean, there is a motor shield mounted directly to an Arduino Mega and the output from the shield goes directly to the programing track.

 

Hi,

 

I don't know the DCC++ system but in order to read CVs there has to be a method of the DCC++ to read the ACK pulses.

 

I think there should be an additional circuitry to read the ACK pulses into the Mega.

 

 

Regards

 

Nick

[nick_bastable]

So after my adventures on this topic http://www.rmweb.co.uk/community/index.php?/topic/141517-dcc-on-rduino-mega/ I fitted a loco decoder to the DCC++ base station but I am unable to read or write any data to or from the decoder. JMRI just returns "No acknowledge from loco (308)" and the DCC++ processing sketch returns "Error - Reading Short Address Failed". I thought it may be the decoder, a laisdcc 4 function, so i have also tried it with a brand new out of the box Zimo MX600r and i get the same results. if the decoder is fitted to a loco, Hornby class 73, the motor twitches when JMRI tries to read all the CVs the voltage into the motor shield is 13.5v is that enough? I would appreciate any help as I don't know how to proceed now.

just to check is this enabled ?

 

 

Nick

[Chuntybunt]

Nick here is a link to the motor shield schematic. https://www.arduino.cc/en/uploads/Main/arduino_MotorShield_Rev3-schematic.pdf

As far as I'm aware all the current/ACK pulses sensing is handled by the L298 an then fed to the arduino on analogue pins 1 and 2, for the main and programing tracks, and no other hardware is necessary.

Other Nick, I forgot to check the preferences but I'm sure everything is set to DCC++

 

I have had some success in re-addressing the Zimo decoder, by adjusting the values in CurrentMonitor.h I was able to write a new address to the decoder and control it  but I am still unable to read the contents back.

[RAF96]

Its usual to have an opto-isolator in there somewhere to keep the arduino and DCC voltages apart.

Rob

[NIK]

Nick here is a link to the motor shield schematic. https://www.arduino.cc/en/uploads/Main/arduino_MotorShield_Rev3-schematic.pdf

As far as I'm aware all the current/ACK pulses sensing is handled by the L298 an then fed to the arduino on analogue pins 1 and 2, for the main and programing tracks, and no other hardware is necessary.

Other Nick, I forgot to check the preferences but I'm sure everything is set to DCC++

 

I have had some success in re-addressing the Zimo decoder, by adjusting the values in CurrentMonitor.h I was able to write a new address to the decoder and control it  but I am still unable to read the contents back.

 

Hi,

 

Do you have an official Arduino Motor Shield from Italy (if such a thing exists) or a Chinese clone? - I only ask as I bought a lot of Chinese RFID reader clones from 12 different suppliers and they were extremely variable in their performance and some had major functions that didn't work at all.

 

My Hornby Class 73s have poor pickups (don't know if its wheels, wipers, something else) and don't like having their CVs read or written.

 

One suggestion would be as you have got a DIY Command station is to make up an 8 pin DCC socket, connect a motor or suitable resistor to it, plug in a good decoder and try and read CVs from it. A simple but reliable DCC decoder with a few CVs would be a good start (dare I say it but a Hornby R8249 might be a good one for this test).

 

The other thing would be to research the CurrentMonitor.h file - if you needed to adjust a variable in order to write to the loco you may have to adjust another variable to get it to detect the ACK pulses. I'm guessing the value you want to put in is a fraction of the value you put into the first variable (which I guess was the current limit value for the programming track).

 

If you can with JMRI Decoder Pro try reading one CV that is known to exist at a time to start with to gain experience and save time.

 

Happy DIYing.

 

Regards

 

Nick

Edited January 21, 2019 by NIK

[Crosland]

Its usual to have an opto-isolator in there somewhere to keep the arduino and DCC voltages apart.

 

Is it? That would greatly add to the complexity in passing back the analog current sense signals to the processor.

[alangdance]

Does anybody know if this is a common issue with DCC++, I was think of building one for just programming locos indoors

away from the main layout which is in a shed.

 

Alan

[RAF96]

Is it? That would greatly add to the complexity in passing back the analog current sense signals to the processor.

Rudy has one in his DCC sniffer/translator setup to keep the Dcc and Arduino apart. I can see the need for a direct path between sensors and Arduino though.

[shiny]

The voltage should be OK for a smallish DCC layout, I've run mine on 12v and it works fine.

 

If your motor is twitching this means that the DCC chip is replying to the commands you are sending it and trying to talk to the programmer, so that's a good start.

The controller must be able to measure the current used by the motor in order to hear the replies.

The motor pulses on and off to send messages to the controller as a series of bits in response to the programming messages, and the current on/off is decoded to figure out what the loco is saying. Sort of a "twitch the motor once for yes, twitch it twice for no" kind of thing - except a bit more complicated.

If you do a "read all values" command, you will see the loco twitching for quite some time before it stops as it sends its CVs back to the controller.

 

If you can't read the values, check the following:

That the shield supports current measurement. This is usually a SENSE_A or a SENSE_B pin. These should be connected to the analog in pins. Check the sketch to confirm which analog pins are used.

There is a utility for measuring the current in JMRI (other railroad software is available), it will normally display zero (or close to it) until you place a loco on the track. Once the train starts moving, or when it responds to programming - the numbers should increase.

If the current still shows zero when the loco is moving, try more locos on the track, or connect a car lamp across the output (you said you were using 12v ish so it should be OK to try).

 

The motor shields are generally built for controlling bigger motors, usually one big motor as opposed to several smaller ones - so the current measuring resistor is sometimes not sensitive enough to read the few tens of milliamps used by the loco when programming. You can increase sensitivity by either changing the shunt resistor to a slightly higher resistance (fairly simple), or adding an amplifier (harder).

 

Some cheaper boards do not have the current measuring capability at all - even if there is a SENSE output pin. A multimeter will give a reading of 0.0 ohms between the SENSE pin and ground on boards without current sensing. It is easy enough to fit a current sensor on the shield - I had to do that to one of my motor shields.

 

A reading between 0.1 and 1 ohms means that a current measuring (shunt) resistor is fitted - but this is only really useful for larger motors and will not be sensitive enough for DCC. 5-10 ohms is a reasonable value to aim for which should give you enough sensitivity to read the current.

 

A word of caution with DCC++.  You have to tell the software how much current constitutes an overload, and for that to happen you must have current measuring available on the motor shield. Do not rely on the shield circuitry to shut down on an overload or short circuit, because if your motor shield is rated at a higher current than your power supply can produce, the cut-out protection on the shield will never trigger and you run the risk of things melting and catching fire. Especially so if you are using a wall wart to power the thing.

 

If you are using the exact Arduino motor shield that is in the diagram, you may have to change the current sensing resistors. The ones in the schematic are 0.15 ohms - more suited to a much larger motor than your Hornby.

 

By the way, you can program the decoder fine without the current sensing, the software just complains incessantly. But it is not recommended due to the lack of a fast and safe shutdown - even more so if you have just converted a loco to DCC and don't want to see it melt due to mis-wiring.

 

(edited to add last paragraph)

Edited January 21, 2019 by shiny

[NIK]

Rudy has one in his DCC sniffer/translator setup to keep the Dcc and Arduino apart. I can see the need for a direct path between sensors and Arduino though.

Hi,

 

That's because DCC is a bidirectional voltage that may or not be referenced to mains ground - so by employing an opto-isolator the Arduino power supply doesn't have to be referenced to or powered from the DCC and you can connect the Arduino to a computer via an ordinary USB lead.

 

 

Regards

 

Nick

[Chuntybunt]

Thanks for the replies, I was busy yesterday but I have had a quick poke about this morning. The motor shield I have is a cheep generic one and sticking a meter on it and comparing it to the schematic shows up a couple of anomalies. On my shield the SENSE_A and SENSE_B pins are connected directly to GND where as they should be connected through a 0.15 ohm resistor second the sense pins that should be connected directly to the analogue pins 0 and 1 are connected through an 11k resistor. So my conclusion is that my motor shield is not suitable for the project, I will order another motor shield (of the type that other people have used successfully) and report back.

[Chuntybunt]

I thought I would do a brief update on this thread and my experiences so far with DCC++. Now it's been nearly a year, and a busy one at that, and I can't remember the exact sequence of events but this is a rough summary of how things played out. I did indeed buy another motor shield but not a genuine Arduino one. I bought another clone off E-bay that was the same as others had used and not reported any problems with. I set it all up and had exactly the same issues as before, I could run my Hornby class 73 with the Zimo MX600r, but could not read the loco address. This was at the end of January 2019. I went away fro a short holiday and started a new job on my return, the job has kept me very busy and I have had no time for playing with trains ( I considered giving the job up!). Around November I thought I would give things another go. I ordered another motor shield as I still thought this was the issue, this time a genuine Arduino one at about £30.00 rather than £4.00. while waiting for the motor shield to turn up I tried the decoder in another loco, a Heljan 47, once again the same results I could drive but not read or write to the decoder. My Arduino shield arrived and I put it all together and again the same results. I bought another power supply, no change. I borrowed a genuine Arduino Mega to replace my £12.00 clone, no change. At this point I was about to give up on the whole DCC++ thing and was thinking about getting a MREG setup. I had tried every conceivable combination of the hardware, I had read through pages of posts on The Train Board and had changed all sorts of values in the software of both the base station and the Processing sketch all to no avail. Back in January I had directly wired the Laisdcc decoder to a Mitsumi motor but had done nothing with it as I hadn't needed to because I had a proper branded Zimo decoder that cost twice the price and was always going to be better then some cheep piece of rubbish bought off of E-bay. I hadn't used the Laisdcc decoder in the locos because it was bare ended wires without an eight pin plug on the end. I connected the red and black wires of the decoder directly to the terminals on the motor shield and lo and behold I was able to read from the decoder, it was a miracle! I tried it with all the other motor shields and all worked perfectly. I thought there must be a problem with my programming track wiring, dirt on the track, dirty wheels on the locos. In order to test things I made a decoder tester on a piece of strip board with the motor and wired a plug onto the Laisdcc decoder. Again I could read and write to the decoder without any problem. I plugged in the Zimo and back came the problems. So in conclusion there is nothing wrong with DCC++ it was the Zimo MX600r decoder that was causing the problems all along. Just to rub salt into the wounds as I was about to write this post I came across this post from back in September

If I had seen this at the time I could have saved myself a whole heap of pain but there you go. So you can use clone Arduino bits and cheep decoders for DCC++ in fact, excluding a PSU, you can have a base station and decoder running a loco for just over £20.00. I will be buying a few more Laisdcc decoders, but no more Zimos, and hopefully next year I can do a bit more playing with trains and a bit less tail chasing. was

Edited December 28, 2019 by Chuntybunt
Bad grammer

[RobjUK]

I wonder if it's something really stupid like the Zimo decoders are sent out defaulting to Railcom only for feedback to the controller?

 

eg. possibly the "command acknowledge" bit set in CV29, or a firmware bug that means railcom ack works but basic DCC ack does not, so the factory programming gear sees them as ok.

https://dccwiki.com/Term:RailCom

 

[Paul80]

Hi

 

Don't know if it's relevant to your problem, I have a DCC++ setup but don't use it anymore having moved to Sprog3 and MERG controllers.  

 

I mainly only use Zimo decoders and found although the DCC++ would run the locos fine I also got a failure to read on the test track, unless I applied pressure the to loco holding it down on the track, the track was scrupulously clean by the way.

 

That was the reason I moved away from using DCC++.

 

Even now I have box based on the DCC++ that is built just to read a locos CV1 value, I use at exhibitions just to identify club members loco address values and that has the same issue with Zimo decoders, pressure has to be applied to the loco or it will not read, any other make and it's fine.

 

A bizzar issue I know, give it a try it might work with yours

 

Paul

[Crosland]

You can often see locos creeping along the programming track when programming. This is the motor current "ACK" pulse (used to acknowledge programming by briefly energising the motor) so putting pressure on the loco probably causes the current to increase as it tries to overcome the resistance.

 

It that's the case then it sounds like the Zimo or motor (or that particular pairing) generates a weaker ACK pulse that the DCC++ cannot detect.

 

[NIK]

2 hours ago, Crosland said:

You can often see locos creeping along the programming track when programming. This is the motor current "ACK" pulse (used to acknowledge programming by briefly energising the motor) so putting pressure on the loco probably causes the current to increase as it tries to overcome the resistance.

 

It that's the case then it sounds like the Zimo or motor (or that particular pairing) generates a weaker ACK pulse that the DCC++ cannot detect.

 

Hi,

 

I've had similar symptoms with an NCE system (can't remember which decoders but a lot of mine are now Zimos) and assumed that it was due to poor contact between the track and the wheels. 

 

The motor current can go up quite a lot when the motor is stalled.

Some recent motors in recent mechanisms probably consume much less current than when DCC was first specified in the early 1990s.

 

I might try and get some evidence of the motor loading effect by finding a loco that doesn't respond at all well to CV reads and tying the couplings to fixed objects. The motor should be loaded up a bit more than usual when the DCC decoder sends ACK pulses via the motor.

 

 

Regards

 

Nick

[NIK]

Hi,

 

I tried reading the Manufacturer ID and decoder versions from as many DCC locos/multiple units as I could put my hand on.

 

I was using the NCE Power Cab starter set. Only one loco played up and that reported a Lenz decoder.

 

I didn't find as many Zimo decoders as I expected but I did notice they appeared to pulse all their function outputs as well as the motor which should generate a bigger ACK pulse (only if LEDs/smoke generators are attached).

 

Regards

 

Nick

 

 

[NIK]

Hi Chuntybunt,

 

If the comparison was between one Liasdcc and one Zimo DCC decoder then I'm not sure there is enough evidence to conclude that the Zimo decoder is at fault and that all Zimo decoders are to be avoided in favour of Liasdcc.

 

It is possible the Zimo decoder produces ACK pulses that are just within the DCC standard but that the DCC++ command station rejects them.

 

I haven't got a current monitor sensitive enough to measure the ACK pulses of a DCC decoder when the motor is of the low current type.

 

I've looked through the DCC++ code and in the relevant module PacketRegister.cpp its not clear to me what the units are used in the tests applied to the ACK pulse. Is there a DCC++ or Arduino for model railways user group you could ask about how the ACK pulse is measured?.

 

I may try and monitor the pulse width of ACK pulses from Zimo DCC decoders when connected to high current motors but the results may be clouded by the reservoir capacitor on the DCC decoder which will be depleted quicker with a higher current motor in circuit.

 

 

Regards

 

Nick

Edited December 29, 2019 by NIK
spelling error