I think I've solved the issue.
1. Even though my track and wheels looked clean, they were not. I haven't had to clean the track for maybe 6 or 7 years now. I gave everything a good cleaning by hand with "odorless" (LOL) mineral spirits.
2 The DigiTrax PR3 seems to be part of the problem. As I became more proficient I guess I must have begun doing the programming proceedures faster & faster. That, along with some locos having more sophisticated decoders, taking longer to read, write and save the data, I think I may have been pulling the locos off the programming track too soon. DigiTrax says the new PR4 is much faster.
99 might actually be a jmri read error.
Most of the time it returns 255 when it can't read a register.
But cv1 is kind of special. Some command stations support 1-127 for short address. Some only support 1-99.
The dcs52 is agonizingly slow on the program track before it completes it's setup and reads. It's waiting for the decoders to power up I think.
What hardware are you using to read the values? And what mode?
Don - Specializing in layout DC->DCC conversions
Modeling C&O transition era and steel industries There's Nothing Like Big Steam!
I replaced my PR3 with a PR4 when it first came out, and I found it did work a lot better.
Since I can't seem to cut & paste to my own post, I'll just re-type the short version of what I wrote to BLI tech support.
As far as I can tell, the issue is two fold.
1. I haven't had to clean the layout track, or loco wheels in years. They "look" clean, but apparently there's enough oxidation at this point to interfere with consistent good conductivity.
2. With these particular BLI locos, all 3 Burlington E8, the road number board lights come on when the decoder is being written to, and then go off. If I don't wait for the lights to go off, AND do not save the changes before removing the loco from the programming track, AND do not change the Digitrax PR3 back to Interface Mode - before I remove the loco from the programming track, then sometimes, more often than not, somehow causes the loco address to change to 127, maybe because the PR3 is a little slow at completing its task with some decoders. Just my unqualified opinion.
I've read that the newer Digitrax PR4 is at least 3x faster, AND you don't have to manually change the Programming Mode back and forth between Program and Interface (mainline). It looks like Digitrax may have become aware of this issue, hence the PR4.
Why can't I copy and paste to reply to my own post? When I do, I get a "Forbidden 403" error
TEST
My experience with Paragon 2 decoders in SW7s isn't great. They are worse than any QSI decoders I've programmed. These SW7s had a max speed of 25 smph and ran well together so other than setting the address I've left every other CV alone. Playing with other CVs always caused other issues (I don't recall what they actually were) requiring a full decoder reset.
I would suggest you try and speed match using the 127 address. When that is done change the addresses back to 99 to see if they maintanined the speed match.
Upgrading your wire from 26 agw to say 18 or 16 would be a good idea but I doubt it causing this issue.
Peter
All NAND flash memory devices can lose their charge in as short as 10 years. That means they start forgetting what settings they had in the memory.
Modern day SSD/NVME storage controllers intentionally "top off the charge" of old cells to make sure the contents are not lost. (When powered on obviously)
Haven't heard from Arto since Monday. Anxious to hear what's going on.
Rich
Alton Junction
Yup, I also resort to trial-and-error in these situations. In at least one case, I thought JMRI changed the CV, to find out later that it hadn't. I think it turned out to be a CV29 issue.
JMRI is supposed to do that math automatically, but in some situations, it just would not work on some of my locos.
As a user of Digitrax decoders (among others), I also use the SoundLoader program. There is a tab to change CVs, which works on many decoders, not just Digitrax. I kinda remember a situation where that program worked, and JMRI did not. And like others have mentioned, I resorted to my DCC system to reprogram a CV, successfully,
Simon
Did you buy these Paragon 2 engines new, or used? I'm just wondering if a previous owner might have one set up in a consist. Paragon 2 uses CV19 and CV230 together to set up consists.
Maybe check that CV15 and CV16 are both zero. If they aren't, it could be the ID number is "locked".
Just to kinda "try everything", maybe set CV1 to something other than 99 (like 67) and see if it saves it and responds. Maybe try setting a long address and see if that works. See if it responds to 9967; maybe even try 0099 as a long address.
On some decoders, you have to change the CVs you want and then power down and then power back up to get the changes to take effect.
I would mention again trying to change CVs using a programming track connected just to your DCC system, rather than JMRI. I've had situations where DecoderPro would allow me to read and change all the settings OK, but then would screw up the ID. I would have to put the engine on a programming track connected to a Digitrax Zephyr to get the address corrected.
ArtoSelect loco 99 on the throttle. Loco powers up, sounds come on. But no throttle response. Prime mover sound is on but other sounds (bell, horn) do not respond.
That sounds like it's in a consist, make sure CV19=0 and that they aren't in a command station consist.
Arto I put the loco back on the Programing Track, JMRI CV tab, Read Full Sheet. Sure enough. Loco address changed to 127.
Is is always 127 that it changes to? I suspect that it's not actually changing, but that the command station is having trouble reading the CVs (not uncommon with sound decoders, especially older designs). The first thing I would do is replace the programming track wire, if the command station is having trouble reading the decoder, the long thin wire is not going to help.
Here's what I would do:
Arto Well, I'm NOT using a long address. And why should CV1=3, for any address? Using JMRI, on the CV list shown under the CV Tab, CV1=99, the address I use for that loco. On the JMRI "Basic" tab, "Short Address" is selected, Active Address=99, Primary Address=99. Extended Address=128 for some reason. And "Address Format"=Short (one byte) address. What am I not understanding?
Well, I'm NOT using a long address.
And why should CV1=3, for any address?
Using JMRI, on the CV list shown under the CV Tab, CV1=99, the address I use for that loco. On the JMRI "Basic" tab, "Short Address" is selected, Active Address=99, Primary Address=99. Extended Address=128 for some reason. And "Address Format"=Short (one byte) address.
What am I not understanding?
Okay. So all your locomotives have addresses less than 127? Most people run a long address. My bad. Disregard the changing of CV29 to long address.
Still look at CV19 when you find the locomotives don't respond. And sometimes CV1 will change when you advance consist. Especially if it is the lead or rear unit.
Pete.
Arto. Like now for instance. I put loco #9967 on the Programing Track. Read the settings from the JMRI Basic tab. It says Primary and Active Address is 99. Save and Close the JMRI window. Change the PR3 Mode back to Interface. Put loco on mainline. Power On. Select loco 99 on the throttle. Loco powers up, sounds come on. But no throttle response. Prime mover sound is on but other sounds (bell, horn) do not respond. I put the loco back on the Programing Track, JMRI CV tab, Read Full Sheet. Sure enough. Loco address changed to 127. HOWEVER....when I had the loco on the mainline and it wouldn't respond to address 99, I tried address 127, and got no response either.
Like now for instance. I put loco #9967 on the Programing Track. Read the settings from the JMRI Basic tab. It says Primary and Active Address is 99. Save and Close the JMRI window. Change the PR3 Mode back to Interface. Put loco on mainline. Power On. Select loco 99 on the throttle. Loco powers up, sounds come on. But no throttle response. Prime mover sound is on but other sounds (bell, horn) do not respond. I put the loco back on the Programing Track, JMRI CV tab, Read Full Sheet. Sure enough. Loco address changed to 127. HOWEVER....when I had the loco on the mainline and it wouldn't respond to address 99, I tried address 127, and got no response either.
What value is in CV29?
CV29=2 turns off long addressing. If you are, in fact, using long addresses, then CV29=34.
Edit Note: Are you using 2-digit addresses? 99, not 9967?
Guys....forget the QSI decoder for now. I've put that loco aside.
The problems I'm having now are regarding the Broadway Limited E8's, all Paragon2.
Something keeps changing CV values that I have not changed! I've verified this repeatedly. And there really isn't any consistency to what I'm seeing, except that the CV values keep changing without me doing anything. Oh, excuse me. The only thing consistent is the loco Address keeps changing to 127.
All of this brings up the question again, of whether or not the 10' long 26awg wire I'm using connecting the PR3 to the Programming Track is adequate
If I have to make ANOTHER (3rd) connection to the Programing Track, directly from the Command Station, bypassing the PR3 and LokProgrammer, this just adds yet another layer of complexity, works for some locos, not for others. I'm really getting tired of this. If things don't work, thats fine. But what is really bugging me is there is absolutely no consistency to what's going on.
I'll second what Rich said. I've had several decoders (not QSI) where it seems like Decoder Pro changed the ID when I was adjusting other CVs. I have a separate programming track hooked up to my DCC system, and using that to change the ID back would work.
Arto AND, now guess what (again)? I did a "Read All Sheets" with JMRI one of the locos that I'm trying to slow down using CV5 (CV5=190). It showed CV2=2 (should be CV2=1) and the loco address (CV1) showed 99. Changed CV2 back to CV2=1. I put the loco back on the mainline - no response. Put it back on the programming track, "Read All Sheets" again, and CV1=127 - address changed again! EDIT: Yep. Confirmed! CV1 changed back to 127 AGAIN. A repeat of what I posted above
AND, now guess what (again)?
I did a "Read All Sheets" with JMRI one of the locos that I'm trying to slow down using CV5 (CV5=190). It showed CV2=2 (should be CV2=1) and the loco address (CV1) showed 99. Changed CV2 back to CV2=1. I put the loco back on the mainline - no response. Put it back on the programming track, "Read All Sheets" again, and CV1=127 - address changed again!
EDIT: Yep. Confirmed! CV1 changed back to 127 AGAIN. A repeat of what I posted above
Arto OK, thanks Henry. CV29=2 (which is supposed to disable DC mode operation)
OK, thanks Henry. CV29=2 (which is supposed to disable DC mode operation)
CV29=34 should be used as the value to accept long addresses.
Well, now the other two Paragon2 are not responding on the mainline.
I'm at a complete loss as to how and why this is happening.
I guess that's probably why I stopped bothering to change CV except for the address years ago. I thought I'd give this a try again but this is insane. All the documentation is inconsistent and in many cases outright wrong or conflicting.
I have support ticket into BLI. But I suspect this is going to be an ongoing/reccuring issue. Right now I feel like getting rid of all this stuff for all the time I've wasted.
Arto.
CV1 should equal 3 if you're using a long address over 0127. Anything under that is considered a short address.
CV29 configures a few things. DC disable, Direction, long address enable, and speed step 14/28-128. Use a CV29 calculator to easily get the proper setting. CV29 calculators can be found online if you Google. Once you enable long address then the decoder will ignore CV1 settings. If the decoder is not responding. Look at CV19. It may have a consist address present. Sometimes for some reason will not clear CV19 when breaking up a consist. Some of my Paragon and an NCE will keep CV19 for some reason.
Arto It looks like CV29 is related to a lot of other functions.?
https://www.digitrax.com/support/cv/calculators/
Use the CV29 calculator. I have no idea why your CV's change themselves
Henry
COB Potomac & Northern
Shenandoah Valley
wrench567 Arto. Make sure you have DC disabled in CV29. As for the QSI decoder. Some had a magnetic read switch that was used for resetting. Sometimes they get accidentally reset during a derailment or going too fast into a sharp curve and I accidentally reset one with a magnetic uncoupling tool. Pete.
Make sure you have DC disabled in CV29.
As for the QSI decoder. Some had a magnetic read switch that was used for resetting. Sometimes they get accidentally reset during a derailment or going too fast into a sharp curve and I accidentally reset one with a magnetic uncoupling tool.
Pete, what value should I use for CV29 to disable DC? It looks like CV29 is related to a lot of other functions.
Arto, my bad. It clearly states in your second sentence that they are Paragon equipped. I just didn't originally read it carefully enough. I'll do better!
Arto This is sort of related to my QSI post. I moved on to speed match three BLI E8 Pragon2 locos.
This is sort of related to my QSI post.
I moved on to speed match three BLI E8 Pragon2 locos.
Sorry about the confusion. To be clear.......this thread I started is about three BLI PRAGON2 locos, not the BLI QSI equipped loco.
There are up to four locos I use in this consist. One BLI w/QSI, plus three BLI Paragon2. Obviously the QSI unit has way different performance characteristics than Paragon2. The QSi unit's top speed is MUCH faster than the Paragon2 units, so I tried to to reduce it's max speed first.
I decided to put the QSI loco aside for now, and focus on the three Paragon2 units.
Sometimes, when I change CV5 (using JMRI) on any of three BLI Paragon2 locos, the loco's address changes. I suspect that's what happened with the QSI loco described in my other thread/post.
When I put the loco back on the mainline with the changed CV5 value, it doesn't respond. Eventually I discovered the loco wasn't responding because CV1 had somehow also changed. The CV1 change does not show up on JMRI - UNTIL I do a "Read All Sheets". Then I can see what number the address has changed to. And it's always a three digit number. All my locos use the short two digit address. For all four of these locos (1 QSI + 3 Paragon2) the short address I use is 99 (all four units road number start with 99).
Hope this explains it better.
(PS: Chris, I agree with you. I avoid QSI equipped locos at all cost nowadays, and replacing the decoder is probably the best option)
EDIT: I don't know if this makes any difference, but.....FWIW
I have both a DigiTrax PR3 AND a LokProgrammer connected to the PC at the same time, PR3 on USB Com3, LokProgrammer on USB Com4. I manually change the wire connection from PR3 & Lok at the Programming Track. The PC is a brand new HP Windows 11 machine.
I beleive that some of the CVs won't hold their changes and revert back to default setting after either a period of running or after power down and power up cycles. Same thing happened to me with older Soundtraxx Tsunami's, which are every bit of "junk" as the QSI. Just a function of the technology of the era.
There is no doubt that the new Loksound V5 and Tsunami2 are better than their predecessors, but dealing with old technology can be rewarding too if you know the limitations.
I just keep the individual turbocharger and prime mover sounds turned down some on the QSIs so that the hisses, spurts, flange squeal, bells, and whistles/horns over power the PM. Which is probably more prototypical anyway.
- Douglas
Yeah, I realize that Rich. I just wanted to express why I was suggesting to Arto to consider replacements. In fact, my biggest issue with them is the sound file. One of my very first threads I started here 11 years or so ago was that the sound file, at least to my ears, sounds nothing like a diesel locomotive. IIRC, I think I mentioned it sounds more like a marine vessel engine. But at least certainly not an EMD nor an Alco. Motor control seems fine, now that I know the three CV sequence to reset it I can live with that, but the sound file . . . .