Jump to content


RMweb Gold
  • Posts

  • Joined

  • Last visited

Everything posted by RFS

  1. I use CV 5 as most of my decoders are Lenz (75 out of 85) and I've only recently become aware of the max voltage option on Zimo (CV 57). My concern was that increasing the track voltage might mean having to reprofile all my locos.
  2. I recently upgraded my DCC system, replacing Lenz command station for the Roco Z21. The Lenz had a track voltage of 15v whereas the Z21 is 20v. I therefore set the Z21 booster voltage to 15.5v as this seemed to be the best match taking into account occupancy detectors etc. But a few of my locos now seem a bit slow. So what track voltage do people use as 20v seems a bit high? My layout is OO gauge.
  3. Well finally got the Z21 to downlevel the firmware but it was a bit of a struggle. I've had to set up a piece of rail close to the Z21 with wires only a couple of feet long. Now a Hornby T9 with Zimo MX600R works, but not the Bachmann EMUs. For these I've had to take the decoder out and put it in a Bachmann C class which has a 21-pin decoder in the socket. I assume the Z21 doesn't like anything with lighting circuitry, but I did flash them all first time around without having to do this! I originally bought 7 MX600Rs a few years ago and all had 31.63 level firmware. The earliest I'm able to go back to is 37.1 as none of the Zimo download files have the MX600 on them. With 37.1 installed the T9 now performs perfectly! Stops in the right position every time, whether running long or short schedules. Then I tried to do a bit of detective work for Zimo to see what version introduced the problem. With 37.8 the T9 overshoots the stop marker, with 39.0 it stops up to 25cm short and 40.1 is basically the same as 40.5, ie OK on the short schedule but stoping 10 cm short on the long. I've since flashed the two MX634Ds in Bachmann 2-EPBs back to 37.1 and these now work fine too. Stephan from Zimo did come back to me and say the best way of limiting max speed on their decoders is not to use CV 5 but instead use CV 57. I did try this while still on 40.5 and it did improve things. I set CV3=0, CV4=0, CV5=1 and CV6=1 and then found that CV57=70 gave a top speed of 70 MPH which is the most I need. On the schedules, they were OK on the short but overran about 2-3 cm on the long. That's quite acceptable and I will stick with that with the 4-CEPs as I really don't want to take their bodies off too! But I prefer the 2-EPBs on 37.1 as they seem more accurate. This was the profile from the 2-EPB using CV 57=70 on 40.5 firmware: Compare this with my other 2-EPBs which have Lenz Silver21+ decoders - A more even profile it seems to me. Still toying with the idea of getting a couple more Lenz decoders for these. Seems Zimo have been making changes to Back EMF and motor control and these are causing the issues. The Lenz firmware is the latest with version 14 which has a build date of September 2011. Seems like Lenz got to this version, found it was OK and have left it alone since. I have 85 locos altogether - 10 with Zimo and 75 with Lenz. Just glad those numbers aren't the other way round!
  4. Whenever I buy anything new these days that has firmware, I make a habit of updating its firmware straightaway if it's not current and updating is possible. Bought a new TV last month for our kitchen, and sure enough it was 2 levels down on firmware currency. Somewhat amazed that the download file was over 500 Mb just for a TV!
  5. After a full week, I'm still waiting for a response from Roco regarding my inability to upgrade decoders with a lower level of firmware. But I have found an issue which may be relevant. I profile my locos using 3 consecutive blocks with occupancy detectors. The measuring block is 75 cm and the run-in/run-out blocks are 60 cm which is long enough for the loco to reach max speed for the speed step being measured as long as F4 is turned on. I re-tested one loco (actually a Bachmann 2-HAP with MX638) for just the top speed step 126 and TC records the speed as 69 MPH consistently. However, if I move the train a long way back (at least 5m) so that it has a long run to reach the measurement block, TC records the speed as 76 MPH. Again this was consistent over several runs. The recent changes to CV 5 handling in Zimo firmware, which resulted in my having to reprofile all of my Zimo-fitted locos, looks like being where the problem may have arisen. I will respond to Zimo shortly and see what they say.
  6. Thanks for that. This is how I see the problem. I've created a simple TC switchboard below that contains just the 3 blocks and two train definitions so I can run this as a test with nothing interfering. The two engines are identical Bachmann 4-CEPs, 7113 with a Lenz Silver21+ decoder and 7141 with Zimo MX638. The two schedules are shuttles - 2block is a shuttle between the station block on the right and the previous block, and 3block goes one block further back. The 4-CEPs are 42 inches long and all 3 blocks are at least twice that so there's no problem with the units getting to speed before moving to the next block. Max speed is set to 40 MPH for the test. 7113 stops at exactly the same point on return to the station on both schedules, but 7141 only does that on the 2block schedule. On the longer 3block schedule it stops 10-12 cm short. I have 8 Zimo-fitted locos on 40.5 at present with MX600R, MX623R, MX634D and MX638 and all do exactly the same. Identical Lenz-fitted locos do not exhibit this characteristic. So I'm waiting to see if it's possible to downlevel the firmware before I can take it any further.
  7. Don't know when the change occurred. My MX600Rs were 31.63 and my MX634s 36.5 before I updated. Just need to be able to download again to see when the problem occurred. I've looked through the Zimo changelogs and can see nothing relevant, but then this big change to CV5 that Stephan describes above is not mentioned either, hence my surprise that I had to reprofile all my Zimo locos. Fortunately that's only 10, as my other 75 all have Lenz decoders. Perhaps we need to continue this discussion on the other thread so things don't get duplicated?
  8. Yes - after reprofiling them they ran OK. One of the tasks with Traincontroller is then to adjust the brake compensation, so that the loco always stops precisely at the stop marker. Having done this and been pleased with the result, I was then surprised that when the locos ran on schedules they sometimes stopped short. Therefore my suspicion is that BEMF is coming into play, and perhaps the sampling is giving varying results depending on how long the loco has been on the move. Now just waiting for Roco to respond and explain why the downlevelling always fails.
  9. Below is the response from Zimo (Stephn Hubinger) regarding the need to re-profile. He explains this was for the MX600 but I had to reprofile all of my Zimo decoders. The MX600Rs were 31.63 and the MX634s 36.5 so it must have been after that, so I don't know whether the change was before version 39. I'm able to reproduce the problem simply using TC's drag-and-drop: if it's a short journey over a couple of blocks the trains stop where they should, but a longer trip over 3-4 blocks and they stop short. Would be nice if you were able to reproduce that. "Yes, please test … but for the MX600-series it is clear for me why and the re-scaling of CV#5 with the current software version for the MX600-series is not counted as bug, it was intended by ZIMO - so EVERY (!) customer how uses TC profiling AND has a MX600 in the loco has to re-perform the profiling after the MX600-update, before he/she should start testing again. The MX600-series was (and partly still is) differently as any other comparable typically ZIMO decoderseries, because the design aim was to make a "affordable" ZIMO decoder - so cuts have been made regarding hardware (so cheaper/slower processor on board, no logic level outputs,…) and software (no motorola, no SUSI, no servo support,…). With the update to 40.5 it gets some features (so processor clock is doubled, more RailCom messages) … so ZIMO has decided later, that we give the MX600-serie (via free software update for the customers) some features, which all other typical ZIMO decoders have to close a little bit the gap to the other series … that includes the re-scaling of the max. speed also (so same CV#5 value in a MX600 with 40.5 is leading now to the same speed as the same CV#5 value in any other ZIMO decoder series (regardless of the software version it has loaded, so older like 37 also count) … that was not the case for the older MX600-software versions (so before the CV#5 internal scaling of the MX600 was different to any other ZIMO decoder series - now (with 40.5 loaded in the MX600) all ZIMO decoders series have the same CV#5 internal scaling)."
  10. This is the issue - https://www.rmweb.co.uk/community/index.php?/topic/166751-zimo-decoders-traincontroller-and-accurate-stopping/
  11. Because of a possible issue with the 40.5 firmware level of Zimo decoders, I'm trying to revert a couple of my MX634 decoders back to the level they were at, namely 36.5. But all attempts fail with the error message - "Error: decoder does not respond to any start-byte of the list". CV8 is 145 for Zimo, CV144 is 0 (unlocked) and CV250 is 240 (start-byte for MX634). Trying CTRL + ALT +Z is also unsuccessful. The decoder is in a Bachmann 2-EPB and the unit's lights come on during the process, so contact is not an issue. I have also tried with a programming track connected directly to the back of the Z21 with very short (50cm) wires. Again no joy. So has anyone managed to downlevel firmware using the tool? It even fails trying to re-flash 40.5. I have been talking with Zimo but they do not know why the Roco tool does not work. I have raised a case with Roco. This is the log:
  12. I think the decoder is just as flush with the roof as I could make it. I don't think it's in the smokebox. The roof is plastic so no risk of shorts, and the underside has no contacts to cause problems. One option is to remove the the wires from the decoder for the lighting to reduce the bulk of the harness, as this is often what causes difficulty. I did take the lid of one of them a few months ago to remove its capacitor (it was causing my Hornby 71 to behave oddly!) but I can't remember exactly how it looked except it was a tight fit getting the body back on .....
  13. I have 4 of the WC/BB rebuilds and all have Lenz Standard+ decoders. I agree they are a tight fit but I managed to fit this decoder in all of them, although one is a later version that thankfully has the decoder socket in the tender! A few years ago now, when the £/€ exchange rate was quite favourable, these decoders could be purchased from German boxshifters for around £12.50 each and I took the opportunity to fit these in all the models I had that would take it. I even have them in a couple of M7s, though hardwired with the decoder in the left-hand tank position. I sold all the decoders displaced on Ebay, and all went for more than £12.50 each which was very pleasing.
  14. That's exactly the problem I had with mine many years ago and why I replaced these decoders with Lenz Standard+. Using Traincontroller measuring, it recorded the loco at 81 MPH st speed step 28, and 87 MPH at speed step 26. It was the poor implementation of the Back-EMF that was the problem. Whether that's been resolved in later firmware I don't know.
  15. Spent some time this morning trying to downgrade the firmware and cannot get it to work. I have MX600R, MX634 and MX638 deocders, and although the MX634 is not an official Roco one, the other two are. When the update fails, I uncheck the "CV Verification" box and hit ctrl+alt+Z but it still comes back and says the decoder is not supported. Tried also using the 1.5 maintenance tool, and downgrading the Z21 firmware to 1.40 from 1.41, again with no success. I have asked Zimo for comments on why the decoder performance has changed, and I will now ask Roco why their Maintenance Tool won't work for me.
  16. It was actually profiled using 128 speed steps not 28, but TC always displays as if it were using 28. This often results in a display of the profile that is not as smooth as it actually is.
  17. No it does not waste speed steps. By setting CV 5 to the maximum speed you want for the loco you then get all 126 speed steps to use. I don't use the TC line-up function - it's far too slow as it moves trains at threshold speed (it was designed for a stack of locos not trains). What I meant to say was 2,3 or 4 trains per storage road: there are separate blocks for each, and when one train leaves the rest move up automatically. I will edit the original post....
  18. Indeed Lenz seem much simpler. This is the other 4CEP I've been using in testing which has a Silver21+ decoder. CV 5 is 180 and CV 6 is 48.
  19. 85 is just the default. When you profile a decoder, the process will end once it reaches 85 even though it's not got to speed step 28 or 126. None of my locos are allowed above 70 MPH as anything above that speed looks quite wrong, and results in the train being signal-checked before being allowed back into the storage yard, as all roads are shared with 2,3 or 4 trains per road using separate blocks.
  20. Yes that is what I had to do with the MX634s to update them to 40.5 in the first place. But now this does not work when trying to go back to 36.5. When the error box comes up, I clear it, hit ctrl + alt +Z, the update starts again but then the error box comes up once more. DC running is off in all my decoders and I verified CV144=0.
  21. The speed profile of the 4CEP looks like this - Actually done with 128 steps but TC seems to always display as 28 subsequently. I prefer to have a nice steady transition, so to get this speed profile I first test max speed and reduce CV 5 until it runs at no higher than 70 MPH. I then measure at speed step 63 and adjust CV 6 until it runs at about 30 MPH. This gives good peformance with TC. Here CV 5 is 120 and CV 6 is 80. The problem with the Z21 is it only updates automatically Roco-recognized decoders. The MX634D is not one of these but I do have one 4CEP with MX638 which is OK for the Z21, so I'll try that on 36.5 tomorrow and see what happens.
  22. Several of my MX600Rs were level 31.63 which is quite old, and I do prefer to have any firmware at the current level. I was not expecting the upgrades to cause any problems though! I have tried to revert a 2EPB back to 36.5 but I can't at the moment get it to work. When upgrading with the Z21, I had to press CTRL + ALT + Z to override the checks and indeed that worked fine. But this technique now does not work installing back to 36.5. I have emailed Zimo with the issue and asked them if there's anything I need to do to regress. Thanks for your comments and I will report back when I hear from Zimo.
  23. Best DCC practice for anything but a small layout is two wires to every piece of track, regardless of whether you are using automation or not. This is also something that Railmagic have not grasped with their claim of being able to return to just two wires to the track.
  24. Having recently upgraded from Lenz DCC to Z21, I’ve been able to update the firmware of my Zimo decoders, all of which are now 40.5. But I’ve had a couple of problems. Firstly, my 4 Bachmann 2EPBs with level 36.5 thereafter started overrunning the TC stopping points – by around a coach length. And all 4 did it and in all blocks. So I was forced to reprofile them all, after which normality returned, or so it seemed. I check the accuracy by running reprofiled engines on a shuttle between the main station and the previous block, to check when they re-enter they stop at the correct point. They all did. But when subsequently entering the same station block on a schedule they all pull up short by at least 10cm. And consistently. Using the following 3 blocks I set up 2 shuttle (there and back) schedules: first from station to transit and back, and the second from station via transit to yard and back. On the first the units stop correctly, and on the second they stop short. I tried my other Zimo-fitted engines (all of which also had to be reprofiled) – 2 Bachmann 4CEPs and 2 Hornby steamers, and they all do the same. 2 Bachmann 4CEPs with Lenz Silver21+ decoders don’t exhibit this characteristic. Seems to me something to do with Back EMF, but all my Zimo-fitted locos use standard decoder defaults. Is it perhaps sampling over a longer run that is the issue? I did try running one 2EPB on the 2-block schedule, and when it reached the stop in the transit block, I pulled it back a couple of feet to lengthen its return . Sure enough it arrived back at the station and stopped short. So it looks like the longer run is the issue? The CVs for Back-EMF are complex, involving CVs 9, 10, 56, 58 and 113 amongst others. I've tried tweaking various of these but cannot eliminate the inconsistent stopping. Any Zimo experts in the house?
  25. We're still very much in the dark as to exactly how it works. But we do know it also relies on Back-EMF data from the motor, hence why the tracker has to be connected to the motor terminals. This is to give Railmagic an estimate of how far the loco has travelled, presumably between magnets, data that is then fed back to the Trainiac. Given that he has also revealed he has had problems with inaccurate data from Back-EMF, and therefore is going to design his own decoder with tracker built in, we have to wait and see how accurate this positioning is. Traincontroller and iTrain tracking is extremely accurate using "dead reckoning" so I think Railmagic will have a challenge to match that.
  • Create New...