LZV200/LH101 Programming track issue

[RFS]

1 hour ago, philg said:

Hmm. I’m at 4388 so maybe it’s a recently introduced problem. The MX600 is one of the ones I’m having bother with

 

thanks for the feedback

 

I did initially have a problem with feedback on the R,S terminals which was reported by a number of other users. In each case Lenz replaced the LZV200. including mine.. The P,Q  and R,S terminals are on the same plug so perhaps it's a hardware issue rather than firmware? The R,S must have been a hardware problem since otherwise they would have just sent people a new update stick. 

[SamThomas]

Couple of things to add (in my experience).

 

Whatever control station/decoders you are using it is absolutely vital to have a 100% connection between the control station terminals & the decoder - this means 100% clean track, 100% clean wipers/pickup/wheels (all of them).

 

When programming if you get the "locomotive not present" response & the locomotive runs try applying gentle downwards pressure on the locomotive when programming - in one extreme case I had to use a direct connection to the wheels using croc' clips in spite of all the wheel pickups being tested out OK.

 

Hope this helps.

[Bucoops]

Ok I have dug out my set - seems I'm on quite old firmware now?

 

[philg]

45 minutes ago, Bucoops said:

Ok I have dug out my set - seems I'm on quite old firmware now?

 

Be most interested in what you discover 

[RFS]

48 minutes ago, Bucoops said:

Ok I have dug out my set - seems I'm on quite old firmware now?

 

 

I started with that level (still have the stick) but when I asked Lenz they sent me 4325. I've asked again about 4388 and will wait and see what they say. Just a pity they didn't provide some means of updating firmware with patch levels via internet download ...

Edited May 22, 2021 by RFS

[philg]

10 minutes ago, RFS said:

 

I started with that level (still have the stick) but when I asked Lenz they sent me 4325. I've asked again about 4388 and will wait and see what they say. Just a pity they didn't provide some means of updating firmware with patch levels via internet download ...

I think they’re protecting themselves. Upgrades are probably chargeable which is why the sticks are specific to one command station. Personally I wish you could downgrade if you find issues with later levels, but not sure you can

[Bucoops]

2 hours ago, philg said:

Be most interested in what you discover 

 

I'm expecting the same as before - Lenz modules work fine, Zimo not detected. Next thing to find is those bits to test.

[philg]

17 minutes ago, Bucoops said:

 

I'm expecting the same as before - Lenz modules work fine, Zimo not detected. Next thing to find is those bits to test.

Well, others seem to have reported that Zimo decoders ARE detected on an earlier release of Lenzs' firmware, but not on the later one(s)

[RFS]

2 hours ago, philg said:

I think they’re protecting themselves. Upgrades are probably chargeable which is why the sticks are specific to one command station. Personally I wish you could downgrade if you find issues with later levels, but not sure you can

 

Yes you can downgrade using your previous stick. I believe that when you receive a new stick, the firmware upgrade process then locks the new stick to your LZV200. In this way Lenz can produce a common stick for people to upgrade that does not need to be tailored for each LZV200. 

 

I understand upgrades need to be chargeable (eg new version) but patch fixes to an existing version really should be free. 

[philg]

8 minutes ago, RFS said:

 

Yes you can downgrade using your previous stick. I believe that when you receive a new stick, the firmware upgrade process then locks the new stick to your LZV200. In this way Lenz can produce a common stick for people to upgrade that does not need to be tailored for each LZV200. 

 

I understand upgrades need to be chargeable (eg new version) but patch fixes to an existing version really should be free. 

Ahh, that's smart. I did wonder how they did that!

[Bucoops]

2 hours ago, philg said:

Well, others seem to have reported that Zimo decoders ARE detected on an earlier release of Lenzs' firmware, but not on the later one(s)

 

Any idea what constitutes older firmware as I'm obviously several behind and it hasn't worked from out of the box new.

 

Just done some tests:

 

Loco 1: Oxford Rail N7

Loco 2: Heljan BTH Type 1

 

Decoder 1: Lenz Gold

Decoder 2: Zimo MX600R

 

Loco 1 with Decoder 1: Works

Loco 1 with Decoder 2: Error 2

Loco 2 with Decoder 1: Works

Loco 2 with Decoder 2: Error 2

 

So still what I was seeing before

 

Both decoders work fine, it's purely programming track.

[philg]

3 minutes ago, Bucoops said:

 

Any idea what constitutes older firmware as I'm obviously several behind and it hasn't worked from out of the box new.

 

Just done some tests:

 

Loco 1: Oxford Rail N7

Loco 2: Heljan BTH Type 1

 

Decoder 1: Lenz Gold

Decoder 2: Zimo MX600R

 

Loco 1 with Decoder 1: Works

Loco 1 with Decoder 2: Error 2

Loco 2 with Decoder 1: Works

Loco 2 with Decoder 2: Error 2

 

So still what I was seeing before

 

Both decoders work fine, it's purely programming track.

I thought I saw someone reporting no errors with an earlier release, but (of course) I can’t find that post again!

 

I’ve just done some more testing. I have an MX637 that seems fine. An MX638 that I’m sure didn’t work, but is now. And an MX600R which steadfastly refuses to read cvs with Lenz

 

So maybe it’s more specific to decoders rather than all of Zimo?

 

I’ve passed this info on to Zimo in case there’s a subtle firmware difference in the MX600 series

 

Be interested to know if anyone else has problems reading any OTHER Zimo decoders with the new LZV200

[Bucoops]

9 minutes ago, philg said:

I thought I saw someone reporting no errors with an earlier release, but (of course) I can’t find that post again!

 

I’ve just done some more testing. I have an MX637 that seems fine. An MX638 that I’m sure didn’t work, but is now. And an MX600R which steadfastly refuses to read cvs with Lenz

 

So maybe it’s more specific to decoders rather than all of Zimo?

 

I’ve passed this info on to Zimo in case there’s a subtle firmware difference in the MX600 series

 

Be interested to know if anyone else has problems reading any OTHER Zimo decoders with the new LZV200

 

What contact method did you use to contact Zimo as it wouldn't hurt for me to do the same.

 

One thing made me jump when I was doing the testing - The Zimo is obviously set to have the lights on as when connected to the BTH it lit up and made me think I'd shorted something

[philg]

26 minutes ago, Bucoops said:

 

What contact method did you use to contact Zimo as it wouldn't hurt for me to do the same.

 

One thing made me jump when I was doing the testing - The Zimo is obviously set to have the lights on as when connected to the BTH it lit up and made me think I'd shorted something

Yep, noticed that too. One other thing I noticed on my decoder tester, they alternate the polarity of pulses, so your loco doesn’t wander down the programming track! Controlled by a cv somewhere too

 

i emailed service@zimo.at. This is a long weekend in Austria aparrently, so any reply may be delayed

[Bucoops]

I do have a couple of MX633P22s but nothing to actually connect them to so don't know if my issue is limited to the 600R.

[philg]

43 minutes ago, Bucoops said:

I do have a couple of MX633P22s but nothing to actually connect them to so don't know if my issue is limited to the 600R.

That’s why I have a decoder tester. That and the fact that in the olden days I always validated a decoder fully before it went anywhere near an engine. I had a SoundTraxx decoder start to smoke even on the programming track!!

[RFS]

2 hours ago, Bucoops said:

I do have a couple of MX633P22s but nothing to actually connect them to so don't know if my issue is limited to the 600R.

 

I've done some more tests and found no problems at all with Zimo MX634D or MX638 decoders. 

 

One issue I've had with MX600R decoders is wires coming adrift from the plug. Lenz Standard+ decoders are much better made with the wires being fed through a slot in the side of the board which holds them tight and prevents any strain on the wires. 

[philg]

I just ordered some 635s and a 630. I’ll report back when they arrive

[jpendle]

Hi,

 

Have any of you looked into the firmware revision on the Zimo decoders? It seems like some work and others don't.

 

CV's 7 & 65 will read back the SW version and subversion numbers, the latest version is 40.5. I use Zimo decoders and the ones I have bought are typically 3 or 4 versions out of date.

 

If there is a correlation between this issue and the Zimo firmware version then the solution might be to upgrade all the decoders to the latest firmware.

 

Regards,

 

John P

[philg]

51 minutes ago, jpendle said:

Hi,

 

Have any of you looked into the firmware revision on the Zimo decoders? It seems like some work and others don't.

 

CV's 7 & 65 will read back the SW version and subversion numbers, the latest version is 40.5. I use Zimo decoders and the ones I have bought are typically 3 or 4 versions out of date.

 

If there is a correlation between this issue and the Zimo firmware version then the solution might be to upgrade all the decoders to the latest firmware.

 

Regards,

 

John P

Good point John. I’ll take a look when my next order arrives. Then I’ll have 5 or 6 to compare 

[RFS]

The MX600R decoders that I have. and which the LZV200 has no trouble with. are firmware level 31.65.  I don't have any means of updating them, but then I don't have any issues either. 

[philg]

1 hour ago, RFS said:

The MX600R decoders that I have. and which the LZV200 has no trouble with. are firmware level 31.65.  I don't have any means of updating them, but then I don't have any issues either. 

Thanks Robert, this is good information. I wonder what version my MX600 is......  I’ll report back when Ive had chance to check

 

Appreciate everyone’s input on this 

[philg]

OK, some updates from tonights testing

 

These decoders can ALL have their CVs read without problem on my Lenz LZV200-based system (which is running their firmware version V3.8 B4388). Below, the version numbers for the decoders are cv7.cv65

• MX638D v37.10
• MX637 v37.8
• MX630R v37.8
• MX635R v37.12

In fact the ONLY decoder I have now from Zimo that I cannot read via the LZV200 is an MX600R (v37.8) - and I did try it both ways on the program track

 

Zimo tell me that NOTHING in the service mode programming firmware has changed for years, and I can believe that. But it does seem odd that the MX600 is the odd one out. I've reported my findings (above) back to Zimo though I'm now wondering of there is a rogue batch of MX600s out there

 

Thanks again everyone

Edited May 25, 2021 by philg
Changed to “service mode programming”

[Nigelcliffe]

48 minutes ago, philg said:

OK, some updates from tonights testing

 

These decoders can ALL have their CVs read without problem on my Lenz LZV200-based system (which is running their firmware version V3.8 B4388). Below, the version numbers for the decoders are cv7.cv65

• MX638D v37.10
• MX637 v37.8
• MX630R v37.8
• MX635R v37.12

In fact the ONLY decoder I have now from Zimo that I cannot read via the LZV200 is an MX600R (v37.8) - and I did try it both ways on the program track

 

Zimo tell me that NOTHING in the ops mode programming firmware has changed for years, and I can believe that. But it does seem odd that the MX600 is the odd one out. I've reported my findings (above) back to Zimo though I'm now wondering of there is a rogue batch of MX600s out there

 

Thanks again everyone

 

There is something wrong in the above :    "Zimo .....  ops mode programming..."     

 

Ops-mode is "programming on the main",  not "programming track", which is "service mode".    There are sub-divisions within service mode for the detailed method,  for Zimo its probably "direct" as the preferred method.  

 

If you were doing "ops mode", then reading may be possible with a Lenz system, using RailCom, to read the CV values.  

 

 

- Nigel

[philg]

14 minutes ago, Nigelcliffe said:

 

There is something wrong in the above :    "Zimo .....  ops mode programming..."     

 

Ops-mode is "programming on the main",  not "programming track", which is "service mode".    There are sub-divisions within service mode for the detailed method,  for Zimo its probably "direct" as the preferred method.  

 

If you were doing "ops mode", then reading may be possible with a Lenz system, using RailCom, to read the CV values.  

 

 

- Nigel

Good spot, thanks Nigel. Duly corrected to “service mode”, which is what I meant!