DCC Concepts Zen Black Decoder Review - Just how good is their ABC?

DCC Concepts Zen Black decoders are being recommended by other Model Railway KZbinrs for their comprehensive ABC implementation.
Does it live up to the hype? Can I use this decoder on my fully-wired-for-ABC layout? Let's find out!
Table of Contents:
00:00 - Zen Black ZN218.6
00:57 - Decoder not recognised by JMRI
02:02 - The Manual (What's there, and what's conspicuously not)
02:40 - Sanity Checking on the DCC Concepts Forum
03:05 - Different Constant Distance ABC Braking implementations
04:48 - Testing the decoder's braking distance
07:11 - Understanding what has been implemented
08:20 - Testing the decoder's response with no.2 end leading
10:13 - Conclusions about the decoder
10:43 - Conclusions about the company

[@medwaymodelrailway7129]

Enjoyed your latest video and liked and share thanks DD.

[@medwaymodelrailway7129]

Thanks very much for replying to my comment. That's the great part about the hobby sharing ideas and learning new ideas from other people to improve our Channel. Take care and stay safe DD

[@chrisuddin9760]

Nice helpful video, I only have a 14ft end to end at the moment and I use these decoders in my Heljan and Hornby locos, I thought they were ok, good enough to just basically run your locos without doing the tests that you are but thankyou, you have helped me understand what they are capable of and I don't think I'll be getting anymore of these should I want to go down the same road as yourself, many thanks. Chris.

[@mywayididit3295]

Well done . You are 1 in a million the company doesn't expect a significant backlash against their bullshit. Most people roll over .give up or never had the intelligence to do what you have done .I wrote to a TV manufacturer when I was 10 . Asking about why the RGB was not ...... I forget lol 40 odd years ago.

[@chrissouthgate4554]

It is unlikely that I will be using DCC. However, Thanks for sharing your experience. Your frustration is very evident & the conclusion well warranted. I shall bear this in mind should the matter ever arise.

[@DongitsModelRailway]

It would be wrong to interpret this as a criticism of the concept of DCC as a whole. I am quite happy with the performance of the Zimo chips I'd previously been using, it's just the availability that is a problem...

[@billywindsock9597]

I feel particularly stupid after watching that. My layout has been left in the loft of my previous home and my new loft is a railway free zone at the moment. When I did play trains, I drove them around, made them whistle and stop and shovel coal and flange squeal and so on and have no idea, or have even heard of ABC constant distance braking. The graphs you made helped and I would assume that it is used for automatic train operation? Returning to the graphs, I would assume that all decoders should be able to apply graph one - trigger point to stop point - without a huge amount of trouble. It would seem that would be a more difficult move than I thought. Well put together video, interesting point well made and pluss one subscriber.

[@DongitsModelRailway]

The decoder measures constant distance by dead reckoning, counting the fluctuations in back-EMF as the motor turns. Given the pole-count of the motor, the gear ratio and the wheel diameter is all fixed, the same distance can be reproduced. ABC can be used for fully automatic train operation, but I use it a bit more like the real railway uses TPWS -- to catch trains that people failed to stop themselves. Consider a club environment with 5+ people driving trains -- and chatting at the same time. All too easy to creep up behind someone, or miss a junction set wrong. This stops everything from expensive accidents to accidental shorts. There are two features of the decoder that are required to support constant distance ABC braking -- the ability to spot the voltage imbalance (which almost all modern decoders have), and the ability to count motor revolutions from the back-EMF. This latter one is not universal -- you'll find all Zimo, all current generation ESU and most current generation Lenz have it, but I'm guessing the reason DCC Concepts haven't implemented it this way is because the hardware they are using can't do this.

[@TheRip72]

I find it intriguing to see what different DCC features appeal to different people. It is not unusual or wrong to only know what you need. ABC braking is often used to bring locos/trains to a halt at the end of sidings. It is achieved by using a diode to slightly lower the voltage on one rail only. The decoder is programmed to detect this & respond by slowing. The distance part is useful to stop the train at the right place regardless of its original speed. When the loco moves off again (in the case of a bay platform, reversing out), the lower voltage rail is on the opposite side so the decoder does not see this as a signal to brake.

[@ncliffe4786]

Not surprised at what you found. I drew the same conclusions about the decoders from reading the manual. As soon as it was apparent that DCC-Concepts had departed from the accepted standard implementation of ABC, it was "forget it". I think your loco-reversed behaviour (creeping on slow-approach when reversing through the brake zone) is predictable from the manual. Alternative decoders given the shortage of Zimo decoders: Your report indicates that Train-o-matic have implemented Lenz' awful constant braking (brake-then-creep). I don't know how well ESU have done things, but I'd start by trying one of their decoders. There's D&H who's manuals suggest there may be constant braking (it's a bit cryptic) and definitely has asymmetric DCC braking (if you can find any decoders, think they've got the same component shortages as Zimo). Uhlenbrock might be another candidate, their documentation says they support ABC. If you trip over one, I think the old Hornby Sapphire decoders may have had ABC in them. - Nigel

[@DongitsModelRailway]

If Lenz decoders work like Train-O-Matic, I can cross those off the list. That's good to know. I do have an ESU here at the moment under test. Video coming later, but so far it's a lot more work than the Zimo (which have been almost plug-and-play for the most part), but I *think* I can make it work. I haven't managed to trip over a Hornby decoder with ABC yet, all of the ones I've dug out of second hand models have been the base model awful ones.

[@bruvaasmodai5250]

I think you've unwittingly developed an attitude problem during this whole encounter. Perhaps this is in response to the attitude displayed by the employee on the forum, but I don't think you've managed to remain objective during your experience. You're clearly a bright bloke, but may have lost sight of the space in which you're working here. The average DCC user doesn't have a clue what ABC is. They also give a very strange expression if told to operate a program like decoder pro. Both actual technical problems encountered here, namely; 1.A lack of available configurations for DCC Concepts decoders in the Decoder Pro software 2.ABC implementation in DCC Concepts decoders being different from that which you are used to are the result of the niche nature of both JMRI and ABC combined with the target market for DCC Concepts' products. ABC, such that it is, is not part of the DCC standard. It is built *upon* the DCC standard, as a 3rd party addition. I can see I have no need of explaining how it functions to you, but you seem to be under the impression that because other manufacturers have settled on one implementation of Asymetrical DCC for automatic stopping that all others should follow suit. The average DCC user is typically not interested in the high quality offerings by Lenz or Zimo (outside of sound decoders). The average user is concerned with, in order: 1. Value for money 2. Availability 3. Ease of use 4. Performance and so the list goes on, but it would take an awfully long time to reach "ABC compatability with other manufacturers". If this were not so then Hornby and Hattons' decoder sales would be considerably less profitable. I don't say this to somehow belittle you for being an advanced user of DCC, but to try to explain that DCC Concepts' decision to implement ABC differently from the way you are used to is not irrational or a failure. It is the direct result of seeing ABC as a means to offer low skill DCC users an effective shuttling facility. Does this mean they are somewhat limited if they later change the purpose of their ABC installations? absolutely. But I cannot imagine it has ever mattered to someone who has been introduced to ABC as a concept by the Zen Black range as a means of creating intuituve shuttles. As for the lack of decoder pro configurations for Zen decoders, that is regrettable for us happy users of JMRI, but not of much consequence to a business which clearly doesn't care much for the software or computer control in general. For a business that doesn't specialise in this potentially very complex and extremely individual world, this is frankly understandable. I don't think DCC Concepts would garner appreciable additional sales by creating configurations themselves, and in doing so would create another line of technical support in an area which most modellers, even experienced ones, simply don't understand. Again, the averge DCC user will turn their nose up at the first sight of code. As someone who is more than happy to use JMRI and indeed enjoy the benefits of more advanced DCC features such as ABC, I sympathise with your frustration. That said, your response to a free, open source piece of software with no afilitation to DCC Concepts not having precisely what you want is somewhat entitled. It is also completely at odds with your very own actions in creating a configuration for your own purposes which I can only hope you have shared with the user community of JMRI. That is how open source programs are built to be so flexible and powerful and yet you seem to be engaging with that process while lamenting that nobody has done it for you already as if it were the fault of the manufacturer? I do not wish to emulate the attitude of the staff member you interacted with as i'm completely with you that their actions were very poltician like and not altogether helpful. None the less it seems to me that the sourness of that interaction has blinded you to the rational reasons for the decisions you are criticising.

[@DongitsModelRailway]

> "I think you've unwittingly developed an attitude problem during this whole encounter. Perhaps this is in response to the attitude displayed by the employee on the forum, but I don't think you've managed to remain objective during your experience." That would have been a reasonable criticism of the first draft of the script -- the one I deliberately sat on for a week, then threw away and re-wrote precisely to avoid that problem. I disagree it applies to this one though. > "The average DCC user doesn't have a clue what ABC is." True -- but this is an ABC specific review. It's in the title, the thumbnail, and the entire video is focused on ABC. If you want a general user review of a Zen Black decoder which doesn't focus on ABC, the decoder has been out for over 3 years and the internet is already full of them. There's not much point in anyone making a new general user review of this decoder now as everything that needs to be said has already been said, and I can't add much to it. However, the internet is also full of what is frankly misinformation about the ABC features of this chip, written by reviewers who have never used ABC, and their "review" of it ranges from "read from the manufacturers blurb" to "put two modules on three bits of set-track and made a single vehicle shuttle back and forth". And it is this misinformation that is why I ended up with this decoder in the first place, and thus why this ABC review exists. > "ABC, such that it is, is not part of the DCC standard. It is built upon the DCC standard, as a 3rd party addition." Look at the history of DCC a bit closer. DCC is built upon a proprietary Lenz product. A few of the predecessor Lenz features (like stretched zeros to allow control of one analogue loco) were deliberately omitted from the standard to avoid patent encumbrance, and a few extra features to make the previously German focused implementation appeal more to the US market were added. You'll note the vast majority of command stations still implement the stretched zeroes feature, and all decoders can cope with it happening because even though it was written out of the de-jure standard, it is still a de-facto standard. While ABC may not (yet) be a de-jure standard according to the NMRA, the basic ABC feature set has become a de-facto standard precisely because many different manufacturers use it in a consistent manner, not just the original Lenz implementation. Directional stopping based on whether the waveform is shifted high or low *is* one of the de-facto standard features. Please correct me if I'm wrong but as far as I am aware, DCC Concepts is the ONLY manufacturer which does implement ABC braking but does not implement this directional behaviour. Everyone else who implements ABC has managed to do this the same way. ABC Slow speed sections are objectively not a standard at the moment -- each manufacturer has done something a bit different with the DCC signal to add this feature, and we've yet to see a 'winner' emerge. That gives DCC Concepts license to implement *this part* however they want, but it does not permit them to drop the standard directional feature without criticism. Constant distance braking doesn't need to be standardised in quite the same way, because (up until DCC concepts came along) it wasn't part of the train/track interface at all, and could be implemented entirely within the decoder. Hence you see a variety of strategies across the different companies that do implement it, and some that have ABC braking but do not have constant distance. In making it a part of the track/train interface, it's again reasonable to criticise them for this. > "you seem to be under the impression that because other manufacturers have settled on one implementation of Asymetrical DCC for automatic stopping that all others should follow suit." Ummm, unironically yes. That would have been the smart commercial decision. If everyone is doing the same thing, there's good commercial reasons to be compatible with it. DCC Concepts could easily have made the standard behaviour selectable by CVs, but in choosing to ignore this de-facto standard, they are siloing themselves off from every other manufacturer. As a small player, that's a really bad idea. History is littered with failed projects to improve things that were both not sufficiently compatible with de-facto standards to see incremental adoption and not enough of a revolutionary jump up for people to abandon their existing installed base and move across all at once to a different way of doing things. > "The average user is concerned with, in order: 1. Value for money" If that is being used as a reason not to buy Zimo's MX600R or MX638D, then it counts against this Zen Black just as much. I paid more for this Zen Black than I did for my most recent batch of MX638Ds. > "2. Availability" ... Yup. That's a kicker, and is the only reason I'm looking elsewhere at the moment. There's nothing to choose between the Zimo and Zen Black on your other two points. > "It is the direct result of seeing ABC as a means to offer low skill DCC users an effective shuttling facility." And in dedicated shuttle train service, with the track tuned to how the loco/unit responds rather than attempting to tune the decoder to what the (existing) track requires, I'm sure these can be made to do the job just fine. But ABC can be, should be, (and in the layout I have built, *is*) so much more than just a way to have a DMU run back and forth on it's own separate single track while you concentrate on shunting in the foreground. Having said that, the fact they don't directionalise their ABC braking zones does create a problem *even in shuttle train service*, as is demonstrated ably in Jenny Kirk's livestreams. If she loses power (perhaps due to a short created by derailment elsewhere on the layout) while one of the locos is in the braking zone, because it is not directional it can get the sequence wrong when the power comes back and proceed out of the shuttle area in the wrong direction. Had the ends been handed with the signal being directional, the decoder could have worked this out on power return, and made sure to move in the correct direction. > "your response to a free, open source piece of software with no afilitation to DCC Concepts not having precisely what you want is somewhat entitled." The point here was that the JMRI developers seem to have put in significant effort about ~7 years ago to support the original Zen decoders, and have been met with a mixture of indifference and hostility from DCC Concepts. I found a forum thread where the same employee blamed a customer's use of JMRI for what was clearly a decoder fault, and this doesn't seem to be an isolated incident. I decided not to include this in the video because I wanted less focus on the forum and more on the decoder. If the company is just going to advise users to avoid using JMRI and attempt to deny all problems they experience if they've ever touched it, it seems reasonable that no contributor to the JMRI project has bothered to update the decoder configuration files for the Zen Black, as a direct result of the attitude of the company. JMRI not recognising Zen Black chips is thus a negative against *DCC Concepts*, not against *JMRI*. Perhaps this point is less clear as a result of me cutting a giant chunk of detail from this area? Also, via some rather imprecise wording, that employee managed to diss the *entire concept of open source*, not just the JMRI project. I had a point ready to make about how all major open source forum software projects have figured out that when a thread is locked, you should also stop allowing people to edit the posts in the locked thread, but that the DCC concepts chosen commercial forum software is one of the few that hasn't figured that out. Honestly it felt like a cheap shot and again, it hit the cutting room floor. > "creating a configuration for your own purposes which I can only hope you have shared with the user community of JMRI." It's not ready for end-user use, as the UI part was not completed. As such it would be inappropriate of me to upload it as a contribution to the shipping product. However, just as it would be a waste of my time finishing it off, it would equally be a waste of anyone else's time to re-do the parts that I already did. So i have made it available by uploading what I made to the JMRI bug tracker ticket regarding this decoder. Should someone else wish to finish the job, they are more than welcome to use my work when doing so if they want to.