In an earlier post today, you said that you are not using long addresses, but 9967 is a long address.
What value is in CV29?
CV29=2 turns off long addressing. If you are, in fact, using long addresses, then CV29=34.
Rich
Edit Note: Are you using 2-digit addresses? 99, not 9967?
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.
That sounds like it’s in a consist, make sure CV19=0 and that they aren’t in a command station consist.
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:
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.
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
Haven’t heard from Arto since Monday. Anxious to hear what’s going on.
Rich
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)
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
TEST
Why can’t I copy and paste to reply to my own post? When I do, I get a “Forbidden 403” error
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.
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.
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.
I replaced my PR3 with a PR4 when it first came out, and I found it did work a lot better.
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?
I think I’ve solved the issue.
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.