TCS 501 decoder

Please note:

I finally upgraded my original WowSound G scale decoder to the new firmware. Thanks TCS for honoring this since it was so old. The unit I had was a very early one, and I understand many issues have been resolved, so I have archived the "negative" stuff at the end of this page. As I check out the new decoder firmware, I will revise and delete all the old stuff that is fixed.

Overview

I had previously found fundamental bugs in their decoder firmware, and the first WOW sound & motor decoder had lots of bugs. I also do custom speed tables and am anxious to see if that has been fixed. Personally I run Z and G scales, and custom speed tables are a must, for consisting, and my own preference to map speed steps to actual scale speed.

Street price is about $190 (list $240), so it has stiff competition from the already excellent ESU, Zimo, and Massoth decoders, with much larger and downloadable sound libraries.

Enough on the negative stuff, I will put details at the end of this page.

The decoder

In the picture below you can see the hardware for some of the features.

• 4 keep-alive caps electrolytic caps, 2.7 volts, 1 farad each
• there is a switching voltage regulator TPS54332 between coil at the bottom edge and the silver cap. By TI, a buck converter.You can see the inductor for the 12 volt regulated power on board. (square thing of ferrite with 150 on it)
• There are 4 soic-8 devices IRF7341, dual power mosfet, rated 4.7 amps at room temperture, but this also generates 2 watts. At 70 degrees C derated to 3.8 amps but still would generate 1.3 watts. Since these devices have no heatsinks, it's difficult to know what the continuous current is, and also realize that you cut the power in half if both FETS are driven. The forum has stated the maximum ratings as specifications, but this is an error. The manufacturer states that in a typical PCB mount, 0.8 watts is possible. (meaning some good solid copper under it). So a good guess is sbout 2.3 amps per package with only one output driven, and about 1.2 if both driven. So a good rule of thumb would be to keep outputs under one amp. Still an impressive number. If you are running a smoke coil directly, then you would want to keep under 2 amps and have no other significant load on the other 'half of the driver. 

 Underneath you can see the full wave bridge diodes and the FETs for motor drivers.

Specifications

I'm trying to be generous, but the manuals and specifications provided are very poor. Here are the ONLY specifications on this decoder:

Documentation - I found out you need all of these the hard way

1. The "manual" that ships with the decoder is flawed, heavy on the menu tree for the "audio assist", but no wiring hints, and weirdly missing things like it only shows part of the output programming CVs, leaves out the setting for Railcom, which is heavily promoted as a feature. (update, turns out that older decoders supported RailCom, the current WowSound does not, and future will support RailComPlus)
2. The next manual you should get is the "Comprehensive Programming Guide" first published in 2015, and revised in 2016 !!! This is very strange, in 6 years there have been no updates? This seems to be mirrored in bugs that have persisted for some time. The manual is touted as "The Comprehensive Programming Guide contains all the information we could fit into one document regarding CVs and decoder configuration." Well not so fast! It is still missing stuff you need for the WowSound unit. This guide also does not make clear which CVs are supported by which decoders - notably CV28 is there in my 501, but it does nothing, no RailCom.
3. Not in either the above manuals, there are version 4 wowsound programming guides, from 2016, mostly on sound but at the end is consisting, speed matching smoke control on a few pages. You need this document also to understand the indexed CVs that control throttle mode and the various resets NOT in the manuals above. Also the all important F8 sequence to switch between "sound mode" and "light mode", yep that's right a third manual with unique information.
4. After that, you probably want to download the sound lists to see what sounds you can choose from.
5. Just alerted to today, there is a TCS Wiki: https://docs.tcsdcc.com/wiki/Main_Page but not all documents are linked through there.

The wiring examples are virtually non-existant, and wiring is how people destroy decoders, not programming! There is a section on documented installations, and surprise, none for G scale.

Bottom line, start with the Wiki, and I will go and see if the wiki is missing any other official published document.

missing from the wiki:

• • easy way to find the comprehensive programming guide.... jeeze

Features

• The calibration mode is a great idea, will test, get an idea of how much track it needs.
• there is a diesel notching mode, will play with that, few decoders support that
• there is an AUX input and you can use it to trigger a sound, and you can control length of the sound loop that plays.
• there is a fan pulse duration for steam locos (on time, off time), needed to tune the "pulse" of smoke, since they do not do "fan braking" (the explanation of why they don't does not hold water)
• Built in keep alive (nice!)
• Built in regulated 12v power output, (but what is max output current?)
• Railcomm is supported, usability with various systems not documented, more later.

Railcom

Apparently the decoder supports Railcom and Railcom+  (update: so, while RailCom is promoted in various places in TCS literature, it is NOT supported on this decoder) The story is that TCS supported the original RailCom standard from Lenz, then when the group split up (Lenz taking their toys and leaving), then some decoders were left with "old" RailCom support and the new stuff does not have it, and it has been stated that TCS V5 decoders will support it. Basically, forget it for now.

Not shown in CV table in the supplied user manual. It is shown in the comprehensive guide. For this decoder, CV28 exists, you can set bits 0,1,2 but no RailCom support. They really need to erase everything about RailCom until they produce V5 and then be clear on what standard they support. Documentation is all over the place, and RailCom is touted in several places in documentation.

Bit 3 needs to be on in CV29 to enable Railcom (NMRA "bi directional communications")

First impressions in configuring:

Motor/Speed Control

The loco takes a long time to start and a long time to stop. I promptly set CVs 2 and 3 to zero (POM) and no change.

Put the loco into service mode, my Zimo system would often take a couple of tries to read back CV's, not good for a DCC decoder, service mode is required for a DCC compatible decoder. Eventually I determined if I did not get an ACK, to perform the action again. I did confirm 2 and 3 were 0. Luckily, the Zimo system will show if the response to a read is properly acknowledged, if not, do it again.

Ahh, the mode it comes in you have to hit the brakes to slow down. OK stabbing F7 applies brakes, works fine, I put my F7 on toggle, so each press applied more brakes.I believe this is "Throttle Mode 2"

I wanted "normal" operation for this, since many people will use it, so went into Audio Assistant and set throttle mode 1. (further investigation shows this can be controlled by an indexed CV)

I checked the momentum CVs, 2 & 3, they were 0 and 2....changed to 0 and 0. This is in an Aristo eggliner, usually run by kids. There is still some momentum there, that is not good. Worse, it still does not slow the sound down to match the physical speed, one of my gripes with the very first release.

Headlights

Now I have driving control, let's look at headlights. I would have expected the lights to work right out of the box. I have 12v incandescents that draw 50 ma.

According to the manual the F0 fwd and F0 OUTPUTS should default to 1 and 2 respectively, but they were 0 and reset to 0, so nothing worked.

So set CVs 33 and 34 to 1 and 2 respectively. (I also had to cycle F0 a couple of times on the throttle)

Controlling other function outputs:

It is worth going through the mapping sequence here, it is a 3 step process:

1. 1. first pick the "light effect" you want, There is a value for operation in forwards, reverse and both, get this number from the chart.
   2. next you put this number into a CV that maps this to one of the "Function Output" connections, ridiculously labeled F0 to F6, CVs 49-58
   3. Now you need to hook the Function Output to the Function Button number, CVs 33 to 44

So I decided to use an unused Function Button, the first function not mapped is 19, kind of goofy. All right, inconvenient, but trying to do the simplest installation.

Onwards:

Now map F1 controlled by Function key 19 (first available after all the defaults)

But NO!

Function F1 is controlled by CV35, oops, seems you cannot remap any of the lighting functions above F12, and there are sounds allocated to F1-F18.... worse only some functions can be mapped to some of the Function Buttons. Boy this is really old school! It's NMRA compliant, a spec written before sound needed function control too.

OK for the running lights on the eggliner:

1. 1. The light effect number is 32 for solid on bright both directions.
   2. I decided to have Function Output 1 control it, so set CV51 to 32 (and keep sending until I get an ACK in service mode, thank you Zimo!)
   3. Now map this output to Function Button 1, so set CV35 to 4

What? nothing happens. Oh further reading in other manuals reveal that there is a "mode" for the function keys, it is easy to get to, but goofy.

Pressing F8 in different sequences allows you to change modes. push once, mute, twice changes between "sound mode" and "night mode"... at least that what it sounds like... you listen to it... it's supposed to be "light mode"

so to turn on my running lights, press F8 twice, then F1... works!

There is a way to make it so that F buttons can work in either both modes, i.e. you can have a light function work at the same time as a sound function from the same button. By default, the headlight functions (F0 button) work in both modes.I might do that later, but I would have to put up with a noise every time I wanted to effect a lighting function.

At this point, I have an acceptable installation, not great with the mode switching though

Configure RailCom: (note after all the below experimentation, it has been made clear WowSound USED to support RailCom, current WowSound does not, future WowSound will support RailCom+, so all the work below was wasted, except that the Zimo system behaved in a reasonable manner)

Since my Zimo has RailCom, let's see what we can do:

RailCom is enabled in 2 places:

Bit 3 of CV29 should be 1, so add 8 to CV29

After doing this entering service mode there was a message in the upper right:

RailCom: Yes (B+D)

   153

(153 is the manufacturers ID for TCS)

OK, now there are some variants on the RailCom support, CV28:

Bits 0 - 3 represent some variations, by default CV28=7 (all variants enabled)

I'll explore more to see what I can do. My Zimo recognizes RailCom in OPS mode, it displays a different color on some indicators and the speed readback is from the decoder. That is not working at this time.

Tweak Sounds:

I guess the first thing to do is select the prime mover. Use audio assist to select prime movers

https://tcsdcc.com/DV4Prime

OK, horn:

Use audio assist, be sure to realize which horn you are changing, long, short or quillable (grade crossing?)

F2: "long horn", Make your F2 function momentary, so the horn will sound as long as you hold the button. If you leave as a toggle it goes forever.

F3: "short horn", Do not make F3 momentary, or you will get two horn beeps for every button press (on for F3 on, and one for F3 off)

F4: "quillable" horn, This which approximates a grade crossing sequence, you cannot "quill" the horn like other decoders. Do not make momentary

It would be much nicer in the audio assist for the decoder to announce the horn type/name and then sound the horn as opposed to just playing until you find something you like. Yes, you can use the CVs, and then find the unofficial list of horns and program, but it detracts from the usefulness of the audio assist feature.

Suggestions on the mode switching from sound functions to lighting output functions:

Having to toggle between sound mode and light mode is NOT superior in my mind, but it does work... having to make my locomotive blurt out "sound mode" or "light mode" every time I want to use a function key for sound vs function output is really a pain, especially since F8 is "touchy" since it is used for mute AND audio assist in addition to mode change. (and making the mode change quiet is not a solution since you NEED to know what mode you are in)

Suggestion that TCS can implement painlessly:
You have a problem caused by making them sound and function output control different modes. You filled the function buttons with sounds, but actually left 10 free functions keys/buttons, so allowing function outputs to mix with sound "outputs" would have been fine, you could map all 8 function outputs and still have 2 spares, if you were "modeless".. function outputs 1-8 (f0 already taken care of) added to function buttons 19-26 would disrupt nothing, you could even do this with your current system.

Proposed Function Button Mapping in "sound mode":

F0R & F0F - active in all modes - default
F1-F18 - sounds in sound mode - use the defaults as they are now
F19-F24 - map to F1-F6 IN SOUND MODE (NEW)

See, in sound mode you could also independently change the 6 Function Outputs with no conflict and no mode switching... nothing would be harmed.

If you wanted you could add in F0f and F0r outputs too, you still are not using F25-F28 function keys/buttons

A simple firmware addition with no conflicts... hope the idea is clear

Other comments:

EVERYTHING FOLLOWING THIS IS "OLD" INFORMATION THAT WILL BE UPDATED BY TESTING THE NEW WOWSOUND 501

Not tested yet, any improvements in the horrible bugs in custom speed tables.

In response to a thread where again my forum nemesis is questioning my statements on DCC, Stan Ames posted this email from "Dan in TCS Customer Service", posted May 7 2018 on Largescale central forum:  (red highlighting mine)

"TCS is continuously improving our products and services in order to better sever our customers and address their concerns. As a small, family-owned and family-grown business, we have of course climbed some steep hills. However, through hard work and determination we are proud to say we offer the world's best DCC decoders. We are aware of the initial 'bugs' in the WOW501, as it was rushed into production in order to meet the overwhelming demand. We have learned from this experience and responded to the negative feedback by ensuring we never rush another product. Very few WOW501 decoders are in circulation which still have the known bugs still in them. Once we discovered them, we had as many as possible recalled and updated. Decoders manufactured in or after May of 2017 are fixed. The WOW501 uses PWM on both the coil and the fan to provide the proto-smoke feature. We don't use 'fan braking' because it isn't constantly running. This can actually extend the life of your smoke unit. We're going to continue to experiment with this feature so we can implement it on HO decoders and smoke units.  Something else to be aware of is that WOW501 decoders (as well as other V4 decoders) have built-in protections such as over-heat sensors and protections which will turn the sound off if the audio peaks too high/your speaker shorts. I.E. if your volume is too high and you are playing too many sounds at once, the sound will cut out until the fault clears. 

Speed table issues are a hurdle we have done our best to fix, but it is a limitation of V4 and older processor architecture. The processor's breakpoints for the PWM on the motor drives can provide some odd results at specific speed steps. In most cases, you don't notice them, as they are more prevalent at high speeds. If you're running your engine like a Metro car, then sure, you'll notice. A fix was put in place in July of 2016 to address issues with CV5 and CV6. Additional fixes which we consider to have completely addressed problems were implemented in February of 2017. Lockups when using ULST were fixed in January of 2017. We haven't seen these problems on our new development architecture for V5.

We are also aware of the claims of 'erratic behavior', but have never observed this in-house. We have never seen one of our own test decoders lose its programming or stop responding, even after many hours in service with constant programming operations and power cycles. JMRI has been known to randomly do strange things to our decoders, but seems to have been fixed by version 4.7.3. We consider 4.7.3 and newer to be 100% compatible with TCS decoders.

Youtube video:

I just have to comment on the video which introduced this product.The Youtube video really set me off in a negative direction, the intro and ending music on the video is, well, over the top. Almost a minute of just the 2001 theme and loud, nothing else. Dear TCS: the WOW sound decoder is nice, has a good price point, but is not even on par with the movie 2001 and Stanley Kubrick. 52 seconds of music with no train! Also "coming in 2013" (now removed from the video)? I guess the "halleuja" chorus was indicative of TCS' celebration that it was only 3 years late from their prediction?

Sorry guys, I have to poke fun at this. Guys, please edit the 52 seconds at the beginning and the chorus at the end from the video!

 Looking at the video, and paying attention:

You hear the dynamo spin up, but the headlight goes on immediately, in a burst. Other decoders go from dim to bright like a real locomotive. The headlight also comes on before the dynamo has spun up, whereas it should come up after.

The next thing I did not like is that the transition from open drain cocks to closed was like a light switch, one chuff they are open and the next closed, no fade and all 4 close at the same time? Yuck. Just sounds artificial.

The first movement with the drain cocks on is not too bad, although you hear there is a sound with chuff and drain cock open, and there is a chuff and drain cock and rod clank, a little weird.

Whistle sounded nice.

The "dynamic chuff" is volume only. Compare this to a QSI or Zimo or Massoth where the sound of the chuff is different under load, heavy load, and coasting.

Also, for example, when you reverse direction, the QSI will give you the sound of the reversing linkage.

So, is it a good sound system, yes. Is it GREAT? No. It does not have all the nuances of sound we are used to having with the top level decoders.

At the time of release it was a small amount cheaper than the top decoders, now it costs the same or more as the competition that have more features, bigger sound libraries. It did and still has a way to go to compete head to head with a QSI or Zimo or ESU or Massoth.

Note: I am reviewing and re-testing all the items below with the updated decoder I graciously received from TCS.

 All I can say is WOW! What a mess!

I'm evaluating the Diesel unit and having some issues, and have noticed some disturbing things.

I installed this in an Aristo eggliner, this motor is noted for smooth and low power draw, and it was a convenient test bed.

First, I try the "typical user test", hook up the track and motor and speaker, put it on the rails and select address 3.

WHOA! The dang thing takes off... ok reduce speed to zero, the dang keeps going! Oh well, it stopped when it ran off the ends of the track! At first it seemed that the unit was programmed with an incredible amount of momentum, but reversing the loco did nothing either??!!

So, first impression: FAIL. Read the manual, and notice sound cuts out too, and the manual says use the audio assist menu and calibrate the loco. Hmm, you press F8 4 times to enable the menu, pretty cool... oops, press too slow and you mute the sound, press twice and came up, not four time. Oh, maybe the guys at TCS think F8 is momentary not latching. Anyway since the woman started yakking at 2 presses, I could tell I was in the menu.

OK calibrate the motor, you run it slow and press a key then fast under a load. OK, that surely fixed it. Run the train. Another runaway! What the hell? I noticed a brake function, that seems to do something, but up to 5 presses to get more brakes? How the heck do you remember what "braking level" you are at?

Running the loco I notice the sound cuts out and on usually when you reverse direction. I keep crashing the loco.

OK, read the manual again, notice the part about prototype mode and traditional mode, yeah saw that before... oops! There it is, the prototype mode, where you have to press F7 like a madman, in lower case, it says the DEFAULT mode is the prototype mode. OK, turn that off! OK, now it runs like the rest of the DCC decoders made in the world. (Note to TCS: you can make a decoder work with brakes and also recognize the throttle is turned to zero, EVERYONE else does this).

OK, now I have control, finally I can run on the layout. Good news, the times the sound cuts out completely is less, but NOT gone. Now the thing I notice is that the motor sound kind of runs on it's own, sort of like just running slow, no matter if you are accelerating, cruising, or stopping. It sounds like it is just coming off idle lightly. It makes a bit more noise when accelerating. So, very disappointing. Now come to a stop.... the motor sound will continue JUST the same as if it was running for several seconds.

Really disappointing. I'm sending it back. Really poor and how can someone not notice these things. I'm guessing, adding in my experience with the bugs in the firmware in the Z scale units also, and the big delay to market, that this unit is not fully baked yet. Perhaps in a year or 2 a new firmware update will correct this. The issue I have is that there is no mention of improving this or fixing this. In fact when I brought the speed table issues to light in their forum, all I got was denial and chastisement, but persisting and explaining brought a number of people out in the forums who have identical issues.

So, TCS, the hardware looks nice, the price point is good, the sound is adequate, dual speakers 8 function outputs, now just improve how it works please.

Programming track issues:

I have both Zimo and NCE systems. I rarely have issues reading ANY decoder with either, both do direct, paged and register mode programming,

But I had basically no success with the NCE system, getting erratic results or read fails. I could never read CV7 for example.

With the Zimo system, when you try to identify the decoder, the system will increase the programming voltage if it has difficulty, so it was running at 14 volts, maybe that is the difference. It also retries the commands a few times. I still had maybe 20-30% read failures, but could read often enough to get what seems to be the real values.

The CV's for the firmware date match the audio readout, and I was able to read CV7 most of the time.

So the upshot is that the decoder is not reliable in reading in service mode. One user says, Oh it works, in JMRI go to Preferences->Roster->Programmer and turn off Index CV Caching and Confirm Writes with a Read. These aren't compatible with TCS WOW decoders. No shit, you turn off the readback function. crazy!

Problem with setting "crew announcements" using AirWire

If your loco runs for a while and then puts on the brakes (makes the brake noise and stops), this is most likely the result of a poorly documented "feature".

What happens with this feature on, if you do not issue a command to the decoder for 43 seconds (default setting), then for the next 15 seconds, the system beeps, warning you of imminent "stopping" and after this 15 seconds elapses, the system will set the brakes, you will hear the squeal and the loco will stop.

In a quest for prototype operation, this feature basically emulates the "dead man's switch" in a loco... it makes sense from a prototype view, and from a "normal" DCC viewpoint makes perfect sense. DCC normally spends it's "spare time" sending redundant "speed commands", so this timeout never happens, and if it does, then that usually means something bad has happened, power is there but the DCC signal is corrupt.

OK, so why the problem using AirWire? Because a compromise has been made on some  "wireless DCC" systems. Power is never an issue for normal DCC since you have a 5 to 20 amp supply, but when your DCC command station is in a battery powered handheld, having the transmitter transmitting continuously is an issue. So normally products like AirWire ONLY transmit when there is a change, like you press a function button, or CHANGE the speed.

So what happens is you are merrily rolling along, everything is fine, but if you don't change the speed or push a function button every 1 minute, your train will stop because of the timeout in the "crew announcements" mode, which we have figured out is also a "deadmans switch".

So, the moral here is don't enable this feature in AirWire or any other system that does not work like "normal DCC".