Model Railway Forum banner
21 - 28 of 28 Posts

·
In depth idiot
Joined
·
7,926 Posts
...Trouble is moving your production to China is ok if you have frequent trips to China to check they are doing it properly, we were forever flying to plants in Europe to check what was going on...
Doesn't matter where your remote manufacturing is based, this is a general truth. If you can find a trustworthy remote outfit, hang on to them like grim death: and fight the finance guys very hard when they 'recommend' shifting the product to Bozo International, who 'can do the job for half the money'...

Long, long ago, in a land far away, while on a quest to slay a dragon (AKA troubleshooting) I encountered my Japanese equivalent as we were ushered outside the office block to our respective taxis, which took us to the same hotel. Happily he spoke excellent English, and we had a most interesting couple of evenings discussing our common interests in securing improvement, diagnosing exactly what were the most critical shortfalls, and generating the corrective action plans.
 

·
Registered
Joined
·
36 Posts
Doesn't matter where your remote manufacturing is based, this is a general truth. If you can find a trustworthy remote outfit, hang on to them like grim death: and fight the finance guys very hard when they 'recommend' shifting the product to Bozo International, who 'can do the job for half the money'...

Long, long ago, in a land far away, while on a quest to slay a dragon (AKA troubleshooting) I encountered my Japanese equivalent as we were ushered outside the office block to our respective taxis, which took us to the same hotel. Happily he spoke excellent English, and we had a most interesting couple of evenings discussing our common interests in securing improvement, diagnosing exactly what were the most critical shortfalls, and generating the corrective action plans.
i could quote many Bozo International experiences. The even more amusing thing is when they have to go back to the original supplier it costs them more.
 

·
Registered
Joined
·
2,533 Posts
Generally with any digital communication system it is how the designer reads the specification. I am surprised you are getting the effect you are, usually the differences in decoders is noticed when trying to read or write CV values. I am an ex Electronics/Software designer specialising in digital communications and normally most errors occur in the timing of the reading of the signal. The best I can recommend is to buy a middle of the road decent decoder like a Zimo, which I have found to be super reliable and change the decoder. If it still shows the same faults then your issue may be nothing to do with the decoder more like the capacitor across the motor or the pickups. I have two controllers a Fleishmann and an Elite, only because I bought them broken and fixed them, but it is surprising how many decoders work on one but not the other always involving reading and writing CV values.The Fleishmann handles most decoders better but the the Elite has an easier menu system for reading and writing CV values. Anyway, sorry but that is the best advice I can offer.
I come from the opposite side as a software engineer, building the communications software to communicate with electronics hardware. I've been doing this since the 1990's. One of my forays was the 'SSI Model Railway Control System' to control model railway hardware systems of both DC and DCC varieties.

Without wishing to point fingers, my observation was that there were a fair number of electronics people who operated on the 'if it just about works, it's good enough' principal. Their thinking was that computer guys would 'fixup' any problems.
On several occasions, I was presented with hardware with major timing issues that couldn't be fixed because no timing signals were even sent to the computer. In one instance, a guy connected the 'send' pin of a parallel port to the 'received' pin, meaning that the synchronisation was bridged at the sending end and there was no wire going to the receiving end. It was impossible to fix so I dropped support for that hardware.

Probably the biggest problem I observed was that electronics people just seemed to want to operate in their own little world and not communicate with the people who are going to use their creations. This is why we ended up with the crap user interfaces on TV's and VCR's all through the 70, 80's and early 90's. It wasn't until Apple demonstrated that if electronics people actually worked 'with' instead of 'against' computer people, an incredibly usable device could result - smart phones. This progressed into the onscreen control we see on TVs and DVD players we see today - collaboration brought about amazing positive results.

I frequently found myself in situations where electronics people would dictate how things were going to be and would not entertain input from people who were going to have to integrate with their hardware. I think the problem was that it was too hard for them to change their hardware and egos/control mentality prevented them working with computer people trying to help them early on in the design.

It may well be that the Lionel system uses a completely different messaging protocol to NMRA DCC, so even if the timing is the same (probably not), the actual byte messages may be completely different.
My observation is that in our hobby space, if non adherence to standards occurs, it's usually because those involved in the electronics side don't want to change hardware to make it compliant with a standard, consequently, they invent their own non-standard.

Interpretation of a standard is obviously an issue. If the standard isn't documented sufficiently well, then it may be open to interpretation. When such situations occur, people shouldn't make localised decisions. They should consult the custodian of the standard for advice.

If everyone works together, far better outcomes can be achieved.

As I see it, the problem with the NMRA DCC standard is that it badly needs upgrading into a proper layered stack like the ISO network stack used in the computer industry. At the moment, the hardware and the messages are one and the same thing, consequently, any upgrade requires hardware upgrades. What should happen is that the hardware provides the networking and the software sends messages across it. There shouldn't be a dependency between the two.
 

·
In depth idiot
Joined
·
7,926 Posts
...As I see it, the problem with the NMRA DCC standard is that it badly needs upgrading into a proper layered stack like the ISO network stack used in the computer industry. At the moment, the hardware and the messages are one and the same thing, consequently, any upgrade requires hardware upgrades. What should happen is that the hardware provides the networking and the software sends messages across it. There shouldn't be a dependency between the two.
Sounds like a good principle, so what are the obstacles to implementation?

As I understand it, DCC and other hobbyist level systems of this sort, were spun off from large scale industrial systems; Bernd Lenz basing his on an automated building management system. So my question would be, what is there 'out there' now of this sort, in the superior architecture, well developed and proven, and in mass production at a scale that could deliver the system at a hobbyist price point?
 

·
Registered
Joined
·
36 Posts
Sounds like a good principle, so what are the obstacles to implementation?

As I understand it, DCC and other hobbyist level systems of this sort, were spun off from large scale industrial systems; Bernd Lenz basing his on an automated building management system. So my question would be, what is there 'out there' now of this sort, in the superior architecture, well developed and proven, and in mass production at a scale that could deliver the system at a hobbyist price point?
When I worked on automotive audio I got sent on a MOST communication course, that seemed very similar to DCC. If you take something like CAN or ECAN there are standard integrated circuits out there, some integrated into microprocessors, so it is a bit more difficult to get it wrong, although if two manufacturers can use different frequencies or bit timing then their devices won't work together. I get the opinion DCC is totally controlled in software rather than hardware, so there will be differences.
 

·
Registered
Joined
·
2,533 Posts
Sounds like a good principle, so what are the obstacles to implementation?
Not invented in the US syndrome, belief that it is the only way, being pushed out of comfort zones, egos, resistance to change etc etc

As I understand it, DCC and other hobbyist level systems of this sort, were spun off from large scale industrial systems; Bernd Lenz basing his on an automated building management system. So my question would be, what is there 'out there' now of this sort, in the superior architecture, well developed and proven, and in mass production at a scale that could deliver the system at a hobbyist price point?
Bernd Lenz's designs would have been based on the technologies current at the time around the mid 1980's. At that time, concepts such as the ISO stack were still to be published.
Lenz's designs predated wifi and were therefore based on the principal of superimposing digital signals over a power transmission line.
Since the mid 1980's, technologies have moved on a long way.

When I worked on automotive audio I got sent on a MOST communication course, that seemed very similar to DCC. If you take something like CAN or ECAN there are standard integrated circuits out there, some integrated into microprocessors, so it is a bit more difficult to get it wrong, although if two manufacturers can use different frequencies or bit timing then their devices won't work together. I get the opinion DCC is totally controlled in software rather than hardware, so there will be differences.
CAN is probably the most well known alternative. MERG and a few others have gone down that path.

My view is that digital command stations of the future should use wifi technology and act as a wifi hub using a private network Communications. The hub should be connectable to the internet in the same way as any mobile phone or laptop. Mobile items such as locos should be communicated with via wifi. Static devices such as turnout control, feedback, tethered throttles etc should all go via something like a CAN bus. Rails should be used to provide power only, not transmit digital signals (unless present NMRA DCC is being applied for backward compatibility). Static devices can take their power either from the rails or a separate power bus (CAN provides power through its 4 wires for its use, but turnouts will need their own power source). Wireless throttles should communicate via wifi. With battery technology changing, the above permits locos to use on-board batteries.

The biggest issue I see with CAN is that it is based on a publisher/consumer model which removes the concept of an addressing model. I think it would be better for each device to have a unique 'MAC address' for low level comms purposes and for the user to be able to apply their own 'name' to each device. If the user wants to use names like you see on real signal posts or just sequential numbering, then so be it - they are names, not 'addresses'.

As to DCC being controlled by software, I think it depends on which system you look at. The Loconet system appears to me to be very low level, requiring software control - but that is the throttle network, not the DCC bus. Lenz is 'abstracted' to a slightly higher level where timing is not exposed to computer control (although it may be to micro-computer control in the command station), but the 'bit stuffing' of messages is very much exposed and is very primitive. NCE is 'abstracted' even higher such that there computer messages are much simpler/readable and the command station translates to DCC messages. Hornby's Elite is completely software controlled - bringing it to NMRA compliance required a software upgrade, not hardware.
 

·
Registered
Joined
·
36 Posts
Not invented in the US syndrome, belief that it is the only way, being pushed out of comfort zones, egos, resistance to change etc etc



Bernd Lenz's designs would have been based on the technologies current at the time around the mid 1980's. At that time, concepts such as the ISO stack were still to be published.
Lenz's designs predated wifi and were therefore based on the principal of superimposing digital signals over a power transmission line.
Since the mid 1980's, technologies have moved on a long way.



CAN is probably the most well known alternative. MERG and a few others have gone down that path.

My view is that digital command stations of the future should use wifi technology and act as a wifi hub using a private network Communications. The hub should be connectable to the internet in the same way as any mobile phone or laptop. Mobile items such as locos should be communicated with via wifi. Static devices such as turnout control, feedback, tethered throttles etc should all go via something like a CAN bus. Rails should be used to provide power only, not transmit digital signals (unless present NMRA DCC is being applied for backward compatibility). Static devices can take their power either from the rails or a separate power bus (CAN provides power through its 4 wires for its use, but turnouts will need their own power source). Wireless throttles should communicate via wifi. With battery technology changing, the above permits locos to use on-board batteries.

The biggest issue I see with CAN is that it is based on a publisher/consumer model which removes the concept of an addressing model. I think it would be better for each device to have a unique 'MAC address' for low level comms purposes and for the user to be able to apply their own 'name' to each device. If the user wants to use names like you see on real signal posts or just sequential numbering, then so be it - they are names, not 'addresses'.

As to DCC being controlled by software, I think it depends on which system you look at. The Loconet system appears to me to be very low level, requiring software control - but that is the throttle network, not the DCC bus. Lenz is 'abstracted' to a slightly higher level where timing is not exposed to computer control (although it may be to micro-computer control in the command station), but the 'bit stuffing' of messages is very much exposed and is very primitive. NCE is 'abstracted' even higher such that there computer messages are much simpler/readable and the command station translates to DCC messages. Hornby's Elite is completely software controlled - bringing it to NMRA compliance required a software upgrade, not hardware.
Funny I was talking to my friend in the pub the other night about something like can over wifi. We both used to work on vehicle electronics and software so we were just discussing it. That was exactly the idea I had 12 volts on the rails, control over the wifi. CAN has 4095 addresses if I remember correctly, ECAN significantly more but then you have 8 byles which you pack with data.My background is in writing software for CAN and ECAN. I was discussing if you could have multiple nodes with the same wifi address, these being the locos. I know absolutely nothing about wifi, I was considering using it just before I retired, so I never did the detail work.
 
21 - 28 of 28 Posts
Top