As I have said in several earlier posts I’m not a happy camper with DCC because of lack of power as compared to standard 12 volt DC. I have been told by several of you that my problem is incorrect programming. I have purchased the MRC computer interface and loaded the current JMRI software. My computer is an HP3500 PRO 3.3gb processor 16gb RAM and I’m running Windows 10 PRO.
That being said I managed to get the driver loaded and operating. I can operate my locomotives using the JMRI program so the interface is communication OK through my Prodigy Advance². My problem is I can’t get the program to write to a decoder, I receive error 306.
I have tried programming two new MRC 1730 decoders and one new Digitrax DH126 with the JMRI program. The Prodigy Controller works on all three decoders but JMRI will not!
I also downloaded the MRC software and it works . . . . The MRC program isn’t easy to manipulate and their operational instructions are terrible so I nee
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.
Thanks Mike! I have always programmed on the Main from my MRC controller and it has always worked. I switched to the programming track and now I have the JMRI working.
I’ll dink around with the programming for awhile and post the results.
Thanks again Mike!
Mel
Modeling the early to mid 1950s SP in HO scale since 1951
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
What puzzle me is the Op say he can operate his loco using JMRI, communication with the command station should be Ok then. It would be interesting to know what is in the configuration file.
Thanks guys, my problem was not using the Program Track on my Prodigy controller for programming. It doesn’t make any difference using my MRC for programming but it does for JMRI. I have the JMRI working but I’m having problems figuring out what does what.
My first problem after getting the JMRI working is that the reset command to factory settings doesn’t work on either the MRC or JMRI. I had to individually reset the CVs back to the factory settings manually.
Slow learning curve but I’m getting there.
Mel
Modeling the early to mid 1950s SP in HO scale since 1951
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.
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.
After the decoder stopped responding it now trips the breaker so something shorted internally during the programming cycle. While it was being programmed by the JMRI program there was a popping noise coming from the speaker, is that normal? At this point I’m afraid to attempt the second decoder until I talk to MRC.
Mel
Modeling the early to mid 1950s SP in HO scale since 1951
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.
I think the decoder just give it up, I had been working on programming it for more than three hours and there wasn’t any noise early on. I got brave and plugged in my other decoder ant it works OK.
When I’m dinking around with decoders I use a 27 ohm resister in series just in case and when it quit the resister was warm. I checked the current and it was drawing 180 ma and when I bypassed the resistor and it tripped the breaker.
Mel
Modeling the early to mid 1950s SP in HO scale since 1951
I talked to a tech at MRC this morning and when I ask him if one could ding a decoder programming it he said “yes”. I told him I was working on the speed tables and he told me that putting in the wrong values could cause major problems but he didn’t go into details of what not to do.
Anyone out there screwed up a decoder by programming other than me? That’s kinda scary! I had just hit the Write All Changes On All Sheets from the Speed Table when the speaker started popping. I didn’t make any changes to the JMRI defaults in the Speed Table. The decoder crashed before it finished loading.
MRC is going to replace the decoder but now I’m a bit wary about using my computer for programming.
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.
I’m not really into DCC yet even though I bought my Prodigy System about 10 years ago. I haven toasted a decoder yet unless this one was my fault. The decoders are pretty durable as far as I’m concerned. I’m overly cautious and I really don’t think this was my fault, I think it just quit on it’s own.
I’ve tried several manufacturers decoders without any success. My BB Athearn SD40-2 frames with cast metal Cary E7 bodies have at least twice as much power operating without decoders running on standard DC than any of my locomotives running on DCC.
I have two MRC decoders (old Brilliance series) in remotored Rivarossi Cab Forwards, one Soundtraxx also in a Cab Froward, a pair of Digitrax (no sound) in remotored Athearn SD40-2/Cary E7s, one TCS in a remotored Model Power E7 and one stock decoder (?) from the factory in a Bachmann 4-8-4 GS4. I also have a non sound Digitrax DH126 in a MDC Shay but that one doesn’t count because of it being greared down to a creep.
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.
I must have worded it wrong, the techie didn’t say that the JMRI dinged the decoder. He said that it was possible to ding one by putting in the wrong data. Actually he said that he didn’t think I dinged it and to send it back for replacement.
I had a heck of a time getting the JMRI program to work because I was using the Main Track output from my controller. It doesn’t make any difference using the MRC Prodigy controller but the JMRI is smarter than the MRC and wouldn’t work on the Main Track. When I switched it to the Program Track it worked first try. The decoder quit during programming the speed tables on the Programming Track.
The decoder I was programming (1730) isn’t in the JMRI list of decoders so I went with the highest 1700 series number in the JMRI list, 1716. I’m thinking the difference between the 1716 and the 1730 is the 17
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.
I want to thank you for your info, it’s always right on the money. I really would like to get a pair of the MRC 1730 decoders programmed correctly. I really like the DCC Sound and the pride of my diesel fleet is the pair of E7s that I’m working on.
I also use a known good and well tested locomotive to check out my decoders. Like I said earlier I’m overly cautious and sometime I check everything a dozen times before powering up a decoder in a locomotive.
I made me a DCC simulator for installing and checking locomotive wiring and I also use it for working on my locomotives with out a decoder. I’m sure that has saved many problems over the years.
