Phoenix P5 Tips

• The Phoenix P5
• Programming 13 Sep 08
• P5 Issues
• Temporary Power Storage 11 Sep 08
• Phoenix Installations

The Phoenix P5 is a DCC compatible sound decoder primarily intended to complement an existing DCC system. However, with an added adaptor board, it can also be used on battery/RC systems as well. The P5 is functionally similar to the larger 2K2 systems but it does not include it's own analog input, battery or charging circuitry. It therefore needs a source of constant power from somewhere else or it will not function.

Both the P5 and 2K2 systems can read and interpret DCC command packets and respond to them for control. The P5 can be installed with just four wires, two for the DCC power input, two to a speaker. A remote volume control switch can be used but it is not needed with DCC as the volume can be controlled via DCC functions. It also can be reprogrammed via a PC serial interface to install firmware upgrades, install new sound files or to change some of the automatic sound responses.

2K2 installations are similar but since there usually won't be DCC available, the extra stuff (battery, programming interface and volume switch) is needed to program and use the system. The 2K2 already has the analog input circuitry on board. A 2K2 can be used in place of a P5 as it has all that is needed to work with DCC, but all the extra cost stuff is not necessary to work with DCC.

The P5 defaults to a reasonable set of function assignments to control the sound as shown in the table below. It responds to changes in speed, via reading DCC packets, in a reasonable way. When the loco is first powered up, the system plays the sound of a door slamming and then an engine cranking up to life, then two toots on the horn, then it settles to an idle. When the system shuts down, the system plays an engine being shut off. When the locomotive starts to move forward, the system plays two toots on the horn and the bell rings. After 10 seconds, the bell stops. The engine ramps up with speed, going through some speed transitions in the process. When coming to a stop, the system plays one toot on the horn and drops to engine idle. When starting in reverse, the system plays 3 toots. The system will optionally shut down after some user settable number of seconds after it was last used. At times, near a stop, the system plays a brake screech.

Sometimes the system doesn't play the single toot upon stopping. It appears to want to run for about 14 seconds before it will play the stopping sound although there are occasions where it had done it in much less than 14 seconds. The system also plays a grade crossing signal at a preset speed which is not settable via CV programming. It will only play once at that speed unless the speed is reduced to 75% of the preset play speed and then increased again to the preset play speed.

The system sounds can also be played and modified to some extent via manual DCC functions.

There are two levels of programming capability for the P5. There is some configuration setability via DCC CV's. However if more extensive programming is needed, then a PC with a serial interface running some flavor of Windows is required. I do not have a PC so therefore I may be out of luck in doing the things beyond that allowed by changing CV's.

The documentation that came with it said to program it's address on a programming track. According to Phoenix, the P5 is designed NOT to respond to the command station on the programming track, but it will still take the programming. The command station then issues an error when it does not hear back from the P5. This is by intent so that the P5 can be wired along with another decoder. The other decoder can then be programmed without the P5 interfering with the normal programming track feedback. If the P5 is to have the same address as the regular decoder, then the address can be sent to BOTH of them. The P5 address cannot be set to a different value from the main decoder this way though. If the P5 is to have a separate address from the main decoder, it should either be programmed BEFORE it is installed or some other means should be provided to have only one decoder connected at a time.

I needed to set the P5 to a different address than the main decoder so that some functions that I was using on the main decoder would not overlap with those functions on the P5. I set up a consist with the P5 address being the "top" address and consisted the main decoder to the top address. The overlapped functions are rarely turned off on the main decoder so I'd rather have those functions go to the P5 at the top address.

Phoenix also says that the P5 will not properly support OPS mode on the main but it worked just fine for me. Your milage may differ. Fortunately the CV's that I want to set on the P5 are not used by the regular decoder so I can send commands to program these CV's to both of them and the main decoder just ignores the commands.

I can do these things:

I cannot do these things without the dedicated programming interface:

• Balance the levels of individual sounds
• Change the response of bells and whistles
• Reassign sounds to terminals and DCC functions
• Modify how often a sound plays
• Modify chuff rhythm, compression and tone (not applicable on a diesel system)
• Fine tune for various non-DCC control systems

Phoenix sells programming software and an USB interface kit for the P5 and 2K2. The kit consists of a CD, a USB interface dongle and a cable that connects the dongle and the 2.5 mm programming interface cable that came with the P5. The software is supplied for Windows only and for me that was somewhat of a problem. I have no working PC's anymore. I, and my family, are all Macintosh users and what PC's that we had have long since bit the dust as, compared to a Mac, they were pretty useless.

My wife's laptop does have a copy of Parallels which allows Windows to be booted as a virtual machine within a Macintosh window. She has Win2K installed so that she can upload software to her Dell PDA. That is all it has been used for up to this point.

The Phoenix software installed and ran under Parallels and Win2K without difficulty and appears to work as advertised. I can do much more customization via this interface than is currently possible via DCC accessible CVs. Phoenix says that they have a Mac versions of their software on their "to do" list to make it easier on the rapidly gowning number of Macintosh users. While this "solution" works, it could be expensive as a new installation. Parallels itself is $80 and the user must supply his own copy of some version of Windows. Parallels requires an Intel based Macintosh and will accommodate DOS through Vista, Linux or anything else that will boot on a PC.

However, the Phoenix software does NOT run properly under Crossover (the Mac implementation of Wine). This system allows some Windows programs to run WITHOUT a copy of Windows. It does so by emulating the Windows API's. However, if a program makes an odd use of the published API's or it bypasses the API's altogether, then the program won't run under Wine. The Phoenix software starts up but can't find a port to use.

I didn't permanently install the programming interface in the Doodlebug, but I can pull it out via a baggage door for access. However, to reduce the possibility that the 2.5 mm connector on the end of the programming cable might touch anything in there and cause some difficulty, I put a 3/8" shrink tube collar around the connector.

The P5 worked acceptably well the way that it came. Although the volume was a little high to start with, it was easy to change.

All is not completely sweetness and light however, I have or had some issues.

First there was the programming thing. I solved this by adding some money to the mix to buy the programming interface which worked on a Macintosh with the help of some additional software.

Second is the tendency for the system to omit the single horn toot when stopping. Sometimes it does, sometimes it doesn't. I have yet to figure out what sequence of events drives either response.

Third is the response of the P5 to dirty track. It does quite well the way it is but on especially dirty sections where power is intermittent (headlight flickering and loco slowing but not stopping) the P5 will get confused and play the horn starting signals and maybe grade crossing signals at odd times. However, it doesn't make any popping sounds that I've heard yet. The engine sound does a good job of playing through the interruptions.

I can perhaps modify the response of the system to power transients via programming to make these transients less of a bother. I also understand that Phoenix has a hack that allows more capacitance to be added to the board so that the DC power to the system will remain more constant and it may not trigger these effects as often. I'll be dealing with Phoenix in the future to improve this situation but it is not a big problem right now. On reasonably clean track, the system seems to work reliably.

On dirty or oxidized track the P5, and without the help of some temporary power storage, does respond in various undesirable ways. Not all of the responses correspond directly to a flickering headlight which is a pretty clear indicator of power problems. This might also indicate that the P5 is not responding properly to garbled DCC packets. On very clean track, it doesn't do these things so power or signal interruption is involved.

I've seen the P5 do these things, more or less in the order presented.

• Play the start horn signal and ring the bell a couple of times while running
• Play the grade crossing signal for no obvious reason
• Restart completely with the engine startup sound
• Command itself to zero volume

The last issue has happened several times, always on dirty track. The sound just fades away over a period of a second or so and then the system seems to be dead. On a hunch the first time that this happened, I pressed F7 to increase the volume and it came back up in the idle state because it was standing at the time I did that. It was running all along, I just couldn't hear it.

The other times that it did it was 6 months later. I reread this page to see if I'd written anything about it and, lo and behold, I had the solution at hand, I'd just forgotten it. Getting old is not a good thing. Overall, I don't recommend it but it tends to beat the alternative.

A loco motor often has sufficient rotating inertia to roll right through a short power dropout. DCC decoders are designed to expect power dropouts and to be able to pick up where they left off when power and/or the DCC signal integrity is restored. Headlights, however, will usually flicker when there are power problems. Sometimes the lights will go out completely for a part of a second but the loco will keep rolling.

Sound systems are a little more touchy. A flickering headlight is a bother, but a sound system that drops out, pops, clicks or plays odd sounds is an outright annoyance. With too much of that, it'll get turned off. There isn't enough stored power on a DCC sound board like the P5 to keep it rolling through the inevitable blackouts that occur in track powered systems. It's nice to have the track really shiny clean, but that usually isn't practical. Once cleaned, the track will stay that way for only a day or so, after that, the systems need to be tolerant of interrupted power. Ideally, the sound system should hang in there as long as the motors do. This would imply that the system should continue to play through outages of half a second or so.

Phoenix has posted their recommended solution to allowing the P5 to bridge dirty track gracefully. It involves adding an external storage capacitor. Their solution doesn't require any modifications to the P5 board, it is inserted into the power/speaker harness in a plug and play fashion.

I did it slightly differently than the Phoenix recommendation, you can see the details on my Aristo Doodlebug Tips page.

I've done exactly one P5 installation so far. This is in a DoodleBug. I picked this loco for two reasons. It didn't have sound already and it's power pickup is not as good as most of the other locos that I have (only 6 wheel pickup). I knew that this loco would stress the capability of the system to deal with power interruptions. However, I expected more power interruption problems than I experienced.