DCC starting out - I'm not a techy but so far its been worth it!

[jcm@gwr]

33 minutes ago, newbryford said:

 

 

From the GM Prodigy manual

"When you program your decoder’s address with PRODIGY ADVANCE, it will automatically program CV29."

 

CHANGES                                      DECODER ADDRESS 1-127        DECODER ADDRESS 128-9999 

PRODIGY ADVANCE’s Default Setting      CV29 = 2                            CV29 = 34

Change Polarity Only                                  CV29 = 3                            CV29 = 35

Change to 14 Speed Steps Only                CV29 = 0                           CV29 = 32

Change Polarity & 14 Speed Steps           CV29 = 1                           CV29 = 33

 

So - yes, it does appear that the Prodigy defaults to DC off when programming an address.

 

 

But - a few quick tests:

 

I have just connected a GM Prodigy to a decoder that has had a full CV8=8 reset, Cv29 = 6 (i.e. DC enabled)

Changed a couple of CVs on the program track -  including address.

 

CV29 = 6 or 38 depending upon long or short address (i.e. DC enabled)

 

 

BUT:

 

When reprogramming the address on the Main track, then CV29 is changed as per the manual and DC running is disabled

 

Very odd!

(Note - I only have a GM PA for test purposes - it's not top of my list for controlling a layout)

 

 

Probably because the GM DC controllers are their own brand. The Prodigy is a re-badged MRC product.

 

 

 

 

 

 

 

It will also re-set it just by running it on the track, you don't need to be programming it.

 

And yes, I know it's a re-badged MRC product

[WIMorrison]

So no mystery in the end , all documented in the manual for the device - seems that people haven’t bothered to read the manual  

 

always worth taking a look at them, surprising what you can find

[Crosland]

1 hour ago, newbryford said:

BUT:

 

When reprogramming the address on the Main track, then CV29 is changed as per the manual and DC running is disabled

 

Very odd!

 

Without something like Railcom, you cannot read the current CV29 value, before writing it, to merge in the changes, when programming on the main.

 

MRC seems to have chosen to blindly write a single value and possibly obliterate whatever is in CV29.

 

A better design would prompt the user for a CV29 value and then apply the changes before writing.

 

An even better design would optionally use direct bit write(s) to change only the bit(s) that needs changing in CV29. The problem is that you cannot determine if the decoder actually supports bit writes (recent ones should).

[NIK]

1 hour ago, boxbrownie said:

Blimey, you’ve had bad luck with new purchases 

Hi,

 

I'm not the only one. The Class 47 was one of the early Heljan OO models and I think others also had motor problems with that type. Others have reported motor problems with early Heljan OO Class 17 models. I saw a club members Limby diesel's wiring loom burn out when the loco derailed and 'shorted' a 5 Amp DCC power district (since reduced to 3 Amp).

 

The first Dapol OO Class 73 I bought had a fault when a DCC decoder was plugged in. To get it running temporarily I disconnected the lighting connections.

 

I've been told about various OO diesel/electric locos where the grease in the gear towers has hardened, slowing the loco and presumably increasing the current draw. My new style all wheel drive Hornby HST already draws over 500ma just to turn it wheels at 12V DC (500ma is the maximum for the Hornby HST TTS DCC Sound decoder). Its top speed has already dropped from 143 scale mph to 129mph.

 

 

Regards

 

Nick

[boxbrownie]

46 minutes ago, NIK said:

My new style all wheel drive Hornby HST already draws over 500ma just to turn it wheels at 12V DC (500ma is the maximum for the Hornby HST TTS DCC Sound decoder). Its top speed has already dropped from 143 scale mph to 129mph.

 

 

Regards

 

Nick

Almost spot on then.......

[Izzy]

6 hours ago, halsey said:

 

As you have got a PA2 can you clear/empty the loco memory on the handset as its got old (previous owner) numbers on it which is annoying

Yes, easily. Press recall to bring up the next loco number stored in the stack. Press Del -1(the speed reduction button). This removes it from the recall stack. As each number appears repeat as desired. One number must remain, the stack cannot be completely empty. Just add a new number as per choosing a loco to be able to clear all old ones.

 

Must say I didn’t know about the re-writing of cv29. Does this apply to the latest Prodigy firmware versions? I don’t think it does, as although I prefer to disable DC running anyway, (and it is necessary with CT decoders fitted with stay-alive in order for them to operate and also others such as Hornby TTS), I have several sound fitted locos (all Zimo) from the likes of YouChoos & Digitrains/Paul Chester that have DC enabled by default in their settings and while they have been used many times on my Prodigy system they are still this way, even when the address has been altered ‘on the main’. 
 

To confirm this I have just taken one, a Bachmann MX648 + SA fitted 03, ran it on my layout, plonked it on my program track connected to my Sprog/decoder pro. Read the basic tab/page. Confirmed DC was enabled. Put it on the layout. Changed the address on the main via the Prodigy. Re-run it on the new address. Re-read it on the sprog to confirm it was still DC enabled. Then again set it back to it’s original address via the Prodigy & POM. Again run it and finally re-checked that it was still DC enabled, which it was. 

So I can only presume that either I have a completely different Prodigy system or am doing things differently? A real puzzle. Maybe the club GM/MRC system could benefit from a firmware upgrade? I am sure that is possible. Oh what fun we have sorting these puzzles out........!

 

Izzy

 

 

[Crosland]

10 minutes ago, Izzy said:

To confirm this I have just taken one, a Bachmann MX648 + SA fitted 03, ran it on my layout, plonked it on my program track connected to my Sprog/decoder pro. Read the basic tab/page. Confirmed DC was enabled. Put it on the layout. Changed the address on the main via the Prodigy. Re-run it on the new address. Re-read it on the sprog to confirm it was still DC enabled. Then again set it back to it’s original address via the Prodigy & POM. Again run it and finally re-checked that it was still DC enabled, which it was. 

 

So how did it know what to write to CV29? Did it write to CV29 at all? Does it use info from the loco stack, and know what to write, or know not to write anything?

 

If you switch from short to long (or vice-versa), which requires a change to CV29, what happens?

 

If DC is initially disabled, does it remain disabled?

 

[Edit] it would also be useful to know what happens to bit 0 (direction) and bit 4 (speed table).

 

Sorry...

Edited December 31, 2019 by Crosland

[halsey]

Talk about threads going off topic...…………………………….. Happy New Year ……………….

[boxbrownie]

13 minutes ago, halsey said:

Talk about threads going off topic...…………………………….. Happy New Year ……………….

It’s RMWeb....what did you expect? 

 

And a very good one too you also.......

[Kaput]

Is it possible the prodigy's that are messing with CV29 for no reason are the older non squared versions and the squared ones work as expected?

[Izzy]

Although this has been seen as being OT, as it arose from questions asked I have to report that further tests have revealed the following, the knowledge of which might be helpful to some MRC/Prodigy users.

 

If a short (one byte) address - 0-99 - is written to replace another short one, or the same with a long address - 127-9999 - to similarly replace another, then alterations to cv29 are not required nor made and the value of cv29 remains as set, whatever that value might be I.e. whether, or not, DC running is enabled/disabled.

 

BUT, if a change is made from either short to long address or vice-versa, then cv29 values are changed in line with requirements, and it seems the values written are two bytes less than that which enables DC, so it is thus disabled. The assumption being, I presume, that anyone wishing to change the address is doing so to run under DCC and not DC, where of course no address is required. 
 

Hope this clears up the situation. 
 

Izzy

[halsey]

I've now got my stable of 6 locos working (DCC) as they should - 2 decoders fitted by a pro as they needed hardwiring but the rest fitted by me which after a lot of trial and error has proved successful and rewarding and made me have a serious go at servicing and cleaning contacts on them all so feeling very much ready for the New Year.

 

One decoder (21 pin) has gone back for replacement as I'm sure its faulty but time will tell ………………...

 

Why do people knock the Prodigy2 system so much I think its very good for a novice/inter user and I certainly wouldn't want anything without the walkabout/remote having had it for a while its very handy.

 

Am I now converted to DCC - probably, but it certainly isn't as easy as the world would have you believe and it could have been a very frustrating/slow process if I didn't have the luxury of loads of time available to "stick at it" and RMW forum members of course

 

Back to modelling and track work for now...………….........

 

BFN

[halsey]

Replacement decoder has just arrived and is now fitted and all is well - just my luck that the first one I ever tried to fit was faulty 

[WIMorrison]

There is a moral here - be careful when fitting decoders as they are fairly easy to break

[halsey]

NOT such good news now I am back at my laptop as the loco has stopped running after about 20 mins and the (ZIMO 21 pin) decoder is too hot to touch and has stopped working.

 

I am clearly wondering if it is the same problem as the first one which never ran.

 

I have just read something which says (re)programming to 100 which I did do here and with the last one might have caused the problem??

 

Not quite sure what to do next am I doing something wrong or should I complain again??

Edited January 7, 2020 by halsey

[newbryford]

Too hot to touch usually means that it is drawing a lot of current.

 

What loco is it?

[halsey]

12 minutes ago, newbryford said:

Too hot to touch usually means that it is drawing a lot of current.

 

What loco is it?

 

Bachmann 31-997 LMS diesel it was running with the body off at the time at 20/28 setting for app 5-10 mins - just fitted plug and play MX638D re-programmed to 100 no other parameters touched - it literally did burn the top of my finger

Edited January 7, 2020 by halsey

[Nigelcliffe]

Looks like either a fault in loco, or a fault in the power (voltage) to the track.   Resulting in too much current being drawn.    I'd start testing at the loco - could be loco internal wiring, could be faulty motor coil.  Likely to be the cause of the earlier decoder's demise. 

 

I test locos on analogue with meters to measure current consumption.  But that's somewhat OTT for ready-to-run stuff. 

 

 

 

 

[halsey]

2 minutes ago, Nigelcliffe said:

Looks like either a fault in loco, or a fault in the power (voltage) to the track.   Resulting in too much current being drawn.    I'd start testing at the loco - could be loco internal wiring, could be faulty motor coil.  Likely to be the cause of the earlier decoder's demise. 

 

I test locos on analogue with meters to measure current consumption.  But that's somewhat OTT for ready-to-run stuff. 

 

 

 

 

 

It's way beyond my skills to resolve this so I'll send the loco and decoder back to the decoder supplier to resolve (AGR Leighton Buzzard) 

 

To be fair that's what they wanted me to do when the first decoder failed and I resisted due to cost of postage and insurance...………...

 

Could it be relevant that the loco might not have been sufficiently run in - I bought it as an "as new" on eBay and it was immaculate and properly boxed etc etc and it ran fine on DC when I got it but was not run extensively before DCC came along

[Pete the Elaner]

8 minutes ago, halsey said:

 

Could it be relevant that the loco might not have been sufficiently run in - I bought it as an "as new" on eBay and it was immaculate and properly boxed etc etc and it ran fine on DC when I got it but was not run extensively before DCC came along

Unlikely. Running in should only help the mechanism to run more smoothly. It sounds like there is a fault.

I also have a cheap DC controller for running in. I expect it will handle less current than a decent decoder & has only ever tripped out when running an 0 gauge Heljan loco, which I assume is too current hungry for the controller to cope with.

[Harlequin]

"As new" often means there's a non-obvious fault in the item, in my experience...

 

[WIMorrison]

yep, a way that sellers often use to offload items (and problems) to someone else.

[boxbrownie]

30 minutes ago, Harlequin said:

"As new" often means there's a non-obvious fault in the item, in my experience...

 

You have to wonder why it was for sale in the first place, especially after these issues with both decoders.

[halsey]

1 hour ago, Harlequin said:

"As new" often means there's a non-obvious fault in the item, in my experience...

 

 

My experience to date has been 100% OK so I'm philosophical about it.

[Nigelcliffe]

1 hour ago, Pete the Elaner said:

Unlikely. Running in should only help the mechanism to run more smoothly. It sounds like there is a fault.

I also have a cheap DC controller for running in. I expect it will handle less current than a decent decoder & has only ever tripped out when running an 0 gauge Heljan loco, which I assume is too current hungry for the controller to cope with.

 

There are plenty of wiring faults possible, and known to have occurred in RTR locos, inside which means it runs fine on DC with the blanking plate, yet on DCC there is a partial, or even complete, short circuit path which will destroy decoders.  

 

 

 

- Nigel