Skip to main content

The LionChief sounds seem to have some limitations at higher speeds but I can say from my experience with Railsounds II through the latest Legacy Railsounds, the 4 chuffs per rev goes through a bit of an audible shift in the chuff cadence as the locomotive speeds up and it really sounds quite impressive. Not every chuff hits with the same fixed intensity which is correct with a real locomotive. Each of the 4 chuffs has its own dynamic variation in volume and intensity which is something Lionel’s sound engineers did a remarkable job of simulating in the Railsounds package. It doesn’t sound like a machine gun at all to me.

Yep, the full Railsounds doesn't have the issues of some of the LC+ 2.0 stuff has.  OTOH, the LC+ 2.0 Polar Express locomotive appears to have Legacy quality sounds without those issues.  I also have an LC+ 2.0 PRR RS3 that has what appears to be the full Legacy sound set, including all the somewhat annoying creaks and groans.

I certainly agree that the sound isn't all that far off for most of them at speed.  However, if you've ever run the LC+ 2.0 Docksider 0-6-0T locomotive at speed, you'd see that once it gets going at all fast (actually not all that fast), the sound suddenly totally breaks up into an unrecognizable hash, not just a fast chuff like a machine gun.  There is apparently a flaw in their higher speed chuff sound algorithm for this particular locomotive.  That's the reason that a bunch of us decided that this particular model needs a chuff lobotomy.

No disagreement here. I'm only speaking to the PS2, PS3 systems and the RailSounds system from about 5 and up.

I think we'd have to agree to disagree about the "solid support" and "availability" you mention. I can count on one hand and have fingers left over the entire staff of the MTH entity working on DCS, one car crash could wipe out the company. One key player deciding to move on could have the same effect.

“Solid” was probably an over statement here but at least they made a move in the direction of continued product support which is a lot more than anyone can say about Lionel. There’s a pretty significant difference between “we’re selling off the business but electronics/parts will remain available” and “we have NOS parts for product older than 5 years on hand but we decided to get rid of them instead of making them available to customers.”

“Solid” was probably an over statement here but at least they made a move in the direction of continued product support which is a lot more than anyone can say about Lionel. There’s a pretty significant difference between “we’re selling off the business but electronics/parts will remain available” and “we have NOS parts for product older than 5 years on hand but we decided to get rid of them instead of making them available to customers.”

Well, it's hard to argue that it was a lame decision to dump all the electronics before the 2010 models, but to be fair, it's parts 15 years old and more that they dumped.

To be honest, I don't understand that move at all.  Again, the cynic in me has to think it might just might be the "we'll just make the old stuff unrepairable so they have to buy new stuff" mindset.  Since all the mechanical parts are still there, dumping that fairly small percentage of the old parts doesn't seem to be a space issue.  Also, since they never showed up on the used market, they apparently didn't sell them to anyone, so they probably ended up behind the plant in the dumpster.  I wish I had been on hand for that dump!  OTOH, I'm committed to keeping the old stuff running, and I have the parts to make that happen.

Last edited by gunrunnerjohn

"at least they made a move in the direction of continued product support which is a lot more than anyone can say about Lionel."

I admire your optimism, but I don't think the facts of the current situation support your analysis.  Which company is likely to still be a going concern 5-10 years from now?  20 years from now, for the younger hobbyists?  No one knows for sure, but the history and today's circumstances suggest the odds are better for Lionel.  They have warranty repairs available, which cannot be said for the MTH product line at present.

They continue to make a handheld remote for their command systems, the cab-1L.  During the period when the Legacy base became unavailable, and the Base 3 vaporware,  new Lionel command locos could be operated in command mode using the Universal Remote or their app. $50 or free.

DCS's remote is long discontinued.  The last iteration of their app had problems.  The TIU or Wi-Fi TIU has been unavailable, just like the Lionel Legacy base and the planned Base 3.  Sure, Legacy boards aren't available, but ERR products were available when PS3 boards were unobtainium.

So at worst, it seems to me the edge goes to Lionel for the last few years, and Lionel's future looks more assured to some of us.   They have a catalog too .

The last iteration of their app had problems. -
The latest iteration of the iPhone app (3.2.3 released a couple of days ago) is stable and working quite well.

Sure, Legacy boards aren't available, but ERR products were available when PS3 boards were unobtainium. -
Several ERR products were also in short supply during COVID and currently, ERR is limiting R4LC board purchases to a max quantity of 2 per customer:

The Cruise Commander M is also currently out of stock and has been for a short while now but is supposed to be back next month? Those also spent considerable time last year on the unavailable list. Mini Commanders are sold out and will never be built again.

Also, ERR had a convenient price hike last year while the PS3 upgrade kits remain at there same $200 price tag they had for almost a decade now.

Attachments

Images (1)
  • mceclip0

Well, it's hard to argue that it was a lame decision to dump all the electronics before the 2010 models, but to be fair, it's parts 15 years old and more that they dumped.

To be honest, I don't understand that move at all.  Again, the cynic in me has to think it might just might be the "we'll just make the old stuff unrepairable so they have to buy new stuff" mindset.  Since all the mechanical parts are still there, dumping that fairly small percentage of the old parts doesn't seem to be a space issue.  Also, since they never showed up on the used market, they apparently didn't sell them to anyone, so they probably ended up behind the plant in the dumpster.  I wish I had been on hand for that dump!  OTOH, I'm committed to keeping the old stuff running, and I have the parts to make that happen.

Amen John there is never a reason to walk away.4.0 5.0 and 5.5 are not that far apart and when I asked a friend who is a jobber to look at each board. There was nothing that could not be bought or the newer version. I hate to think it but you are right buy new rather than repair.

That’s the big difference from HO to O and in O there is no excuse.

@ThatGuy posted:

Amen John there is never a reason to walk away.4.0 5.0 and 5.5 are not that far apart and when I asked a friend who is a jobber to look at each board. There was nothing that could not be bought or the newer version. I hate to think it but you are right buy new rather than repair.

That’s the big difference from HO to O and in O there is no excuse.

Well, RS5 and RS5.5 are the same hardware, it's just the contents of the processor and sound chips that changed.  The RS4 board wasn't that much different than the RS5/5.5 board, but they added the coupler & rear light feature on the RS5 board as well as being able to address more memory for the larger files.

I contacted SoundTraxx yesterday to comment on their lack of a chuff input on their Blunami product. Their response, as noted previously in this tread, is it isn’t necessary due to their “decoder is able to read the BEMF to determine the revolutions of the motor”. In their response they say a cam can easily be synchronized with motor revolutions to have sound & smoke synchronous.

Thoughts on this?

@Trainmstr posted:

I contacted SoundTraxx yesterday to comment on their lack of a chuff input on their Blunami product. Their response, as noted previously in this tread, is it isn’t necessary due to their “decoder is able to read the BEMF to determine the revolutions of the motor”. In their response they say a cam can easily be synchronized with motor revolutions to have sound & smoke synchronous.

Thoughts on this?

Not true. You can use a cam or other means to drive a smoke fan at 4 times per rev but it can’t be synchronized with sound reliably. BEMF doesn’t know wheel/valve position at startup so sound can start anywhere in the rotation.

Pete

@Norton posted:

Not true. You can use a cam or other means to drive a smoke fan at 4 times per rev but it can’t be synchronized with sound reliably. BEMF doesn’t know wheel/valve position at startup so sound can start anywhere in the rotation.

Pete

IMO, that's a total crock!  If you used a cam, it would be perfectly synchronized with the drivers. BEMF doesn't enter into the pictures, that's just controlling the speed, we're talking about inputting the chuff signal, not trying to generate it from BEMF, that's what they do now!

Now, if they're too lame to synchronize the chuff sound when they get the pulse, that's not a problem with synchronizing with the drivers.  Truthfully, most of our O-scale stuff that doesn't use an axle cam doesn't synchronize with the drivers.  Neither MTH or Lionel Legacy synchronizes to the drivers, somehow we live with that.

The MAJOR problem, at least IMO, is the smoke and sound aren't synchronized!  Those are two things that are readily observed.  It's almost impossible at any speed to see that the sound and/or smoke doesn't perfectly synchronize with the drivers, even using a cam.

I'm not nearly as worried about synchronizing the drivers with the smoke and sound as I am synchronizing just the smoke and sound.

Why can't they just be honest and simply tell you they don't want to do it or it's "too hard"?

FYI, I don't know if it matters but the TCSWOW board can generate synchronized chuffs.  I installed one in a Bluerail experiment I did a while back and was REALLY happy with it.  I was originally going to use a Tsunami (not Blunami, this was before then) with a separate Bluerail board, and bought one of GRJ's chuffer kits, but ultimately the Tsunami couldn't handle the big motor.  The TCSWOW501 board was actually cheaper than the Tsunami + chuffer kit anyway.

Here's a link to the thread:

https://ogrforum.com/...c/154730474344205453

IMO, that's a total crock!  If you used a cam, it would be perfectly synchronized with the drivers. BEMF doesn't enter into the pictures, that's just controlling the speed, we're talking about inputting the chuff signal, not trying to generate it from BEMF, that's what they do now!

Now, if they're too lame to synchronize the chuff sound when they get the pulse, that's not a problem with synchronizing with the drivers.  Truthfully, most of our O-scale stuff that doesn't use an axle cam doesn't synchronize with the drivers.  Neither MTH or Lionel Legacy synchronizes to the drivers, somehow we live with that.

The MAJOR problem, at least IMO, is the smoke and sound aren't synchronized!  Those are two things that are readily observed.  It's almost impossible at any speed to see that the sound and/or smoke doesn't perfectly synchronize with the drivers, even using a cam.

I'm not nearly as worried about synchronizing the drivers with the smoke and sound as I am synchronizing just the smoke and sound.

Why can't they just be honest and simply tell you they don't want to do it or it's "too hard"?

Reading is fundamental John, Read it again. You CANNOT get synchronized sound.
A cam or optical detector can be perfectly synchronized with wheel position. ANY system that uses motor rotation will never give a pulse at the same wheel. position unless you somehow add a home signal. Your chuff generator only compounds the problem.

Pete

@Norton posted:

Reading is fundamental John, Read it again. You CANNOT get synchronized sound.
A cam or optical detector can be perfectly synchronized with wheel position. ANY system that uses motor rotation will never give a pulse at the same wheel. position unless you somehow add a home signal. Your chuff generator only compounds the problem.

Pete

My desire is to synchronize the sound with the chuff, and I have no problem doing that with my Chuff-Generator.  I get exactly the same results as both MTH and Lionel Legacy as far as synchronization with the drivers, as you correctly observe, that's none.  Lionel, MTH, and my C-G all get the four-chuffs/rev, but without a wheel cam or detector, you obviously aren't synchronized with the drivers.

My whole point is that with the simple addition of the chuff input on the Blunami, I could have synchronized smoke and sound.  In my mind, that's the big whoop here.  I can tell from across the room that the sound and smoke aren't synchronized.

@Trainmstr posted:

Correct me if I’m wrong, some kind of signal must be getting sent to the sound chip to generate the chuff. Couldn’t they provide that signal as another wire, so a smoke board could be developed like KarlDL did for electrocouplers?

Maybe if we asked for that instead?

It could but Sountraxx has decided not to include that option with their Blunami. Other DCC decoder makers do have that option and I believe Soundtraxx has dine so in the past, just not in this line.

Pete

@Trainmstr posted:

Correct me if I’m wrong, some kind of signal must be getting sent to the sound chip to generate the chuff. Couldn’t they provide that signal as another wire, so a smoke board could be developed like KarlDL did for electrocouplers?

Maybe if we asked for that instead?

We did ask for exactly that.  Harry Henning talked to them and they flat stated there would be no input or output to synchronize the smoke.  Why they'd take that stance I'll never know!

@Norton posted:

Not true. You can use a cam or other means to drive a smoke fan at 4 times per rev but it can’t be synchronized with sound reliably. BEMF doesn’t know wheel/valve position at startup so sound can start anywhere in the rotation.

In addition, back-EMF doesn't exactly track motor revolutions, it's an analog function.  You're measuring the back-EMF from the motor, there's no way they exactly determine exactly the number of rev's of the motor from that reading.  Even if they started synchronized, it would go in and out of sync as you run, there's no way to control that.

@Norton posted:

It could but Sountraxx has decided not to include that option with their Blunami. Other DCC decoder makers do have that option and I believe Soundtraxx has dine so in the past, just not in this line.

Pete

Soundtraxx does in fact do that.  I have a couple of DCC N Scale locomotives that have Soundtraxx decoders in them and there are CVs that can adjust the chuff rate.  It works very well.  Of course they do not have smoke.

John

@Craftech posted:

Soundtraxx does in fact do that.  I have a couple of DCC N Scale locomotives that have Soundtraxx decoders in them and there are CVs that can adjust the chuff rate.  It works very well.  Of course they do not have smoke.

John

I was referring synchronizing chuff and smoke fan. I know you can get the chuff rate to match driver rotation but no way the chuff sound can be accessed to drive a smoke fan or vice versa.

Pete

@Norton posted:

I was referring synchronizing chuff and smoke fan. I know you can get the chuff rate to match driver rotation but no way the chuff sound can be accessed to drive a smoke fan or vice versa.

Yep, that's the problem I want to solve.  Truthfully, the driver's exact position synchronized to the chuff doesn't happen with most of our stuff.  However, we can get 4-chuffs and the sound and smoke are synchronized, 90% of the effect.  If you use an axle cam, you can go all the way if you get the cam positioned correctly.

Yep, that's the problem I want to solve.  Truthfully, the driver's exact position synchronized to the chuff doesn't happen with most of our stuff.  However, we can get 4-chuffs and the sound and smoke are synchronized, 90% of the effect.  If you use an axle cam, you can go all the way if you get the cam positioned correctly.

It only matters at low speed anyway so why can't an internal optical motor trigger be used taken right from the flywheel?

John

And you synchronize this with the Blunami sound how?  There is no input or output chuff signal to or from the board.

Just throwing out ideas.

The Soundtraxx Decoders on other scales have a chuff rate that is adjustable by quite a lot.  I was wondering if you could adjust the chuff sound to come close with the smoke circuit triggered by maybe one of these?

https://www.amazon.com/Fielect...7V4P#customerReviews

Attach something to the flywheel to pass between the slot to trigger the sensor switch.  Then adjust the chuff sound with a CV

John

Last edited by Craftech
@Craftech posted:

Just throwing out ideas.

The Soundtraxx Decoders on other scales have a chuff rate that is adjustable by quite a lot.  I was wondering if you could adjust the chuff sound to come close with the smoke circuit triggered by maybe one of these?

https://www.amazon.com/Fielect...7V4P#customerReviews

Attach something to the flywheel to pass between the slot to trigger the sensor switch.  Then adjust the chuff sound with a CV

John

It'll never stay in sync, the Blunami has no direct visibility to the exact actual speed of the drivers.  Even a tiny variance in the Blunami chuff timing and the actual chuff cam or tach reader will cause the smoke and sound to drift in and out of sync.

Other Soundtraxx decoders have the ability to synchronize the chuff with smoke, for some reason Blunami has refused to make a simple software change to output a chuff trigger.  I know it's their ball, but I don't have to play the game.  I might do one or two diesel Blunami projects, but there's no steam projects in my future with the Blunami.

Last edited by gunrunnerjohn

A chuff switch input would be even better, as the same switch could be double poled to provide the input to a smoke unit that has the chuffing circuit built-in or has an external smoke unit motor control circuit. They probably don’t want to support smoke unit motor control since their board does so much already, and much of it very nicely.

I wouldn’t mind an input as I like to home brew my own chuff input devices but at this point it’s not a deal breaker since I am so enamored with Blunami’s sounds and excellent motor control. If anyone has survived a few of my YouTubes they may have seen my obsession with crankpin-synched exhaust.  

Pete is exactly right.  We don't need smoke motor control, all I asked for was a trigger pulse when they were triggering the chuff sound!  Easy Peasy, shouldn't have been much of a problem at all.  As Pete states, the Tsunami has such a capability, and it would be trivial to add the capability to the Blunami.  I honestly don't get why the reluctance to make this obvious simple improvement!

@rplst8 posted:

I wonder if one could use the speaker outputs with a well designed filter to detect the the chuff rate. Could also maybe detect whistle signals and trigger a whistle smoke unit.

Not easy to design or build, but could be very versatile.

That would be expensive and ridiculous!  Why even have to resort to this effort and expense when a simple software change that can't possibly take more than a couple hours would solve the problem?  I don't know how versatile or reliable it would actually be without spending a ton of money on it.

Would the reluctance stem from limits of a four amp board?   What amperage are folks steamers pulling a reasonably heavy load from a dead stop on a graded corner with full smoke... get one anywhere near to four amps?

Not sure how others are doing it but I am driving the smoke unit off track power. The Blunami only drives a relay with a 30ma coil current. Similar setup for couplers.

Pete

I'm happy enough if the chuff rate is proportional to speed, even if it's not perfectly synchronized with the drive rods.

That being said, could you place a Hall effect sensor in the cylinder area, to detect exactly when the piston rod slides forward?  (This approach would work no matter the gear ratio or driving wheel size.)  It seems that you would only need one sensor, and then you could divide the measured interval by two or four.

Many of you are missing the point John and Pete keep making: there is no capability in the Blunami to sync ANYTHING with the chuff. Adding sensors or cams of any type to the motor, wheels, pistons, etc. will accomplish nothing.

Without a sync wire from the decoder, you will never have syncronized puffing smoke. Even if you use a sensor tied to the drivetrain to make the smoke puff, the sound will never sync up. Think of watching a movie or tv show where the audio lags behind the picture. Annoying and obvious, right?

At higher speeds, it would likely not be noticeable but moving at yard speeds, the mismatch will atick out like a soar thumb.

To John’s irritation, Soundtraxx has provided a chuff input wire on literally every sound decoder they’ve ever made until this point. Why the sudden desire to remove it, I can’t comprehend.

Last edited by Ryan Selvius

That would be expensive and ridiculous!  Why even have to resort to this effort and expense when a simple software change that can't possibly take more than a couple hours would solve the problem?  I don't know how versatile or reliable it would actually be without spending a ton of money on it.

I agree, but if they won't change the software on the board to provide a sync signal (or take a signal as input), this is about the only way I can think of to accomplish the desired effect.

@rplst8 posted:

I agree, but if they won't change the software on the board to provide a sync signal (or take a signal as input), this is about the only way I can think of to accomplish the desired effect.

**** the torpedos, and full speed ahead!….jam a PS1 smoke unit in there and run that joker at 18V!….who needs puffs?….that’ll fog out the whole house just in a yard move 😁

Pat

Add Reply

Post

OGR Publishing, Inc., 1310 Eastside Centre Ct, Ste 6, Mountain Home, AR 72653
800-980-OGRR (6477)
www.ogaugerr.com

×
×
×
×
Link copied to your clipboard.
×
×