开云体育

Hi Dave and everyone, First off, this turned into a pretty long post so if nothing else, please see near the end, the section starting with "REQUEST FROM ZIMO FOR HELP - - - ", they could use help from someone in the USA with familiarity with Zimo products and maybe also web site design. best combination is a Zimo motor decoder with a SoundTraxx DSX sound decoder. And most of us came to this conclusion independently. <<< To reinforce that fact, I've seen lots of people come to this conclusion independently too. Many times I've seen such posts on the SoundTraxx, Digitrax, the fairly new DCC Sound, and even the Nn3 group (and it wasn't all me ;^) <snip> the DSX. <<< I've found that to be necessary on two occasions also, both in HOn3. First a Roundhouse plastic tender where I hollowed out the plastic and the already glued in real coal load and 2nd a brass tender where I cut out most of the floor for the coal load and soldered back in a roughly rectangularly shaped bulge of .005 shim brass using 158 degree melting point alloy for solder (so I could get things hot enough to stick without melting the whole tender). Then a new coal load was glued back in, hiding the shim brass bubble. guys do in that scale. <<< Thanks for the compliment, I'm wanting to model the D&RGW from Salida to the end of the Monarch branch and would also like to include Salida to Minturn over Tennessee Pass to give me an excuse for running triple headed 2-8-8-2s and such. A narrow gauge 2-8-2 sitting next to a standard gauge 2-8-8-2 in the Salida yard is too big of a temptation to resist! I also like for all the function buttons. <<< Safe to call it another common "independent conclusion" I think. Now the interesting e-mail I received from Zimo the other day (it's good news). What follows is probably only really relevant to the use of SoundTraxx's steam engine DSX decoders. It describes a CV programming conflict that can occur if you would like to adjust the volume of the cylinder exhaust sound while an engine is running through the use of OPS MODE programming commands. Doing this is somewhat analogous to the manual RPM notching that the SoundTraxx Diesel engine decoders are capable of. I was talking to a local hobby shop dealer the other day and told them about Zimo decoders and they are going to look into becoming a dealer. After that I came home and got onto the Zimo web site which I hadn't been on for a while. I noticed that the English content had gone down quite a bit since the last time I was on which wasn't all that long ago. There was mention in there somewhere that they had recently made a lot of changes and updates and I assume that they haven't had a chance to "catch the English version up" so to speak. Still, I was concerned enough that I wrote them an e-mail to voice my concerns because their site is a great resource and I think a very big aid to the selling of their products here in the states. I didn't expect to receive a reply but was pleasantly surprised the very next day to find one in my mailbox. The 'surprised' part came from the fact that I got a reply at all (I shouldn't have been so pessimistic I guess), the 'pleasantly' part came from what they had to say in response to a suggestion of mine. In short, the suggestion was that they relocate the function of their CV 56 to some other CV. Why? Well, I've found this CV to be the only CV that is in conflict with any of the CVs of the SoundTraxx DSX decoders, at least in so far as how I like to program and use them. And if it could be relocated in some manner, it would open up a way to gain some neat extra controllability for the sounds of the DSX that they don't have built in already, making the Zimo/DSX an even more perfect match then it already is. Bear with me, some explanation is needed to fully understand the CV conflict, why it occurs, what can be done about it, and what could be gained if it was resolved. The reasons a conflict arises with this CV is that in the Zimo it partially controls the operation of the Back-EMF feature and in the DSX it controls the volume of the steam exha

Gentleman, While CV 56 is the only major conflict between Zimo and DSX steam decoders. There are other major conflicts with Zimo and DSX diesel decoders in CV #56, #58, #60 and #61. There are also minor conflicts with both decoders in function mapping of CVs #33 thur #40. These are all conflicts that happen on all DCC systems, but users of the Zimo DCC system have many more conflicts because they also use many of the special Zimo features. I would like share with you my simple method of programming multi-decoders locomotives. It works well as I have been using it since I beta tested the DSX many years ago, and many of my client have been also happy using the method. I call it CV Multi-Address Programming (CVMAP) <A href="http://members.aol.com/dccatmlb/cvmap.pdf">Click here or copy URL : http://members.aol.com/dccatmlb/cvmap.pdf</A> Hope this helps. Best Dugan Shop foreman of the Miniature Locomotive Backshop: Dugan Gorman, PO Box 402, Newfield, NY. 14867 http:members.aol.com/DCCatMLB/intro.html Authorized Dealer since 1995 for: NCE, Zimo, Digitrax, Lenz, SystemOne and Soundtraxx. <A href="http://members.aol.com/DCCatMLB/intro.html">Miniature Locomotive Backshop DCC Sales</A>

decoders, there are other major conflicts with Zimo and DSX diesel decoders in CV #56, #58, #60 and #61. There are also minor conflicts with both decoders in function mapping of CVs #33 thur #40. These are all conflicts that happen on all DCC systems, but users of the Zimo DCC system have many more conflicts because they also use many of the special Zimo features. <<< Hi Dugan, You and I are on the same wavelength in regards to CV programming when using Zimo and SoundTraxx decoders together except in our respective definitions of the meaning of the word "conflict". I have 2 definitions for CV "conflicts", the difference between them is subtle but important. Which definition is applicable depends on what is trying to be accomplished with a programming action. In my original post, my use of the word 'conflict' had a much more restricted application than your use of 'conflict'. I used the word to mean there was a conflict in CVs when a person would want to use OPS MODE programming to alter the behavior of a decoder while the engine is "running" or "operating" on the layout to gain controlability that isn't available otherwise rather than to mean a conflict while doing the necessarry programming of all the CVs of both decoders. I fully agree with you in that for the Steam DSX CV 56, and for the Diesel DSX CVs 56, 58, 60, and 61 there is a programming conflict in the sence that if the two decoders are currently using the same address then you can't program these DSX CVs without messing up the same CVs in the Zimo (and visa-versa). However, for the Diesel DSX and using my restricted definition of 'conflict' to mean conflicts only when using OPS MODE programming to gain extra controlability, then CV 58 becomes the only (well, possibly only, see the next paragraph) CV in conflict between the Zimo and the Diesel DSX. As example, I can see a time in the future where I will have Diesel DSXs in some dummy B unit FTs, F3s, F7s, and F9s for use in helper sets to get long trains over the steep 3.8% ruling grade on the West side of Tennessee Pass on the Rio Grande from Minturn to the summit. When the helpers are cut out at the top, I may want to use OPS MODE programming commands to set CV 58 in the DSX so that on the trip back down the hill, the engine RPMs and dynamic brakes don't "rev up" to much (when using 'auto throttle notching') since it will be just the engines by themselves with no train weight behind them to have to brake. If I use "manual throttle notching" then CV 58 is not in conflict at all (in my restricted sence). I haven't used any of the Diesel DSX units yet so there is something you could clarify for me that is important to this discussion. When you turn the dynamic brake sound on, is it affectted by the throttle setting as far as a "speed" of the cooling fans or the "volume" of the brake sound? If so then there could be another conflict in my restricted sence in that it could be handy to be able to change CV 61 on the fly to manipulate the dynamic brake volume to reflect the engines braking a heavy train or just their own weight as in the case of my helpers returning home. Would the volume of the dynamic brakes even need to be able to change on the fly? If the prototypes don't then I don't need to worry about it. Any light you could shed on this would be great because I'm working on an E-mial to Zimo in responce to their suggestion that they could possibly incorporate a "SoundTraxx Mode" into their decoders to increase the compatability and usefullness of their decoders with the SoundTraxx brand of decoders. I also need to study the manuals for the newer DSD090LC SoundTraxx decoder line to see what might need to be taken into account of there as I've heard of some people using those decoders as a DSX when a DSX wouldn't fit their particular installation. The DSD150s don't appear to have any more conflicts than the DSXs do so they shouldn't be a problem. You also mentioned CV 56 and 60 as being in conflict between a DSX and a Zimo but again, as far a what these CVs control in the DSX, I don't see them as being in conf

I presently own all of Digitrax products. I have both 5 and 8 amp command stations and boosters. Throttles from the DT100,300 and 400 series, all radio controled. I have all their assesories and decoders. Also Soundtrax decoders are used in my locomotives. I have in the works a very large layout with the first leg of 2,000' of track being layed this summer. I am very much interested in the Zimo system and have contacted Zimo with my plans. The only reason that I have not putchased a Zimo system is because I like the encorders used in the Digitrax throttles and also the stand alone transponders. Also Digitrax has the best way to implement consisting with their "nested consisting." This metod of consisting is far more supieor than any other system on the market. I inquired to Zimo about the production of a stand alone id, nested consisting and encoder throttles for their system and have not got any reply. When I first contacted Zimo and told them of my plans and the purchase of thousands of dollars of product they semmed interested but when I asked them about product line and innovation I was ignored. My only fear with this company; are they willing to be responsive to the general user and not have a love it or leave it company policy. Zimo does have in the works a new throttle and time will tell. I feel that with these three innovations Zimo would be second to none but Digitrax has the most features and leads the DCC world in innovations. Ed

Hi folks, I just joined the group today. I've had a Digitrax Chief system for a couple of years now and just recently bought one of thier new DT400R wireless radio throttles with the 13 individual function control buttons (super for use with sound decoders!). My Zimo experience so far has been limited to installing a few of their MX61R- 2000 decoders along with some SoundTraxx DSX sound only units in some HOn3 engines belonging to a freind of mine. My own modeling is in N and Nn3. The best way I can describe the performance of the these Zimo decoders is WOW! I figured they would improve the running of the engines because of the BEMF feature and "quiet" high frequency motor drive but I was still very impressed when I saw and heard the engines in action for the first time. Zimo decoders are the first ones I've used that have BEMF motor control. For those who haven't had the joy of using SoundTraxx and Zimo together, let me elaborate. The first step for these engines was adding all wheel power pickup to the tenders. This made a big improvement to how they ran, very little anoying stalling at turnouts or on slightly dirty track. Next came the SoundTraxx decoders with cam synchronized exhaust and the Digitrax/Lens decoders for the motors. This took the engines performance up another order of magnitude because of the sound (obviously) and because of the pulse power from the decoders to the motor. They could run noticeably better at slow speeds comparred to running on DC. There were still some fluctuations at slow speeds but much less than before. Trouble was, having cam synchronized exhaust is great and all but it made the speed fluctuations a lot easier to notice which kind of spoils the illusion (I know, picky picky). The final step for these engines was the substitution of the Zimo decoders for the Digitrax/Lens. This took their performance up another order of magnitude! With the BEMF on, the slow speed performance was nothing short of spectacular. They could creep as slow as you'd like and the speed was perfectly smooth which meant the exhaust beats were equally smooth and regular. They finally really and truely performed and sounded like real steam engines! Also, with the high freq motor drive on, the motors and drive trains were nice and quiet, no more buzzing from the motor or drive line at 60 Hz. The icing on the cake is Zimo's added capabilities in regards to their momentum effects, the exponential acceleration and deceleration and the ability to turn them on/off or reduce their effects with the press of a function button. The Zimo decoders are the only ones I've seen that have realisticly performing and USABLE momentum. Now for my own efforts in N and Nn3. I don't have any Zimo instlaled in any of my N or Nn3 yet but I've done some test running of both by means of some flex track connected to the motor output leads of the MX61R-2000. The results have been as dramatic for N and Nn3 as for the HOn3. I can tell you from seeing with my own eyes that the recent N scale Bachman 2-8-0 is the absolute best running steam engine I have ever seen in my life when running with a Zimo with exponential accel/decell and BEMF. To watch it start and stop you would really believe it weighs tons. It has a smooth running motor and good gear reduction to begin with so the Zimo really lets it perform. Also, there was a huge difference in the performance of some large N scale articulated steam engines I have. On DC power and without the Zimo I would consider them almost unusable without lots of work but the Zimo is able to make them pretty good runners just as they are. I will tweak them as needed of course, then they too will be great runners. For the information of other people in N scale, the "HO" MX61 should have no trouble fitting in most medium to large steam engine tenders in N scale, it is smaller than any other "HO" decoder I've seen. What I'm really excited about is the MX62 Zimo is working on. With all the same funcions and capabilities as the MX61 (except for two less function outputs and lower overall current rating) their prop

quantities are still relatively small. <snip> decoder. Apparently there aren't many companies that succeeded in doing that. As always Zimo is leading ...... Hi Art, I've developed a theory - I think I've got a pretty good idea of what they were trying to do and what they were up against in trying to do it, until recently I worked for an electronics manufacturing company (got a better job now). Although all the eveidence was there to be seen, I didn't put it all together until recently. Their picture of the MX62 on their web site shows that much of at least one side of the decoder is covered with encapsulation and doesn't show many (or any if I remember right) individual IC chips. I'm pretty sure that what they had to do to achieve the incredibly small size and retain as many capabilities as they did was to litteraly put JUST the IC chip itself (just the cilicone wafer, no package) on the decoder circuit board and not a traditional surface mount IC chip with solder leads. I have seen this done on a small single board color video camera I recently bought to build a "rail- cam" car with. It has a number of these "raw chips" and the edges of them all are covered with a type of encapsulation. Mounting just the raw silicon chip on the circuit board could achieve anywhere from a 4X to 16X reduction in the area of circuit board required for any given IC chip but I can easily see it making the board 4 to 16 times more difficult to build. If I'm right, then like you said, "As always Zimo is leading". If I ever were to totally blow one up beyond all hope of repair, I'll have to disect it and test my theory. Later, Jim Hoover

Hi Jim, That's true. They directly bond the chip to the ceramic board. But they are not the first to do so: Selectrix decoders are build like that since more than 10(?) years. They were the first to build a decoder with just 14 x 9 x 2.5 mm^3 and it included BEMF. But it is NOT compatible with DCC and we with DCC are still waiting for a decoder with just 2.5 mm (0.1") thickness. Regards, Reinhard

OK guys, here's a conflict that is driving me nuts. (not hard to do!) I use a NCE PowerHouse Pro. I have a GP9 Switcher/Road Engine set up with a Zimo MX61-2000 and a Soundtraxx DSX diesel. CV3 & 4 are set fairly high (around 20) for the acceleration/deceleration that I like for road operation. F1 = Bell F2 = Horn F3 = Coupler Clank F4 = Dynamic brakes F5 - F7 Sounds/lighting effects F8 - mute All works great and I'm happy. So far , so good. Now, I also use this engine for some yard switching. I want one button to set CV3 & CV4 to zero so I have no acceleration/deceleration effect while yard switching and then by pressing the same button again I want to return to the original CV3 & CV4 settings. Still no problem. I just set CV124 on the Zimo to 7 and now F4 accomplishes this. HOWEVER, here's my problem (finally!) With F4 pressed once for yard switching, the Dynamic Brake howls continuously while switching. Very unrealistic, not to mention annoying. Two obvious solutions: 1. Using ops mode, set CV3 & CV4 to "0" for yard switching and then reset both CV's to "20" for road operations. Ugh! To much for my poor pea brain to remember. 2. Re-map the Dynamic Brakes to some other F button leaving F4 free to toggle momentum on and off. Possible, but all my Dyn Brk fleet uses F4 and not only would I have to reprogram every engine, I would also have to rearrange the other sound and lighting functions to match the new configuration in ALL my engines (steam & diesel) Until NCE comes out with the momentum button software update I think I'm stuck with option 2. Any other ideas? I have posted this message on several groups, so please forgive me if you see it more than once. Mark L.

Zimo-DCC@... writes: Sorry Peter . Yes it is described in the listed as Revision 3-15-02 for the MX61-2000e that is currently posted on the Zimo website. My mistake was that I had download the that same dated revision on 3-18-02 and on that date: CV124 half speed was not described in English, I had to figure out the German. As I regularly check the Zimo manuals web page for updates and revisions I saw no reason to download what listed as it had the same revision date of the manual I already seem to have. But since we are on the topic of Zimo manuals. When can we expect the completion of the English MX2 ( I made have also missed the latest revision if the revision date was not listed) and an English manual for the MX7. Best Dugan Shop foreman of the Miniature Locomotive Backshop: Dugan Gorman, PO Box 402, Newfield, NY. 14867 http:members.aol.com/DCCatMLB/intro.html Authorized Dealer since 1995 for: NCE, Zimo, Digitrax, Lenz, SystemOne and Soundtraxx. <A href="http://members.aol.com/DCCatMLB/intro.html">Miniature Locomotive Backshop DCC Sales</A>

seems to be here the problem, that CV 56 is ued in ZIMO for PID values and in Soundtraxx for some other thing. The proopsal is to make an option, to shift the PID thigs to CV 57. Do you think that would make sense ? The original meaning of CV 57 will be lost then (but in most apllication you do not need this "volatage reference" setting anyway. Hi Peter, This is Jim Hoover, I made the original suggestion that it could be very helpful for those who are using Zimo and SoundTraxx together, to be able to reassign certain Zimo CVs to alternate locations. To avoid confusion, I should have been more clear in my original description of this idea. Instead of saying that "if CV 56 could be moved to some other CV such as CV 57" I should have said "if CV 56 could be moved to some other CV that is not already being used". I would not want to see CV 57 made unavailable. I am close to finishing the e-mail that I promissed you, which describes my idea properly. I have researched the programming manuals for all the veriations of the SoundTraxx decoders which has revealed a couple of other Zimo CVs that it could be helpful to be able to optionally relocate. These few additional CVs would make both the SoundTraxx Steam and Diesel decoders of the LC100 and LC090 series very compatable with Zimo decoders in addition to the SoundTraxx DSX Steam and Diesel sound decoders. The reason to include the SoundTraxx LC series decoders is that there are people who are using these instead of the DSX, expecially because the LC090 are actually smaller than the DSX even though the LC090 have sound + motor drive capability. Again, thanks for your patience while I finish my more detailed e- mail to you. Sincerely, Jim Hoover

Jim Hoover. I believe that Jim's goal was to quickly and easily change the steam Soundtraxx decoder's exhaust volume (CV56) for a different load condition without affecting the Zimo CV56 PID settings, (Jim please correct me if I am wrong). <<< Hi Dugan, no correction needed, you are exactly right! that if you run (as I do) with the Soundtraxx decoder CV52 bit 1 enabled (Dynamic Digital Exhaust) then CV56 has no effect. <<< That is true, the DDE has to be 'off' for CV 56 to be able to effect the exhaust volume. I experimented with the DDE when I got my first SoundTraxx unit (a C-16 DSX) and connected it to the track and a small bookshelf speaker with alligator clip leads but I was a little disappointed by what I think is too little of an effect on the volume. For my tastes, it doesn't vary the volume nearly enough. Also, the DDE can't keep the volume "up" or "down" for extended periods of time like I would need it to do unless you use an unreasonably excessive amount of momentum. That was when I started thinking of using Ops Mode programming commands. Exhaust Tone for that same effect. <<< That is a very good point, I had kind of forgotten about CV55. Originally, I had played around with different combinations of values for both CV55 and CV56 and had found that I could get the widest range of effect for CV56 by setting CV55 (the exhaust tone control) to a value of 30 hex (48 decimal). This gave CV56 a good effective range of all but zero for CV56 = 0, and almost too loud for CV56 = 254 (at 255 the exhaust is lower in volume than at 254, don't know why). Once I had settled on CV55 = 30hex, I had not thought to change from that value. Thanks for reminding me of it, I'll have to experiment again with CV55 and see if I can get the volume range I'm looking for. If I can, I can see another advantage to using CV55, that being the change in tonal quality along with the potential volume change which could have a very interresting combined effect. Hopefully, it would sound duller (less high frequency content) at low volume and sharper (more high frequency content) at higher volumes. alter setting to CV54 Exhaust Cutoff Control and in effect act as a Johnson Bar. > Best > Dugan <<< I am a steadfast proponent of using cams if at all possible too ;^). I have experimented with adjusting CV54 also, and if it is used to effectively silence the exhaust, I feel it can be useful. But being the picky-eared steam lover that I am, I have noted that there can be a distracting quality to the exhaust sound if CV54 is even a little bit out of adjustment when any exhaust volume is present. The best way I can think of to describe this is to picture the normal exhaust volume on a graph such that the volume looks like a repeating series of "Bell" curves, the volume builds up and then drops off over at least some amount of time. If CV54 is a little out of whack in the wrong direction (meaning set too low), then the exhaust can start to take on the graph of a saw-tooth wave such that the volume is still building when it then instantly cuts to zero. This effect is most noticeable at slow engine speeds. It WILL reduce the exhaust volume by limiting how loud it has a chance to build to but the unnatural cut off at the end of each exhaust beat is what I would like to avoid. I'll experiment with CV55 and see what I can come up with, thanks again for reminding me about that. Jim Hoover

In a message dated 7/1/02 1:29:28 PM Eastern Daylight Time, Zimo-DCC@... writes: You can POM CV 124 = 3 when your road engine wishes to > defeat the accel-deccel, and POM CV 124 = 0 to return to mainline running > with accel-deccel active. > Although this is not as easy as using function 4 to defeat the Accel - > Deccel, it is another option. > > I would like to clarify the above statement. > It is actually just as easy or easier using the MAN button then the > F4 button. Here is why: > CV 124 can be set as mentioned above. But setting CV124 to the value > of 3 doesn't in itself defeat the accel/deccel function. It > rather assigns the MAN button for this task. The actual on/off > switching of this function is then accomplished by pushing the MAN > button (instead of F4). In fact there are more advantages to having > the MAN button: it is easier to find, because it is not part of the > other F buttons and it leaves F4 (or F7) free for other functions! > Not only can You simply turn the momentum on/off, as with most other > systems. Zimo gives You even more options. You can also set it so > that when You push the MAN button the momentum is reduced to 1/4 of > it's value written in CV 3 and CV 4. That engine may now react more > like a shunting engine, since even that one has some momentum. > Or it deactivates CV 121 and CV122 (exponential accel. and deccel.) > CV 121 and CV 122 is used to strech the acceleration/decceleration > rate in a selected number of speed steps (usually the lower steps). > It results in a non-linear extremly smooth accel/deccel behavier! > > have a great weekend everybody! > > Art > > MRS http://www.mrsonline.net/ Art I believe at present Mark is using the NCE system, so that the MAN button presently is not an option for him. That was the meaning of my original post, as an option to POM CV124=3 when needed. I am sure he will let us know it he ever wished to upgrade to Zimo system. Best Dugan Shop foreman of the Miniature Locomotive Backshop: Dugan Gorman, PO Box 402, Newfield, NY. 14867 http:members.aol.com/DCCatMLB/intro.html Authorized Dealer since 1995 for: NCE, Zimo, Digitrax, Lenz, SystemOne and Soundtraxx. <A href="http://members.aol.com/DCCatMLB/intro.html">Miniature Locomotive Backshop DCC Sales</A>

Hi Mark, I'll intersperse my comments between yours. efforts to remove conflicts between the two. My only concern is in using the Soundtraxx programming manuals as the "gold" standard that other manufacturers should work around. Although I love the Soundtraxx decoders, they cannot even standardize functions between there own products let alone another manufacturer. One example that comes to mind (and there are many others) is the DSX. You purchase a Diesel version, and try to set the volume control using CV50 as found in the Technical Reference manual only to find out that this is only for STEAM decoders. To set the DIESEL sound level you actually use CV61 (found in the Addendum for Diesel decoders). I won't even get into the fact that the two manuals cover both the DSD and DSX which give you a real interesting effect for the DSD if you happen to set CV50 "thinking" it will control the volume. <<< Your observations are well taken and have no fear, not lost on me. I have wrestled with the same thoughts. In regards to the writing of user manuals, I have done some install/user manual writing myself for a former employer who is a designer and manufacturer of aftermarket voice/data security electronics for 2-way communications equipment. With that experience under my belt I've come to adopt a bit of a foregiving attitude twords manuals in general (but certainly not blind foregiveness) since I have learned how much more difficult and time consuming it is to write a "good" one verses a "poor" one. All else being equal, I would have liked to see a fully separate manual for the Diesel version rather than an "addendum" but I can sympathise with their reasoning (to a degree) on how they did their Diesel manual. On the subject of the CV's functions not being consistant from Steam to Diesel versions I can only offer this; I can see a case for arguing that they (steam & diesel) are different enough animals in their sounds and how they need to be controlled that it wasn't practicle to maintain matching CVs and functions throughout both versions. My only support for thinking this is from a couple of conversations I've had with SoundTraxx on ideas for other sounds/functions I'd like to see. From what I understand, there isn't hardly a bit (or byte ;^) of program or memory space in their ICs that isn't already being used for the current capabilities. This is one reason I was so supprised when Zimo (Peter) responded with the possibility that my ideas were something that could be looked at. With all the great features the Zimo decoders have (NMRA defined plus all the additional special Zimo features plus small size) I would not have thought there was any "processor" space left to play around with! and next week Soundtraxx could arbitrarily use CV130 for some "we can't live without it" sound <snip> but in the absence of published standards, in my opinion, Soundtraxx needs to be a participant to this effort to make it really work.. <<< This is absolutely true AND the biggest "if" in the whole equasion. There are some mitgating circumstances that could (I hope) reduce the chances of disruptive changes happening. One is the fact that there haven't been any changes to the DSD, DSX, or LC programming (that I am aware of) since thier introductions. The LC series has seen the introduction of the LC090 but it doesn't have any changes except the addition of cam synchronization for steam (a big plus) which doesn't cause any CV conflicts. As I mentioned above, it would seem that there is not any room left in the SoundTraxx ICs for more sounds or features than they have now so (hopefully) there wouldn't be changes that could throw a wrench into the works. This isn't to say that in the future they couldn't use a more powerful processor and add features (and CVs). One thing I will do is try and start a dialoge with SoundTraxx on the idea of "voluntary cooperative standardization between manufacturers" (a symbiotic relationship you could say) which would be to the benefit of both. It would seem to me to be a logical thing to do, after all, the reason Sound

Zimo-DCC@... writes: Mark, The Zimo "MAN" (Manual Override) is the way all other DCC run in as normal mode. Zimo uses extra packet bits of the preamble DCC signal to tell a Zimo decoder that it is working with special "Zimo only" instructions (some other Zimo only instructions are Signal Controlled Speed and Stop packets) . By pushing the MAN button on a Zimo system will tell that decoder to override the special ZIMO instructions. Since all other DCC systems run normally in "MAN" manual override of special Zimo instructions. You can POM CV 124 = 3 when your road engine wishes to defeat the accel-deccel, and POM CV 124 = 0 to return to mainline running with accel-deccel active. Although this is not as easy as using function 4 to defeat the Accel - Deccel, it is another option. Also there is information in CV 124 that never made the English translation. If you set CV 124 Bit 3 on (1) [+8] you can use function 7 to cut the speed curve in half for slow speed switching. Zimo system users can also use the "L" button on the cab to do the same. Best Dugan Shop foreman of the Miniature Locomotive Backshop: Dugan Gorman, PO Box 402, Newfield, NY. 14867 http:members.aol.com/DCCatMLB/intro.html Authorized Dealer since 1995 for: NCE, Zimo, Digitrax, Lenz, SystemOne and Soundtraxx. <A href="http://members.aol.com/DCCatMLB/intro.html">Miniature Locomotive Backshop DCC Sales</A>

Train Connection Limited operates as National distributors in all states through a small but growing number of enthusiastic dealers and professional installers. In Florida we continue to operate our original retail outlet. We try and act as liaison with ZIMO/ Peter Zeigler. While relatively new to Zimo we are expanding our shop layout to include more Zimo/DCC features. Hoping to see a good group at next weeks National Convention in FT. Lauderdale. Clinic On Tuesday July16 10:30 am. Carroll

In case You haven't heard, the following is a news release from Zimo regarding a new generation of HO decoders: MX64- a new Zimo decoder familie, smaller size, more features then ever. Standard version delivers up to 1.2 A, high output version up to 1.8 A. And all this for a very attractive price! The new MX64 families of Zimo decoders come with all the advantages we have taken for granted on the MX61/2000. Thanks to using the most advanced parts available and an optimum layout configuration it was possible to lower the manufacturing costs and as a result make one of the most advanced decoder affordable for anyone! This is probably the cheapest way to enjoy a high performance decoder that includes features like: fully adjustable back-EMF, high frequency drive and fully compatible with core less motors (e.g. Faulhaber). Besides the basic MX64 (with 9 leads attached), the MX64R (with 8 pin NMRA connector) and the MX64F (with 6 pin connector) is also available. Preliminary specifications for the MX64, MX64R and MX64F are: motor current up to 1 Amp 4 function outputs 0.5Amp each 4 additional logic level outputs. total current 1.2Amp dimensions: 1.02x0.63x0.12 in. For the high output version, MX64H, MX64HR, MX64HF: motor current up to 1.5Amp 8 functions outputs total current 1.8 Amp dimensions:1.02x0.63x0.2 in. A special version, MX64B, with built-in sending unit for bi-directional communication is ready to go, as soon as NMRA makes their final decisions! Of course all the NMRA-DCC standards are fully met, such as: 5 digit addressing to 10239, 128 speed steps, programmable speed table, function mapping etc. As with all Zimo decoders, there are a lot more special features available: - fully adjustable back -EMF (programmable PID parameters) - high frequency operation up to 32 kHz, for ultra quiet motors - special CV's to guarantee smooth engine starts and stops - shunting function - engine won't stall on power interruption of up to 1 sec. (e.g. dirty track) - all special lighting (EFX) functions - Zimo's signal controlled speed influence - train number recognition This will be the first decoder that can activate a selected function(s) automatically at a specific point on a layout ("position controlled function influence"). For example: turning lights on/off, blowing the horn when approaching a level crossing etc. For more details (picture, prices) see: http://www.mrsonline.net/html/news.html Art http://www.mrsonline.net

<snip> Jim wrote: Jim, here is another possible conflict to add to your list. As you are aware, Soundtraxx uses F8 for mute. With my NCE system, pressing F8 using the Zimo MX61-2000 VERSION 13 and a Soundtraxx DSX combo mutes the DSX but also turns on the lights. It appears Zimo is shipping VERSION 13 with CV42 set to 16. Setting CV42 to 0 seems to correct the problem. Unfortunately, the Zimo manual does not even mention CV42 anywhere that I could find so someone not familiar with CV42 will have a conflict without an answer. I only have a few VERSION 13's, but all of them have the same setting. Can anyone out there verify my findings? Can anyone using a Zimo system share with us what CV42 (Function 8) is used for with a Zimo system? Thanks, Mark L.

Hi all, A couple days ago I received my first ever MX62W (the version with wires). Just thought I'd pass on a first impression. These are very impressive looking decoders. The PC board is thin, and for those who aren't aware of the developement challenges this decoder had to overcome, is not made of the traditional layered fiberglass/epoxy like you might expect. It is a type of material that is more like a ceramic. The placement of the components is also very good (I used to work with PC boards with these same kinds of very small surface mount parts). I haven't had a chance to hook one up and try it but having used several of their MX61 decoders in the past, I don't think that is too important at this time. There is only one significant thing I feel I should point out at this time, that is that because of the way the decoder's output connections are configured, the two decoders I have don't quite meet the dimensional size specifications as listed in their manual and on the Zimo web site. The listed size for the MX62 is 9mm x 3mm x 14mm. Because there are solid metal pins that extend out from the circuit board which the wires attach to, the decoder should be thought of as 16mm long due to the pins sticking out at least 2mm from the PC board. This doesn't sound like much but it makes the decoder longer than the smallest Lenz decodrs, even though the circuit boards are virtually identical in size. Also, you can't unsolder these pins and attach the wires directly to the pads on the PC board because the pins are covered by encapsulation (looks like black epoxy) where they connect to the board. You could cut the pins flush with the encapsulation but then you'd have to solder the wires to the cross sectional end of the pin which isn't much to solder to. It would be very risky I think to try and bend the pins "up" to reduce the length because they are so short that they don't really have enough material to absorb a bend and they could break out of the encapsulation and off of the PC board, taking the solder pad for the pin with them. The decision to bring the wire connections off the board this way may have been due to considerations that I don't appreciate as yet but for now, all else being equal, I would like to suggest that if possible, a mask be used to keep the encapsulation off of the pads for the wires and the wire soldered to them instead of to pins. Afterall, this is such a great little decoder, it seems a shame to not keep it as small as the PC board. There are those times where every little bit of space is/will be hard to come by (especially in Nn3 and Z ;^) Looking forward to insalling one of these in either a Bachman Spectrum 'N' 2-8-0 or my test Marklin 'Z' 2-8-2 with the 6mm x 10mm pager motor and the Namiki 7mm planitary gearhead. The other has long been reserved for a freinds HOn3 2-8-0, inside the backhead space. Thanks for the bend of the ear, Jim Hoover

Hello everybody, Boy did I just save you all a bunch of reading. I decided to delete all the peripheral why's and where fore's I had written and just go straight to the heart of the matter. How about if we eliminate almost all the CV conflicts with sound decoders that we've been talking about in one fell swoop, not just with SoundTraxx, but with ANY brand (ESU, Lok Sound, Phoenix, QSI, Umelec) and with any and all other brands that I don't even know about or that will be introduced in the future? Pretty grandiose statement eh? I said "almost all" conflicts because as we have seen, there will always be the potential for instances to arise where two decoders might try to use the same "activating action" (pressing F8 for example) for effects which you don't necessarily want to occur in both decoders. The only solution to this would be the capability of re-mapping decoder function controls that would go beyond the current ability of re-mapping, and allow ANY decoder function to be mapped to ANY function button, not just a certain range of function buttons as the standard now describes. But back to my main point. The kinds of conflicts I've been talking about in most of my previous posts are the kinds that prevent two separate decoders from operating much more like a single unit that has the combined capabilities of both. There has been talk about moving CV's around (mostly from me ;^) so that conflicts are eliminated but as has been rightly expressed, this would not assure at any time in the future that new conflicts wouldn't appear and if I may be so bold, they WOULD almost certainly appear in time because of new brands and new decoders being introduced. So the problem becomes; What kind of a "universal" solution can be devised that can take into account the things that cannot even be foreseen in the future? I may have just such a thing, and it might be much easier to implement than moving CVs around. I originally thought of this a long time ago but forgot about it and didn't think of it again until recently when something jogged my memory. More on that shortly. What I propose is to add two CVs into the operation of a decoder that runs the motor and lights. The first CV would contain a number of your choosing that you would program to this CV. The number in this CV is your "key". The second CV would work as the "lock" that would turn off the decoder's Ops Mode programming ability by you programming a zero into it. After doing this, you could send Ops Mode programming commands to the decoder's address and it would just ignore them completely, except for the CV that is the "lock". The "lock" CV would remain accessible so you can "un lock" the decoder by sending an Ops Mode command to program the "lock" CV with the "key" number. Now I think you can see why this would be a kind of universal solution, it would work regardless of what brand of sound decoder you were using or what CVs controlled what sounds. To eliminate the problem of losing your key (forgetting the "key" number) and not being able to access the decoder, the "master reset to defaults" CV would also still be accessible when the decoder is locked. This would clear the locked condition and as normal, reset all the other CVs to their default factory settings. To reduce the possibility of locking when you don't want to, the value you are required to send to the "lock" CV to make it lock could be 255 instead of 0 because you would have to press 3 keys to enter the number (or at least you would have to press MORE that ONE key) so the chance of accidental locking would be reduced. A value like 255 to make it lock would also allow systems that don't use numerical inputs for programming (such as older systems like the Digitrax "Genesis") to still be able to use the locking capability. Also the key number would best be set to 0 in such a system to make it easy to input the correct key value for unlocking. Now, as to what jogged my memory. You may have seen this "lock" idea elsewhere before. There was a post to a Yahoo Group by someone that was describing a feature of a cert