Train Magic

I concur with RFS and 34C.

Having been a supplier of software for computer control for many years, I have come across many perspectives on 'computer control'.

I think one thing to clear up from the start is that there are several types of computer control (probably others):

1) Total automation where you can sit back and watch
2) A level of automation where you run trains manually and the automation runs everything around you
3) Automated block control, whereby signals are changed and trains are automated to move with signal changes
4) Mimicing prototype IECCs whereby the computer controls all the signalling and interlocking, but routes are (mostly) set by an operator and trains are driven manually by people

The present subject matter only deals with (1). My software was aimed at (4) and was capable of (3) (I have a few Youtubes of 3 in action).
Only 3 and 4 actually represent something prototypical, so consideration needs to be made as to whether one wants to follow some form of prototype or just build a 'toy train set'.

There is also the aspect of 'how much' a computer is involved in a solution. My observation is that many solutions, including Railmagic, Bluerail and several others are (with no disrespect) developed by electronics engineers who have a pathalogical allergy to involving computers in their solutions and consequently, they end up solving a single problem and leaving lots of other problems unsolved.

The single most 'forward thinking' part of DCC is the implementation of a 'bus'. The fact that the bus is entirely proprietary and doesn't comply with any form of modern ISO layered network stack is another discussion, but in itself, the use of a bus provides a single, standardised communications line onto which multiple devices can be connected and controlled through two wires. The fact that the two wires run at a constant 16VAC and allowed multiple trains on the same track, constant lighting and much more reliable continuity due to the high, constant voltage are all side effects of a sound foundation - in other words, DCC is a good solution to multiple problems and to date, there hasn't been anything comparable other than perhaps, Marklin.

When you look at solutions like the present subject, what you find is that they are all single solutions to single problems with tie-in to a single, proprietary manufacturer.

The only way our hobby is going to move forward is when there is a recognition that electronics engineers (hardware) and computer engineers (software) must work together to provide overall outcomes.
We all remember the days of VCR's and the convoluted/awkward ways they worked, And the awkward way that we had to tune TV's. That's because they were designed by hardware engineers who had no experience of human-computer-interface (HCI) design. Once the computer engineers came on board, suddenly, hardware became much easier to use and we ended up with modern TV's with their visual menus and phones which progressed from 1980's Nokias to what we have in Apple and Android 'smartphones'. It was the merging of disciplines which brought about the progress.

I've come across several hardware-only systems - present subject included - where the system shows no convergence with anything prototypical and looks and operates like it has come out of the domain of our slot-car racing friends.
NMRA DCC might not be perfect, but at least it is aimed at railways and had people involved in it with railway backgrounds, not a slot-car system extended to incorporate railways in a slot-car fashion.

I've been working at this for years, coming up with designs which cater for most tastes and solve lots of problems for everyone. The problem is, there are entrenched views that anything involving a computer is bad. The electronics guys make what 'sort of works' for them and expect the computer guys to 'fix up' all the timing and hardware problems. The electronics guys resist at all costs, the computer guys trying to get involved to help design in ways that would prevent problems in the first place and result in workable solutions - like having the hardware use a workable messaging interface instead of convoluted bit-stuffing. Very much a 'them and us'.

Look at how easy an ESU Ecos is to use - I believe it runs a form of Linux - that kind of architecture is the way forward.
System designs need to be based around a bus which is extendable. The problem is that the industry is hanging itself on 1980's NMRA DCC which is quite frankly, way past its technological sell-by and tech-debt date.

Above all, there has to be a recognition that the way forward is a merging of hardware and software technologies (not a 'them' and 'us' approach) and a standardisation on modern computer and communications technologies. But it needs to be a team.

Back to the OP, it appears to me that Railmagic (what a toy-like, demeaning name!!) uses some kind of transponder in each loco which seems to be activated by trackside magnets and the base unit detects the magnetic wave disturbances and uses that to feed train control messages back to a DCC command station. That poses the question of what range it has and/or whether it complies with radio interference legislation There is mention in text which talks about setting it up - like some kind of 'tuning'. If it doesn't use a computer, I don't know how its 'computing' capability is provided or controlled (probably just pre-coded hardware) or how it can be configured visually. I didn't see anything about how it avoids collisions either.

Good idea, but I think there are far better ways forward using industry standard technologies that are open to everyone.

I had a look at this and their website.
It appears to me that the way it works involves using magnets to activate a decoder piggy-back component which creates a magnetic 'signal' which the main control box detects and coordinates the location of. The main box then applies some logic to feed decode control requests back to the DCC bus.

I suppose the first question is: how does this magnetic implementation comply with radio/interference legislation ?

There is mention on the website that it uses BEMF but they are creating their own decoder (with no CV's ?) because even top of the line decoders are variable. One only has to look at the configuration of a the motor settings of an ESU decoder to see that this variation in BEMF is not due to the decoder, but due to the whole spectrum of different motors available. Evidently, this mismatch is a weakness of the system.
And then there is the issue of a train-length switched section between two boosters.

I can't honestly see this taking off.

With no disrespect to hardware engineers, to me, it smells of a hardware engineer who has come up with an idea - a single solution to a single problem - without full regard as to how it will integrate with other equipment that people use. It seems to be a closed system. Sorry, but closed system marketing approaches don't work these days - it has to be open and available to other manufacturers.

What all this does highlight to me is why is all this fiddling about and piggy-backing necessary ? It is because the core NMRA DCC bus is 1980's technology which is long since obsolete and needs upgrading with a proper, fully bi-directional high speed bus using a current modern layered computer/phone/network stack. That way, new features are simply new messages sent across the bus and no new hardware every time! The bus and message can't be the same physical thing as they are with NMRA DCC.
We need to move away from this notion that 'computer is bad'. It is the single most reason why your phone is as flexible to use as it is. Viable solutions need to be able to integrate with a computer in order to ease configuration and operation.
The problem is that hardware engineers want to justify their solutions (and protect their own limitations) by creating the notion that computers are bad. A proper solution involves a collaboration of both hardware and computer/software but it has to be properly integrated and designed. Trouble is, some hardware engineers won't step out of their comfort zones and think that 1980's user-interfaces are acceptable! It is far easier to add new features with software than to have to change hardware!

Hmmm. That's interesting and obviously, we are speculating.

If address 8191 is reserved, that poses the question: what is it being used for ? It could be:

• an address being used by their logic box to send messages out onto the DCC bus (most likely, but how would it address individual locos when they all have different addresses ?)
• the address used by their logic box to communicate with a command station (and if so, what does this achieve ?)
• the address used by the 'railcom-ish' feedback system (which would mean all of their on-train sensors would be hard-coded to send Railcom messages on address 8191, presumably with another address embedded in the message for the actual loco ? Using a single address would potentially create a bottleneck)

In all cases though, control and feedback of an individual loco (my understanding) goes back and forth on the address of that loco (Railcom or otherwise), so what is the 8191 being used for ? Surely it can't 'crossover' to control other decoders with different addresses ? Or is it being used to broadcast to every loco ? I doubt it. That would quickly swamp the network with large numbers of locos...unless that's the reason why they limit the number of locos...

Probably need to clear up whether this uses Railcom or not and what address 8191 is actually used for.