Trip

 

Yes - it isn't the prettiest, but is usually the most reliable.

 

Yeah, they reliably drive me fkin nuts.

No other forms of torture are still allowed. Has anyone actually checked the Geneva Conventions? 

That worked. Thanks very much gents.

If anyone knows why a motor must be present to get a response (or even read CVs) I'd be very interested to know.

I've bought a Hornby R3390 from ebay It's had the sound decoder(s) remove and left with an 8-pin socket in both the powered and dummy car.

Fitting a decoder to the powered car worked fine. Fitting a decoder to the dummy car (to work the lights) and I can't get a response from the decoder on the programming track. Using a multimeter in beep mode I've established that there is a perfect connection from the rails all the way to pins 8 and 4. (This is measured at the solder contact of the wire that runs to the decoder.)

The decoder was pulled from another loco which was working fine.

I'm assuming that although the other connections to the decoder are important for working the lights the only connections required to read/write CVs are pins 4 and 8 to the tracks? 

Any ideas what could be wrong?

That's absolutely fantastic GU, thanks very much.

Well that's all very well for you Russ what are the rest of us going to do for entertainment now?

Well, quite. I bought it from the UK ebay site but from a German vendor. He has agreed to refund me, which he really had no choice about, but I have not been able to persuade him that selling this item in the UK without clearly stating, in English, that it will not work on any track somebody in the UK is likely to have is going to cause him (and his customers) trouble.

Never mind.

Thanks all. As many of you worked out this model only runs on Marklin AC track. So the very stupid thing I had suspected I'd done turns out to be buying the wrong fking loco.

 

I've just ordered some DCC Concepts 6-pins with Stay Alive to see if that eliminates the problem. I suspect I shall soon be returning a number of decoders to Hattons as either faulty or not fit for purpose.

It might do but to be honest you're better off using another brand of decoder until they get that issue fixed. If you've got room for a keepalive you got room for several other options.

DC version in robby rage here  http://www.piko-shop.de/index.php?vw_type=artikel&vw_id=9178 

Thanks. That link says it's got a NEM 652 digital interface which is an 8-pin DCC socket. If that's true, it's exactly what I'm after. I think I'll wait for confirmation on that before buy it though.

JMRI absolutely works on a Mac (and Windows, and Linux).

​If I am reading the one in the Piko link then it is 3 rail  & may not be sound fitted

type of current: AC, decoder-equipped for normal and DCC operation

 

This is excellent advice John and I wish I'd seen it before I ordered it. It arrived this morning an apparently doesn't work unless you have Marklin AC track (whatever that is). It claims to have an NRMA compliant decoder in it but that doesn't actually seem to be the case.

Back to the drawing board.

Incidentally I don't want DCC sound. Just DCC capability.

It's actually a Piko 57305, not a 57691 per the title. 

Yep, it got removed immediately and hasn't been put back.

It doesn't cause a short on the programming track incidentally.

I've just received a Piko 57305 which has a built-in decoder.

There is a manual for the decoder in English which says it's NMRA compatible. It also says Decodertype: 76 320. DCC manufacturer id 76 is Auvidel, a German company, which makes sense.

On the programming track every CV is set to 255. Writing new values appears to work but reading them back suggests it hasn't taken.

I thought I'd try using it with the default address (which the manual says is 3) and putting on the layout causes an instant short.

Normally when I'm totally baffled by something on the layout it's because I've done something really stupid.  Any ideas?

If you're thinking about the Z21 you might want to consider the DR5000. It has Xpressnet and Loconet (and S88) and can connect to your Mac via USB or Ethernet. It doesn't have the software of the Z21 but it's more capable and at a fraction of the price.

I was about to say that WIMorrison has makes a very sensible suggestion about buying the Lenz ethernet adapter instead of a whole new system but in fact the DR5000 is actually cheaper than the Lenz ethernet adapter.

The DR5000 is very new and there are some teething troubles. There's a new software version and new manual due RSN. Buy it from somewhere you can send it back if you don't like it. If you buy it from Amazon UK you get a month to try it.

Hmm not sure what to think now as I bought a multi five pack from Hattons, so they will all be the new type.  

 

So did DCC Concepts offer any advice on weather this can be CVed on and off?  What also concerns me is that it was happen on plain line and not just on places like dead frogs where you might expect power loss.

 

DCC concepts claimed it was the intended behaviour and there is no way to modify it with CV changes. DCC Concepts decoders (but not the ones they make for Hattons)  usually come with a small keepalive capacitor which can mask the problem.

Hattons will refund you for those decoders without question, or at least they've always done so for me. I've found Bachmann decoders (which are currently rebadged ESU) to be much better, and the same price or actually slightly cheaper.

Nice one, thank you.

I've just taken my train-obsessed 5-year-old to miniatur wunderland in hamburg. On the way back we stopped off at Hamburg station so he could get up close and personal with some ICE trains as they moved through.

Back at home and on my layout, which is almost but not quite as impressive as miniatur wunderland,  I assumed it would be easy to  buy a model ICE 3, but it seems I was wrong. Anyone got any suggestions?

 

Trip, your reply sound absolutely spot on to what I have been experiencing of the stop star issue.  The Mallard once stopped will then stat up again with moment style speed increase.  The chip was a new one for Hattons in their new style of packaging so may well be a newer version of the chip,  My question here is then, is this a fault or a feature?  If a feature can it be turned off and on?  Or is this just the effect on this particular Loco?

 

In my opinion it's a design fault. I spoke to DCC Concepts about it and they claimed it was the intended behaviour on the new version of the decoder. I have not bought any DCC Concepts decoders since, and sent three decoders back.  I have not found anyone else who thinks this behaviour is a good idea. I dare say this bug feature will be ironed out designed away in future versions but until then I'm steering clear of DCC Concepts decoders. Which is a shame because they do a lot of things right, including the price.

This is a guess but it would explain it.

Hattons chips are (or at least were) actually rebranded DCC Concepts. At least one DCC Concepts decoder type has recently been updated and its behaviour when seeing very short duration loss of power has changed. When power comes back instead of continuing at the existing speed it goes back to zero, suddenly, and then starts to accelerate again using the momentum settings.

So my guess is your new chip has this new characteristic and the Mallard fails to deliver power to it for a split second and it halts, then starts again with no prompting. Putting that chip into another loco which doesn't have intermitten power delivery issues means you don't see the problem any more. Similarly putting a 'normal' chip into the Mallard masks the tiny outages because it doesn't suddenly decide to stop.

+1 for Coastal DCC, they are excellent. Super fast and a really nice bloke.

 you are still left with the problem that a DCC based system would have to communicate a loco's position to a computer (or software running on the same DCC operating computer), where the software would then have to select the appropriate sound file for that loco, take into account any loco acceleration/deceleration changes. Then from the positional information map that sound to a discrete output on a audio hardware device which either has onboard amplification sufficient to drive a loud speaker or in turn feeds a multichannel loudspeaker amplifier. The real heavy work would be the software required to do the mapping and the amount of "fiddling" required to come up with some sort of convincing soundscape, when the whole system is meshed together.

 

This is more or less what JMRI's virtual sound decoder tries to do. It uses a 5.1 or 7.1 surround system connected to the PC running JMRI. You can associate a collection of sounds and a config (together called a VSD file) with a JMRI roster entry. JMRI tracks the loco round the layout using whatever block detection system you like and knows what the throttle positions and speeds of the loco are (the same way a sound decoder does) and plays sounds through the speakers.

I've only just started playing with it, but it looks promising.

Does it actually make a difference where it is connected across the bus wires? I don’t think that the electrical signal makes note of whether it is at the end or 10’ from the end

This is sort of why I asked the question. My limited understanding of electronics would suggest that only one is required, at any point between any DC bus wire pair. But all the diagrams suggest it should go at 'the end'. I'm perfectly happy either way I just want to get it right.

Ok, so my DCC bus doesn't have two ends. A pair of wires comes out of the booster and snake off down one side and two other pairs of wires are joined to the first pair near the booster and go off in different directions. So I count three 'ends' plus one 'end' connected to the booster. Is that right?

Would I need to put one of these terminators on each of the three exposed 'ends'?