Joined
·
2 Posts
Has anybody got information about Danish company having invented a system by which a computer knows the exact position of locos. It is called Rail Magic .
Train Magic
1 - 17 of 17 Posts
Do you mean this - Railmagic – Imagine magic
Joined
·
2 Posts
Interesting concept. Likely to be of greatest utility for those with larger layouts where the cost of a conventional section reading approach becomes rather steep in both implementation effort and cost. Will it be unrestrictably scaleable? It might need real care in magnet positioning to avoid aliasing problems is one immediate suspicion I have. Between random bad reads and quasi random movement of magnetic fields - the motors of the locos, ferromagnetic components in moving mechanisms, wheelsets and ballast weights - the magnet placement may well need very careful installation mapping for truly robust performance.
(I have been there many years ago with contactless mapping using RFID, and what looked very promising in principle unfortunately collapsed hopelessly at the scale of the proposed application.)
(I have been there many years ago with contactless mapping using RFID, and what looked very promising in principle unfortunately collapsed hopelessly at the scale of the proposed application.)
There's been discussion of this on a couple of other forums, in particular these
Railmagic - DCC Discussion Topics (not questions) - RMweb
RailMagic Model Railway Digital Control System - Railways of Germany (tapatalk.com)
Railmagic - DCC Discussion Topics (not questions) - RMweb
RailMagic Model Railway Digital Control System - Railways of Germany (tapatalk.com)
Read through the website for this and also the above-mentioned threads with more fascination than real interest. How is it all going to work in the real world? Got to the bit about how the system will handle multiple boosters and quickly came to the conclusion the product is doomed. This is what the website says about multiple power districts:
"In order to ensure that the transfer of responsibility is smooth, the track which connects the two different power districts must be quadruple isolated. This means that a piece of the track longer than the trains must be double isolated in each end. We are going to provide a piece of electronics called the Layouter that will switch the power to the track piece between the two power districts. Until the Layouter becomes available, boosters will not be supported."
So any track crossing two power districts basically needs the equivalent of an auto-reverser with a length of track for your longest train? Totally impractical in my opinion.
"In order to ensure that the transfer of responsibility is smooth, the track which connects the two different power districts must be quadruple isolated. This means that a piece of the track longer than the trains must be double isolated in each end. We are going to provide a piece of electronics called the Layouter that will switch the power to the track piece between the two power districts. Until the Layouter becomes available, boosters will not be supported."
So any track crossing two power districts basically needs the equivalent of an auto-reverser with a length of track for your longest train? Totally impractical in my opinion.
Everything I have read leads me to the perception that the invention is occurring 'on the fly' to deal with the obstacles as they are encountered. If it remains practical with all the obstacles overcome and still offering a simpler route than established 'in section current detection etc.' methods I'll be
And it's a 'one man and his dog' outfit developing it I think? That's an immediate caution if true. One person can get sick, injured, killed; or simply lose interest and move on elsewhere with no notice.
Joined
·
2,536 Posts
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.
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.
Joined
·
2,536 Posts
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!
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!
That's the easy bit - it complies. They are scattering small permanent magnets around a layout. There is no legislation covering that, so its fine. No different to using fixed magnets for uncouplers.
Their loco-mounted detector appears to have a three-axis magnetic sensor in it (not dissimilar to the compass sensor in phones), which can measure the field created by the magnets (which is over the field for the layout room from other magnetic sources, plus the earth's magnetic field).
They then compute something from that field (possibly strength, orientation in three axis) and transmit it back to the base unit over the rails. The base unit knows the magnetic-field reports from each loco for each cluster of magnets, so knows position as a cluster of magnets are passed by a particular loco.
I think its then using back-EMF pulse counting from thereafter to compute position of loco between clusters of magnets (so can't work with a Dyna-drive loco which has a free-wheeling clutch, but there are not many of those around).
The rest, I agree, is unlikely to fly as currently presented.
The booster issue is not the product-killer (though its serious), its the detector piggy-back installation. That makes it impractical for most owners (those who regard plug-in decoders as their technical limit). The maker proposes to build a new DCC decoder, but I can't see how they'll replicate the sound options on ESU and Zimo decoders, so that's a "no sounds" option (or "generic chuffs and grunts"), and another large category of users no longer interested.
- Nigel
Joined
·
2,536 Posts
Thanks for the clarification Nigel.
I guess it remains to be seen how accurate the magnetic proximity detection is and then the subsequent application of BEMF measurement to control motors and the actual positioning of a loco. Given that every motor is different, I would imagine that there must be some sort of tuning and synchronisation process.
Something that isn't clear to me: does this system use Railcom to send the positional information back to the logic box or does the logic box detect 'disturbances in the force' from the magnets ?
Personally, I think more effort should be put on resolving the network stack issues of DCC in order to significantly improve its longevity. It only needs a new feature to come along and everyone is up for hardware changes again, like they were for RailCom. A proper network stack would negate that necessity and facilitate numerous enhancements.
I guess it remains to be seen how accurate the magnetic proximity detection is and then the subsequent application of BEMF measurement to control motors and the actual positioning of a loco. Given that every motor is different, I would imagine that there must be some sort of tuning and synchronisation process.
Something that isn't clear to me: does this system use Railcom to send the positional information back to the logic box or does the logic box detect 'disturbances in the force' from the magnets ?
Personally, I think more effort should be put on resolving the network stack issues of DCC in order to significantly improve its longevity. It only needs a new feature to come along and everyone is up for hardware changes again, like they were for RailCom. A proper network stack would negate that necessity and facilitate numerous enhancements.
First para - don't know how they do it, but assume they are "tuning" things against every loco. Given they measure a loco during a calibration process, assigning a value to BEMF-pulses:distance ratio for each loco would be relatively simple, and thus distance travelled per-loco can be known. (Not fundamentally any different to the speed calibration used in Traincontroller and iTrain, so those software packages can calculate distance travelled beyond spot-detectors).
Second para - no idea what method they're using for back-communication. Something RailCom-ish would seem logical. (If I found a bit of information on which systems did and didn't work reliably with their setup it would give clues about whether its RailCom. ).
There's no way (with the physics I understand) they will be able to detect magnetic issues at the main control box; the magnet detection is only in the device in the loco, which then sends some data back to the main control box about the magnetic field the loco is passing through.
Logically, one would only need a handful (possibly as few as 3 or 4) magnetic field orientations to cover an entire layout because the track (including all turnout positions, which have to be known to their system) also comes into consideration. A loco can only move on the track. From field shape detected as "B", the track will allow the loco to go either forwards to "C" or backwards to "A". Similarly at "C", the loco can go to either "D" or "B", so I could re-use the same magnetic shape as "A" at "D". If I knew the orientation of the loco on the track (probably do from the detected field shape), then the question as to whether the next field from "B" is "A" or "C" is already known; going forwards it must be "C", the only question is when will I get to "C".
I agree with your sentiments over a proper upgrade to a bidirectional stack architecture for "DCC-version-2" or whatever it is to be called. But see no large moves in that direction.
- Nigel
This is what they say in their setup document -
"This system will use the address 8191 for special operations and this address must therefore not be used by any locomotive."
This from the very brief start-up guide, plus there are some videos for calibration and setup here - How-to – Railmagic
Joined
·
2,536 Posts
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:
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.
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.
1 - 17 of 17 Posts
Join the discussion
