As I mentioned in the other post, I received my new NCE CAB-04p throttle and UTP panel in the mail today and now have had a chance to use it. I was originally just going to add it to the NCE Power Cab: A Quick Look review thread but thought it might be better to make an entirely new thread so that you didn’t have to wade through pages and pages just to get to this portion.
Using an extra throttle with the NCE Power Cab
Click picture to enlarge
As you can see, this particular throttle uses a potentiometer to adjust the locomotive speed – hence, the “p” in the model #. The throttle is simple to use, lightweight and easy to hold. The potentiometer knob is at least 1” OD. (NCE also makes a CAB-04e, if you prefer an encoder over a potentiometer.)
According the manual, the CAB-04p comes “shipped from the factory with the address of 5”. There was some discussion earlier on this thread about how a throttle is used in conjunction with the Power Cab. In order for any throttle to work successfully with the Power Cab, the throttle has to have an address of “3”. Before I got the throttle, it wasn’t very clear as to how you would go about doing this. Thankfully, using the Operational Manual that came with the CAB-04p, made set up easy and straightforward.
For those interested, here’s the step by step process for setting up the NCE CAB-04p to use with your Power Cab. (The following steps were originally written for use with the NCE Power Pro command station. I’ve added [comme
Yes. At least the way the PowerCab is set up to run when NOT using the 3A booster, you can only run one (1) additional throttle and it has to be set to address “3”. WITH the booster, I believe you can use up to 3 additional throttles with the Power Cab.
NCE have had an interesting dilema in attempting to go after the entry level starter system market. How do they gain market share with a system designed to compete with the Digitrax Zephyr without sacrificing the sales volume of the presumably higher profit margin Pro systems? Some of the limitations that have been discussed were clearly imposed to ensure that there is a reason to still purchase the higher end systems. This is a fine balance, and a problem that I think that they have faced quite well. The PowerCab is sufficiently different from the Zephyr in design (walk around V console) that some of the limitations, Volt output, # trains controlled will likely not be deal breakers. Yet the ProCab clearly offers advantages over its new baby brother giving good reason to spend the extra dollars in future. The last thing they needed to do was to make the Powercab so good as to capture the bulk of the Procab business. Good luck to them, I hope they do well with it, and in turn encourage Digitrax, my supplier to keep on improving and developing as well.
Those are some VERY astute conclusions you have developed and, I believe, are right on the mark. [tup] Good, healthy competition and product development will always be good for the future of any hobby. It’ll be interesting to see where things go from here…
Thanks for clearing that up. [:)] I’ll have to admit that that bit of new news (echo, echo) is somewhat disappointing to hear. Even so, the inability to recall more than 2 trains on the Power Cab is only a minor shortcoming to me. No DCC system is perfect, and this is just another good example of why that’s so.
Yes, it is a bit of a shortcoming, but I look at it like this.
The powercab was designed as a starter system, not something to replace their powerhouse pro system.
It was designed with small layouts in mind- thus the 1.7 amp limit.
Most small layout designs don’t support running 3 continuous trains. That’s maybe why the racall stack design was limited to 2 instead of 3?
Being a handheld system, you don’t have to buy a handheld throttle just to follow and control your train. That in itself is a nice selling point for a starter system.
All in all, I love mine. I can and will incorporate it into the powerhouse pro system when I buy it. Now I just need to learn more so I can use more of the functions the powercab has.
I’ve run across an interesting anomaly of late when using my new NCE CAB-04p throttle with my BLI “Light” Mike. It’s somewhat sporadic but happens most often within the first few minutes after my Power Cab has been turned on.
(Picture supplied again for clarity)
At idle, the Mike sits there chuffing away, as it’s supposed to. The CAB-04p throttle only has a button for the horn so you have to use F0 to turn on the headlight. A couple of times now, when pressing F0, the coupler noise sounds but no headlight. A second press of F0 will then turn on the headlight.
Another time, the Mike was cruising around the layout. I distinctly pressed F7 for the break squeal and the sound muted or cut out. (Like pressing F8.) This has also happened a couple of times now. Unfortunately, I haven’t been able to really see a pattern so far, other than it happening within the first few minutes after I turn on the Power Cab. I also haven’t seen this particular problem happen when using my Power Cab as the throttle.
Has anyone else run into these anomalies before using a NCE throttle?
I found out from someone a few days ago that the above “anomaly” has nothing to do with the CAB-04p throttle but with the BLI QSI decoder. I haven’t run across it in the literature yet but this particular quirk is supposed to be mentioned in the Troubleshooting section of the manual. I plan on updating to the new QSI update chip that is due out. Perhaps this will be/has been addressed with the update.
Not sure what the deal is there, it doesn’t happen on the M1a. If it only happens from the Cab04p and never from the PowerCab I don’t think it’s a QSI anomaly.
Here’s the complete response from Mark over at the Yahoo NCE-DCC forum:
[quote]
QUOTE:
Short answer: It’s not your Cab04P that is causing the problem.
Long answer: This is a very well know BLI problem. It is discussed in Appendix
III Trouble Shooting of the early BLI manuals. (may be in the newer manuals also
don’t know -don’t have one.) Here are 2 sections right out of the manual.
Problem: My headlight does not come on when I start my engine out but
mysteriously comes on whenever I blow the horn or turn on the bell. also, if I
try to turn on the headlight, it requires two pressings for the F0 or FL key.
Answer: Pressing the horn button of toggling the bell will cause your command
station to send out a Function Group One command, which contains the lighting
information. Not all command stations automatically send this information unless
a command is requested for that function group. Regarding turning on the
lighting with the F0 key, the toggle for the light may already be on at the base
station but not sent. When you press the F0 key, it toggles the lights to be
off and sends that command. It takes a second press of the F0 key to send
another command to turn on the light.
Problem: My breaks, bell, air release, or other sounds come on sometimes for no
apparent reason while operating my locomotive.
Answer: See above. Some functions may already be turned on but not sent. When
you request any function, the entire function group that contains that function
will be sent and this may trigger other features already enabled within that
I don’t have any first-hand experience with this loco/DCC system combination, but Mark L. seems to be contradicting himself. First, he says:
But then he goes on to say:
…and…
So first he says it’s a BLI problem, but then he says it’s because the command station isn’t sending the command until an additional command is requested!
Well, if the command station isn’t sending every command when it’s requested, then IMHO it’s certainly not the loco’s problem.
I double-checked the most recent Quantum DCC Reference Manual (v. 3.0), and what Mark wrote can be found on p. 151, under Appendix IV. The manual is dated “16 February 2005”.
However, Mark L. said it was “a very well known BLI problem”.
He also said, or apparently quoted the BLI manual, to the effect that some command stations queue at least some commands instead of sending them immediately.
And, in reading between the lines of the (quoted from BLI?) explanation, it seems that unless you request certain other functions, that original command may never be sent out. Or if it is sent, to use their example (F0 on/off), it’s immediately negated by the next command.
Seems pretty clear to me that the command station not sending out commands in a timely manner makes it, well, a command station problem.
After all, how can it possibly be BLI’s problem that their loco isn’t responding to a command that the command station never sent? Or that the loco responds to a command later, only because the command station sent it out later? None of that is BLI’s fault.
Therefore, my original comment that the two statements are contradictory still stands.