My new layout will allow five trains to “run” at the same time - on dedicated display loops.
But I can only “operate” one train at a time, just like I can only operate one motor vehicle at a time…
But with ten other people, the layout will support the operation of 10 trains at once - one dispatcher, 10 operators.
I can assure you, that if I tried to keep track of more than one train, and switch back and forth to control them, or look at some touch screen on my tablet and remember which is which, there would be a crash…
Just another nice feature of my control system, even with a dispatcher and operators for each train, we will have ATC on the mainline, automatic train control, you run a red signal - your train stops.
So once again, DCC throttles FULL of features I would never use, and never want.
The Digitrax DT throttles are small and light enough to easily hold two in one hand (at least pre DT602, I don’t have one of those to try it with), one on top of the other offset so the knobs on the bottom one are exposed. It’s not something I do regularly, but I have on a few occasions to give me direct control, minus functions, of four trains, two per throttle.
And now it is apparent that my ESU Cab Control is not working as it should.
The problems are intermittent and random which indicates to me that the wireless controller is defective.
Sometimes it works as the manual indicates and at other times the unit responds completely differently. If you enter the same data in the same way and get different results then the unit is defective. Also, on reboot it drops locomotives that have already been entered. You can enter the same locomotive again and it will work, maybe. It also remembers locomotives that have been deleted without being re-entered.
I suggest you join the ESU groups.io or the facebook group as they are very active with a good many very knowledgeable members. Problems with that system seem to be pretty rare and usually end up being operator error.
Note - these groups have actual ESU and JMRI designers / techs on board so play nice.
the PSR club gave up using wireless for similar problems. i borrowed a spectrum analyzer from work and we discovered an intermittent strong signal occurring.
I don’t know much about wireless systems interference. I have a wireless router of course and recently added a booster.
I guess I could either try to run the ESU as part of my LAN or switch off the LAN wireless function and see if the unit magically revived in either case.
Mind you, our neighbourhood is packed with wireless LAN. My main LAN is hard wired.
And my simple 27 MHz throttles are rock solid at distances in excess of 100’…
OK, if you want all these extra features fine. But Charles Kettering was right, “parts left out cost nothing and cause no service problems”.
And the use of fewer different parts improves things as well. I have my throttles, my detectors, my relays, my power supplies, and my lighted push buttons - they make everything work.
The giveaway that it is a controller or ICU issue is the system remembers deleted locomotives and forgets entered locomotives. Suggestive that it reboots from a back up file of some kind. iPads and iPhones do the same as indeed will Windows.
Also it won’t be a range problem. The room is 12’x12’. I’m also only 4 feet away, maximum and usually even closer, from the ICU when I make data entries. Besides, once the locomotive is entered everything works just fine.
One odd thing is the ICU doesn’t “find” the mobile controller automatically on reboot. I have to select the refresh button, the same curled up arrow familiar from the browser search bars.
Are you deleting the engines properly ? It’s not by using the minus icon, you have to go into the Edit Locomotive screen to delete that entry.
As for the controller not finding the base, that’s likely because the base hasn’t fully booted yet. It’s basically a small computer, and like a home computer, it takes up to a minute to fully boot from being shut down. Give it a bit more time, then turn your throttle on and it should find it no problem.
Yes, I delete from the Edit Locomotive menu which lists the options available from “edit” through “create”, “delete” and “consist” down to “settings”.
Yes, I note the wireless connection isn’t retained when power is off. It seems to take longer than my other devices to connect to its special closed network, possibly because it is a special and closed network, not really a WILAN.
The system started working again later this morning.
It still won’t always address a new locomotive using the DCC address option on the programming track nor will it consistently read the address of any locomotive, whether entered (created)or not, using that direct access function. I haven’t checked any Loksound or Lokpilot locomotives yet by trying that function. The ESU decoder equipped locomotives all seem to behave properly.
The programming functions, either “prog on main” or “programming track”, do not work consistently. They neither read from nor write to a decoder (haven’t tried any ESU decoders for those functions yet).
I still don’t know how I got two QSI decoders and two TCS motor only decoders to enter but they did. Three only accepted two digit addresses and one TCS accepted a four digit address. One of those two LL8 TCS decoders won’t accept a four digit address whereas the other will. CV 1 only accepts two digit addresses so if the automatic addressing function isn’t working that’s just a nuisance to program the other two CVs.
The QSI voice read back function works while the ESU displays the message “programming failed” when it clearly succeeded. And so on. It’s all just weird.
I did get a Spectrum 4-4-0 to address automatically using the DCC address function to input its three digit road number. There’s no rhyme nor reason to it.
When I reboot, power up or just wake up the throttle unit the led power indicator on the left
While ESU products are amazing, their major pitfall are their manuals (even for their decoders). Some aspects are way too technical to be clear and other things are just plain not explained clearly if at all. That’s why I suggested the two groups above (apparently my links were a no-no and removed).
Once I had my ESU programmer up and running, the manuals became almost moot.
Yes, I’ve noticed that complaint elsewhere. Since the manual uses the very common Americanism “quicker” as an adverb I suspect some things are lost in translation.
I intend to test another idea. I happen to have three QSI equipped locomotives on track along with a couple of Soundtraxx equipped when I first switch on the Cab controller. I’m now wondering if the overload protection in the Cab Control system reads rate of current rise in the course of tripping the power rather than just total current. The QSI decoders all begin to generate sounds as soon as the power is turned on. ESU decoders do not do that.
Removing locomotives one by one and then powering up the track results in the red light turning green and staying green at some point. It may be that the Cab controller is fine powering up one or two sound locomotives but not three on initial startup.
It can’t be total current draw because the Cab controller is set for 5 amps and once the track is powered up I can rail more locomotives (one at a time of course) and they all power up and run just fine.
I do wonder why the power pack can deliver 7 amps max but the Cab Control max is 5 amps. Additonal current capacity headroom for when you add more Cab controllers maybe?
I honestly feel bad for you that you are having so many problems with that ESU unit. But, look where you are at. Spending all of your time trying to figure out why the ESU unit is so screwed up instead of running trains. Why should you have to troubleshoot issues that ESU should have resolved before prematurely introducing this product in the marketplace?
BTW, for all of the problems associated with QSI decoders, they do not begin to generate sounds as soon as the power is turned on, at least not on my layout.
Dunno, I just feel that you would be so much happier with a wireless 5 amp PH-Pro from NCE. In the 17 years that I have owned this unit, I have never experienced one single problem with it.
A little experimentation pretty much proves that the ESU Cab control overload protection is very capable. Maybe too capable when you have old fashioned decoders to deal with.
Testing various start up events reveals that QSI decoders draw too much initial current for the ESU. One locomotive is fine but add a second QSI equipped locomotive on track when you power up, or even one locomotive using another brand of decoder and one QSI equipped locomotive, and the overload protection kicks in.
Easy solution which I intended to implement anyway, since I dislike sound decoder equipped locomotives that startup by themselves as soon as power is connected. One thing I really like about ESU decoders is they do not do this.
I plan on parking all my locomotives that remain on track on unpowered sidings, I.e. switchable power, before ending an operating session anyway. Problem solved.
Newer decoders are not causing any difficulties. My Genesis GP 9 and my little Spectrum Atlantic both start up their sounds without overloading the current sensor in the ESU Cab Control. Non sound locomotives of course have no effect.
I’d be interested to understand whether the ESU overload protection is more sensitive than is usual for North American systems. Maybe you don’t need separate circuit breaker devices protecting power districts if you use the ESU.
The QSI decoders are also the ones that have been causing CV read/write issues. The other brands of decoders work fine with the ESU. QSI decoders accept coding but the ESU Cab Control says programming failed even though it succeeded. Might be QSI’s goofy voice read back of CV values confusing the Railcom software.
I note BLI still uses versions of these types of decoders. Not smart imho.
At present I have a Paragon 2 Pacific and a rolling thunder decoder equipped Mikado. Very nice models but with these problematic decoders. I also have Intermountain FP7A and two F7B with QSI de
Entered my newly acquired QSI equipped MP-15 DC today. Same weird inconsistent behaviour. Entered it as address 3 and it ran fine. Tried to change CV1 to 41 and got the weird voice confirmation “CV 1 41” and the “programming failed” message. Locomotive no longer responded to address 3 but clearly powered up. “Address conflict” oops. Went back and tried to change CV1 to 14 (open address slot) with no effect. Tried programming track and DCC address function. No success.
Reset to default using my Tech 6 (the ESU also wouldn’t reset CV8 to 8).
Went back to the ESU and the locomotive ran fine again under address three. Used Prog on Main to set CV1 to 14. Same voice confirmation and same programming failed message. Changed the address to 14 in Edit locomotive and all works fine.
The ESU Cab Control really doesn’t like talking to the QSI decoders. Maybe it’s because they talk back.
I am talking in Greek here because I am unfamiliar with the ESU unit, but what is the value of CV 29 when you are using CV 1 for the primary address? Bit 5 of CV 29 should be set to zero when using CV 1 as the primary address in QSI Quantum decoders.
Does the ESU system have a decoder setup mode for initially programming the address? On my Power Cab I use Programming Track mode and enter “1” for setup. It then displays the decoder manufacturer # and allows me to setup the short and long addresses. I then exit Programming Track mode and the locomotive moves on the preferred address.
If that is the way you plan on changing the decoder address, I would suggest cycling power (off then on) to see if the address takes. Some decoders seem to require a power cycle for changes to take effect.