Using a Seuthe smoke generator with DCC.
Art D asked on July 19 2006 on NCE Yahoo groups,
Is a Seuthe smoke unit a source of inductance that requires a diode across the wires or is it just the same as a resistor across the rails?
Mark Gurries replied
It is my understanding that a Seuthe unit is nothing more than a heater which is a resistive element that draws a lot of current relative to a headlight. Needs to get hot. If there is any inductance, it would not be anything to worry about for it would be very small.
There are 3 options for connection.
1) To a high powered function output (DC). This gives you complete control if you "play the function" as the train moves. Since the function is off by default, this helps protect the Seuthe unit.
2) In parallel with the motor (pulse DC). Remember to check decoder motor current ratings so it can do both motor and heater. I suspect as good as this sounds like doing, it may not give you the results you want. You may not get any smoke until you close to full speed.
3) to DCC track power directly (AC). Not 100% sure, but I do not recommend this one for I think the element will burn out quickly.
I have plans to install two Seuthe units in my Trix Big Boy and use a high powered function output to drive them.
But what would really be the best solution is to find a old cheap decoder with a speed table. Program to the same address as the locomotive. Drive the Seuthe unit from the motor outputs (high power by default) and adjust the speed tables to get the smoke you want for any speed. I suspect the resulting curve would all be above the 50% speed level for there is a minimum amount of energy needed to put into the heater to get any smoke. If done correctly, the smoke level will vary with the speed of the engine. I would even fool around with the Kick Start functions if the option was available to help heat the element up faster when you start to move the engines...speed step one. It may also turn out that a speed table may not be necessary and using Vstart, Vmid and Vmax instead might work too.
Trial and error experimentation.
Best Regards,
Mark Gurries
Richard Johnson relied
Yes that would work Mark, but surely that's not how a steam engine is driven - when a steam engine is at speed it is generally emitting much less smoke than while moving the train from rest and accelerating, so the effect of using a speed curve would be the reverse of the real need.
I'd guess the only way to really "tune" smoke production would be to use a BEMF decoder with start volts set very high as this might at least increase "heater energy" when the loco is going uphill or taking off etc, and correctly <perhaps> allow the smoke unit to "coast" when the loco is cruising. (I haven't tried it)
This problem with smoke is similar to the difficulty in getting sound to be realistic with a steam loco - sound decoders are generally consistent with revolutions of the wheel which is correct for timing, but they should be much louder when starting or working hard uphill and relatively quiet when "at run speed" on the flat / almost silent when coming to a halt, not "chuffing" at the same volume level.
Re using smoke on a decoder function, they usually draw 100 to 150mA (Seuthe #22 for plastic bodied locos for example), however I note that TCS now use 250mA MosFETs on all functions, so presuming other brands may have also done this, a normal function will be more than adequate.
Richard Johnson
Mark Gurries replied again
Yes that would work Mark, but surely that's not how a steam engine is driven - when a steam engine is at speed it is generally emitting much less smoke than while moving the train from rest and accelerating, so the effect of using a speed curve would be the reverse of the real need.
I'd guess the only way to really "tune" smoke production would be to use a BEMF decoder with start volts set very high as this might at least increase "heater energy" when the loco is going uphill or taking off etc, and correctly <perhaps> allow the smoke unit to "coast" when the loco is cruising. (I haven't tried it)
Absolutely agreed this would be potentially a better solution. However, there is still the issue of "sensitivity". It is true that a engine going up a hill will need more power than running on flat track.
But I strongly suspect the decoder output power will not change significantly enough to make any difference in the smoke level. Even though the BEMF decoder adjust it output up and down a bit, the primary parameter used for initially setting the starting point of the power is the speed of the motor. Stated another way, the speed setting will mostly mask the variation in power such that there is not enough difference in power to make a significant smoke generation change.
If we had a power signal that remove RPM information and only looked at motor work load, then that would make the smoke generation more realistic.
This problem with smoke is similar to the difficulty in getting sound to be realistic with a steam loco - sound decoders are generally consistent with revolutions of the wheel which is correct for timing, but they should be much louder when starting or working hard uphill and relatively quiet when "at run speed" on the flat / almost silent when coming to a halt, not "chuffing" at the same volume level.
The new Soundtraxx Tsunami decoders due just that. Tsunami's calculate the motors "work load" value and use this information internally to adjust the chuff volume dynamically while the chuff rate remains tied to the speed as it should.
Best Regards,
Mark Gurries
Michael asks
Richard makes a good point. My comment is to say that the volume of smoke and the volume of the "chuff" should be parallel.
Semi-humorously, what about driving the smoke generator off the speaker output???
Assuming the sound is already load-dependent.
Just as a curiosity on the side, is there any reason a speed curve could not be set up such that the output is high at low speed, and low at fast speeds?
ie, a curve with a negative slope. Perhaps the internal interpolation would get confused?
Michael
Mark replies.
Absolutely agreed this would be potentially a better solution. However, there is still the issue of "sensitivity". It is true that a engine going up a hill will need more power than running on flat track.
But I strongly suspect the decoder output power will not change significantly enough to make any difference in the smoke level. Even though the BEMF decoder adjusts it output up and down a bit, the primary parameter used for initially setting the starting point of the power is the speed of the motor. Stated another way, the speed setting will mostly mask the variation in power such that there is not enough difference in power to make a significant smoke generation change.
If we had a power signal that remove RPM information and only looked at motor work load, then that would make the smoke generation more realistic.
The new Soundtraxx Tsunami decoders do just that. Tsunami's calculate the motors "work load" value and use this information internally to adjust the chuff volume dynamically while the chuff rate remains tied to the speed as it should.
Best Regards,
Mark Gurries
Mark replies again
Richard makes a good point. My comment is to say that the volume of smoke and the volume of the "chuff" should be parallel.
Semi-humorously, what about driving the smoke generator off the speaker output???
Right idea but not enough power. Music has a high peak but low average power content. Average power is what will generate the heat. Most amplifiers are already having a hard time driving some speakers as it is.
Assuming the sound is already load-dependent. Only Tsunami Decoders have this feature of adjusting the sound based on
the work effort of the motor. Not speed.
Just as a curiosity on the side, is there any reason a speed curve could not be set up such that the output is high at low speed, and low at fast speeds?
ie, a curve with a negative slope. Perhaps the internal interpolation would get confused?
Absolutely can be done which is what I was suggesting one due. It just has to be different decoder than the one controlling the motor. You cannot share the speed table.