Model Railway Forum banner
1 - 14 of 14 Posts

·
Ian Wigglesworth
Joined
·
750 Posts
Hope someone can help with this!

I have this CT elektronic decoder fitted to a diesel 04 shunter and it's being a swine!

It says that programming CV1 with a value of 0 gives it a hardreset.

So I did that first.

Set a short address to 7

Ran the loco all ok works fine, but very slow at top speed.
So I altered CV5 (Max speed top volts) to a value of 200, it says the range is 0-255.

I couldn't then run the loco as the address had changed to 200!

This seems to happen no matter what settings I put in, when ever I change any of the speed settings the address changes as well!
This decoder was replaced only a week ago, and I've only just got round to running it, now find it's playing up, is it another decoder required?

Cheers
 

·
Ian Wigglesworth
Joined
·
750 Posts
Discussion Starter · #2 ·
This is mental!

Carried out a decoder reset and also went through decoder recovery program with the PowerCab.

If I program CV1 (short address) with a value of 7 then select loco 7, the loco will run forwards and in reverse but very slow.

So go to CV5 and that is reading 7 ?? So I enter 250 which is almost top volts and the address in CV1 now reads 250

It doesn't seem to effect the long address, but somethings not quite right.

Very very strange, me thinks the decoder is having a brain drain!

Any other ideas anyone?
 

·
Just another modeller
Joined
·
9,983 Posts
QUOTE (wiggy25 @ 15 Jun 2008, 21:03) <{POST_SNAPBACK}>Hope someone can help with this!

I have this CT elektronic decoder fitted to a diesel 04 shunter and it's being a swine!

It says that programming CV1 with a value of 0 gives it a hardreset.

Cheers

***Doop - CV1 is reserved by the NMRA for short address - it should NEVER be used for anything else! It sort of beggars belief that setting short address to zero will set short address to 3 if you see what I mean :) :)

When CV's start showing 255 everywhere, its usually an indication of an attack of brain death or accidentally induced alzheimers in the decoder processor.

Set CV1 to address 3 and then simply try CV8 to 8 as a reset and see if that helps. I'm not hopeful - its just that I cannot believe any decoder Mfr would use the standard short address Cv for global reset!

Go Back to TCS M1's or ESU LokPilot Micro's for a sensible reliable result Ian!

Richard
DCCconcepts
 

·
Just another modeller
Joined
·
9,983 Posts
***Hi Ian

Not bad as manuals go, but in relation to your problem there's not much help there. I'd suggest looking at CV30 and resetting it to zero if it has any other value in it - apart from that, no other ideas, sorry.

Richard
 

·
Registered
Joined
·
827 Posts
QUOTE (wiggy25 @ 15 Jun 2008, 14:45) <{POST_SNAPBACK}>This is mental!

Carried out a decoder reset and also went through decoder recovery program with the PowerCab.

If I program CV1 (short address) with a value of 7 then select loco 7, the loco will run forwards and in reverse but very slow.

So go to CV5 and that is reading 7 ?? So I enter 250 which is almost top volts and the address in CV1 now reads 250

It doesn't seem to effect the long address, but somethings not quite right.

Very very strange, me thinks the decoder is having a brain drain!

Any other ideas anyone?

Ian,

If I'm correct, then I know exactly what is wrong.

Are you using page mode programming?

Do you find that writing to CVs 5 - 8, or 9 - 12,... (each group of 4) actually writes to CVs 1 - 4?

I had a problem with SPROG and QSI Version 6 sound decoders that did this and had to tweak the SPROG firmware to fix it. Co-incidentally, about two days later, someone sent me a small Tomix n gauge track cleaner that exhibited the same symptoms and I believe it had a CT decoder fitted, but need to check on that.

Andrew Crosland
 

·
Ian Wigglesworth
Joined
·
750 Posts
Andrew,

I can't be 100% sure, as I tried lots of different things but I do believe that is whats happening.
As when I program CV1 short address to say 7
Then CV5 and CV6 read the same as CV1 thats a fact, didn't check the others but I can do later.
As for paged mode I'm not sure, just use program track on the PowerCab, which I assume would default to page mode?

Is there any way round this, if this is actually the case.
 

·
Registered
Joined
·
827 Posts
QUOTE (wiggy25 @ 16 Jun 2008, 14:03) <{POST_SNAPBACK}>Andrew,

I can't be 100% sure, as I tried lots of different things but I do believe that is whats happening.
As when I program CV1 short address to say 7
Then CV5 and CV6 read the same as CV1 thats a fact, didn't check the others but I can do later.
As for paged mode I'm not sure, just use program track on the PowerCab, which I assume would default to page mode?

Is there any way round this, if this is actually the case.
If it the same problem then CV5 should read the same as CV1, CV6 the same as CV2, CV7 the same as CV8, etc.

I was a bit confused with my earlier reply. I'm now at home and able to check my notes. Whilst the symptoms with the DCZ75 were the same as the QSI v6 decoder, I didn't manage to fix the problem for the DCX and came to the conclusion that this decoder does not support paged mode. This was certainly true for some earlier CT decoders, but someone else may be able to confirm for the DCX75.

The only solution in that case, is to program in direct mode.

Andrew
 

·
Registered
Joined
·
116 Posts
QUOTE (SPROGman @ 16 Jun 2008, 18:43) <{POST_SNAPBACK}>Whilst the symptoms with the DCZ75 were the same as the QSI v6 decoder, I didn't manage to fix the problem for the DCX and came to the conclusion that this decoder does not support paged mode. This was certainly true for some earlier CT decoders, but someone else may be able to confirm for the DCX75.

The only solution in that case, is to program in direct mode.

Andrew

I believe that I can confirm that the DCX75 does not accept paged programming. I have tried this method with my Uhlenbrock Intellibox and it says "No page" and will not let me proceed. When I programme with what Uhlenbrock call program (byte), which I think is another name for direct programming, there is no problem. I tried a reset by programming CV1 to 0 and that worked too.

Don't write off CT decoders; they have many virtues.
 

·
Registered
Joined
·
193 Posts
The best place for information about CT Elektronik (Tran) decoders is the website run by Arnold Huebsch. He even has some documentation which is better than the standard manuals from Mr Tran.

If you get really stuck, try emailing Arnold with all the symptoms and I am sure he will help. He's pretty good about that, even if you did not buy from him, and his English is perfect. He can be slow to reply if he is away at one of the major exhibtions or trade fairs in Austria or Germany, but that's usually announced on his website.
 

·
Registered
Joined
·
1,652 Posts
QUOTE (wiggy25 @ 15 Jun 2008, 13:03) <{POST_SNAPBACK}>Hope someone can help with this!

I have this CT elektronic decoder fitted to a diesel 04 shunter and it's being a swine!

It says that programming CV1 with a value of 0 gives it a hardreset.

So I did that first.

Set a short address to 7

Ran the loco all ok works fine, but very slow at top speed.
So I altered CV5 (Max speed top volts) to a value of 200, it says the range is 0-255.

I couldn't then run the loco as the address had changed to 200!

This seems to happen no matter what settings I put in, when ever I change any of the speed settings the address changes as well!
This decoder was replaced only a week ago, and I've only just got round to running it, now find it's playing up, is it another decoder required?

Cheers

I've just been round all the same issues (in an Farish 04 with my own 2mm finescale wheels). After some headbanging, I now have a loco which goes from crawl (1 wheel turn in 12 seconds) to sensible top speed, sane acceleration etc.

There is a bug in one of the JMRI/DecoderPro files, so use caution if using those (see below).

In summary:

MUST use DIRECT MODE to program the chip, don't try anything else.

CV1 = 0 does execute a factory reset. I have used it a couple of times. It takes a while to respond.
CV109 can be useful in allowing access to alternative CV range (basically have two full sets of CVs which are swapped by CV109). Its worth setting CV109 to an odd number to gain access to the second set, fiddle with those for a while, and if still stuck, then go back to the first set by setting the value to an even number (0). That seemed to fix some of the wierdness in mine, though still not 100% happy that I understand what is going on.

Half speed in reverse is caused by bit 2 (numbering bits 0,1,2, etc) of CV116

To make decoder work satisfactorially in my 04, I ended up with:

CV1 = 7 (I am using short addresses)
CV3 & CV4 = 4
CV5 = 255
CV6 = 84 Wanted low speed range to be more controllable, hence somewhat skewed downwards, couldn't make a custom speed table behave to my satisfaction, but suspect some of the JMRI files may be screwed and ran out of time.
CV29 = 1 (guess who wired the chip to motor leads without checking !!).
CV50 = 255 (regulation influence, standard value)
CV51 = 30 P-value (much reduced from default)
CV52 = 15 I-value (kept in proportion to CV51, seemed to be OK, so stopped fiddling).
CV64 = 200 ( cuts top speed, see the Arnold Web Commentary on the Trans decoders and note below)
CV116 = 3 (Half speed operates on F3, reverse speed is normal, bit 3 can give 65% reverse speed)

NOTE that there is an error in one of the JMRI files for the DCX in that it has CV64 incorrectly labelled in the definitions as CV49 !
Setting CV49 to a non-zero value causes the half-speed (F3) to turn off, and may cause some of the other wierdness.
Faulty JMRI file on CV64 is "CT_Elektronik_DCX_new", not to be confused with "CT_Elektronik_DCX_new2"
I've not fully reconciled the JMRI files to my satisfaction, so cannot say which is properly correct on all aspects.

I will fiddle some more with the values after the 2mm Scale Association Expo at the weekend.

If still stuck, drop me email via the contacts link on the 2mm Scale Association website and I'll try to get my full set of CV's over to you, I don't read the MRforum too frequently.

- Nigel
 

·
Registered
Joined
·
1,652 Posts
QUOTE (Nigel2001 @ 23 Jun 2008, 19:06) <{POST_SNAPBACK}>CV29 = 1 (guess who wired the chip to motor leads without checking !!).

I should have said CV29 =3 , whilst some of my controllers are 28 step, none are 14 !
 

·
Ian Wigglesworth
Joined
·
750 Posts
Well it works, but only in DIRECT MODE!!

Luckily, Mike Bolton from MERG had just sent an email regarding a new PIC program for the Standalone programmer! Excellent timing!

This new program was for some problematic sound decoders, but it has also meant the MERG standalone programmer will now read and write CV's in DIRECT mode on the CT Elektronic decoders.

The programmer already had Direct mode programming but wouldn't work with the CT Elektronic decoder, this little bit of information from Mike may help.

Maybe I can explain a bit about 'direct mode' programming. When reading in
direct mode, you ask the decoder is bit 'n' a one or a zero by sending it
the bit and asking it to 'verify' it. If it is the same as the one you sent
you get an ACK, if it is not, you get NO ACK. To speed things up with the
original MERG programmer code, we just sent ones and if there was no ACK we
assumed it must have been a zero. This meant only sending 8 bits to verify.
However, as a check we then did a direct 'byte' read which should confirm
the value with an ACK. The NMRA RP does say that a decoder that supports
direct mode should support both bit and byte read / write. Unfortunately
not all manufacturers have conformed to this. Some, like CT only do the bit
mode so will fail to verify with a byte read. Some, I believe only do the
byte read.

For the direct mode programming we only implement the byte write. Hence the
CT would program but not confirm it.

As the CT decoder is 'non compliant' it failed when using the strict RP
interpretation but still actually programmed. We also had problems with some
other decoders where the delay between the ACK and trying to read the next
bit was too short. The RP says 'one or more' reset packets needed. In the
latest code we included more reset packets and also changed the bit read
sequence so it checks for both a one and a zero (needs 16 tries instead of
8) but now we assumed the read would be correct so dropped the byte verify
as confirmation. This should now work with the CT decoders. The added resets
also enabled a Digitrax decoder to work in direct mode and some sound
decoders which were problematical. All but the QSI ones will now read in
direct mode. QSI still needs the page mode. The additions do make the
direct read a bit slower.

So thanks to Mike Bolton for the explanation!
Hope others find it useful.

CT decoders are great in that they are so very small, and will fit where you would never believe possible,but they do need quite a bit of playing with to get the motors to run well.
They are not a great 'out of the box' decoder!
The instructions are a bit rubbish and hard to follow as well.
Once you have them set up though they do perform very well and the slow speed you can get is incredible!

Cheers
 

·
Premium Member
Joined
·
6,202 Posts
Hi Wiggy,
I have the same loco fitted with a DCX74Z i had it fitted and the only problem with it was the direction of the loco running corrected by setting CV 29 to 3, factory reset on this model is CV 1 = 0 on my instruction sheet here
Hope this helps.
 
1 - 14 of 14 Posts
Top