96RAF Posted June 3 Share Posted June 3 It has been reported that inability to control a loco after a profile swap or update can be due to CV19 (consisting address) having a random value other than the default value zero. This bug does not appear to be associated with any particular profile or decoder pin type. Could anyone who trips over this problem please confirm decoder type, what CV19 value was seen and if it was after a profile update (same profile) or loading a new profile. Any other information that may help track this bug down would be appreciated - e.g. track power type, dcc controller make/model - if used, long or short DCC address allocated, etc. Link to comment Share on other sites More sharing options...
Britannia Builder Posted June 3 Share Posted June 3 I've had one confirmed instance, documented in this thread: https://community.hornbyhobbies.com/forums/topic/34969-consist-cv19-changes-with-no-reason-on-hm7000-sound-8-pin/#comment-376830. Controller is RM/eLink. The SD066 profile had been installed a week or two earlier, so it didn't happen immediately after a profile install. It hasn't happened again since I reported it in March. Regards, John 1 Link to comment Share on other sites More sharing options...
Too Tall Posted August 5 Share Posted August 5 Confirmed instance, changing between BT and DCC, value of CV19 was set to 6, resetting to 0 cured issue. Link to comment Share on other sites More sharing options...
HST Mainline Posted August 5 Share Posted August 5 I have the same problem with changing from BT to DCC. Loco does not work on DCC. I will have a look at CV19 when I get home. Mine is the 21-pin decoder with Class 66 sound profile (the normal one, not the King Charles one). DCC controller: Märklin Central Station 3 Plus (latest update 2.5.0) I've also tested: Märklin Mobile Station (60653, 60657 and Mobile Station WLAN). Same issue. I use longer addresses; the loco seems to not pick up on address change via the app. Now with the knowledge of a potential CV19 problem, I am not sure if this is an actual issue. Link to comment Share on other sites More sharing options...
HST Mainline Posted August 6 Share Posted August 6 (edited) Okay, I got my Class 66 working on DCC. My CV 19 value was set to "19". I am not sure if that was the only thing I had to do. It was a bit stubborn, but in the end it worked. I have another decoder with the same problem, and I will try a more step by step approach on that one to see if I can find exactly what is needed. I also tried changing the addresses in the app, and it worked as expected, so I guess this was not an issue after all. Do we know if simply setting CV19 is causing the problem? Because it should not as CV19 is the multi traction address. Or is CV19 filled with "rubbish" data? Which kind of could explain it. Edited August 6 by HST Mainline Link to comment Share on other sites More sharing options...
96RAF Posted August 6 Author Share Posted August 6 1 hour ago, HST Mainline said: Do we know if simply setting CV19 is causing the problem? Because it should not as CV19 is the multi traction address. Or is CV19 filled with "rubbish" data? The test team has been looking at this and Hornby Tech has the answer, which is being tested on the 800 sound profile and proven robust. It is thought the problem is poor error checking in the NMRA spec leading to as you say 'rubbish' getting past the checksum leading to CV19 and previously CVs17/18 being populated with false data. The forum has previously discussed CV17/18 errors and how to compare written values with those correct values seen in an on-line calculator. The CV19 fix will be rolled out across all profiles in time. 3 Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now