The ProtoThrottle is a wireless model railroad throttle that mimics a standard EMD control stand including full detent throttle and reverser handles, a spring-loaded horn handle, a push-on/push-off bell button, and fully programmable front and rear headlights with a setting for ditch lights. It works with your existing DCC system and provides a realistic operating experience.
Tim Garland, a professional railroad engineer, has written an extensive narrative on prototypical operations as they relate to using the ProtoThrottle. Download a pdf of Tim’s article here.
No, not at this time. Due to the size of the mechanics inside the throttle, and for economy of production reasons, we settled on using the current enclosure with a 1.8 in. depth. Some find this size more than reasonable, but with the incorporation of the Lovehandle elastic strap, handling the throttle becomes very comfortable and easy.
At this time there are no plans to do so. The engineering investment required for each unique variation is large and cannot be justified at this time. However, the ProtoThrottle is open source, so you are free to modify or enhance the throttle to meet your specific requirements.
Due to differeing EMC regulations around the world, and the cost of accommodating all of them, we will only sell the throttle to customers in the United States, Canada, Australia, and New Zealand.
Iowa Scaled Engineering is committed to making open source hardware and software for the model railroad community. What this means is that we release the design files necessary to produce or modify our products – schematics, board layouts, and source code. Primarily this is a safeguard against obsolescence. But it also gives you the freedom to modify and improve our products, maybe in ways we never considered. For a more in-depth explanation of what open source means and why it should matter to you, please see our article here.
The range of the radios depends on the conditions in your layout room. If the radio signal has to travel through thick concrete walls, your range will be more limited than if you’re in a giant convention hall with wide open spaces. Here are the specifications from the radio module datasheet:
We are planning to use the XBeePRO, which should get well in excess of 100′ of range indoors, subject to your specific conditions. Always try to locate the receiver in a central location for optimal performance.
The ProtoThrottle is powered from two AA batteries. These can be standard alkaline or rechargeable NiMH. If using alkaline batteries, you will need to replace them when they run out. NiMH batteries can be charged, but not in the throttle. Many inexpensive chargers are available on the market, such as the following:
Yes. It’s not required to use the throttle, but Drive Hold can be used if you so desire. Typically, in this case, the AUX button is programmed to the Drive Hold function.
We get this question often. Since the ProtoThrottle receiver for NCE and Lenz is simple and straightforward – literally plug and play – why not the same for Digitrax LocoNet? Well, to set the record straight…
– A Non-Disclosure Agreement covering the full version of LocoNet (Items #3 & 4)
– The licensing fee is set only when you’re ready to go market (meaning you’ve already done all the hard work of actually designing and testing the product) (Item #6).
Honestly it’s not having a license fee that bothers us. We would be willing to just pass it along on top of the receiver cost. The NDA, however, would be completely incompatible with our desire to keep the firmware open source and user modifiable. It would mean the LocoNet interface could not be open source. Plus, having them set the license fee after everything is said and done rather than up front just rubs us the wrong way.
We’ve met with a few of Digitrax’s reps at shows, and they’ve run the question up the chain about even providing test hardware, but we’ve never heard a peep back. That’s fine, we’re a small venture and probably not even on their radar.
This is, however, in pretty stark contrast with Jürgen Lindner and Matt & Alec Herman at ESU and Jim Scorse at NCE, who have enthusiastically supported us and provided what we needed to make the ProtoThrottle work well with their command stations. Lenz has always been an open, documented bus protocol, so it was easy to work with from the beginning.
Fortunately, Digitrax introduced the LNWI, which speaks the open JMRI WiFi Throttle protocol (more or less – there are a few key undocumented and irritating differences, one of which cost much of a Saturday afternoon), so we can both adhere to our principles about open firmware and still be interoperable with those who have made the investment in Digitrax equipment. The downside is that it’s slightly more complex to set up in that you have to configure the wireless network information.
That’s not to say that somebody out there couldn’t build a Loconet interface. Honestly, we’d like to see somebody build an open source one under the LNPE license. We’ll gladly help you from the ProtoThrottle side of things with all the technical details you need if you can’t find them in the released source code. It just probably shouldn’t be one of us, and everybody who wanted one would need to source their own parts and fabricate their own hardware, as the LNPE license states that no money can change hands as a result of anything built around LNPE.
The most common reason for the ProtoThrottle not working with the NCE Power Cab is that the Cab Number on the receiver is set to an invalid value.
Unlike the NCE ProCab command stations, the Power Cab only supports a limited set of Cab Numbers. The valid Cab Numbers for use with the Power Cab are 3, 4, 5, 8, 9, and 10. The rest are never polled by the Power Cab and thus the receiver never gets its chance to communicate. For more information, see the NCE Information Station.
Note: The ProtoThrottle does not work with Power Cab v1.1. To use the ProtoThrottle, the Power Cab will need to be upgraded to v1.65.
Some decoders, like the ESU Loksound, start and stop the prime mover sound based on the state of a function, typically F8. If F8 is on, the prime mover is on. If F8 is off, the prime mover is off. Other decoders, such as the Tsunami2 by Sountraxx, require activating one function momentarily to start the prime mover and another function (again momentarily) to stop the prime mover. The ProtoThrottle has provision for both types of prime mover control.
If the ENG STOP function is set to off (F- -), the throttle will act in a Loksound compatible way, sending the ENG ON function when the prime mover is on and not sending the ENG ON function when the prime mover is off. If the ENG STOP function is set to any other function number (F00 to F28), the throttle will act in a Tsunami2 compatible manner. It will send the ENG ON function for a few seconds when starting the prime mover and send the ENG OFF function for a few seconds when stopping the prime mover.
If you have the throttle configured with both ENG ON and ENG STOP set to function numbers, but try using it with an ESU Loksound decoder, you will get the behavior described in the question. The prime mover will start for a few seconds, but then stop for no apparent reason. The solution is to turn off the ENG STOP function by setting it to F- -.
The ProtoThrottle was designed to maintain a clean, prototypical look. Because of this, we felt a keypad had no place on the throttle and opted for a small (8×2) LCD screen to display the necessary, but minimal, information needed on this throttle. This is accompanied by four discrete pushbuttons that allow the user to interact with the throttle when necessary for settings things like locomotive number, functions, and user preferences.
Here’s the logic behind choosing the 802.15.4 XBee radio module over something like an 802.11 WiFi module:
- We have the infrastructure for XBee’s already and have built a number of products around the technology, including our wireless fast clocks. The software libraries are already in place and we have extensive field testing on the technology.
- The 802.15.4 technology behind the XBee is proven for reliable, low data-rate industrial networks. WiFi tends to be more consumer focused, with significant existing (and unrelated) traffic over the same radio bands we would have been using, creating interference concerns.
- With a WiFi radio, the throttle would require a much more complicated user interface just to get it going each time you change networks. There would need to be a way to select an SSID and enter a password for the network. With only an 8×2 LCD and 4 buttons this becomes quite cumbersome. The XBee radio module “just works”.
- More extensive (and expensive) testing would be required for FCC compliance if using a WiFi module. Using pre-certified modules (in either case) eliminates the need to perform FCC Part 15 Subpart C testing for intentional radiators – that’s already been done at the module level. Subpart B (unintentional radiators) testing is needed in both cases. Where the difference comes is in Specific Absorption Rate (SAR) testing, which is basically a measure of the heating effect caused by RF radiation on a human body. Since this is a handheld device, it falls into the portable category which requires SAR testing, or being able to justify an exclusion from the testing. While both types of modules would likely pass this testing with ease, the cost of doing the tests is prohibitively expensive. Our only option is to get an exemption, which is based on frequency and output power level. The XBee module falls well below the exemption threshold, so we don’t have to perform the SAR testing. The XBeePRO module, with higher output power, does not qualify for the exemption based on peak output power, but may based on average output power since we limit the transmission duty cycle in the throttle. The WiFi modules we’ve seen, however, all fall above the exemption threshold based on their peak output power, requiring them to be tested. It’s also unclear that average output power for a WiFi module would get them below the threshold.
These four points, taken together, drove the decision to use an XBee module instead of WiFi.
We considered many options for the ProtoThrottle, some including battery compartments accessible directly from the outside. However, in the end, for simplicity and to keep the costs down, it was decided to mount the battery holder to the main PCB. The benefits of this include having a single, self-contained unit which is easier to manufacture. A standard, off-the-shelf, low-cost box can then be used which simply acts as a cover on the back – it has no functional purpose other than covering the electronics and providing a place to hold the throttle.
Changing the batteries is not much harder than with some other cases (with integral battery boxes) that were considered. Simply remove 4 screws from the front of the face plate, slip off the back cover, and replace the batteries.
Standard AA batteries were chosen over a cell-phone like lithium battery for a number of reasons. The most important one was practicality. Using an integrated battery means the throttle is out of commission when charging. If the batteries die in the middle of an operating session, or someone forgets to charge it, you’re sunk for the hour or so it takes to charge. Using standard AA batteries alleviates this problem. You can simply swap in another set of batteries and continue operating while the original set are charged (assuming they are rechargeable). You also have the choice of using standard Alkaline or rechargeable NiMH batteries.
Other reasons include cost, both per unit and regulatory. The necessary charging and protection circuitry for an integral lithium battery would have added significant cost to the ProtoThrottle. We’re not manufacturing these throttles in the millions of units like Samsung or Apple, so the cost per unit (and additional cost to the end user) for these circuits can be significant. Additionally, California enacted legislation a few years back, regulating products with battery chargers. Frankly, we didn’t want to deal with this, having our hands full already. Any small benefits to the end product did not justify the time and expense involved. This was a case of “keep it simple”.