Search The Inn

Thursday, September 26, 2024

Loksound Equipped Engine Refuses To Move But Sound Is Fine

This problem has plagued users for a long while now and is almost constantly an issue brought up on the LokSound groups.io forum. Guaranteed you'll see it brought up about every two or three days.

There are several reasons this could happen and the majority of them are easily remedied. There is a list of things that need to be checked and these are mentioned whenever the problem pops up. 

  • Make sure Drive Hold is not on
  • Insure the Independent Brake is not on
  • Insure the Automatic (Train) Brake is not on
    • To learn how to implement the Train brake read this
  • Make sure CV19 is set to 0 (not in advanced consist)
If group members think of other things that need to be checked, email the author and he'll add them to this list. 

Now For The Insidious One
Recently, the author came across this problem in a couple of his locomotives and it always occurred when initially programming the decoder. It didn't matter if the engine was programmed from scratch or was a copy of a previously programmed engine with just the engine number changed. It happened in both instances and was always for a v5 decoder (that's what the author has) so, both 21 pin and micro decoders developed the problem.

Re-burning the unchanged original downloaded file from ESU (pure factory reset not a reset to previosly programmed values) would clear up the problem so what did the author change that caused this? 

Today it was decided he was going to take the time and trace the cause. One sheet at a time utilizing the Drivers Cab to test running or not after changes and then go changed setting by changed setting on the particular sheet if the problem occurred.

This took some time. Brake Settings, Driving Characteristics, the various Function Sheets, all were fine. Motor Settings, WAIT!!! the engine refused to move!!! Now change by change until the author got to Motor Overload Protection. Long story short finally, checking the Enable motor current limiter would prevent the engine from moving!  See figure 1.

 


Fig1 Motor current limiter

Think! Why? This was an older HO KATO AC4400CW purchased at a swap meet and it had the same changes made to a new one that was working. This makes perfect sense. The older motor needs more current than the new model and the protection wouldn't let it move because it was above the set limit.

Uncheck the Enable motor current limiter box, test, engine moves! Problem solved.

Don't forget this one after checking Drive Hold and all the different brakes don't fix the problem. Also remember that if after all of these checks are done and the engine still does not move, you probably have a blown drive circuit in the decoder and it requires a trip to Colorado for a fix. Remember that the ESU office has moved. It's no longer in Pennsylvania. 

I hope this helps and I know it demonstrates what lengths you sometimes have to go through to isolate problems. Good luck!


If you have an idea for a blog post here, let me know. If I can comment on it, I will or I'll see if someone else can and post it

Wednesday, September 25, 2024

Digitrax Closed on Thursday 9/26 Due to Hurricane Helene

From Digitrax - Sept. 25, 2024

Digitrax will be closed tomorrow (9/26/2024) as Hurricane Helene heads our way. We're putting our team's safety first with the storm coming in. We aim to reopen on Friday if it's safe. Thanks for your understanding, and we will let you know if anything changes!


  • If you have an idea for a blog post here, let me know. If I can comment on it, I will or I'll see if someone else can and post it

Friday, September 20, 2024

Replacing the Sound Module in a Bachmann Spectrum EM-1 Locomotive.

Need to replace a Bachmann Spectrum EM-1 sound module? Be careful!


Fig 1 Standard 21 Pin Decoders Not Compatible

The key take away here is that standard 21 pin(Soundtraxx Economi, Tsunami2, TCS 21 pin, etc.) are not compatible with the sound module that accompanied the EM-1. One option is to install a Soundtraxx TSU-2200 decoder. How to do this is explained in this video from Soundtraxx.

Another option is to install a DecoderBuddy motherboard by NixTrainz and the 21 pin decoder of your choice.


  • If you have an idea for a blog post here, let me know. If I can comment on it, I will or I'll see if someone else can and post it

LokSound Volume Control Options (There are several)

An excellent discussion of the different ways to control volumes of the various sounds of LokSound decoders took place recently on the groups.io LokSound forum. It started with a user wanting to know the difference between the controls on the Decoder tab and the Sound tab. See figures 1 and 2.

Fig 1 The Decoder tab

Apoorva (better know as the IndianRailModeller) gave a good explanation of the difference and even explained additional ways to control volumes.

The volume setting for a soundslot set from the Decoder tab (figure 1) is like the Master volume control for each soundslot. In the same example, let’s say your Radiator fan soundslot is not very audible. Changing the volume setting from say 60 to 128 under soundslot settings will increase its volume, and the change will be applied equally to all sounds in the soundslot.


Fig. 2 The Sound tab

The volume settings in the window in the bottom right of your second screenshot sets the volume at which each individual sound file plays at when used in any of the sound slots in the sound project. Let’s say you have a Radiator Fan sound slot that uses three sound files, a start sound, a single loop sound and an end sound. The volume of each of the three sound files (typically a 16-bit .wav file) is set in this window. Let’s say you change the volume for the loop sound file from 100 to 150 and leave the volume of the start and end sound files at 100, when you play the radiator fan soundslot, the loop will play louder relative to the start and end sounds. Further, the loop sound will also play at the higher volume setting of 150 if it were used in any other soundslot.

Continuing, Apoorva stated there is in fact a third place where one can change the volume of individual soundstates and sound containers. This is contained within the sound flow of soundstates. Open a soundslot and click on any sound state or container and the menu on the left has a volume setting that one can use to increase or decrease the volume of that particular soundstate or sound container. See figure 3.

Fig 3 Container sound control

He also mentioned that ESU uses this third method of volume control in their prime mover Dynamic Volume Control feature in the most recent versions of their diesel sound projects. They set the volume of the idle sound to a low volume (Volume setting of 50) and each subsequent notch is set to a progressively higher volume, all the way up to 128 for Notch 8. The transition soundstates between notches also step up in volume from the previous notch volume level to the next notch volume level. This gives a more realistic sound transition that many modellers like. Open up the prime mover soundslot and browse around clicking on the various sound containers/soundstates and take a look. 

Apoorva also has a YouTube channel containing videos demonstrating his custom prime mover sounds along with other topics.


  • If you have an idea for a blog post here, let me know. If I can comment on it, I will or I'll see if someone else can and post it

Sunday, September 8, 2024

Announcement From The JMRI Community - 25 YEARS!!

The Java Model Railroad Interface (JMRI®) community announces two major milestones:  the 25th anniversary of the first use of JMRI and the 10,000th update to the Java Model Railroad Interface software used by almost 50,000 model railroad hobbyists for managing and operating today’s digitally controlled model railroads.  With over 300 developers worldwide having contributed, the “community sourced” JMRI project began in 1999 to provide a way for model railroaders to manage the complexity of train engines fitted with digital decoders.  Today, model railroaders worldwide use the greatly expanded JMRI system for everything having to do with the development and enjoyment of modern model trains and layouts.

Bob Jacobsen, a member of the original team and still a senior developer, said “JMRI has helped bring the sophistication of modern electronics and computers to thousands of model railroads - all based on open source software.”  Not only model railroad hobbyists, but millions of people of all ages have seen JMRI in operation at holiday train displays, hobby shows, and train exhibits at multiple museums around the world.

 

“JMRI was one of the key steppingstones in the wide adoption of Digital Command Control across the model railroading community by making the process of implementation easier, visual, and common across all manufacturers,” noted Peter Ely, a founding member of the NMRA DCC Working Group.  “JMRI itself grew in complementary directions to allow the typical model railroader to do things at the system-wide railway level only dreamed about by the original working group.”

Jacobsen said that JMRI development continues to keep pace with changes in technology and that another 10,000 updates are likely over the next decade.  It is through the continued interest and contribution of time and effort of the community members that JMRI feature are expanded and technology updated.  Interest in JMRI extends over dozens of user forums and social media platforms, with over 8,000 users participating in the primary user forum on groups.io, asking questions and contributing answers and suggestions that are used to expand and improve JMRI capabilities.

 

Congratulations and thanks to all who have participated in using and improving JMRI, now and into the future.

 

About JMRI 

The Java Model Railroad Interface project was initially a modest undertaking of some dozen model railroad hobbyists who wanted to bring their computer skills to the emerging field of digitally controlled model trains.  Forming an open source software development project, their first output was called DecoderPro® and provided easy-to-use screens for managing “configuration variables” in the small computers that manufacturers and hobbyists were installing in train engines.  The effort expanded to create PanelProTM with features for controlling all types of electronic devices and automating train operations by monitoring sensors around the layout.

Unfortunately, the community was soon embroiled in a copyright and patent dispute that resulted (after seven years of litigation) in the landmark Jacobsen v. Katzer case that helped establish the legal basis for today’s open software movement. The Electronic Frontier Foundation cites this case as one that has allowed the internet to flourish and find its way into millions of computers in homes, offices, and businesses.

 

JMRI today provides functions including management of Digital Command Control decoders in train engines, cars, and other devices, graphic display of small and large train layouts, on-line real-time operational monitoring of sensors and other devices, automation of train operations, and management of realistic train operation scenarios.  JMRI also provided the first widespread implementation of the WiThrottle protocol.

 

New releases of JMRI are made available to users approximately monthly.  JMRI is comprised of several thousand source files available at GitHub, the free open source code repository, and is maintained and expanded by community members.  One of the milestones celebrated today is the 10,000th developer update to the JMRI repository on GitHub, indicating the robustness and on-going development of this important open source project.


  • If you have an idea for a blog post here, let me know. If I can comment on it, I will or I'll see if someone else can and post it