The other evening spent whiling away time speed matching my son's CN roster, it occurred to me that some sort of auto speed matching would be really helpful.
What would be neat, is if you could consist a pair of locos, and then put one of the decoders into "learn mode" As you gradually speed up the consist, the decoder in "learn mode" would auto adjust its speed table to match the other locomotive. This would allow perfect speed match throughout the speed table. It would also allow you to quickly speed match locos where you don't just want a linear speed curve.
I suspect that this would be more complex than it appears, which is probably why it has not been done already?
Simon Modelling CB&Q and Wabash See my slowly evolving layout on my picturetrail site http://www.picturetrail.com/simontrains and our videos at http://www.youtube.com/user/MrCrispybake?feature=mhum
Simon, it's a worthy idea in my opinion. 21 years ago I purchased a telescope with a clock drive so that the telescope tube/optical path would counteract the rotation of the Earth on its axis by keeping the tube aligned on a target indefinitely...untl the target fell below the local horizon, that is. The mechanism had a chip that could learn corrections the user could input with a hand-held paddle that gave momentary voltage corrections to the can motor. This was to be done by viewing the target and keeping crosshairs on it. Due to machining errors in both the worm drive and the ring gear, such 'periodic' corrections had to be made for a total of about 20 minutes, or the time it took for the worm to turn completely. If the target began to move ahead of the crosshair intersection, you would press a button and the motor would speed up until the crosshairs were directly over the target once more. If falling behind, another button would reduce voltage to allow the Earth's rotation to catch up to the action of the clock drive. Then, you would press a memory button and the drive would store those corrections and actuate them itself at the appropriate point in the period of the worm.
Something like that could be built into the decoder and stored in files. File 1 would be for MUing to partner engine B, and File 2 for MUing with Engine D. The rest is easy to anticipate.
Crandell
Sounds like a great idea. What if you emailed some of the decoder manufactures about it? That is most likely the best way to make it happen.
sfb
And watch the price of decoder equipped locos go through the roof. Oh, wait. They've already done that. We'll have to buy our locos from Lunar Base 1.
Dr. Frankendiesel aka Scott Running BearSpace Mouse for president!15 year veteran fire fighterCollector of Apple //e'sRunning Bear EnterprisesHistory Channel Club life member.beatus homo qui invenit sapientiam
I guess the only problem with this is how is the loco to determine how fast it is moving? BEMF alone is not enough, you also need to knwo the total gear ratio and driver diameter. If you knew allt hat, it's fairly simple to calculate ground speed based on motor RPM. Some decoders already do this, QSI and MTH for two, so that each speed step corresponds to a set scale MPH. If this feature was built in to all decoders (with and without a 'cruise control' option - so that if you set the loco for 40 smph and then it starts climbing up a steep grade it will slow down) we'd have what was needed - just add CV5 support to reduce the top speed so that if one loco does 70 at full throttle and another does 8- you can slow the 80 mph one down. Instant speed match.
The other way is likely possible today with JMRI but requires some pretty complex scripts. As far as I know, you cna do anything in a JMRI script, including sending programmign commands. So you would need a continuous track loop and some sort of measured distance for speed calculations - either detected blocks with space between them or a device liek the TDP speedometer. The script would take the addresses of the two locos, and start one at a low speed step and check the trap speed, then as the second loco went through it would adjust the first step of the speed table so they match. Then the second - until after 28 laps, all steps in the speed table are set to match the 'master' loco. I'm pretty sure this is doable today, if anyone has the jscript programmign skills needed. All that's required are decoders that support 28 step speed tables, no new decoder design.
--Randy
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.
QSI's regulated throttle control is pretty close to what you describe. If you consist 3 loco's and one is faster than the other 2, the trio will learn each other and steady out with no bouncing that you get on other decoders. I do it all the time and it works great.
Springfield PA
It seems TCS's self adjusting BEMF does a little of this. I consisted my Stewart FT A with a TCS decoder and the B unit with a Tsunami by givning them the same address (drawbar connected - you can't put a coupler on these if you wanted to, without a lot of hacking) and they run quite well together with no adjustments to speed tables or anything.
I ran a pair of my GP7's, both with TCS T1 decoders, for many hours this past week, although I would expect them to run well together with no tweaking - they are the same model produced around the same time and differ only in road number. Both had the gears replaced with AThearn since it was only a matter of time until an axle gear cracked. I just swapped them all out as a preventative measure. They ran solid with a fairly heavy train about 4 hours each day from wednesday til monday.
rrinker The other way is likely possible today with JMRI but requires some pretty complex scripts. As far as I know, you cna do anything in a JMRI script, including sending programmign commands. So you would need a continuous track loop and some sort of measured distance for speed calculations - either detected blocks with space between them or a device liek the TDP speedometer. The script would take the addresses of the two locos, and start one at a low speed step and check the trap speed, then as the second loco went through it would adjust the first step of the speed table so they match. Then the second - until after 28 laps, all steps in the speed table are set to match the 'master' loco. I'm pretty sure this is doable today, if anyone has the jscript programmign skills needed. All that's required are decoders that support 28 step speed tables, no new decoder design. --Randy
Randy,
There is already a JMRI script available although it does have some limitations. It's located in the file section of the users group:
http://groups.yahoo.com/group/jmriusers/files/Script%20examples/Speed%20Table%20Script%202.14.txt
Peter
I want a DCC system that you dont have to put Decoders in the locomotives,and wireless at that.
Russell
If someone came up with a setup that measured the push/pull between two loco's...maybe a load cell or something that could give feedback to see which way you needed to adjust. You could speed step the master loco and adjust the other loco to match. Even better yet it would do it through JRMI automatically.