Some pressing personal business has kept me away from this website since I created the OP. Lots of good suggestions and things to try. I believe I have already tried the F8 key with the MTH Hudson but I'll give it another crack just to be sure. This is at least the second time it has gone quiet on me and I've never known what caused it to happen or why it came back. "Under the covers" I guess. I didn't know about the chuff sensor and if a factory reset doesn't do the trick, I'll look into this one. Also will do as suggested on the lube job.
PS. I've been retired for almost 13 years now and I was already becoming a dinosaur. Our shop was already moving to networks and servers and phasing out the mainframe which they finally did about five years ago. I wondered how much was still being done with COBOL and CICS or with Big Iron for that matter. Nice to know it's still alive and kicking. Since the shop I spent most of my working life at having ditched the mainframe and many of the companies I had done contract work for having gone belly up (not my fault, I swear), I doubt there is a single line of code I wrote that is still being used. Maybe I should have been an architect.
The MTH problem is a different one, they are set to come up silent when power is applied, so a power loss results in a silent loco until you hit F8, but if only one unit in the consist shut down, then the one that was on gets and F8 to shut off. Very annoying.
With BLI (Paragon II models, the old ones with QSI didn;t have a chuff sensor), it's fairly common for the chuff sensor reed switch to fail. It's a poor application of a reed switch, it has to operate too fast (it's on the motor shaft, so it turns many times faster than the wheels). For a few pennies more they could have used a hall effect sensor and not had this issue. Should have been OK vs MTH patents because MTH uses an interrupter disk.
--Randy
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.
jecorbettFor almost a year, I have been having a similar problem with my MTH Empire State Express Hudson. Its sound disappears suddenly for no apparent reason and just as mysteriously comes back, but with that one, it is all or nothing. I know MTH does not use a pure DCC system, but this one is also baffling. I know there is a mechanical switch with that one and I haven't taken it apart yet to see if that might be the source of the problem.
Randy Rinker has mentioned this same problem with a pair of F-7s he runs. When power is slightly interrupted the sound will cut out (sometimes only on one engine) then if he uses F8 to restore the sound the other one cuts out.
It is a fault in the design of the sound function in (some?) MTH locomotives. Since you are running the ESE engine by itself try F8 next time it cuts out to see if that restores it. Does it happen at the same place on the layout? Maybe you have a small dead spot that interrupts the power?
For the BLI I stand by Cacole's and my reed switch diagnosis.
Good Luck, Ed
TZ,
The wonders pf VM - and the users think they are running a WIN machine at their desktop!
Jim - Retired for two year....
Modeling BNSF and Milwaukee Road in SW Wisconsin
I agree with Jim. This does not sound like a DCC problem. I'm guessing there is a wheel speed rotation sensor somewhere that is dirty or blocked somehow. I've had a similar problem on and off with the PFM sound units since 1983 (long before DCC). They ran off a cam that physically made and broke a connection. When the cam got dirty it could skip a chuff, put an extra one in, or cut out all together.
I noticed my BLI sound equiped stock cars have a optical sensor that looks at white strips on the axle to determine speed. Perhaps there is something similar on the MTH?
P.S. I used to be an IMS system programmer. Now I'm back to applications using COBOL and CICS with HTML screens, but I still play under the covers from time to time. zVM is great! We use it to run all the Linux "systems" virtually. All the programmers for those systems don't know they are really running on the mainframe. They think we have a data center somewhere with 100 Intel servers in it.
I suspect the 'chuff' cam or switch may be the problem. I doubt if it is a DCC issue - but you can try a 'reset' of the decoder. I hope you are using JMRI to program these engines - Changing CV's from your throttle many times leads to strange problem! As mentioned, give MTH service a call to discuss the p/d steps.
BTW, tweaking 'under the covers' on large servers is usually frowned on these days. I had an engineer lead a senior service rep through one of these adventures and he managed to take down a 24 way server! At the 'review' meeting the next day, he was 'sure' that he had found the reason for the outage and wanted to try it again. I had a VP take my side and we just replaced CPU, rather than try to figure out the original problem(customer satisfaction).
Jim
Cacole is probably right-on-the-money!
I have replaced three reed switch "chuff sensors" in my BLI steam engines. BLI sells the reed switches for about $5 each (last time I bought some, I got 10 just to keep them on hand)
It's a simple fix but you have to disassemble the engine then solder the new switch in place. It is located near the flywheel since the magnet is recessed into the flywheel.
Being a mechanical device the switches don't have 100% reliability and I'm guessing BLI's supplier isn't using the best product available, either.
Be careful handling them, too. I broke one just bending the leads before soldering it on to the board.
I would direct this problem to BLI customer support. There have been problems in the past with some BLI models needing to have a "chuff sensor" within the locomotive mechanism replaced.
When you lube the mechanism, don't forget the wheel bushings and gears.
When I was programming mainframe computers for a living, when there was a process going on that was transparent to the end user, we referred to that as going on "under the covers". Systems programmers would also use that phrase referring to the internal workings that was transparent to us application programmers.
One of my frustrations in working with DCC is that I've never understood what is going on "under the covers" and so I have difficulty figuring out problems. Yesterday, another mysterious problem popped up. I was running a BLI Dreyfus streamlined Hudson. As the loco pulled out of the station the chuffing sound began cutting out sporadically at first and eventually went completely quiet. The baffling part is that the other sound functions (bell, whistle, etc) still work fine. This might make more sense if none of the sound functions worked because it might indicate a lose connection to the speaker from the decoder, but I haven't a clue as to why I've only lost this one sound function. Any suggestions would be appreciated.
For almost a year, I have been having a similar problem with my MTH Empire State Express Hudson. Its sound disappears suddenly for no apparent reason and just as mysteriously comes back, but with that one, it is all or nothing. I know MTH does not use a pure DCC system, but this one is also baffling. I know there is a mechanical switch with that one and I haven't taken it apart yet to see if that might be the source of the problem.
One more problem, also with a BLI Hudson, this one an earlier non-streamlined model. The loco began running sluggishly. When I increase the throttle, the rate of the chuffing sound increases but the speed of the loco remains slow and not synced with the chuff. This doesn't seem to be a problem when running in reverse, only going forward. I suspect this might be a mechanical problem rather than electronic and I'm hoping a lube job on the tie rods will clear up the problem.