You may want to first see what the track power setting might be in the PA2. Most DCC units default to ~14 volts. Usually, there is a command station setting that allows that to be adjusted down or up a few volts. I run my NCE Power Pro at 12.5 volts. If that setting is adjusted low, that could cause symptoms like dim lighting.
That said, one of the advantages of DCC is that full power is on the track at all times. The decoder acts as a valve to allow part or all of the potential voltage through to the loco's motor, lighting and sound. How much depends on settings in the individual decoder. With DC, you go from 0 to nominally 12 volts (actually higher, but let's not split hairs here.) The decoder is where you can make the adjustments that can provide whatever power settings you want as a maximum.
Are you trying to do programming track operations on the main? That could be one issue, as you may need set that up separately from the layout. Are the decoders sound? Doing the initial programming on them may require a programming track and possibly a booster to write the loco address. Not sure about how the Prodigy handles that. Usually, on the main only allows writing to the decoder, but you have to move to the programming track to read what is on the loco. JMRI let's you write to the loco, then store those settings so that you don't need to read them first before making changes. You make the chnages on the computer, then write them to the decoder, so there's no absolute need to read the decoder. The exception is when you want to enter a new loco and it's best to use the programming track to read what's in it to give your JMRI roster file what's on the decoder to start with unless you want to enter the default settings that JMRI has on file for that decoder.
Mike Lehman
Urbana, IL
Mel:
Did you check the JMRI site for the error codes? Error code 306 indicates some potential problems: V306 — timeout talking to command station
The program did not hear back from the command station when it expected to.
This is by far the most common error message when people first start using JMRI. In that case, it usually means that the connection to the command station isn't correct. This could be a problem with the cable(s) making the connection, or a problem with how the preferences are set. Picking the wrong serial port is particularly common.
Once JMRI is working properly, this error may occasionally happen due to a transient error. DecoderPro generally will retry it successfully in that case
Joe
EDIT: The above was taken from the JMRI site.
Jack W.
Mel,
Glad I got you moving again. Yes, it can be a bit of a learning curve with JMRI, but they are working on it. It's come a long way in the ~year I've been using it.
Remember to always hit Save when you've made changes in a roster file. That way they'll be there when you open it again later.
Edit Preferences is one place where you'll find lots of things that you'll want to adjust. The first thing you may want to adjust there is the the COM port settings if you still run into connection problems, as it should show whatever adapter you've used to connect to the layout and associate the correct COM port to it. You can also set up what you want on Startup, which can then automatically call up the right apps you need inside DecoderPro when you launch it.
MRC has a limit on which cab addresses can do programming. You might want to check that the interface and JMRI are set up correctly using a cab that is allowed to program - that would account for the behavior you are experiencing - ANY cab can run a train, which is why you can run trains with JMRI, but not program decoders. Yes, these 'simple' systems have some strange gotchas in there.
--Randy
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.
RR_MelI’ll call MRC tomorrow and find out what to do next. This isn’t helping my feelings about DCC.
You may find that in the end you are running into limitations of the MRC gear, not DCC in general. As Randy noted, the low-end systems have less functionality and may not work as expected, especially with sound decoders that take more power.
Dozens of layouts in the Bay Area run DCC (mostly NCE, as it happens) and trains could run much faster than anyone would want (who isn't drag racing). Lack of "top end" has never been a problem on any layout I've seen running a full-featured DCC system.
Good luck.
Byron
Layout Design GalleryLayout Design Special Interest Group
JMRI didn't cause the problem. JMRI only emulates a throttle in the system. You shouldn't get noises from the speaker when programming. Something was shorting - loose wire, or something.
A fumbled up speed table can cause major weirdness. Done it myself. But I can't see it letting the smoke out. It's good that MRC is replacing the decoder. They probaby want a happy customer and to find out what made them unhappy when they get yours back.
I've often thought I've toasted a decoder, but haven't ever actually done one in totally, although I have burnt up some lighting outputs a time or two.
MRC decoders are not known for their reliability. Programming wrong values in a speed table may cause some odd behavior in the throttle response, but it's not going to fry the decoder (or shouldn't). A system with a true seperate program track generally won;t fry a decoder even if the motor wires are shorted, the program track is very low current - that's why you shoudl test on the program track before putting the loco on the main. If it won;t program, something's wired wrong so you cna fix it before you hit it with full track power and actually fry it. I can;t imagine ANYTHIGN you could issue in program mode from JMRI or a throttle (remember, all JMRI does is emulate the throttle, it just pushes the buttons faster than you can) that could possibly smoke a decoder. You could accidently program a nonexistent CV which is actually used internally, causing the decoder to not operate, but actually fry the electronics? No. Using the decoder definitions in JMRI, it's very unlikely that an undefinded CV was programmed, most of the definition files in JMRI have been around for years and someone would have long noticed an invalid one. The only exception is in the single CV programmer aprt of JMRI, that's like having your throttle in hand and picking a CV number, there you cna enter anything. But if using the tabs in a JMRI definition - it will only set the CVs related to whatever it is you changed.
Bottom line - I think the MRC support guy is putting you on by saying it was something JMRI sent to the decoder that fried it.
JMRI will do Ops Mode (main track programming), you just have to select that option when you launch the programmer. But the program track is safer - you (technically) shouldn't be able to fry decoders there!
As for the not highly thought of comment, I meant the decoder. While the MRC DCC system may be just fine, their decoders have a completely different reputation. Remember DCC is a standard, so you aren't limited to MRC decoders because you use an MRC DCC system.
I've been a long time MRC DC user, but I've opened up some of their newer (80's on up) transistor power packs and I am less than impressed witht he internal build quality. It's never failed, so I guess that says something, but it's wires and components just hanging all over the place instead of neatly arranged on a circuit board. Hopefully the newer ones are btter - I have not opened up the 1370 I use to test locos before installing decoders. I also have a tech 4 courtesy of a "box o' junk" I picked up - mostly junk but it did have an Alco S2 (Roco version) and an Athearn BB SW repowered with a can motor, plus the Tech 4 pack - just those 3 things combined are worth more than I paid for the box. The rest is Tyco and Bachmann and Life Like train set level stuff and some dried out scenery materials, and a couple of Bachmann train set power packs.