# Help programming LGB MTS decoders (and Massoth) with NCE Powercab



## ansleyl (Dec 27, 2007)

All,
I saw an old thread that tackles this problem but the solution didn't work for me. Last year I purchased 2 LGB Mikados, and also a Stainz with a powered tender, both with Massoth 8154001 eMOTION L decoders installed. All 3 of these, naturally, are defaulted to the address of 3 (with the tender being 72 per the previous owner). The good news is they all work with my NCE Powercab with booster, not a problem...well other than the functions are out of whack, but I can get them to work, I'll deal with that later if I can. I currently have just over 20 DCC locos, with all sorts of decoders in them, and they all work fine. 

However, I can't program these decoders. I was able to setup a consist with the Stainz and powered tender, and works fine with existing addresses. When I try to change the addresses, or use the CFG menu to change to 28 step addressing, or downgrade to 14 (becasue the Mikados are set to 14), nothing works. I saw a thread from about 10 years ago that said to turn the switch in the cab of the Mikados to turn off sound so the capacitors don't interfere with the programming. I've tried this, but to no avail. I also can't program the Massoth decoders in the Stainz or Tender. Any advice would be appreciated. I found a lot of info on this topic, and many say to use an LGB MTS programmer, but I'm not investing in one of those. Others say it worked when turning off the sound, but that wouldn't explain the Stainz and Tender either (but the tender does have DCC sound too).


----------



## Dan Pierce (Jan 2, 2008)

LGB bypasses the cab switch when the engines were upgraded by the user from the original DC only to DCC. When using the Massoth decoder check for the decoder to be 'locked' which will keep you from being to program any CV except the lock CV. For sure Zimo decoders have this feature and many others may have this feature also. CV 15 and 16 have to be the same value to 'unlock ' some Massoth decoders.


----------



## Greg Elmassian (Jan 3, 2008)

So, can you read CVs?


----------



## ansleyl (Dec 27, 2007)

Greg Elmassian said:


> So, can you read CVs?


I thought I couldn't, but I'll try again and let you guys know.
Ted


----------



## Greg Elmassian (Jan 3, 2008)

Please try on the "programming track", i.e. not the programming on the main.

With the PowerCab the entire layout becomes the programming track, so make sure no other locos or devices are connected to the track. If in doubt, hook the track output to (only) a short section of track.

You CANNOT read CV's when "programming on the main"

Greg


----------



## ansleyl (Dec 27, 2007)

Greg Elmassian said:


> Please try on the "programming track", i.e. not the programming on the main.
> 
> With the PowerCab the entire layout becomes the programming track, so make sure no other locos or devices are connected to the track. If in doubt, hook the track output to (only) a short section of track.
> 
> ...


Ok, I have some news, good and bad news, and a problem. I setup a program track with my new DCC++EX setup, since it has a separate programming track output. ie. It didn't require me to disconnect the wires from my DCC terminal strip I was using with my NCE system, and to the programming track from the main (sorta a pain in my setup).

So first, I tested the programming track and read a Piko Mogul I knew I could program, and it read all the CVs and added to my roster in JMRI. I tried some others too, but a known QSI Titan I was unable to read, also unable to read the decoder in my SD45 which I think is also a QSI (it talks when you set things). I don't understand, as I can program both of those on the main with my NCE. So I try both my small LGBs wihich have Massoth decoders, no luck. I figured there is no way the LGB Mikado that I can't program will work. But Viola, it reads all the CVs, I add it to my roster in JMRI. Then I was able to progam the address, FINALLY to something other than 3. I tried the road number of 4 digits, but found out it doesn't support 4 digit addressing, which I suspected, so changed it to 10 (last 2 digits of road number). The only other thing I did was try to change speed steps to 28. I thought I read that it will suppport 28. Then I went back to test, and yes address of 10 worked fine, was able to ring bell, toot horn (even though the function numbers are still messed up). However, it wouldn't go, either forward or backwards. I noticed JMRI says 128 SS on the throttle, but no way to change as I could ascertain. So go back to program track and switch it back to 14 speed steps, but still doesn't work! No forward or backwards. So, thinking maybe it's JMRI and my DCC++EX station. So hook my NCE system back up, still doesn't work. I then wen back to program track, tried resetting to defaults, and it took a while and seemed to write practially all 256 CVs (or all the ones it could). Address back to 3, bell, horn, and sounds work, still won't go on either DCC++EX or NCE command stations. I then try it in analog DC and it goes! That made me a little happy, but I can't get it to work in DCC. 

Any specific advice on what to change? I can program throught GUI in JMRI or simply set CVs. Also, I did notice that decoder seemed to have no speed table, nor voltage range for DCC in the GUI in JMRI. I noticed the PIKO decoder was set to voltages, not speed table. Did this get messed up somehow? I have zero clue what to try now. I was sorta ok with the way the LGB Mikado worked before, it ran fine in DCC but I could only use even speed steps or the lights went out, and the functions didn't map correclty, but they worked. I really just wanted address 3 to be changed, then speed steps if possible. Now I have no DCC operation! 

Any help or advice would be greatly appreciated!

Ted


----------



## Dan Pierce (Jan 2, 2008)

I had a programming issue the other day with a decoder. I figured out the current output in programming mode was too low. My system (Zimo MX10) allows you to change the programming current and when I increased this current my issues were solved. SO, be sure all lights/smoke /sound are off when programming and many largescale decoders are current hogs and need more than what the smaller scale DCC systems can provide.


----------



## Greg Elmassian (Jan 3, 2008)

My advice is to change your DCC system ha ha! Seriously, I have never had any issue reading or writing the large scale QSI decoders (revolution and titan) with my NCE or my Zimo systems.

Specifics:
"I tried some others too, but a known QSI Titan I was unable to read, also unable to read the decoder in my SD45 which I think is also a QSI (it talks when you set things). I don't understand, as I can program both of those on the main with my NCE. "


> >> of course, programming on the main is one-way, if the decoder is working, this always works (for POM available CV's).... the service mode is a lower voltage and current and supports readback. Any other loads across the rails like lights or other decoders, etc will cause problems. The service mode programming is also more touchy about timing. Poor quality DCC systems will have issues.



However, it wouldn't go, either forward or backwards. I noticed JMRI says 128 SS on the throttle, but no way to change as I could ascertain. 


> >>>you need to read up on the JMRI system, it is possible.


"So hook my NCE system back up, still doesn't work. I then wen back to program track, tried resetting to defaults, and it took a while and seemed to write practially all 256 CVs (or all the ones it could). "


> >>>> sounds confusing, if you hooked your NCE unit to JMRI and wrote ALL CV's this is what would happen... it is doing what you told it to do... why not just do a decoder reset? You seem to be getting overly complex, and not quite understanding JMRI.


"Also, I did notice that decoder seemed to have no speed table, nor voltage range for DCC in the GUI in JMRI. I noticed the PIKO decoder was set to voltages, not speed table "


> >>> it seems you have some fundamental issues understanding how decoders work. You should read how CV 2,5,6 work and how a speed table interacts.


I don't know why you are looking at speed tables before you actually have a reliable way of reading and programming in service mode.... you need a reliable system first. Then if you want to use the GUI on JMRI, you need to make sure JMRI has a good definition for your decoder.

You seem to have gone way down into the details before the fundamental operation of your DCC system and JMRI are working.

I'd back off and get it so service mode is reliable with your DCC systems... NO JMRI... I suspect you have wiring issues or decoder installation issues... if you cannot get service mode to work properly, pull the decoder from the loco and hook it directly (with a test motor) to the DCC system.

Get that working 100%, there is nothing wrong with NCE, JMRI or QSI...

Greg


----------



## ansleyl (Dec 27, 2007)

Wow, you completely ignored much of what I detailed, or maybe I left out some details?. The decoders all work fine. Except the LGB Mikado. I did do a factory default reset, maybe you missed that. Both the NCE and DCC+EX system work fine other than getting the LGB programmed. You can ignore my ramblings on the other decoders, I am able to program them to do what I want, just can't read them for some reason all the time. I've changed volume CVs and other settings like momentum on all my decoders EXCEPT the LGB, and 2 other Massoth decoders. I can fully read and see the CVs and program them on the LGB, my point is why won't it move in DCC now after changing two settings, the address and speed steps, literally all I changed and then changing them back when it didn't work, then tried a reset. My point of mentioning both DCC systems is that I ruled them out by using two different systems. I'm 35 year veteran of electronics and computer science and I know how to troubleshoot, literally was my career for 33+ years. Exactly why I tried the engine in 3 configurations to prove it's some sort of decoder setting which I'm unaware. I'm just not all that familiar with dozens of CV settings in various decoders, and since I know LGB MTS decoders are strange, is there something I should reset or try that I haven't? I will do another reset later today just to be sure. Also, the JMRI is with the DCC+EX system, not the NCE. Two separate completely independent DCC systems, and yes, completely disconnected and hooked up independently before anyone asks. I just happen to have a program track setup with the DCC+EX system.


----------



## Greg Elmassian (Jan 3, 2008)

Further reinforcing what I said about not getting the fundamentals to work.

Here is your statement from your post:
*"I tried some others too, but a known QSI Titan I was unable to read, also unable to read the decoder in my SD45 which I think is also a QSI (it talks when you set things). I don't understand, as I can program both of those on the main with my NCE. "*

So did you write this in error?

I understand English, it says you were unable to program the QSI in service mode. Am I understanding English properly?

Unless you deny or retract that statement, you have a *fundamental *issue with your DCC system in service mode, and I suggest you get that working before you go all over the place with more attempts at different functions.

If you cannot rely on the service mode programming, then I submit your DCC system operation is in question, and any other data "derived" from using it is worthless.

I have over 40 QSI decoders, they all read and write fine on my THREE NCE systems and my TWO Zimo systems.

I'm trying to help you, but I submit you are way too deep in "results" that cannot be relied on.

Please consider getting your fundamental DCC communications working first. I understand you are a 35 year veteran of electronics and computer science (I do have you beat numerically), but not everyone "gets" the nuances of getting reliable programming working. 

I could go into the fine details of what is wrong, but you need to go back to the beginning and get service mode working properly on your systems, otherwise you cannot trust the results, there are way more variables and gotcha's than you know now.

I would strongly advise using your NCE system on a dedicated programming track. Please also describe what system you have, 5 amp ProCab, 10 amp Procab, PowerCab without booster, PowerCab with booster, or some other permutation?

Greg


----------



## ansleyl (Dec 27, 2007)

I was unable to READ them, I was not programming them. I was testing to see if I could read them. As I said, not concerned because I've had no problem actually programming them before. I only posted that becasue I was actually surprised when I was able to read and program the LGB decoder. I had never been able to change ANYTHING on the LGB decoder before. EDIT: Yes, I plan on doing another reset and using a program track on the NCE.


----------



## Greg Elmassian (Jan 3, 2008)

YES!!!!

My statements stand, until you can read them (the decoders / CVs) , there is something WRONG...

Pull the decoder out of the loco, and determine if it is the installation or your DCC system.

Again, you want to go way further without the BASIC communication working.

Trust me, I am trying to help you, and I have been here before (your identical situation with many other people). I know how to solve this, but step by step will take you there fastest, not "I'm not concerned because ....". and then trying something else and it fails.

Right now there is most likely more than one issue stopping you from getting to your goal. We know you have a fundamental programming issue in service mode, let's get that fixed first.

Greg


----------



## ansleyl (Dec 27, 2007)

Ok, I spent some time 2 days ago working on this again. I setup the programming track with my NCE Powercab system, which consists of the Powercab feeding an MRC 8 Amp booster to the programming track only. First, I was able, with some experimentation and reading other forums about programming the LGB Mikado, to use register mode to program the LGB Mikado. However, could not read CVs. First I tested by changing loco address to 10 using register 1, and that worked. The Loco still won't go forward or back. Then, I used the LGB reset decoder codes (according to the LGB Mikado manual) of 55 into CV 55. To do that you load the contents 55 into register 6 (CV 6) and the CV into register 5 (I might have that backward), but in this case, they are both 55. I did that, saw the LOCO jump some, i twas actually very quick. However, after this back to address 3 but the Loco works! It goes forward/back. However, now none of the lighting works. Actually, not sure when the lighting stopped, but it worked before I started trying to program the loco last week. No headlight, no rear light, no cab light, no firebox in both DCC or Analog mode. I also did the reset again, just to be sure, so now I have this new problem. Have no idea what to do now. Now I have the Loco programmed to address 10, and everything else is working, except all the lights. I would understand maybe....if one of the lights was out, but all 4 of them? Strange.

Also, since my test layout is small, only about a 14 x 7.5 ft oval, I have the exact same behavior on the main as on the programming track (3 ft. long) regardless of which mode I use. I tried everything on both, that I mention above and below. ie. tell the NCE I'm on the programming track when on the small main. It is an oval with no switches or other connections. (one of the reasons I did this was to make sure the wiring I have running to the rails is not the problem, since I'm using two separate sets of wires)

About the programming track, sill unable to read CVs on 2 other locos ( I only tried two). Don't know why, not sure I've read any CVs in 10+ years but haven't need to until now. I've tried using my Bachmann 5 Amp booster (18V), my new Tam Valley 5A booster (24 v), and this MRC 8 Amp booster with 24.6v at power supply and 23.X(forgot the tenths) at the track. The only time CVs were read was when I used my DCC+EX system last week with the Tam Valley booster, but the programming track was running at only 16v 3A max power supply from the motor shield. With that setup I could read everything from one of my PIKO engine decoder (made by Sountraxx) and the LGB Mikaod decoder mentioned above, but not from the 3 other engines I tested.

However, I'm able to program settings on the main, or programming track now, on every loco I've tried. I can write CVs even though I can't read them. I've successfully written volume settings directly using CV and sometimes a few others. I don't typically have the need to program CVs. I only do it if there is setting I really need.

With all that said, I'm sure I was able to read CVs back around 2013-2015, before I moved, using the NCE Powercab with the Bachmann 5A Booster I have. However, the Aristo Pacific that I have a QSI Revolution (Magnum?) aristo socket installed, which I KNOW I have read CVs, is boxed up and I have not tried it in any of this testing. One of the Locos I've been testing on is an Aristo SD45 with "I think" a QSI decoder. Since I can't read CVs It doesn't return the manufacturer. It does talk when I set a CV, Momentum, Address, etc. The other engine I've been testing with is an Aristo RS-3 with a QSI Titan ET. I know this for sure as I have pulled this loco apart, and inspected the decoder, wiring, and connections. I also have the original manual from the original owner, with hand written info on the sound file, serial number etc. I guess the next step is to pull out my Pacific that allowed me to read CVs and see if it works. However, the only problem I'm really wanting to solve is now is to get the lighting working on my LGB Mikado!


----------



## Greg Elmassian (Jan 3, 2008)

It almost pains me to read this.

1. You cannot add a booster to the "programming track output" and still read CV's.... boosters do not allow readback THROUGH them.
2. A powercab changes the normal track output to a "programming track output" when you select "use program track" AND it is on the same wires to the track.
3. to use the programming track output and service mode on a PowerCab, you must run the output from the NCE "panel" (with the red light on it) DIRECTLY to the programming track.

So as I stated earlier, you have some fundamental issues to understand what you are doing when you are trying to use a "programming track" in service mode.

Take the booster out of the circuit, use a short piece of track connected directly to the NCE panel, select "use program track" on your PowerCab and then you can read CV's.

Turn any lights that have a separate switch off... NO BOOSTERS IN LINE when using PROGRAM TRACK and SERVICE MODE...

Greg


----------



## ansleyl (Dec 27, 2007)

Greg Elmassian said:


> It almost pains me to read this.
> 
> 1. You cannot add a booster to the "programming track output" and still read CV's.... boosters do not allow readback THROUGH them.
> 2. A powercab changes the normal track output to a "programming track output" when you select "use program track" AND it is on the same wires to the track.
> ...


As I said, I did not use a booster for the programming track on my other DCC system, and I got the same results. Also, when it did work, back in 2013-2014 I DID use a booster!

Ted


----------



## ansleyl (Dec 27, 2007)

ansleyl said:


> As I said, I did not use a booster for the programming track on my other DCC system, and I got the same results. Also, when it did work, back in 2013-2014 I DID use a booster!
> 
> Ted



Sorry, however, that's an easy fix to test. I literally move the wires 5 inches and bypass the booster.


----------



## ansleyl (Dec 27, 2007)

Greg Elmassian said:


> It almost pains me to read this.
> 
> 1. You cannot add a booster to the "programming track output" and still read CV's.... boosters do not allow readback THROUGH them.
> 2. A powercab changes the normal track output to a "programming track output" when you select "use program track" AND it is on the same wires to the track.
> ...


Also, why does it "pain you to read this"! I have 3 boosters, and non of the docs for them say ANYTHING about not reading back through them, so just how am I supposed to know this? I would suspect that a digital signal, I'm very familiar with digital communication, should easily pass back through a booster with simple filtering circuits that I'm surprised they don't have. (ie. the same way the strip off the DCC signal, then amplfy the voltage then combine the signal again, yes that's an oversimplification), they are not that complicated so it makes no sense IMHO that they wouldn't allow two way communication.


----------



## ansleyl (Dec 27, 2007)

ansleyl said:


> Also, why does it "pain you to read this"! I have 3 boosters, and none of the docs for them say ANYTHING about not reading back through them, so just how am I supposed to know this? I would suspect that a digital signal, I'm very familiar with digital communication, should easily pass back through a booster with simple filtering circuits that I'm surprised they don't have. (ie. the same way the strip off the DCC signal, then amplfy the voltage then combine the signal again, yes that's an oversimplification), they are not that complicated so it makes no sense IMHO that they wouldn't allow two way communication.


Of course, I understand you are "trying" to help, but my basic problem that I need fixed is ONLY with the LGB Mikado, of which so far, I've tried everything in other threads and forums, and yes, I've checked your web page, but you apparently want to withhold that information unless you don't know? Programming the LGB Mikado and my other 2 Massoth decoder is the topic of this thread! I can succeed now program the LGB. Yes, I understand getting my system to read CVs is something I should do, but I don't CARE about doing that so much as ALL my other 20+ decoders are setup the way I need them. I'm have limited time to fix this,due to my family and schedule, and I want to run this Mikado at an upcoming train show so I don't have hours and hours to spend on this. I suspect the lights may have been damaged, but I don't know how, so I might have to drive 120 miles to an LGB repair guy to look at them, but I'm trying to avoid that by ruling out settings first. The fact it doesn't work in Analog worries me though.
Ted


----------



## Greg Elmassian (Jan 3, 2008)

Sigh... I was going to try to write something helpful, but all I can say is you are deep in the details but have some fundamental misunderstandings / gaps in your DCC expertise and you are trying to beat your problems senseless with a lot of different experiments.

Now you try to insult me by saying I "apparently want to withhold information".

Insult accepted, I'm sorry, so please don't read my web site any more, and I will also stop trying to help you too since I am a bad guy witholding information and giving you bad advice.

Greg


----------



## ansleyl (Dec 27, 2007)

Greg Elmassian said:


> Sigh... I was going to try to write something helpful, but all I can say is you are deep in the details but have some fundamental misunderstandings / gaps in your DCC expertise and you are trying to beat your problems senseless with a lot of different experiments.
> 
> Now you try to insult me by saying I "apparently want to withhold information".
> 
> ...


My point stands, my problem was specifically programming the LGB decoder, but not once did you actually give any advice along that line, when I know you and others have experience doing this, since after searching again I found other threads that specifically addressed using paged or register programming, yet you never mentioned that once and you were part of that. You also completely ignored that I did have a direct programming track hooked up, using DCC++EX and JMRI, NOT using a booster. Then you insult me FIRST, by saying it "pains" you to read this. Then you post steps 1-3 AND another paragraph all saying a single point. Yet, not once did you address the LGB issue. Why even respond if you were just going to carry this on, without actually addressing the issue.
This is exactly why I don't post much on train forums, been in here since '07, because you get people who like to hoard information, and don't have the patience or respect to be polite. I've only been on Gscale.net for a short time, and have written many technical posts with info I've researched and experienced,and get tons of kudos for freely and openly sharing my knowledge, with kindness and understanding. Apparently, that's not how it works here, I apologize for wasting everyone's time. I recently got several compliments for being helpful and freely sharing my knowledge. Apparently trying to methodically explain a problem, and the process, is not acceptable by you.

Also, I've read many threads on programming track boosters, specifically because of problems programming decoders. Pardon me if I failed to remember they aren't the same as a normal track booster 

I would step back a little and work on your online persona a little more. All the experience in the world isn't great if you're trying to help others and you come out insulting someone with a frustrating problem. I've been on forums and internet since '94, seen this too many times, I'll look elsewhere, apparently my instincts were correct after reading much over the years.


----------



## ansleyl (Dec 27, 2007)

Wait, you gave advice, one piece of useful advice, never said it was bad. Don't put programming track through a normal DCC booster, yes it was helpful, but....I had already done that, and specifically pointed it out early on. I don't know why you withheld info, which I discovered, but you did, your motivations are your business. I'm probably the most humble and polite person you'd ever meet, but I don't take kindly to veiled insults and arrogance. I've NEVER once insulted someone for lack of basic info or knowledge.


----------



## Greg Elmassian (Jan 3, 2008)

Not ignoring, just that the DCC++EX system does not have a good "track record" and is not as sophisticated at programming CVs as your NCE, so I did not respond because it's not as good a system. (if you want to argue this, please be prepared to PROVE it can do register, paged and direct programming and submit the waveforms from a scope, otherwise you need to take the advice of people with more knowledge)

Again you say "you get people who like to hoard information".... that is just preposterous, if they did, why in the heck would anyone try to help you? You are paranoid. Since you are doing character references, it's you that is defective, that you insist you have done all the right things to debug the system, and don't want to listen to anyone else.

Notice that you are the one with the DCC problem, not me, or the other people trying to help you.

Greg


----------



## FlightRisk (10 mo ago)

Greg Elmassian said:


> Not ignoring, just that the DCC++EX system does not have a good "track record"...


Hello Greg. I take exception to this. I realize discussions can get heated at times, but to disparage our efforts and present information that isn't accurate regarding DCC++EX, can give people the wrong impression. I am not sure why you have this opinion of EX, but I will guess that perhaps you are using old information about the abandoned DCC++ "Classic" Base Station and are not current on the DCC++EX Command Station. The command API and concept are similar, but it is a complete rewrite of the code. As a dedicated modeler yourself, I hope you can appreciate my passion in this response to you. You may see as I do that despite being able to snap your Command Station together for less than $50, there is incredible value in it.

The DCC-EX group is a team of over 20 dedicated professionals who continually update the software, test new hardware, and design new solutions. We have virtually 24/7 support on our Discord channel, with more through email, our website, and a Facebook page. While many of the over 1200 channel users (and growing) can answer questions, there is almost always a team member online, as there is now (in addition to me) as I type this at 12:24AM EST.

DCC++EX can read and write any decoder that adheres to the NMRA specification and most that don't. Rather than "dumb down" our system beyond even the wide latitude we do by default, we opted to allow settings to change parameters to deal with the decoders that are so wildly out of spec.

As a test, please do a page read in JMRI of a decoder in DCC++EX and any other system, time it, and compare it to ours. We have stats on our web page for those who don't have our CS. Several clubs use EX just as a programming station and SProg was so impressed they included part of our technology in their recent software.

I am not aware of another system that has full decoder diagnostics built into the Command Station to determine exactly what is wrong with the decoder and how to fix it. For example, we have all these things based on testing real-world decoders and their issues:

Get the baseline value of the resting current of a loco on the programming track then,
Intelligently test the loco by knowing the most likely values in the key CVs
Log the response or lack thereof to each "test"
Flip between read types on the fly. ex: is this byte 233?, no, "is bit 7 of CV 8 a zero?"
Time the rising and falling edge of the signal to read the pulse at the correct time
Interrupt the process as soon as we receive an ACK to speed up the system and also not miss an ACK
Measure the time it took the decoder to respond
Check the duration of the ACK pulse
Measure the magnitude (current) of the ACK pulse
Provide the number of samples we took to get the ACK pulse
Detect if there were any gaps in the ACK pulse
Use an interrupt driven high-accuracy waveform automatically if the hardware supports it to reduce jitter
Then with this log viewable live in JMRI or another device that can monitor serial output (the Arduino IDE or our WebThrottle-EX), we can change settings to deal with a decoder that for example gives an ack pulse of 25mA with a duration of 1900uS when the required standard is 60mA for 6000uS. We have also worked with decoder manufacturers to update their decoder firmware when we found these issues.

We develop updates to JMRI and Engine Driver concurrently with DCC++EX. With our built-in WiFi option, an operator can place a loco on the track, hit a button on Engine Driver, causing it to read the loco ID and automatically put it in the roster, then drive it off that track onto main without touching it again. This does not require a user to have JMRI. We call this DriveAway(tm). And Engine Driver, which is just one of many throttles that works with "CS-EX", recognizes its WiFi credentials and automatically displays it for you to connect to.

We can join our programming track to the main track by providing the DCC waveform to both when the programming track is not in use. This is similar to NCE except we don't require you to have to take all your other locos off the layout to program a loco, just drive it onto the part of your layout you are using as the programming track.

We introduced EX-RAIL, a simple scripting language anyone can learn, to use automation to control their entire layout. Imagine with no other software except your handheld throttle and DCC++EX, to be able to push buttons for predetermined routes and have your locos run them. The train drives the layout, not the other way around. Sensors detect the loco position and then actions or sequences happen around the track. You can have things run based on time or delays. Turnouts throw, signals operate, sounds play, crossings come down and the trains run themselves. Want to run the locos yourself? Move the throttle or do something else to send a command to a loco and it is now under your control. The other locos continue to run their routes and respond if you do something that would cause them to have to react. Get tired? Press the button again to handoff the loco to remote control. You can connect displays, I2C devices, and anything you can connect to a sensor or output pin on the Command Station. There are premade sequences for trolleys, crossings, and even arc welders simulated by LEDs.

You don't have to run the loco automation, you can just use it to automatically control all your accessories instead of having tons of controllers everywhere each just operating one device each. You can use DCC or you can use the devices connected directly to the CS interchangeably. You can even use the command station simply as an accessory controller to connect to other brands of command stations. Want it wireless? Use LCN nodes to control everything.

Dr. Geoff Bunza of MRH Magazine kindly wrote: "My sincere thanks to the DCC++EX team for their hard work, great ideas, and contributions to this hobby. In my professional opinion, they have done a fine job! And further thanks to the JMRI team for developing the environment and code which led to the Wifi throttles and interfaces that DCC++EX uses"

DIY and Digital Railroad calls DCC++EX "A game changer"

Tom's Trains and Things has created several videos just on DCC++EX

There is so much more like our ability to run DC or DCC on either track with potential to have many more than just 2 tracks, but I will respectfully just ask that you check us out and make a fair assessment of how we are positively contributing to the model railroad hobby and helping to make it accessible to everyone. It would great to have someone with your knowledge and experience be in our corner too. Who knows, maybe I can recruit you to be part of the team in an advisory capacity 

Sincerely,

Fred

Fred Decker
DCC-EX


----------



## Greg Elmassian (Jan 3, 2008)

I will admit I was unaware you did support more programming modes.

With such an eloquent response, I will re-discover DCC++EX, and will re-evaluate my comments. (Perhaps even build/buy one)

As a shortcut, could you please point me to documentation on where/how the various available service modes are called out. I see how to build it, and load firmware, but then I got to a part about throttles, and it's of course not specific, understandably.

Would JMRI have the most full-featured control of all the capabilities, or the Web-Throttle-EX? Do they specifically let you choose page vs register vs direct mode?

There are many decoders that are really finicky about programming, and I am always in the market for a system that supports several modes, the Zimo does this and you can control voltage and current in service mode (often an issue).

Thank you for your response.

Greg


----------



## FlightRisk (10 mo ago)

Greg, Thank you for the kind words.

Since we depend on a front-end like JMRI, Engine Driver, WebThrottle-EX, etc. a lot of the functionality comes in how they implement our API. The three I mentioned are under our control in that we change code for them when we update something for DCC++EX. We work with the authors of other programs to update their throttles.

Based on practicalities like trying to remain backward compatible with things like the Uno that have very little memory, and what we felt our market was, we decided to see if anyone would ask for one of the 20+ year old decoders that used Register mode or it's sibling, Paged mode. In the last 2+ years, no one has. So we improved our our algorithm that uses Direct Byte Mode to use intelligent guessing and verifying bytes and bits.

If you use a serial monitor or JMRI's DCC++ command window and the traffic monitor, you can manually execute commands like below. Throttles send either these or WiThrottle Commands (have 2 parsers):

<1> Power On
<D ACK ON> Diagnostics On 
<R 8 1 1> Read CV 8 (Mfg ID)
<R> Read the Engine Address (or any other CV's with <R CV>)

The log with ACK Diagnostics enabled shows the attempts made and when we are trying read a byte verify a bit or a byte, etc.

This is an example of our simple encapsulated commands:

<W 1333> Set the loco address to 1333.

The Command Reference on our WEB page shows all the commands, you can also use these:

<W CV> To write a byte to a CV
<B CV BIT> To set a bit in a CV

You can also use commands to send a packet with whatever information you want.

We have a lot of information on our web page, including the link to our GitHub where the source code is there for all to see. This page has a lot in it for JMRI. The "Comprehensive DCC++EX & JMRI Getting Started Guide" is worth reading. It is the first draft. We need to put it into our standard themeing. Any comments or corrections are always appreciated.






Documents — DCC-EX Model Railroading documentation


DCC-EX is a team of dedicated enthusiasts producing, easy to use, affordable, do-it-yourself, open source, DCC solutions to allow you to run your complete model railroad layout.




dcc-ex.com





We can adjust limits such as the max pulse duration, the min pulse duration, and for G Scale or other locos with large keep-alives in them, which usually pulls a bit more current than the NMRA Spec, we have <D PROGBOOST> to boost the Programming track limit.

If you want to drop in on use, you can always ask around or offer suggestions. Here is the invitation to our Discord:

Join the DCC++ EX Discord Server!

Fred


----------



## Greg Elmassian (Jan 3, 2008)

Thanks Fred, just "dropped in", will be gathering information to understand system better.

will add it to my pages of DCC manufacturers: https://elmassian.com/index.php/dcc/specific-manufacturers/dcc-ex

I have overviews of several other manufacturers there too 

Greg


----------

