pauliebanger

PM me for help. Paul

It's possible but only with another Select sound project. Paul

Unfortunately, from your description of events you have probably shorted the speaker terminals if they touched metal (eg chassis) simultaneously. If the sound was 'on' when this happened, the very low resistance would cause the decoder's amplifier to die. This would be why no sound is heard. Often there would be no sound at all rather than buzzing. At this point there's not much you can do other than return to your supplier for a repair or replacement, but it's probably worth doing a reset before this. Programme CV8 = 8 to reset. For the future, consider covering the metal parts of the speaker with insulation until it's finally fixed in place, since such catastrophic failure is instant giving no time to react. ESU have a good warranty policy, so, as sickening as it appears now, all is not necessarily lost. Good luck. Paul

Flange squeal in this project is a simple on/off function. There's no native way to stop this sound automatically. Later versions have speed related flange squeal which does automatically cease when movement stops, but that requires special scripting to be added during project creation/ sound loading. So, to get that, you'll need a re-blow. PM me if you wish. Paul

Should be very soon now. The one on eBay says with 'a' Paul Chetter sound project. My projects are readily available from Digitrains, including one for the Victory. I'm sure it sounds great. But the one I've created for Planet Industrials is an exclusive custom sound project, specially compiled to take advantage of the new ZIMO MS decoder. This includes 2 new, unique, operational sound features to enhance your immersion and enjoyment during shunting movements. I know the wait is frustrating (I'm in the queue too!), but it should be worth it. Paul

Don't be shy, the RTR sound fitted versions will be the way to go. I'm working on the sound projects for the factory sound-fitted Black 5s currently. They'll knock your socks off. Full suite of authentic sounds, playback in 16 bit resolution, plus a host of added functions and features. The sound will operate on DCC or DC analogue by default. And you will get far more on analogue than just the exhaust sounds. Paul

Hi Ian, Ok, those CVs show that whatever the sound project loaded, it's set up with significant momentum, CV4, Brake Key on F2, CV309, and high brake efficiency, CV349. So it should be working. Of course it's set up to simulate real brake action, not toy train brakes like some other brands efforts. That means that in order for the brakes to have any actual retardation, the operator (driver) must first reduce the regulator/throttle. This can be set to any speed step below the current one, including to zero. With the throttle reduced, the brake feature will reduce speed in a progressive curve until the new speed is reached or the loco halts if at zero. The way the operator uses the Brake Key determines how the curve is modified in real time, so the operator is always in control of the braking simulation. This is all explained in the project's User Notes. Incidentally, if the brake key is engaged without first reducing the throttle, the feature still has a useful purpose. The loco cannot increase in road speed until the brake key is released, even if the throttle setting is increased and whatever may happen to the engine sounds as a consequence. Use this to traverse speed restricted sections, a sort of upper limit cruise control. You can see why this multi-use feature is so popular with ZIMO users. I didn't comment earlier on the brake squeal which you believe to be missing. It's not. It's just accurately selective. If the brake key is not active at the time of stopping, there will be no brake squeal. The attention to detail in these projects is there in order to produce realistic effects. As Paddy M might have said, No brakey, No squeaky! If other projects produce a brake squeal when the brakes have not been applied, that says more about their lack of realism than ought else. Lol. I can't think of any adjustments which are necessary, or possible. I can see only one circumstance (with a fault free decoder) in which the reported CVs can be in place and the feature not operate in exactly the way I described above, is if the decoder software (not the sound project) is ancient. Versions prior to my introduction of the Brake Key Feature, will accept values in CVs 309 and 349 but will have no effect. Paul

The PowerCab F2 key is not momentary, it's latched as are all F keys. The Horn/Whistle key is momentary and will play/activate whatever is assigned to F2 for as long as it is held 'ON'. The default set up on the PowerCab is just daft, and is not the ZIMO brake feature you are seeking, but the manual explains how to assign it to something useful. However, that has no effect on your reported problem, Digitrains and the Farish rtr default setups work fine out of the box. So something's wrong. Reset the decoder, CV8 = 8, probably all good after. If not, come back. Let us know the values in CVs 4, 309 and 349. The model, sound project name and from where it was sourced are all relevant details that would help us to help you. Paul

If the Bachmann non sound decoder is also a ZIMO, (rebranded) then your initial thoughts re copying the sound decoder CVs should work fine. Paul

I should have been clearer. The arrangement with ZIMO is that PI can fit decoders to rtr Victory models and supply decoders to customers of DC versions for retrofit. Since no one has yet received a sound decoder, even in RTR purchases, you are in the same position as everyone else, so PI should be able to supply the decoder and sound project when stocks are received from ZIMO. Paul

Don't know what you have heard but the factory sound chuffs at 4 per wheel revolution, just like the real Victory and any other 2 cylinder engine. PI should be able to supply this version when it's back in stock. Paul

Which Class 37 version did the decoder you are using come from originally? There are, apparently, 4 different versions of the sound project. We need the version you have in order to know how the fan should operate. Paul

Don't mess with CVs for this. If you have a Bachmann supplied sound decoder, all CVs are correct for appropriate fan operation, even when not originally fitted. Just plug fan unit in correctly and it will work. Fan operation differs between model subclasses, most do not operate immediately when the engine starts up. (Like the real thing). Paul

If you have the Bachmann supplied decoder and sound project you will just need to add the fan module and connect it correctly. It will automatically operate according to the pattern applicable to your particular model. No CV changes required. Best regards, Paul

Hi Dave, Yes, that's possible, but the decoder's DC output to the track will leave it very vulnerable. An alternative which would be less risky, perhaps, would be a non-sound decoder in the loco and the sound decoder located remotely with a speaker. Use the same address on each decoder and run in consist. Saves the DC switch/power sections issue, engine sounds can follow the road speed more closely and the layout can be DCC so other DCC locos can be run together as usual. The If you use a ZIMO sound decoder it could even have several different loco types (selectable) in the project, to make this prospect a little more affordable. I've supplied a few special projects for this type of operation over the years. At least one was discussed here on RMweb, but I can' recall the layout's or title of the thread, but it was a club exhibition layout, quite successful, so maybe someone remembers it? Best regards, Paul

Yep, microfarads is what I meant. Matt, The Lais 'Kung Fu' stay alive supercapacity packs described by Nigel do not require the LifeLink as the charge/discharge managemnet and voltage regulation this supplies are already a component in the Lais pack. The Lais unit is available in 3 different formats, each with same capacitance. Choose the best shape for the space available. This is what can be achieved, though for actual operations, it would be wise to limit the duration with CV153.

Matt, The amplifier could be the power 'tipping point', still most likely due to less than perfect contact somewhere. The 03 does not have the best reputation for good track to decoder power pathways, though mine runs very well. You could test your theory by running with sound on but reduced in volume, either by using the 'volume down' key or reducing CV266 value to around 60 (just for these purposes). What voltage is arriving at the tracks? Can you adjust this on your DCC controller? (What's the make and model?) If so, try gradually raising this until sound performance improves. 16v is not outlandish - the decoder has a max voltage input of 35V, so plenty of headroom. Stay alive performance is mostly related to capacitance. CV153 = 0 or 255 means the all of the available power will be used, any other value will give a proportionate reduction in use from that. CV153 values can reduce duration of power delivery from a very large capacitance, but cannot make a tiny capacitance provide additional power. Size matters, and so does one's expectations. A 1000ohms capacitor will help over small dirt specks by keeping the decoder alive and amplifier running, but the amount of wheel movement will be imperceptible. You will need several magnitudes higher for visible benefits like traversing insulfrog type points. I notice Nigel Cliffe has posted a detailed response on this whilst I'm typing, so I'll end now, only adding that I agree with him. Best regards, Paul

Matt, Forgot to mention, F8 is the ZIMO factory default sound ON/OFF key with built-in fade so It's likely that you have reverted to ZIMO Factory defaults. In this condition, you will need F8 latched on to get any sound, and movement to increase engine revs. You may find that other parts of the sound project will operate too but with odd behaviour. They may not match the F keys to the expected sound either. (UK sound projects use F1 for sound ON/OFF, so when your reset is successful, remember to use F1 latched). The sprint starts are a sure sign of the decoder reverting to DC operation, and as the track is at full power whenever it's connected to DCC, the decoder gives the motor 'the full beans'. Incorrectly reverting to analogue can be due to a number of reasons - poor electrical contact, incorrect CV settings or faulty/damaged decoder components. Bachmann state that this model will run on DCC or DC out of the box. If you do not intend to operate on DC, you can disable analogue operation with a CV change*. This will prevent the decoder entering DC mode. This may cure the problem completely, but if not you may need to investgate further. *To do this, change the (project default) value in CV29 from 30 to 26. Best regards, Paul

Matt, What was this reset feature you employed for your reset? Factory settings are the ZIMO defaults and will typically allow decent running. However, they may have little in common with the defaults set in the sound project of a ZIMO sound decoder. It's perfectly possible that the sounds are still there, but incorrectly set CVs (factory defaults) are preventing you from accessing them, so it's worth eliminating ths possiblity before moving on. To correctly set sound project defaults, use the CV8 = 8 reset method. (CV8 is read only and is locked at 145 for ZIMO decoders. You will never read the value '8' so don't bother trying). CV8 = 8 is a 'pseudo' programming command. It does not write the value to CV8, but it does start the process of installing the sound project CV set. Suggestion. Set the address to a single number other than 3. Perform the CV8 = 8 as usual. Check that CV1 = 3 to confirm the reset has 'taken', then test all features. If the address has not reverted to '3' then repeat the CV8 = 8 routine until it does. With some DCC systems POM works more reliably than Service Mode, so if you have difficulty resetting try both methods. Best regards, Paul

Dave, Maybe they will, so it's worth keeping a note of ypur prefered values. I will not be directly involved with these projects in future as Digitrains will be maintaining and updating them. Best regards, Paul

Hi Dave, I had a lengthy technical response from ZIMO just now. The bottom line - the Firmware has been changed at V4.226 (actually at V4.225.1 and V4.225.2 but I don't think these are public releases) regarding the Brake Key in Light Engine mode. You're probably not going to like this next bit, however. LOL. The operation in V4.219 was incorrect. V4.226 aligns the brake effect with the way it has always operated on MX decoders. So, you have a couple of options. 1. Backdate your firmware to V4.219. (but see below*) 2. make the adjustments I suggested earlier to achieve the correct balance to suit your needs. If you do think about changing the firmware to an earlier version, please note this warning which I copied from the firmware page on ZIMO's website. ATTENTION! As of SW version 4.225, downdates are STRONGLY DISSUADED! After an update to SW version 4.225, a downdate of the decoder to an older SW version is only possible to a very limited extent for technical reasons - the decoder may no longer respond! A downdate with MXULF works on decoder firmware level, but the loaded sound project including settings is no longer accessible! (ZIMO sound projects can, however, be reloaded from the sound database). Future updates can then be downgraded to version 4.225 again. Best regards, Paul

I'll contact my colleagues at ZIMO and get back to you.

The MX658N18 has 4 'normal' (aka 'full power' or 'open collector') Function Outputs and two further Logic Level Function Outputs. (LL output has to be selected using CV 124 Bit 7 and anyway will require amplification to be suitable to operate most functions). All FOs are passed through the Next 18 connector. The first 2 FOs (FOf and FOr) are used for front and rear directional lighting, the next two (FO1 and FO2) can be used for whatever you wish (if they are not already in use). Look on the loco PCB to see if the relevant pin outs are provided with a solder pad (on the PCB). You might be lucky, depends what the manufacturer decided to include. Good luck with trying to wire into a Next 18 connector. Maybe better to replace the Loco PCB with a Next 18 adapter/break-out plate which will have reasonable sized solder pads, one for each separate pin in the Next 18 interface, giving you full access to the decoder's features. see this: https://www.digitrains.co.uk/next-18-adaptor-board.html Best regards, Paul

Dave, I can't answer your question any differently. One of the possible variables I mentioned earlier is the decoder. This could be due to changes in hardware*, firmware or a combination of the two. *Shortage of components has caused some design changes. So, yes, it may be the firmware. What is the firmware version on the L&Y which works to your satisfaction? And the version loaded on the more recent one? (CV7 for the main version number and CV65 for the sub-version). BTW, issues with multiple triggering of brake squeal below the value in CV287 should have been fixed at V4.205 (December 2021) Best regards, Paul

Dave, The default settings for those CVs are what Digitrains and I decided was appropriate for the Hornby Peckett model, and from your posts, have not been altered. Individual users can choose to change them to suit- that's the advantage of highly configurable decoders like ESU and ZIMO. The downside is that they can seem complicated, unfathomable even, for some. The same project on the same decoder in the same model with the same operator should produce similar results, within a small margin. This gives at least 4 possible areas where dissimilarities can arise, and you can add one more when layout type is added. Given your displayed skills at customising, re-engineering and re-motoring models are you sure you are comparing like with like? Regarding repeating brake squeal. This is a consequence of changing the sound project's parameters. Here's a brief explanation. The brake squeal sound sample is of a finite length. The decoder is internally programmed to play the Brake Squeal during the final portion of F2 brake application. If the duration of brake application exceeds that of the brake squeal sample, the decoder will play the sample again. During sound project creation, these are balanced to produce the correct single play event. If parameters are changed, this balance may be upset CV349 = 20 which you have used will give a braking duration far longer than the CV349 = 6 which is the project default, thus requiring three times the sample length to cover the braking duration. There are several changes you can make via CVs to bring this back into balance so that the brake squeal plays only once. I suggest that you make small changes at a time to one or all of them until you are satisfied with the results. My suggested order is as follows: 1, Lower the threshold at which the Brake Squeal sound begins. This will shorten the 'play' duration to more closely match the length of the sound. CV 387 = 40 is the default, try 20 or even 10. (It is possible to reduce this too far which results in the Brake Squeal being reduced so much that it becomes almost inaudible, so use some discretion) 2. If this does not prevent the repeats, increase the brake efficiency a little at a time. CV349 = 6 is project default. Lower numbers give shorter stopping distances, higher values give longer. Small changes can make a large difference. I find that values between 5 and 10 are most useful, a value of 20 suggests you have a leak in your brake pipes! Lol. (just my view). 3. Reduce the 'normal' value in CV4. The default is 100, try something around 80 (the smaller the number, the quicker the stop). This has implications beyond Brake Squeal duration so use with caution. If you get lost, CV8 = 8 will reset to defaults so you can start again. Are you using Shunt Mode when these problems occur? The way this operates has changed on MS decoders and may have an undocumented impact here. Try the above, first, and let me know outcomes. One further thought. The MS decoder hardware is of significantly higher specification than the MX and requires higher power for programming . Make absolutely sure that when you make a CV change or perform a re-set, that it actually occurs. Repeat if necessary. Best regards, Paul