Zimo MX621N strange behaviour

[jpendle]

Hi,

 

I have been trying to double head 2 locos on my layout using the Roco Z21 'Multi-Traction' feature, which means I haven't been fiddling with CV's to set up a consist.

 

To do this you measure each locos performance over a set distance and enter the values into the Z21 app and away you go.

 

Here's the story.

 

I have 2 Dapol N Gauge CL86's, one has an MX621N and the other has an MX617N. When measuring the time taken at various speed steps to traverse a fixed length of track the loco with the MX621N in was around 4 to 5 times slower than the one with the MX617N.

 

Suspecting the loco I tried them both out on my DC test track, with the decoders still fitted, and both locos performed very much the same, if anything the MX621N equipped loco was marginally faster than the other one. But they were running in opposite directions on DC (of which more later)

 

I then checked DC current draw and they both draw around 100mA.

 

I put them back on the layout and swapped the decoders around, the slow moving loco was always the one with the MX621N fitted.

 

Next I looked at CV setting, as all my decoders have been purchased new, I expected to see default values everywhere. CV's 2 to 6 (3 step traction) were all set to the Zimo default on both decoders, BUT CV29 was not.

On the MX617N CV29 was set to 14 (default), but on the MX621N, CV29 was set to 223!!!, or 1101 1111, so reverse direction of travel, individual speed table and long addressing were turned on as were bits 6 & 7, which don't do anything according to Zimo.

This explained the backwards DC running, and perhaps the 'slowness' of the loco, but I'm mystified about the long address thing as I had programmed it to address 6. So I set CV29 back to 14 and tried the MX621N loco again. Now it ran the correct way round on DC and was faster on DCC but still took almost 3 times as long to traverse a fixed distance as the MX617N equipped loco.

Next I did a Zimo hard reset (CV8 to 0) to clear any other programming that may have been done to the chip, this made no difference, so finally I manually checked CV's 1 to 120 and found that they are the same as on the MX617N.

 

Questions.

Has anyone else bought a new decoder that appears to have been programmed?

Is there any significance in CV29 being set to 223?

Could the MX621N be 'faulty' and someone has tried to 'fix' it by tweaking CV's.

Given that the Zimo manual applies to all their decoders, shouldn't the performance from an MX621N, be identical to an MX617N, or MX622N for that matter?

 

Finally I have read back CV29 on 8 more locos with Zimo chips, all of them are set to 14 (MX617N, MX622N, & MX618N18), except for the other MX621N that  I have checked and it also reads 223 from CV29!

 

Apologies for the long post but the details are important to make sense of things.

 

Regards,

 

John P

Edited March 5, 2020 by jpendle
Spelling

[jpendle]

Well by sheer chance I've managed to make some progress on this issue.

I've been playing around with RailCom and my MX621 and MX622 locos seemed to be misbehaving.

As I have a Z21 I can reprogram some Zimo decoders using the Z21 maintenance app, I duly reprogrammed the firmware in an MX622N in one of my CL66's.
I immediately noticed that it seemed to be running faster after the update.

So I took two more MX622 equipped locos and did some experiments running the locos the length of my fiddle yard, around 8 feet.

CL67 with MX622N at rev 31.5

Speed Step 30 took 2 minutes & 25 seconds
Speed Step 40 took 1 minute & 18 seconds

After updating the decoder firmware to rev 37.8 I got these numbers

Speed Step 30   51.8 seconds
Speed Step 40   30.2 seconds

I did the same with a CL66 and got this

Before
Speed Step 30   2 minutes and 31 seconds
Speed Step 40   1 minute and 26 seconds

After
Speed Step 30   56 seconds
Speed Step 40   33 seconds

These speeds are a much closer match to my MX617 and MX618 equipped locos.

So the issue seems to be with the firmware revision in the decoder.
Unfortunately I can't reprogram the MX621's because Roco don't support this decoder  

Regards,

John P