[kristopher1805]

I liked ZTC decoders but then it changed hands and I thought it would get better but it sort of went to sleep

On decoders DCC concepts for 8 pins as they fit everything, the nano type
For 21 pin either Bachman or DCCC again both good
As for warranty DCCC will provide as Richard Johnson is on here, less active than before but still breathing
and for 4 pin, 6 pin, next 18 etc - whatever you can get

 

[Alex Hempel]

The NCE system is very clunky for Functions above F10 where the better sound chips have many effects.

It is also unlikely to be updated to support >28 functions, something a fair few new sound locos now have.

There's a reasonable chance it will work with an NCE system via the "sniffer" port.

I doubt it, the Cab Bus protocol is challenging for developers to implement correctly. An attempt by Digikeijs to create a piece of hardware that would make their command station work with NCE gear has been abandoned.

 

[Graham Plowman]

It is also unlikely to be updated to support >28 functions, something a fair few new sound locos now have.

Let's be realistic, 28 functions is a lot of functions (mind you, at one time, it was said that no-one would ever need more than 640k) and all of the 'earlier' DCC systems with 'non glass' throttles based on 8-bit technology were manufactured to operate a handful of functions. Some had individual buttons assigned to each function.

As I see it, there are a few ways to accomodate extra functions:

• Add 28 buttons to throttled. That will result in a large throttle and will only work until someone invents a 29th function
• Use 'mode switching' to switch between 'banks' (ranges) of functions - I think a few systems do this and it is really clunky, reminiscent of the VCR throttles of the 1970's
• Enable the user to enter the number of the function they want to change on a visible screen. This method is infinitely extendable. 'glass throttles' are particularly good at this. Throttles with screens such as NCE could be reprogrammed to do it as they already perform similar actions in programming

I can see a conflict arising between the number of buttons on a throttle and the functions that users want to be 'single button' and/or the ability to map them.

 

[Alex Hempel]

@Graham Plowman I am talking about locos with more than 28 functions. This is already a thing with ESU decoders (I own an ESU-equipped model that maps to F30) and some of the newer, more detailed locos have a lot of both sound and other functions (smoke, cab and machine room lights, moving pantographs etc). A lot of older physical cabs will probably never be able to support that even with the banking of functions they already do, because they'd need a software update. I don't see e.g. NCE doing that with hardware that was last updated 15 years ago.

 

[Nigel2001]

It's not mentioned because throttle choice is (almost) anything you like with the Z21.
........

There's a reasonable chance it will work with an NCE system via the "sniffer" port.

I doubt it, the Cab Bus protocol is challenging for developers to implement correctly. An attempt by Digikeijs to create a piece of hardware that would make their command station work with NCE gear has been abandoned.

Sniffer port doesn't touch the Cab Bus.. It takes the DCC track output of the "sniffed" system, and inserts those into the DCC signals the Z21 is already generating and sends them to the Z21's track outputs.
(Were I implementing it, I'd decode the DCC signal to each instruction, such as "loco 123, speed 84 forwards" or "turnout 567, thrown", and put those into the larger set of commands going to the track. Ideally with a priority system so the loco speed/direction instructions are put ahead of other things).

The questionable part is the variable pre-amble length that NCE uses in its DCC packets. Whereas just about every other DCC system maker has a fixed pre-amble to their DCC packets. (NMRA spec has a minimum pre-amble length, and a maximum pre-amble length, so NCE are "in spec" in doing this). If doing a full packet decode, that shouldn't matter, as a valid pre-amble is seen, it just might be a different length to the previous packet's pre-amble.



Digikeijs problems may, in part, be that the designer of their system left them a few years ago. He's set up a new company (YaMoRC) with plans which look like a "Digikeijs Mark2 improved" system.


- Nigel

 

[Graham Plowman]

Hi Nigel,

Digikeijs problems may, in part, be that the designer of their system left them a few years ago. He's set up a new company (YaMoRC) with plans which look like a "Digikeijs Mark2 improved" system.
- Nigel

Interesting that you should mention YaMoRC as I had never heard of it, but I checked out their website.

Something that you may be able to answer for me: we seem to be entering an era where we have DCC system manufacturers providing a plethora of add-on boxes to interface with their competitor's systems. Under normal circumstances, one might assume that this is a strategy to entice customers to particular systems by making it 'easier' for them. But surely, it can't be cost effective for all manufacturers to do this ? I can see a lot of these boxes being discontinued when they don't sell.

What it all tells me is that there is a need for a new unified DCC standard, which is something I've been banging on about for years! The 1980's, no-network-stack architecture of the current DCC standard is long since obsolete. It works, but it is difficult to enhance, hence we are stuck with a mish-mash of boxes and add-on networks, some of which are useful, some are not.

 

[Alex Hempel]

What it all tells me is that there is a need for a new unified DCC standard, which is something I've been banging on about for years! The 1980's, no-network-stack architecture of the current DCC standard is long since obsolete. It works, but it is difficult to enhance, hence we are stuck with a mish-mash of boxes and add-on networks, some of which are useful, some are not.

I completely agree with this, but at the risk of sounding like a negative ninny, I don't believe it's going to happen any time soon.

A new standard would have to incorporate and extend both the current digital control method, as well as the additional functionality provided by third party bus systems such as LocoNet, XpressNet, S88 et al. There's a good chance that, in order to not be 'just another standard', but something people actually want to move towards, it would have to be largely if not completely incompatible with current setups. At which point we're back to square one, because it'll have a hard time capturing those users who already have full setups and don't want to go through the pain of replacing everything. There would have to be a serious quality-of-life improvement in such a move for many people to even consider it. That has a knock-on effect on manufacturers adopting it, because if people aren't going to buy it in large numbers, why bother?

Thing is though, not everyone wants or needs the additional functionality provided by the third party standards. Not everyone is working with detection and feedbacks, which is what Railcom, LocoNet etc are generally used for. Plenty of people operate their trains by hand, and mainly use DCC for simplified wiring, loco lights and sound. They wouldn't need to move to a new standard, they have all they need in their 15 year old NCE, Digitrax or Lenz setup.

Companies like Digikeijs and YamoRC (on which I am keeping a close eye) had to somehow get a foothold in this current market, which is a) small and b) saturated with competing standards. Their selling point had to be "Our box will work with that", where 'that' is as many different bus systems as possible, so that people could upgrade their command central without having to rip out and replace all the peripherals, throttles/cabs etc. To be fair, a large selling point for the DR5000 was also that it works with the Z21 app.

Where's LCC? Supposed to really improve the handling of accessories on DCC, but so far it's a niche product, and doesn't look as if it's likely to break out of that niche any time soon. Same with BiDiB, which was hailed as a bus system that improved on the shortcomings of others (the iTrain dev is in love with that one), but it's not being adopted widely. People have what they need, warts and all, and the impetus to move to something completely new is very small.

I'd love a new standard, possibly incorporating radio control, where the track goes back to just supplying power instead of being used as a low-grade network cable. But the only thing that would make this happen is if someone came up with something so groundbreaking that everyone wants to throw their current system away.

 

[34C]

...I'd love a new standard, possibly incorporating radio control, where the track goes back to just supplying power instead of being used as a low-grade network cable. But the only thing that would make this happen is if someone came up with something so groundbreaking that everyone wants to throw their current system away.

Hornby are floating a Bluetooth wireless system, running DCC 'as is'. I don't see an obstacle to Bluetooth transmitting a different digital control standard, if some developer feels brave enough to punt the cash; it's just another data stream. It could be transmitting both with some clever management, potentially reducing the barrier to entry for existing DCC users.

 

[Nigel2001]

.....
Where's LCC? Supposed to really improve the handling of accessories on DCC, but so far it's a niche product, and doesn't look as if it's likely to break out of that niche any time soon. ....

Unfortunately seemed to get mired in "which standard" for ages, which left it struggling to get started. I think it will stand or fall on the new TCS DCC systems. If they take off and start shifting users out of Digitrax and NCE (the two clear main targets), then LCC has a starting place. If not, its yet-another-ignored-niche-standard. It might also shift RailCom into the US market. TCS have their base covered to an extent in their throttles talking the "WiThrottle" protocol, so don't have to be on "LCC".


Digikeijs and YaMoRC appear to be primarily aiming at the "upgrade" market. They're an attractive option for someone who wants to upgrade if they have friends with different maker's handsets. I'm a fairly regular operator on a layout which has a Digikeijs system because it allows the use of Digitrax DT602's (the owner's preference) and Lenz LH100's/LH101s (several regular operator's preference). Plus its got the smartphone option. And being European it does RailCom. I expect the layout will get the YaMoRC upgrade module added in the near future.


I've been playing with cheap WiFi devices recently. Raspberry PI Pico processor onto a MQTT broker. Processor (sort of turbo-charged Arduino) comes in the WiFi version for £6 retail in the UK. For accessories and feedback, this is a "no wires" bus, just needs power.

The radio stuff seems to be heading towards Bluetooth. Not sure how that works with lots of trains around, but can see how its fine for a small number. Radio has the advantage of not needing as much compatibility, so long as there isn't actual interference, it doesn't matter if operator-1 is using ABC-system and operator-2 is using XYZ-system to drive their respective locos.


- Nigel

 

[34C]

...The radio stuff seems to be heading towards Bluetooth. Not sure how that works with lots of trains around, but can see how its fine for a small number...

My recollection based on fairly minimal exposure to Bluetooth (confined to a desk while the bright young technical guys had the hands on fun) is that the Bluetooth receivers had addresses, and thus only responded to traffic to their address, which of course is much as DCC works.

Now the implementation will be key, because in the model railway context using Bluetooth to send DCC commands, a layout only requires one Bluetooth receiver address: because the DCC decoder will only act on commands for the unique DCC address of each loco.

 

[dwb]

I wonder how much money there is the DCC Systems market given Lenz and ESU are growing their business by making models at the higher end of the price range. If they are the smart ones, that doesn't leave much money or incentive for other control manufacturers to invest in newer fancier systems.

If Hornby have a good reliable Bluetooth implementation I think they're on to a winner so long as they don't try to replicate all the accessory decoder stuff already available from many others.

David

 

[DC Marvel]

There's a good chance that, in order to not be 'just another standard', but something people actually want to move towards, it would have to be largely if not completely incompatible with current setups. At which point we're back to square one, because it'll have a hard time capturing those users who already have full setups and don't want to go through the pain of replacing everything.

Why not, it's what happens with most 'digital' systems. TV did it after going Freeview with set top boxes that everone bought, then along came Netflix etc and the boxes were dumped in favour of a wi-fi enabled TV. PC manufacturers and software has always at some point dumped backward compatibility in order to introduce new features. Same will eventually happen with DAB radio killing off FM.
Possibly current DCC has reached it's limit in what can be done and in order to still increase market share, manufacturers are simply looking to pad out their product line and profit margins with anything and everything that will sell.

 

[Alex Hempel]

Hornby are floating a Bluetooth wireless system, running DCC 'as is'. I don't see an obstacle to Bluetooth transmitting a different digital control standard, if some developer feels brave enough to punt the cash; it's just another data stream. It could be transmitting both with some clever management, potentially reducing the barrier to entry for existing DCC users.

I'm interested in the more general idea of controlling trains via Bluetooth. The Hornby-specific implementation will be a non-starter for many, since it appears to require Hornby decoders and other Hornby gear - nobody with an extensive fleet equipped with e.g. ESU or Zimo decoders is even going to contemplate replacing them with Hornby. I do hope though that it gives impetus to other manufacturers to develop in that direction.

Digikeijs and YaMoRC appear to be primarily aiming at the "upgrade" market. They're an attractive option for someone who wants to upgrade if they have friends with different maker's handsets. I'm a fairly regular operator on a layout which has a Digikeijs system because it allows the use of Digitrax DT602's (the owner's preference) and Lenz LH100's/LH101s (several regular operator's preference). Plus its got the smartphone option. And being European it does RailCom. I expect the layout will get the YaMoRC upgrade module added in the near future.

That's precisely where they are. I upgraded from NCE to the DR5000 because I realised that for what I had planned in terms of automation and software control, I'd be much better off with a more standardised bus (locoNet) than with NCE's Cab Bus. I'm also pegging that YamoRC upgrade module for a near-future purchase, since the further development of Digikeijs' own software appears to have stalled again.

Why not, it's what happens with most 'digital' systems. TV did it after going Freeview with set top boxes that everone bought, then along came Netflix etc and the boxes were dumped in favour of a wi-fi enabled TV. PC manufacturers and software has always at some point dumped backward compatibility in order to introduce new features. Same will eventually happen with DAB radio killing off FM.

TVs and digital entertainment are a huge market. There's new tech in that area every year, and plenty of people are happy to regularly upgrade their TV, so manufacturers are churning out new stuff. It's easy to replace a TV.

When someone has a DCC setup incorporating one or more bus systems, with accessory decoders and occupancy detectors and what have you, those devices tend to be interdependent. One might exchange/upgrade individual components with compatible parts, but the appetite to rip out and replace all that gear with something new but incompatible may be a lot smaller. Railway modellers are a small market, and many of them love to stick with the gear they know works, because is has worked for the past x years, and they will replace it only if it breaks.

 

[Graham Plowman]

Good points made by everyone here.

In terms of 'standards', my observation is that with a few exceptions, the majority of new 'standards' tend to to be single solution to single problem setups. For example, they might solve how to drive trains (perhaps wirelessly) but then they don't integrate or offer a solution to changing turnouts. Or they focus on doing some other feature with a deliberate exclusion of a computer. Or they focus on trying to bring DCC capabilities to DC.
This is where DCC has excelled in a big way: the use of a single network bus has enabled it to solve multiple problems and that is what all future solutions should be doing. Coming from a very analytical, software engineering background where we have to deal with large numbers on concurrent issues, I don't think this is hard. It just needs people to think in ways of bringing things together in compatible ways so that they all work together instead of people focussing on single issues or creating hardware vs software 'them and us' scenarios. Why have mobile phones become so successful ? Because this process has been applied to them and everyone has been brought together.

34C raises an interesting point about 'addressing'. I haven't worked with bluetooth, but I have developed software to drive numerous other hardware systems (including industrial and DCC), all with their own 'addressing' systems. 34C suggested a single address for a layout. That would effectively be a 'network address' to which all devices could be confined and secured. How are individual devices (like locos and accessories) addressed within that ? Theoretically, that is possible within the messaging system. Does bluetooth work on the principal of a network address with multiple devices within the network ? I don't know - perhaps someone more knowledgeable than myself on this can advise ? I always though my phone/car bluetooth connection was a single address, single network, but maybe I am wrong. If bluetooth does operate with a sub-addressing system, then that does create huge opportunities, especially for address ranges.

DWB asked about the every increasing high end prices of DCC systems. In the case of Lenz, I would suggest that is probably not justified as the Lenz system is not a high-end system any more. It is a good, solid, reliable system, but it is very dated now. In the case of ESU, I think it is possibly justified because their system is very innovative and they continue to develop it. I think in time, all DCC systems will go this way with a *nix based computer running inside with a display which may also appear on throttles.
Rising prices could also be symptomatic of compensating for lower sales and as DWB says (but my words), milking the products for as long as they can.

Other 'Dave' indicated the way digital systems change the standards. Set top boxes originated to transition from analogue TV signals to digital signals. DAB is effectively the same to FM radio.
From what I can see, Hornby's bluetooth foray is very similar to some suggestions I sent to SK a couple of years ago, particularly the ways of integrating it with current tech and migrating the current tech to the new tech. It will be interesting to see how it progresses.

 

[Graham Plowman]

I'm interested in the more general idea of controlling trains via Bluetooth. The Hornby-specific implementation will be a non-starter for many, since it appears to require Hornby decoders and other Hornby gear - nobody with an extensive fleet equipped with e.g. ESU or Zimo decoders is even going to contemplate replacing them with Hornby. I do hope though that it gives impetus to other manufacturers to develop in that direction.

My view on this is that there needs to be standards which everyone can work with and benefit from. Too many organisations are still in the business of creating niche tech so that they can corner the market with it and tie people in, but we only have to look at the success of MS Windows to see a different approach. Prior to Windows, nearly all software conformed to the niche approach and you had to pay for information or sign NDA's etc. Microsoft simply made all the information free and easily accessible and as a result, it was instantly accepted and took off like a rocket, leaving it's competition behind. I think the model railway industry could learn from this: one solution to one problem tech doesn't cut it. It has to be something that solve multiple problems for multiple people in an open, non-niche way. A commonly used, high-speed, fully duplex bus/communication standard would be a good starting point.

That's precisely where they are. I upgraded from NCE to the DR5000 because I realised that for what I had planned in terms of automation and software control, I'd be much better off with a more standardised bus (locoNet) than with NCE's Cab Bus. I'm also pegging that YamoRC upgrade module for a near-future purchase, since the further development of Digikeijs' own software appears to have stalled again.

I take a slightly different approach to this. I identify what I want to do and then go and buy the product that achieves it and has some 'future-proofing' built in. I don't think I'd be buying a product which has every bell and whistle for every standard that I probably wouldn't use. In other words, I'd be more specific about my requirements. Maybe that's the business owner/software engineer in me!

 

[Alex Hempel]

I take a slightly different approach to this. I identify what I want to do and then go and buy the product that achieves it and has some 'future-proofing' built in

In the context of model railways, this is a difficult approach for newcomers to take, simply because it takes a while to figure out what you want to do when you're new to the hobby, and then work out what you need to do it. In addition, one of the most commonly things said to people looking for e.g. DCC controller recommendations is 'get what people around you are using', and in my case that was NCE. More specifically, people around here acted like NCE was the best thing since sliced bread and I wouldn't ever want anything else.

Sure, you could spend a lot of time researching it all before you even start spending money. But that doesn't work for everyone.

 

[Graham Plowman]

In the context of model railways, this is a difficult approach for newcomers to take, simply because it takes a while to figure out what you want to do when you're new to the hobby, and then work out what you need to do it. In addition, one of the most commonly things said to people looking for e.g. DCC controller recommendations is 'get what people around you are using', and in my case that was NCE. More specifically, people around here acted like NCE was the best thing since sliced bread and I wouldn't ever want anything else.

Sure, you could spend a lot of time researching it all before you even start spending money. But that doesn't work for everyone.

That's fair comment.
I originally went with Lenz on the basis that it was the founder of DCC tech and that it would therefore be consistent with standards. It didn't fail in that respect.
It wasn't until I wanted wireless throttles that Lenz couldn't deliver, that I looked elsewhere. NCE had a very good system where the wireless is properly integrated and it works really well. I agree that people here also acted like it was the best thing since sliced bread, although I chose to do my own research and make my own mind up. At the time, it probably was one of the best systems available. It certainly does everything I want right now, but by the same token, technology has moved on and there are newer system entrants who have grasped more modern tech.

I am of the view that DCC uses a proprietary standard and while it continues to do so, it will never achieve the amazing progress that has been achieved with the convergence of computer technology and standards with most white goods products such as phones, TV's and video.

 

[34C]

I wonder how much money there is the DCC Systems market given Lenz and ESU are growing their business by making models at the higher end of the price range. If they are the smart ones, that doesn't leave much money or incentive for other control manufacturers to invest in newer fancier systems...

I feel this is the obstacle to the development of a successor control system, because to win over the market it has to offer some massive superiority over DCC at a price attractive enough for the potential market.

Personally, with DCC decoders installed in the best part of 100 traction items, I wouldn't even consider a system that didn't offer full backward compatability, because what I have works reliably and is able to meet all my operational requirements. I am far from averse to spending on upgrades, but it has to be the full package...