ChrisPSR:
If only DCC., & its pwm., worked that way then perhaps the query wouldn't arise.
As far as I know it does. Have you some evidence to the contrary?
leads us right back into basic DCC., operation which is most certainly not for the faint hearted.
I think you are overstating the complexity of DCC. As @TomGeorge says it just broadcasts a number which is the ID of the loco and another number representing the desired speed and direction. The PWM stuff all happens behind the scenes within the loco decoder chips.
Maybe the following question would help to move the project forward ... "If it was easy to use the DCC signal to figure out the speed of a loco would that meet your requirement?"
I know little about model railways but I notice this on the wikipedia site on DCC:
In 2006 Lenz, together with Kühn, Zimo and Tams, started development of an extension to the DCC protocol to allow a feedback channel from decoders to the command station. This feedback channel can typically be used to signal which train occupies a certain section, but as well to inform the command station of the actual speed of an engine. This feedback channel is known under the name Railcom, and was standardized in 2007 as NMRA RP 9.3.1.
It's curious. Given that the DCC protocol (apparently, based on comments here) passes the requested speed to the engine, and the engine (presumably, on those systems that would support Railcom) has speed sensing capability, wouldn't it have made more sense to put the closed loop speed control inside the engine? If DCC actually provides a 'power demand' rather than a 'speed demand' then this would explain why direct speed control isn't currently possible; it would IMO make more sense to repurpose the signal to be a speed demand and just make the engine a little bit smarter. Given the amount of time and effort people put into these installations it strikes me as strange that this hasn't already been done and adopted as a standard, and I can't help thinking that somebody somewhere must have already solved this problem.
PeterH:
It's curious. Given that the DCC protocol (apparently, based on comments here) passes the requested speed to the engine, and the engine (presumably, on those systems that would support Railcom) has speed sensing capability, wouldn't it have made more sense to put the closed loop speed control inside the engine? If DCC actually provides a 'power demand' rather than a 'speed demand' then this would explain why direct speed control isn't currently possible; it would IMO make more sense to repurpose the signal to be a speed demand and just make the engine a little bit smarter. Given the amount of time and effort people put into these installations it strikes me as strange that this hasn't already been done and adopted as a standard, and I can't help thinking that somebody somewhere must have already solved this problem.
The problem is that there's no generic internal way to measure the speed, as the gearing and wheel size for each locomotive is different and some have 5 or 7 pole motors, although most have 3 pole motors. There is a way of measuring the speed of the motor[1] on traditional 12V layouts, by counting the fly-back pulses from the commutator. Even using this method, you can't have more than one loco running at a time, as the pulses will interfere with each other. With DCC, these fly-back pulses are supressed for obvious reasons.
[1] By calculating the number of motor poles, gear ratio, wheel diameter and scale, you can get an approximation of scale speed. This, of course, assumes no slipping or wheel spin. It's more accurate in larger scales (Gauge 0 and above) where the weight of the loco gives better adhesion and less slippage, the accuracy of the wheel diameter measurement is less critical and the scale factor less likely to multiply up any errors.
This method, if I remember correctly, was from a project by MERG in the late 1960s, when I was a member.
PeterH:
wouldn't it have made more sense to put the closed loop speed control inside the engine?
As @Henry_Best has said there are lots of unknown variables that the decoder chip manufacturer can't anticipate.
However most decoder chips have lots of settings that can be adjusted (the DCC fraternity refers to it as programming - but it's not programming in the Arduino sense of the term) and which could be used to "standardize" the response of the locos to the DCC speed command. It wouldn't be accurate in the same way that a feedback system would be, but it would be good enough.
ChrisPSR:
If only DCC., & its pwm., worked that way then perhaps the query wouldn't arise.
As far as I know it does. Have you some evidence to the contrary?
leads us right back into basic DCC., operation which is most certainly not for the faint hearted.
I think you are overstating the complexity of DCC. As @TomGeorge says it just broadcasts a number which is the ID of the loco and another number representing the desired speed and direction. The PWM stuff all happens behind the scenes within the loco decoder chips.*1
Maybe the following question would help to move the project forward ... "If it was easy to use the DCC signal to figure out the speed of a loco would that meet your requirement?"
...R
Many thanks for your input, sure however if it's so easy please, please share the answer. I'd love to know as that was the purpose of this thread.
*1. I wasn't aware that anybody had said otherwise. In fact that has been the main reason for the criticism of many answers where the author was not aware of DCC., operations or the remit.
Chris S.
Robin2:
Maybe the following question would help to move the project forward ... "If it was easy to use the DCC signal to figure out the speed of a loco would that meet your requirement?"
Many thanks for your input, sure however if it's so easy please, please share the answer. I'd love to know as that was the purpose of this thread.
Sorry, I had the impression from earlier posts that you did not want to use the DCC signal. But, if you are prepared to use it we can take the project further in that direction.
In Reply #15 I suggested measuring the speed of each loco with a stop watch (or conceivably with an Arduino and some position detectors on a special part of the track) so that the speed can be related to the speed number being sent to that loco by the DCC signal. Is that a practical proposition for you?
Another option (I think) would be to "program" the DCC chip in each loco so that they would all run at the same speed when sent the same speed number by the controller. If that can be done would it be a better option?
Robin2:
In Reply #15 I suggested measuring the speed of each loco with a stop watch (or conceivably with an Arduino and some position detectors on a special part of the track) so that the speed can be related to the speed number being sent to that loco by the DCC signal. Is that a practical proposition for you?
Another option (I think) would be to "program" the DCC chip in each loco so that they would all run at the same speed when sent the same speed number by the controller. If that can be done would it be a better option?
You'd need to use option 1 (to determine the speed for each DCC setting for each loco) before you could use option 2.
Henry_Best:
The problem is that there's no generic internal way to measure the speed, as the gearing and wheel size for each locomotive is different and some have 5 or 7 pole motors, although most have 3 pole motors. There is a way of measuring the speed of the motor[1] on traditional 12V layouts, by counting the fly-back pulses from the commutator. Even using this method, you can't have more than one loco running at a time, as the pulses will interfere with each other. With DCC, these fly-back pulses are supressed for obvious reasons.
I have assumed that DCC sends a power demand not a speed demand, and that conventional DCC controllers are open loop and just convert the received number to a PWM duty cycle. Is that correct?
It seems to me that any solution providing closed loop speed control will require some way for the engine to measure the wheel speed and I assume you would need to add sensors to do that. That's easy enough to do in electronic terms and the only issue I can see is how difficult the physical packaging would be in a given model. The speed sensing would need to be calibrated to each engine. I suspect that sensing rotations of the wheel itself would be the easiest approach since I guess the rolling radius of the wheels is probably fairly consistent for a given scale and you could probably just select from the standard wheel sizes.
PeterH:
I have assumed that DCC sends a power demand not a speed demand, and that conventional DCC controllers are open loop and just convert the received number to a PWM duty cycle. Is that correct?
It seems to me that any solution providing closed loop speed control ........
I would be very surprised if the OP's requirement needs anything approaching this level of sophistication and it certainly would not justify all the effort involved.
As I said earlier there are options for "tuning" the response of the DCC decoder to suit its own locomotive - but even that may not be necessary if there is a reasonably linear relationship between the speed "number" sent by the DCC controller and the measured speed of the loco. Even if the relationship isn't linear it would be simple to measure the relationship at one or two critical speeds.
The simplest and most accurate solution is to embed detectors under the track and time the passage of the loco from one point to the next.
Somewhat to one side (but not completely off topic) the simple Arduino based non-DCC radio control system that I have developed for my N Gauge trains probably could be easily extended to measure and report motor rpm on OO/HO trains. It might be a physical challenge on N Gauge trains.
Robin2:
I would be very surprised if the OP's requirement needs anything approaching this level of sophistication and it certainly would not justify all the effort involved.
See Reply #14. If there's a need to control the speed, closed loop control is IMO the most sensible way to do that, and implementing the closed loop within the engine itself seems to me like the most capable, scalable and flexible approach. It'd need work, but it strikes me as the most logical way to extend the basic DCC to provide positive speed control if that is what is required.
Robin2: Somewhat to one side (but not completely off topic) the simple Arduino based non-DCC radio control system that I have developed for my N Gauge trains probably could be easily extended to measure and report motor rpm on OO/HO trains. It might be a physical challenge on N Gauge trains.
Or you could model BR Southern Region (or the UndergrounD) which would give you a 3rd (and 4th) rail on which to send and receive speed and other data.
