Congratulations! I'm looking

Congratulations! I'm looking forward your success and patiently await the release of a unit that works with a Digitrax system.

This is a nice idea whose

This is a nice idea whose time has come. I like the idea that the throttle will actuate the brakes on sound trax decoders as well as the loksound units. I video of guys running trains with your throttle would have been great. I never get tired of watching trains.

A new market?

Have you thought about something that looks like a steam locomotive backhead for steam operation?

I have one diseasel on my layout and if you ever get one of these compatible for MRC, I might buy one.

I would be remiss…

…if I didn’t thank ESU Loksound, Soundtraxx, and Athearn for helping us at the St. Louis RPM show by supplying us with locomotives and rolling stock. We were most appreciative! Thanks Alec (Matt) – ESU, George – Soundtraxx, and Chris – Athearn!

I second the Steam...

As for system... well... I don't have my permanant system yet (I've been using "Bachmann's EZ Command") so once a Steam one comes out (if a Steam proto-trottle comes out) what it supports will sway my decision on what DCC system I'll be using!

Congratulations!

So ... it seems that Soundtraxx is the decoder of choice for the brake feature?

Thanks, John

Currently, it is that way. I’m hoping that the other decoder manufacturers develop a brake just as good. I’m not that familiar with other decoders outside Soundtraxx and Loksound, so maybe there are other great brake features.

A question to Scott. So right

A question to Scott. So right now based on what you are saying if I understand correctly, the unit interfaces well with Sound traxx. The brake features map to the throttle and the momentum allows the throttle to have the sound ramp up and down according to the notches. As I take it the locomotive will coast for a considerable distance with the throttle in idle if the unit is programmed correctly? All of these things will happen with out a continuous stream of rewriting cvs as the throttle changes speed and direction?

The specifics of different decoders and how they work with the throttle would be great to know since you guys are doing so much work with them now.

I for one would strongly consider making changes to my choices in decoders to make the best use of this excellent throttle design. I have already found myself leaning heavily to the NCE system because of its ease of use and the fact that it can easily support the throttle. The fact that they can lenz decided to share their technology so you could work on a direct interface with their systems moved them to the top of the heap for me.

Rob…

Michael is the better person to ask regarding anything electronic with the throttle, but to answer your question from my observation, yes, the throttle worked very well with Soundtraxx’s Tsunami 2 decoder. There is no need for CVs to be dynamically rewritten. The Tsunami brake feature allowed very realistic operation and was a big hit. 

We’re still hoping to work with Matt from Loksound to lock in the prime mover sounds to their respective notches on the throttle as well as see if a brake similar to Soundtraxx’s could be developed. This would put both of those fine products on a similar level in terms of realistic performance. We’ll see as things progress.

When?

I am so excited about this. When will they be available?

Great news Scott!

That is great news Scott and very interesting about the brake feature. LokSound also has a brake feature. Can you explain what the difference between braking with Soundtraxx vs braking with LokSound and how they differed?

Thanks,

Tim

Brake Differences

Availability and the brake

Tore:  the throttle will be available sometime next year, hopefully earlier rather than later.  We still have a fair amount of programming development to go and we’re also required to send it through FCC testing because it’s wireless.  

To expand on Michael’s comments regarding the brake: the Soundtraxx brake included both an independent and train brake. Each one responded differently both operationally and with the sounds. With the independent, the train responded more quickly while the train brake required more distance. I had one professional engineer tell me sounds were dead-on accurate. Michael set up one of the push buttons to toggle between both functions. 

It seemed the ST brake feathered so the brake could be applied, released, applied, etc., thus slowing the train each time. It also allowed the engineer to hold the engine while notching up – "power" braking. Very cool performance.

@Scott - that brake behavior

@Scott - that brake behavior sounds similar to what I experience with my ESU decoders.  

I can quickly toggle the brake on and off with the function button to simulate the "feathering" effect.  It seems to decelerate about twice the speed of the CV4 value for deceleration.  Also,  If I leave the brake turned on, the locomotive won't move until I release the brake.

That said, the ESU decoder only has one brake, and I don't think it is as configurable as the Soundtraxx brakes. I haven't carefully read the ST-2 documentation yet.

I was curious about the brake on the throttle - is it an on/off or variable input?

gs

Brake

Voltage sensing?

Could the Raspberry Pi use the pot (or encoder) for the brake and measure voltage? If so some triggers could double the brake as if you had pressed the button twice, three times, etc.

How the brake works

Feathering the brake

Feathering the brake

Feathering the brake and TCS WOW decoders

Okay, then I understand it correctly. FWIW, TCS WOW sound decoders have a brake function, but each press of the brake function key applies 20% braking. So I'm assuming you could send the appropriate number of function presses per how far the brake lever is pulled over with a TCS decoder.

I have a WOW sound decoder installed in a loco and I can say the multi-press brake is a blast. When in hit the function key five times to get a hard brake application, I get a really loud brake squeal and the loco stops more quickly. If I just press the brake function once (20% application), I may get a slight brake squeal just as the loco comes to a stop over a much longer distance, but that varies somewhat (which makes it more realistic since it's not completely predictable in sound).

I'm curious how this differs from what SoundTraxx has implemented in their Tsunami2 for braking. It seems like LokSound braking may be the most rudimentary at the moment across the three leading sound decoder makers.

You’re right, Joe…

…it seems each decoder has pros and cons.

But, darn it, we want the ultimate decoder that has it all!  

It seems to me that if this

It seems to me that if this great throttle idea had not been developed by you guys from Iowa scaled engineering we would, or at least most folks like me would be unaware of the things in our decoders. It seems there will be more than one great choice available for decoders with some working better than others, and with out this discussion for most of us we would still be unaware of these great features.

Now if you guys or anyone else knows which non sound decoders also have control functions that can work with these brake features. Up till this point I have considered putting sets together with one sound unit (lead unit) with two to three other decoder equipped locomotives with out sound. I was thinking that might be a nice way to use some semi permanent consists and save money on the process.

Granted 2 to 4 sound units would be impressive on a train, but I have found that mixing the two still seems to have the effect and drastically reduces the cost. It might be handy to have a list of decoders from all the manufacturers that will work the best with this neat throttle. Maybe the makers of decoders would like to advertise their products along these lines for the rest of us to buy. I for one will be looking for info regarding what works the best with this throttle and spending my money accordingly.

Okay, then I understand it

I do remember someone mentioning this a while back.  Thanks for the reminder.  I don't have any TCS decoders at the moment so my experience with them is about zero, so this is good to know.

Yes and no.  While it is certainly possible to do this, there are some practical issues.  This is the same reason using manual notching to control the sounds seems appealing at first, but ends up being problematic in the end.  Fundamentally, with the ProtoThrottle, the brake (and throttle) levers are absolute inputs - they are in a certain position, remain in that position, and expect the decoder to be in the corresponding state.  On the other hand, the TCS brake function (and manual notching) are relative controls - each activation advances the control up or down but there is to way to say "go to 45% brake" or "go to notch 6".  Therein lies the problem.  The ProtoThrottle has no way to know if the decoder is actually in the desired state (and take action if it is not), nor any way to reinforce the state to the decoder.

So, for example, let's say we are using the common example brought up on these forums of "just use manual notching" to decouple sound from speed.  Let's say you are moving along in notch 6.  The locomotive briefly loses power and loses its brain.  You'd expect, when it comes back on line, to be moving again in notch 6.  However, the PT already sent the manual notching commands to put the decoder in notch 6.  It cannot keep resending those "notch up" commands without adversely affecting the state of a good decoder.  It also has no knowledge that the decoder in question lost its brain.  There is just no way to reinforce that the decoder should be in notch 6.

Speed, on the other hand, is defined by DCC to be an absolute control.  The desired speed can be (and is) continually refreshed to the decoder so when the decoder comes back on line, it resumes the previous speed.  There is simply no way to do this for relative notches, or in the case of this thread, relative brake steps.

Yes, there are ways to somewhat work around this.  Things like sending eight notch up commands when the throttle is put in notch 8, eight notch down commands when the throttle is put in idle, or a bunch of brake down commands when the brake handle is fully released, but that only resynchronizes the throttle and decoder when the PT control enters that position AND the decoder is ready to accept the command.

These relative controls on the decoders will make the PT interface less than ideal.  I've mentioned this to the decoder manufacturers, and I think they understand, but we're not going to see any quick fixes soon.  So, my only option left may be to build some wizardry into the PT to try and emulate the desired behavior.  Maybe using manual notching and/or TCS style braking will end up being the solution, with the knowledge that there are some corner cases, like mentioned above, where things can get out of sync.  In the meantime, my opinion is that using absolute (on/off) functions that can be reinforced periodically is the best, most reliable solution and gets most of they way toward the proto-experience.  It's also the most universal among decoder manufacturers.

The Soundtraxx brake is just on/off, at least the form of it that I was using.  There may be other modes, like the TCS, that I'm not aware of yet.  This is the same as the Loksound brake.  The main difference between the two was the feedback that the user got from the Soundtraxx decoder, both in terms of the brake's effect on speed and on sound.  The ESU decoder, at least as configured, did not provide the immediate feedback that the brake had been applied.  Once you got used to the Loksound brake, it worked well, but it was clear the Soundtraxx decoder had a shorter learning curve with the brake than the Loksound.

Michael

Now if you guys or anyone

I don't have a list yet, but plan to do it for personal reasons if nothing else.  The plan for my layout at the moment is to go "Lance Mindheim" style with non-sound decoders in the locomotives (I'm in N-scale) and a bank of sound decoders permanently stationed on the layout connected to headphones for the sound.  So I'll need non-sound decoders that work well with the ProtoThrottle.  I know both ESU and Soundtraxx have non-sound versions, though for N-scale, finding decoders that support all the necessary light functions I want is proving difficult.  For myself, I need 4 function outputs and the ability to independently dim both front and rear headlights.  At the moment, ESU (Lokpilot) and NCE (N12NEM) have this.  The Soundtraxx NEM651 and TCN EUN651 only have 2 function outputs and cannot independently dim front and rear.

Incidentally, using the approach of having 2 decoders, one sound the other non-sound, makes decoupling speed and sound really easy, solving that problem rather elegantly...

Eventually we'll compile a list.  It is on my todo list.

Michael