kato n700 decoder programming

[goldingone]

I have a N700 with EM13, FL12, & FL11 decoders on board. I am trying to program em13 to a new address using Prodigy Controller, cant even read any of the above, what am I doing wrong?????

[CaptOblivious]

Are you trying to program a 4-digit address? The Kato decoders, for whatever reason, are very tricky to program with a 4-digit address, and do not accept the usual commands to do so. However, you can set it using a slightly round about method, detailed here:

http://www.ruppweb.org/Xray/comp/decoder.htm

[KenS]

You should be able to read the EM13 (unless it's not making proper contact in the socket, which is an all too common problem). Bt the others don't have enough of a load for their CVs to be read (reading CVs works using a method that detects variations in the power drawn by the decoder, and it needs a load on it for the variation to be large enough to detect; LEDs aren't large enough).

[nik_n_dad]

We have an NCE system, and it seems like it can't ever read anything out of any of the Kato decoders.  However, programming a 4-digit address is simply done by choosing the "long address" option.  On the NCE programming track, about all the feedback we get when programming the kato (FL12) decoders is that the lights will flick on and off.

[inobu]

Normally the flickering is it booting up.

 

Although they say everything is compatible I don't really think so. Digitrax used 12.4 volts as their track carrier voltage where as NCE factory setting is 14.25 and MRC has 14.5. I'm thinking that the voltage is playing a part in the failure to read the decoder. Although the decoder is suppose to operate in a wide range of voltages I not sure that it is perfect.

 

There are standard protocol for all but each manufacture has their own product specific information and how it is interpreted.

 

Try this..........

 

Extend the length of your programming track. Instead of having just 1 segment add 2 or 3 segment and put the train on the opposite end of your programming leads. The intent is to cause a voltage drop on the track to the decoder. Check to see if it responds to the programming command signal then.

 

This is the main reasons I just stick to one manufacture. It really simplifies things. The other reason I use JMRI is the ability to see the messages going across the track.

[KenS]

At least on the U.S. systems, the voltage varies. My Zephyr produces a track voltage of 13.8V (as measured by an RRampMeter), using the standard power supply. They claim it should produce 12.8V RMS.  My DCS100 set on "N" defaulted to a voltage a bit above 12V, but could easily be adjusted to 12.0V via a trim pot.  I believe to some extent this depends on the power supply used (Digitrax can accept a range; my DCS100 can use 12 to 20V AC or 12 to 28V DC). However, under load the DCS100 track voltage dropped from 12.0V to about 11 volts under most circumstances.

 

I expect you'll see similar variation on other systems due to supply and individual system design.  Track voltage will also vary significantly due to resistance in the track, track feeders, and rail joiners.  I've seen it as low as 10V on my track, and the DCC standard says it may be as low as 7 V.

 

While Kato does sell the Zephyr as their DCC system, and thus the Kato decoders might presume 13.8V (or 12.8), if that's what the Zephyr outputs when used with the standard transformer on the Japanese power grid, it's very unlikely the decoder was designed to operate properly on a narrow voltage range.  The real world just isn't that clean, and both Kato and Digitrax have been around long enough to know that.

 

It's not impossible that voltage is the cause. But Kato's decoders are notoriously hard to read.  I've had reads fail on EM13s using my Zephyr, although usually they'll work.  And I've never been able to read the FL11.

[inobu]

The reason I suspect it may be a voltage issue because voltage is the signal carrier. The rise and fall of the voltage and its duration is the data signal. Any type of noise or interruption can cause voltage drops. These dropouts cause a saw tooth effect on the data stream which effects the pulse duration and can cause data errors.

 

If the preamble on the protocol is missed due to this signal corruption then the decoder will just sit there. I have been able to gain access to loss decoders by placing my finger on the test track. I think the resistance on the test track creates a load that drops the voltage. I think it reduces the voltage over shooting of the data transitions which removes line errors.

 

The ability for the decoder to operate at such a wide voltage range has to have limitations in signal detection (Just my guess) .

 

There is no such thing a hard to read in data. Either it is going to read the data or something is impairing the transmission data. To send the command twice means the decoder did not receive the first command packet. The decoder reads the same script written in the PIC every time so there are no typos no mistakes. So if you send a command to the decoder on the test track and it did not respond there are only 4 possible problems.

 

No transmission, No path continuity, No receive or No read back script. If it works one time and not another then the last possibility is removed.   

 

Inobu

[Martijn Meerts]

function decoders often don't give a response when trying to read them, because they need around 50 to 60mA on 1 of the outputs to give off a decent feedback signal. As most trains use LEDs these days, changes are good that you're not reaching those 50-60mA. I have the same with various other function decoders.

 

The motor decoder should be possible to read though, unless there's a bad contact somewhere, somehow.

[KenS]

You are correct about the need to correctly read the signal, and the effect that track can have on signal quality. But I expect it applies more to programming on the track ("operations mode") rather than on a programming track.  Even assuming we're talking about on-track programming, the normal problems I'm familiar with involve low voltages, not high ones.

 

Digital signals are ultimately analog waveforms on the wire that are interpreted to "recover" the digits. That interpretation can fail if the signal is corrupted. While voltage is an issue, the integrity of the signal is also important; DCC depends on signals rising and falling rapidly, and not overshooting, both things that can be affected by track problems, although DCC was designed to minimize its sensitivity to these effects. It's really noise or signal alteration (corruption) that is the problem, but this is often caused by the same things that cause voltage loss, and it may have a greater effect when the difference between low and high voltages is less. You'll see that kind of problem on sectional track with dirty/loose track joiners or large layouts with inadequate feeders.

 

Note that this is a case where low track voltage is the problem, not high.

 

If the problem happens on the layout, one thing to try is programming on a dedicated strip of clean track wired directly to the power pack.  If you suspect layout problems, check the voltage at the command station output and compare it with that at various places around the track.  A loss greater than one volt is probably something to look into (likely causes are dirty track joiners and feeder wires that are too small gauge for their length, or not enough track feeders).

 

The other possibility is that Kato/Digitrax made a bad design decision, and higher-than-expected voltage causes the decoder to misread the signal. That's the part I find less plausible, but it's certainly a possibility since the circuit doing the signal recovery could misbehave if driven with more voltage than it was designed for.

 

However, I will disagree on one point, or perhaps we're saying the same thing differently: there is "hard to read" in digital data.  The problem is that the analog signals that form the digital signal can be right on the border of being recoverable. So one packet that gets through may be followed by another that doesn't.  DCC sends the signal multiple times to try to make this less of a problem. But on really bad track, a lot of packets may not get through, even though enough do for the train to run properly.  If programming is more sensitive to getting good packets than simply running the train (I don't know if it is, as it would depend on the individual decoder, but my suspicion is that programming is more sensitive), then programming could fail on track where DCC otherwise works fine.

[inobu]

KenS,

 

When the term "Hard to read" is used in data it conveys to the layman a misconception of data operation. Data is a precise means where there are 1's and 0's. Either its there or its not and retransmission is an indication of an error be it component, transmission path or marginal threshold operations as you suggested these are still impairments.

 

Remove these impairments and you will see a perfect operation system. The PIC (Programmable Integrated Chips) are programmed and run scripts on power up. If the command/booster issues a command the PIC carries out the instructions issued by the command. Either it sees the command or it does not.

 

The reason I am sure of this concept is I worked in a test and validation lab where we tested data equipment. If the new equipment failed the test cases it would not be deployed until all test cases pass.

 

If I were to test the FL12 this would not be an issue. I would have issued a red tag and do as I'm doing now, identifying probable faults to be address. The reason I'm am leaning toward high voltage or overshooting is the units ability to operate in the track where the voltage is lower due to the loss induced by the length of the track. Just trying to create an operating environment to identify the cause of problem.

 

Maybe I just need to get one myself and test it. 

 

Inobu   

 

 

 

 

 

[KenS]

I agree.  From the persective of the decoder either the message is there, or it isn't. But that isn't the whole story. The problem I'm getting at, perhaps not very clearly, is that while a single message is either there or not, some things require more complex interactions, and there's no protection in DCC to ensure that the whole transaction is either performed or not started if it depends on more than one message.

 

Note that DCC doesn't do retransmission the way more sophisticated networking systems do.  It always sends multiple copies, and there's no mechanism for the decoder to acknowledge "yes I got it" (well, there is, but it's not guaranteed to work so it's not something you can depend on).  So when packets are being lost one (or more) out of set A could get through while all of set B were lost, something that doesn't have much effect when set A was "set throttle to 15" and set B was "set throttle to 16", but can have a much greater impact when both need to be received for programming to work properly. While most programming actions only set a single CV, and thus use one packet, some set more than one CV (e.g., adding an enable bit to CV 29 in addition to making other changes), which require more than one packet.

 

It's the more complex operations related to programming that are more sensitive to disruption.  I spent a number of years diagnosing faults in large Ethernet networks, so I am probably more sensitive to the way deterministic digital systems can behave erratically due to analog effects in the wiring. Perhaps I'm overvaluing that.

 

But I think we've wandered a bit off the original topic of this thread, so I'll leave it at that.

 

I do see your point about the "works on the track, not directly" potentially suggesting an issue with high voltage.  I'm doubtful, but you may well be right.

[inobu]

You hit on it. DCC has no means for error correction CRC's (Cyclic Redundancy Checks) on the transmission path so it (the path) must be at optimum performance. One bit loss anywhere in the packet and the decoder will discard it (decoder just sitting there).

 

My overall point to those who might be interested is that the issue may be in the voltage on the programming track and if you change some of the variables you may be able to get it to work. You have to play around with it.

 

DCC is working but it is not manufactured to perfection. Digitrax, MRC and others don't have the Sony, Samsung revenue dollars to support it. So we may have to solve the issues our selves.

 

Inobu